La sorprendente verdad sobre la transformación digital: el caos en la nube

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Esta es la segunda entrada de una serie sobre los retos derivados de la transformación digital.

• La sorprendente verdad sobre la transformación digital

Caos en la nube.

Algún ingeniero avispado estará señalando ahora mismo que esta expresión es redundante. Al fin y al cabo, la nube es un caos, dada su falta de gobernanza y su enfoque de laissez-faire a la hora de proteger las aplicaciones arrojadas a sus esponjosas profundidades blancas sin una planificación bien definida.

Hagamos aquí una pausa para señalar que el caos asociado a la nube suele ser un problema de personas y procesos y no un problema técnico.

Eso no quiere decir que no haya desafíos técnicos —o, al menos, arquitectónicos— asociados a la nube. Algunos están relacionados con la complejidad de las redes virtuales. Pero la mayoría son de carácter arquitectónico. Uno de esos desafíos arquitectónicos está relacionado con la propia naturaleza de la nube y su enfoque específico para cada aplicación.

Si lo pensamos bien, 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 principios y presentar las mismas características.

Eso implica API y aprovisionamiento de autoservicio. Paneles de control y consolas web. Pero también supone un cambio arquitectónico hacia un despliegue centrado exclusivamente en una única aplicación.

Las arquitecturas específicas para cada aplicación son la norma en la nube. Los servicios se implementan y configuran para admitir una aplicación a la vez y crear una única ruta de datos entre el usuario y el punto final que atraviesa dichos servicios. Esto contrasta claramente con el diseño tradicional de las redes de centros de datos, en el que se comparte una parte significativa de la infraestructura de red y de servicios de aplicaciones.

Es el concepto de «infraestructura compartida» el que plantea dificultades en un entorno de desarrollo DevOps y Agile tan centrado en cada aplicación como la nube pública.

Las redes tradicionales de infraestructura compartida dan lugar a «una única ruta válida desde la puerta de entrada hasta la aplicación». Los retos que plantea este enfoque en el vertiginoso mundo digital actual son:

• Alineación de versiones de la infraestructura. Una aplicación puede necesitar funciones proporcionadas por una actualización o un parche, mientras que otra depende de la versión existente. Por lo general, la infraestructura compartida no permite utilizar distintas versiones en un mismo sistema, por lo que puede perjudicar a una aplicación para favorecer a otra.
• Calendarios de despliegue incompatibles. Cuando los recursos compartidos se ven afectados, las empresas inician una fase de negociación en la que las partes interesadas de las aplicaciones intentan resolver los conflictos entre los calendarios de despliegue. El proceso puede ser largo (y siempre resulta complicado), y nadie sale ganando cuando una nueva aplicación o actualización se retrasa debido a conflictos de programación.
• Radio de impacto. No hace falta decir que, si mi aplicación provoca el fallo de un sistema compartido, todas las aplicaciones que dependen de él también fallarán. El radio de impacto de una infraestructura compartida es enorme y constituye un factor importante en la reticencia a facilitar un mayor acceso al proceso de despliegue a quienes no pertenecen al departamento de TI.
• Resolución de problemas. Intentar rebuscar entre registros agregados es una tarea ardua. Se han creado empresas de gran éxito basándose únicamente en la capacidad de analizar registros masivos y desglosar los datos en flujos por aplicación. Resolver problemas en sistemas compartidos es complicado y requiere mucho tiempo, además de repercutir negativamente en el tiempo medio de resolución, un KPI fundamental para las TI modernas.

En la nube, nada de esto suele suponer un problema. Hay una ruta por aplicación, ya que las aplicaciones suelen desplegarse según su propia planificación y en su propio entorno, a menudo por equipos diferentes.

Para conservar la cordura (y nuestro centro de datos), debemos adoptar este enfoque en nuestras propias instalaciones, ya sea en una nube privada o no.

Seguirá habiendo servicios de red compartidos. Los cortafuegos, los sistemas IPS/IDS, la protección contra ataques DDoS y la inspección de usuarios son, en gran medida, independientes de las aplicaciones y pueden (y deben) implantarse en toda la empresa. Para todo lo demás, existen servicios e infraestructuras específicos para cada aplicación. Esta separación lógica preserva la estabilidad y la seguridad de la empresa, al tiempo que permite disponer de un entorno más dinámico y quizá inestable en las capas más próximas a las aplicaciones. También mantiene una ruta de datos para las aplicaciones tradicionales (heredadas y antiguas) que no requieren la velocidad ni el soporte que necesitan las aplicaciones más recientes. La red específica de cada aplicación podría ser una nube privada, varios clústeres de contenedores o una combinación de ambos.

La combinación de ambos dará lugar a una red más estable y resiliente, que además será flexible y rápida.

Un enfoque de red específico para cada aplicación ofrece diversas ventajas, además de mitigar los problemas derivados de un enfoque compartido combinado con arquitecturas de aplicaciones y modelos de entrega modernos:

• Canalizaciones y calendarios independientes. Puedo programar mis propios despliegues cuando estén listos, ya que no afectan a ninguna aplicación ni infraestructura salvo a las mías. Esto ofrece la flexibilidad necesaria para adaptarse a los distintos calendarios que hay que gestionar en un centro de datos moderno.
• Radio de impacto limitado. Si mi despliegue provoca un fallo en mis sistemas dedicados, la responsabilidad es exclusivamente mía. No afecta a ninguna otra aplicación. Este enfoque de ruta de datos dedicada para cada aplicación también facilita la resolución de problemas, ya que puedo tener la certeza de que los registros y mensajes de error de todos los sistemas corresponden a mi aplicación.
• El escalado no está limitado por los recursos de la plataforma. En un mundo sumamente volátil y dinámico, es prácticamente imposible saber cuándo se producirá la próxima avalancha de visitantes, si algún contenido se hará viral o si, Dios no lo quiera, se está sufriendo un ataque. Sea cual sea la causa, cuando se dispara la demanda de aplicaciones en sistemas compartidos (de hardware o software), el escalado queda limitado a los recursos disponibles en la plataforma. El uso de una arquitectura específica para cada aplicación mitiga esta limitación y permite escalar horizontalmente los componentes individuales según sea necesario para satisfacer la demanda.
• Admite un verdadero modelo de infraestructura como código. Los sistemas compartidos utilizan configuraciones compartidas, aunque solo se trate de una configuración básica con políticas específicas para cada aplicación. Este modelo puede generar 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 operaciones de confirmación y clonación pueden fallar porque otros usuarios bloquean los recursos cuando se necesitan. Una arquitectura por aplicación garantiza que los artefactos de despliegue pertenezcan a una sola aplicación y que sus propietarios puedan gestionarlos correctamente (ya sean desarrolladores, equipos de DevOps, NetOps u otros).

Aunque una arquitectura por aplicación no resolverá todos los problemas derivados de la transformación digital, puede contribuir en gran medida a controlar el caos generado por la nube. Ofrece mayores oportunidades para estandarizar la seguridad y para dar soporte a los entornos multinube hacia los que están evolucionando la mayoría de las empresas.

No te pierdas la próxima publicación de esta serie, en la que analizaremos en profundidad cómo abordar los casos en los que se omite la seguridad debido a las presiones por acelerar la salida al mercado derivadas de la transformación digital.

Sobre el autor

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.

Más artículos de Lori Mac Vittie