La sorprendente verdad sobre la transformación digital: Caos en las nubes
Este es el segundo blog de una serie sobre los desafíos que surgen de la transformación digital.
Caos en las nubes.
Algún ingeniero inteligente está comentando ahora que esta frase es redundante. Después de todo, la nube es un caos, con su falta de gobernanza y su enfoque laissez-faire para proteger las aplicaciones arrojadas a sus suaves profundidades blancas sin un cronograma bien definido.
Detengámonos aquí para señalar que el caos asociado con la nube es, en la mayoría de los casos, un problema de personas y procesos , no técnico.
Eso no quiere decir que no existan desafíos técnicos (o al menos arquitectónicos) asociados con la nube. Algunos de ellos están relacionados con las complejidades de las redes virtuales. Pero la mayoría son arquitectónicas. Uno de esos desafíos arquitectónicos está relacionado con la naturaleza misma de la nube y su enfoque en cada aplicación.
Si lo piensas, la nube pública y su modelo de implementación se consideran la forma ideal de nube (la "forma de nube", como la llamarían los platónicos ). Esto significa que la nube privada también debería seguir sus preceptos y exhibir las mismas características.
Esto significa API y aprovisionamiento de autoservicio. Paneles de control y consolas basadas en web. Pero también significa un cambio arquitectónico hacia una implementación enfocada puramente en una sola aplicação.
Las arquitecturas por aplicación son la norma en la nube. Los servicios se implementan y configuran para admitir una aplicación a la vez y crean una ruta de datos única desde el usuario hasta el punto final que atraviesa esos servicios. Esto contrasta marcadamente con el diseño de red de centro de datos tradicional en el que se comparte una cantidad significativa de infraestructura de servicios de aplicação y redes.
Es el concepto de “infraestructura compartida” el que se vuelve desafiante en un mundo de desarrollo DevOps y Agile que está tan centrado en cada aplicación como la nube pública.
La infraestructura y las redes tradicionales compartidas dan como resultado “una ruta verdadera desde la puerta hasta la aplicación”. Los desafíos que surgen de este enfoque en el acelerado mundo digital de hoy son:
- Alineación de versiones de infraestructura. Una aplicación puede requerir funciones proporcionadas por una actualización o parche, mientras que otra depende de la versión existente. La infraestructura compartida generalmente no permite diversidad de versiones en el mismo sistema y por lo tanto puede obstaculizar una aplicação para favorecer a otra.
- Programaciones de implementación conflictivas. Cuando los recursos compartidos se ven afectados, las empresas comienzan una fase de negociación en la que las partes interesadas de la aplicação intentan resolver los conflictos en los cronogramas de implementación. El proceso puede ser largo (y siempre doloroso) y nadie gana cuando una nueva aplicación o actualización se retrasa debido a conflictos de programación.
- Radio de explosión. No hace falta decir que si mi aplicación provoca un fallo en un sistema compartido, todas las aplicaciones que dependen de ese sistema fallan. El radio de acción de la infraestructura compartida es enorme, y constituye un factor importante en la renuencia a brindar mayor acceso al proceso de implementación a quienes están fuera del área de TI.
- Solución de problemas. Intentar hurgar entre troncos acumulados es doloroso. Empresas muy exitosas se han construido basándose únicamente en la capacidad de extraer registros masivos y desagregar los datos en flujos por aplicación. La resolución de problemas en sistemas compartidos es complicada, requiere mucho tiempo y tiene un impacto negativo en el tiempo medio de resolución, un KPI fundamental para la TI moderna.
En la nube, nada de esto suele ser un problema. Hay una ruta por aplicación, porque las aplicaciones generalmente se implementan según su propio cronograma y en su propio entorno, a menudo por equipos diferentes.
Para salvar nuestra cordura (y nuestro centro de datos), debemos adoptar este enfoque en nuestras instalaciones, ya sea en una nube privada o no.
Seguirás teniendo servicios de red compartidos. Los firewalls, IPS/IDS, DDoS y la inspección de usuarios son muy neutrales con respecto a las aplicações y pueden (y deben) aplicarse a nivel corporativo. Para todo lo demás, existen servicios e infraestructura por aplicación (específicos de cada aplicación, si lo prefieres). Esta separación lógica preserva la estabilidad y la seguridad del negocio al tiempo que permite un entorno más volátil y quizás inestable más cercano a las aplicaciones. También conserva una ruta de datos para aplicaciones tradicionales (heredadas y heredadas) que no requieren el tipo de velocidad y soporte necesario para aplicaciones más nuevas. La red por aplicación podría ser una nube privada, múltiples clústeres de contenedores o alguna combinación de ambos.
La unión de ambos dará como resultado una red más estable y resistente que también sea flexible y rápida.
Un enfoque por aplicación para la red tiene una variedad de beneficios además de mitigar los problemas que surgen de un enfoque compartido junto con arquitecturas de aplicaciones modernas y modelos de entrega:
- Tuberías y horarios individuales. Puedo programar mis propias implementaciones cuando estén listas porque no afectan a ninguna aplicación o infraestructura excepto a la mía. Esto ofrece flexibilidad para soportar los diversos cronogramas que debe respaldar en un centro de datos moderno.
- Radio de explosión restringido. Si mi implementación provoca un bloqueo en mis sistemas dedicados, será toda mi responsabilidad. No afecta a ninguna otra aplicación. Este enfoque de ruta de datos dedicada para cada aplicación facilita aún más la resolución de problemas, ya que puedo estar seguro de que los registros y los mensajes de error de todos los sistemas me pertenecen a mí y a mi aplicação.
- La escala no está restringida a los recursos de la plataforma. En un mundo altamente volátil y dinámico, es casi imposible saber cuándo llegará la próxima oleada de visitantes o si algún contenido se volverá viral o, Dios no lo quiera, si sufrirás un ataque. Cualquiera sea la causa, cuando aumenta la demanda de aplicaciones en sistemas compartidos (hardware o software), la escala se limita a los recursos disponibles en la plataforma. El uso de una arquitectura por aplicación mitiga esta restricción y permite que los componentes individuales se escalen según sea necesario para satisfacer la demanda.
- Admite un verdadero modelo de infraestructura como código. Los sistemas compartidos utilizan configuraciones compartidas, incluso si se trata solo de una configuración base con políticas por aplicación. Ese modelo puede causar caos al intentar implementar un modelo de infraestructura como código , especialmente cuando varias aplicaciones intentan actualizarse al mismo tiempo. Los cambios pueden afectar a otras aplicaciones sin previo aviso, o las acciones de confirmación y clonación pueden fallar debido a que otros bloquean recursos cuando los necesita. Una arquitectura por aplicación garantiza que los artefactos de implementación pertenezcan a una sola aplicación y que los propietarios de la aplicación (ya sea desarrolladores, DevOps, NetOps o ) puedan administrarlos adecuadamente.
Si bien una arquitectura por aplicación no resolverá todos los problemas que surgen de la transformación digital, puede contribuir en gran medida a controlar el caos que surge de la nube. Ofrece mayores oportunidades para estandarizar la seguridad, además de dar soporte a los entornos multi-nube en los que se están convirtiendo la mayoría de las empresas.
Manténgase atento a la próxima publicación de esta serie, en la que analizaremos en profundidad cómo puede lidiar con aquellos que se saltan la seguridad debido a las presiones de salida al mercado que surgen de la transformación digital.