Foco en el código abierto: Infraestructura como Código de F5 y gestión multicloud
Es posible que hayas notado que un tema importante detrás del mantra de las nubes múltiples es la manejabilidad. Esto se debe a que la tarea de escalar, proteger y entregar aplicaciones a los usuarios requiere un determinado conjunto de servicios: balanceadores de carga, computación, almacenamiento y seguridad de las aplicaciones. Y aunque la nube puede (y lo hace) facilitar mucho el proceso de provisión de dichos servicios, lo hace en detrimento de las operaciones. Lamentablemente, esto traslada la complejidad a otra parte.
Si eres tú quien proporciona esos servicios, todo está bien. Pero si eres tú quien tiene que configurar, ajustar y administrar los servicios, no es tan bueno.
Porque la complejidad hace más difícil la gestión. No hay dos nubes iguales (en términos de API y servicios) y eso a menudo significa dos modelos operativos completamente separados con los que ahora la gente tiene que lidiar.
Por lo tanto, la capacidad de gestión es un factor importante para que la multicloud sea exitosa.
Una de las formas en que las organizaciones pueden lograrlo es adoptar estructuras que simplifiquen las implementaciones. Estos se presentan cada vez más en forma de algún tipo de plantilla: OpenStack Me vienen a la mente HEAT, AWS Cloud Formation y Azure ARM. Estas plantillas codifican la mayor parte de una implementación de BIG-IP en términos de la configuración específica que debe existir para aprovechar el valor real de BIG-IP: sus servicios.
Las plantillas son uno de los mejores ejemplos de infraestructura como código (IAC). Esto se debe a que pueden tratarse exactamente como artefactos de código. Se pueden versionar, ramificar, fusionar, recuperar, clonar y, en última instancia, implementar.
Este modelo se adapta bien a la visión de la nube orientada a DevOps y a su gestión a través de API y lenguajes de scripting. Después de todo, si DevOps puede extender su influencia a NetOps y, a su vez, pueden implementar rápidamente servicios utilizando un enfoque IAC, todos están contentos. Es justo lo que recetó el médico, considerando que la falta de dichos servicios por parte de NetOps influye significativamente en las decisiones de DevOps de eludir a TI cuando se trata de la nube.
Apoyar la capacidad de administración de múltiples nubes es exactamente lo que nosotros (la empresa actual) imaginamos cuando comenzamos a desarrollar plantillas para OpenStack, AWS y Azure. Para permitir un enfoque IAC que proporcione mayor agilidad y velocidad, estas plantillas están disponibles gratuitamente a través de GitHub.
Porque nuestras implementaciones de laboratorio no son sus implementaciones, ni tampoco son las de ese otro sujeto (en la fila detrás de usted, leyendo por encima de su hombro). Las implementaciones comparten un conjunto común de características, pero todas las aplicaciones tienen necesidades específicas que no pueden satisfacerse con la misma configuración de servicio mercantilizado. El equilibrio de carga round robin puede ser suficientemente bueno para aplicaciones sin estado basadas en microservicios, pero puede ser terriblemente ineficiente (sin mencionar costoso) para otras arquitecturas de aplicação , particularmente en entornos de nube. Necesita la libertad de adaptar y optimizar el rendimiento de la aplicación y garantizar la seguridad de los datos y la protección de las interacciones del usuario.
Debe poder extraer, clonar y confirmar esos artefactos en sus propios repositorios para poder aprovechar los beneficios de un enfoque de NetOps que incluye IAC para implementar la mayor parte posible de su base de servicios en la mayor cantidad posible de entornos de nube.
Así que extrae, clona, confirma e implementa según tu cronograma, ya sea tres veces al día o tres veces al trimestre. Es de código abierto y siempre está abierto al acceso.