¿Qué es la infraestructura como código para NetOps?
A medida que los enfoques de DevOps se introducen en las operaciones de red, arrastran consigo una nueva terminología. Estos coloquialismos pueden resultar confusos para los NetOps que no los han experimentado antes, y pueden confundir a los ejecutivos de TI que están siendo presionados para adoptar la metodología.
Entre ellos se encuentra el concepto de infraestructura como código. En el mundo de los desarrolladores, la infraestructura son principalmente las plataformas, servidores y sistemas de contenedores en los que se implementan las aplicaciones y en los que se escalan. La infraestructura es fundamentalmente informática.
Al otro lado del muro existe un conjunto de infraestructura más amplio y robusto que abarca el almacenamiento, la seguridad y la red, además de la computación. Después de todo, hay cuatro operaciones y todas deben funcionar en sincronía para lograr una implementación continua y permitir el tipo de optimización que los líderes de TI y de negocios buscan en la transformación digital. Esto significa que la infraestructura como código incluye una gama mucho más amplia de sistemas, dispositivos y servicios en producción que en desarrollo. La implementación de una aplicación generalmente significa que la infraestructura en cada una de las cuatro operaciones se verá afectada de alguna manera. Esto hace que la infraestructura como código en producción sea un poco más complicada, pero también tiene un mayor impacto en la eficiencia y la velocidad.
Esto se debe a que la automatización puede eliminar los tiempos de espera entre entregas que a menudo son la fuente de ineficiencias en las implementaciones, en particular cuando los procesos manuales entran en conflicto con las vacaciones, los días de enfermedad y las horas de almuerzo.
ES UN SÍMIL
Infraestructura como código es un símil, lo que significa que en realidad no queremos (al menos no ahora) convertir nuestros sistemas de red y servicios de aplicação en código que construimos y luego implementamos. Eso sería una locura para la mayoría de las organizaciones empresariales y perturbaría la estabilidad y fiabilidad de la red corporativa. Pero sí queremos aprovechar los beneficios de un sistema que desacopla la configuración y los perfiles de los sistemas en los que se ejecutan.
Esto significa separar las configuraciones, políticas y perfiles del hardware o software en el que están implementados.
Esta colección es la que luego se considera “artefactos de implementación” y puede tratarse como si fuera código. Esto significa que pueden almacenarse y gestionarse en repositorios, versionarse y revisarse. Se pueden extraer, clonar y confirmar de la misma manera que un desarrollador extrae, clona y confirma código hacia y desde un repositorio (como Github).
También deberíamos incluir “artefactos de automatización”. Estos son los scripts y archivos asociados que describen las tareas de automatización que acompañan a su kit de herramientas de automatización de elección. Si eso es Ansible, son playbooks. Si es Chef, es una receta. Para Puppet, un manifiesto. O tal vez simplemente sea un viejo script de Python.
Para BIG-IP y un número cada vez mayor de sistemas alojados en red, esto también incluye plantillas (iApp) que pueden describir con más detalle configuraciones más complejas o estandarizadas. El uso de una plantilla puede ser ventajoso en este caso porque puede admitir opciones y servicios de aplicação que quizás aún no sean compatibles con el conjunto de herramientas principal.
Junto con los artefactos de implementación, los artefactos de automatización forman la colección que llamamos “infraestructura como código”. Se supone que puede aprovisionar un sistema y posteriormente ejecutar un proceso de automatización en él para configurarlo como desee.
Cuando se combina con un enfoque por aplicación para los servicios de red y aplicação , un enfoque de infraestructura como código puede mitigar drásticamente el riesgo de implementaciones frecuentes. Al aislar las configuraciones y limitar su impacto a un solo sistema, se elimina prácticamente el impacto de una implementación que sale mal. Esto, a su vez, fomenta programaciones por aplicación que se alinean mejor con las necesidades del negocio y las demandas de los usuarios.
Para las organizaciones que priorizan la nube, adoptar un enfoque de infraestructura como código puede reducir la fricción que implica migrar del centro de datos a la nube, o de nube a nube. Dado que la configuración está desacoplada del sistema, es posible implementarla en un sistema similar en otro lugar.
Hay muchas buenas razones para emprender el esfuerzo de migrar a un enfoque de infraestructura como código, y muy pocas buenas razones para no hacerlo. La infraestructura como código es una de las formas más ventajosas de hacer realidad la red ágil que las organizaciones necesitan para tener éxito en una economía digital impulsada por aplicaciones y múltiples nubes.