La brecha más grande que he visto es el cambio fundamental en el pensamiento de las operaciones de TI tradicionales hacia las nuevas metodologías que la computación en la nube puede permitir. Estoy hablando de DevOps, desarrollo de software ágil, integración / entrega continua, etc.
Muchas organizaciones todavía tratan la nube como un servicio de “virtualización alojada” y generalmente lo quieren porque ya han virtualizado su infraestructura internamente y están buscando externalizar (o simplemente quieren servidores más baratos). Instanciarán un puñado de máquinas virtuales, instalarán su software y simplemente los dejarán correr. Si las cosas comienzan a funcionar lentamente, crearán una instancia de una nueva VM más grande (más memoria, más vCPU, etc.), planificarán un tiempo de inactividad, migrarán datos y terminarán. O si son un poco más sofisticados y utilizan un proveedor de servicios que admite sus herramientas, utilizarán algún software empresarial para migrar la VM (“¡mira qué flexibles somos!”).
Si la VM se golpea con el tráfico o sufre una interrupción, el departamento de TI toma sus grumos, escribe una autopsia y luego compra equilibradores de carga caros y más VM, diseña cuidadosamente una arquitectura que todavía se ve como el mismo diseño de 1997, y lo hace todo de nuevo.
- ¿Qué tan confiable es la nueva aventura de Kim DotCom Mega?
- ¿Cómo se relaciona la virtualización de funciones de red con las infraestructuras en la nube? ¿Cuáles son las preguntas de investigación más importantes para el NFV en la nube?
- ¿Firebase es de código abierto?
- ¿Cómo funcionan las licencias para tecnologías propietarias en la nube?
- ¿Es una buena idea que los más nuevos vayan con la computación en la nube de AWS?
También ejecutan máquinas virtuales muy por debajo de su capacidad real, ya que así es como siempre han ejecutado sus servidores. Con el hardware tradicional en las instalaciones, los conserva durante más de 3 años, ¿verdad? Por lo tanto, especifique en exceso ahora para que tenga espacio para crecer.
Las aplicaciones nativas de la nube, por otro lado, tienden a tratar las máquinas virtuales como efímeras … es decir, temporales y desechables. Los enciende cuando lo necesita y luego los apaga nuevamente cuando haya terminado. Pero para hacer esto, debe dejar de hacer las cosas a la antigua usanza. En lugar de los instaladores .iso, utiliza imágenes preconstruidas y scripts de implementación o herramientas de administración de configuración. Utilice herramientas de línea de comandos o interfaces de portal. Ahora puede aprovisionar cualquier número de servidores en minutos.
Las aplicaciones nativas de la nube también tratarán el almacenamiento de manera diferente. Tradicionalmente, instala la aplicación y los datos de almacenamiento en los discos adjuntos. Quizás use un dispositivo SAN o NAS para “centralizar” el almacenamiento, pero todo actúa como si fuera un disco local. Cuando necesite implementar 100 servidores web idénticos en cuestión de minutos, no desea copiar más de 100 GB de almacenamiento en cada uno, ni desea un aumento repentino de la sobrecarga en su SAN / NAS tradicional. Por lo tanto, el almacenamiento se abstrae del servidor local y se traslada a algo más centralizado y escalable como el almacenamiento de objetos. Las bases de datos también pueden construirse de manera diferente. En lugar de usar una base de datos relacional tradicional con datos altamente consistentes pero más lentos bajo una carga pesada, podrían adoptar una o más bases de datos NoSQL que estén específicamente diseñadas para cumplir con un caso de uso específico dentro de la aplicación más grande. Pero esto afecta el diseño y rara vez es una tarea simple.
Muchas aplicaciones comerciales tradicionales simplemente no se han adaptado para usar estas nuevas tecnologías. Pueden funcionar “en la nube” (es decir, virtualización administrada), pero aún confían en los viejos marcos de diseño del servidor en el modelo de arquitectura escalonada. Esta desconexión entre el diseño empresarial tradicional “en las instalaciones” y la nueva generación de aplicaciones nativas de la nube es la razón por la cual existe esta brecha de competencia.
Espero que la generación actual de desarrolladores nativos de la nube que trabajan para nuevas empresas sea absorbida por compañías más grandes y tradicionales y desplacen a la vieja guardia que no se ha adaptado. A medida que esto suceda, la brecha de competencia se volverá cada vez más estrecha y finalmente se cerrará.
Al menos hasta que ocurra la próxima interrupción, creando una nueva brecha de competencia …
