NetOps debe ser ágil porque la nube puede cambiar de la noche a la mañana
NetOps necesita adoptar las metodologías y los principios de DevOps para restablecer el equilibrio entre estabilidad y velocidad para soportar el creciente número de aplicações implementadas en la nube pública.
Existe la creencia de este lado (el lado de la red) de que los equipos que adoptan DevOps han sacrificado estabilidad y seguridad por velocidad.
En muchos casos esto es absolutamente cierto. ¿Recuerdas esta joya de Arxan e IBM sobre la seguridad de la IoT y las aplicações móviles? En él, supimos que la mayoría de los encuestados citaron la “prisa por lanzar” como la principal razón por la que se lanzan aplicações que contienen código vulnerable. La velocidad supera a la seguridad y a la estabilidad.
En cuanto a la estabilidad, hay menos datos cuantificables pero sí una gran cantidad de evidencia anecdótica. Lo más notable es la respuesta frenética de los socios de la nube cuando “la nube” cambia de la noche a la mañana.
No se lo dice a nadie. Alguien simplemente se da cuenta de que algo se ha roto. Se investiga y, invariablemente, la causa es un cambio en la infraestructura subyacente. Un cambio que sin duda fue beneficioso para el proveedor y quizás incluso para los clientes, pero que resultó en la ruptura de muchas soluciones que dependen de esa infraestructura.
NO TIENES CONTROL SOBRE LA NUBE PÚBLICA.
Tal vez debería comenzar una lista de “reglas para la nube” con esa como Regla Cero, porque es fundamental para su salud mental y para la forma en que aborda la adopción de la nube.
La infraestructura de la nube no es tuya. Tú no lo controlas, no puedes cambiarlo, pero el proveedor sin duda puede (y lo hace). Si aborda la nube con la misma mentalidad que utiliza la infraestructura de su centro de datos corporativo, será miserable.
Todo lo que puedes hacer es reaccionar a esos cambios. Y una de las metodologías DevOps que puede ayudarle a reaccionar de manera oportuna es la infraestructura como código. Recuerde, la infraestructura como código es un símil: significa tratar las configuraciones, plantillas y scripts que implementan, aprovisionan y administran la infraestructura como código .
La clave para ello es la adopción de un modelo declarativo de implementación, es decir, el uso de plantillas cuando sea posible para describir lo que se desea que haga la infraestructura, no cómo debería hacerlo.
El uso de un modelo declarativo permite una mayor agilidad (velocidad de reacción) ante cambios inesperados (pero no sorprendentes) en la infraestructura de la nube. Sí, se romperán. Pero podrás adaptarte más rápidamente porque solo necesitas abordar los cambios en una plantilla central (compartida) para corregirlos.
No necesitarás modificar el código en sí, ni tampoco revisar y hacer cambios en las configuraciones existentes (como aplicar parches, solo que más aterrador). Puede modificar, probar y volver a implementar una plantilla mucho más rápido que modificando el código o los instaladores o la "guía de instalación" heredada en un PDF.
La nube va a cambiar y usted tendrá que reaccionar. Necesitarás ser ágil y seguir sus principios para abordar rápidamente los cambios que no puedes controlar.
Un enfoque ágil combinado con un modelo declarativo para la infraestructura en la nube pública es la mejor manera de restaurar la estabilidad de las aplicações sin sacrificar la velocidad.