A medida que los enfoques de DevOps traspasan la barrera y se adentran en las operaciones de red, traen consigo nueva terminología. Estos coloquialismos pueden resultar confusos para los equipos de NetOps que no los hayan encontrado antes y desconcertar a los responsables de TI que se ven presionados para adoptar esta metodología.
Entre ellos se encuentra el concepto de infraestructura como código. En el mundo de los desarrolladores, la infraestructura está formada principalmente por las plataformas, los servidores y los sistemas de contenedores en los que se despliegan y escalan las aplicaciones. La infraestructura consiste principalmente en recursos de computación.
Al otro lado del muro existe un conjunto de infraestructuras más amplio y robusto que, además de la computación, abarca el almacenamiento, la seguridad y las redes. Al fin y al cabo, hay cuatro áreas operativas, y todas deben funcionar de forma sincronizada para lograr el despliegue continuo y posibilitar el tipo de optimización que los responsables de TI y de negocio esperan obtener de la transformación digital. Esto significa que, en producción, la infraestructura como código engloba una gama mucho más amplia de sistemas, dispositivos y servicios que en desarrollo. Por lo general, el despliegue de una aplicación implica intervenir de algún modo en la infraestructura de cada una de las cuatro áreas operativas. Esto hace que la infraestructura como código en producción sea algo más compleja, pero también que tenga un mayor impacto en la eficiencia y la velocidad.
Esto se debe a que la automatización puede eliminar los tiempos de espera entre traspasos, que con demasiada frecuencia son la causa de ineficiencias en los despliegues, especialmente cuando los procesos manuales se ven afectados por las vacaciones, las bajas por enfermedad y las pausas para comer.
ES UN SÍMIL
La infraestructura como código es un símil, lo que significa que en realidad no queremos (al menos por ahora) convertir nuestros sistemas de red y de servicios de aplicaciones en código que compilamos y después desplegamos. Para la mayoría de las organizaciones empresariales, eso sería una locura y alteraría la estabilidad y la fiabilidad de la red corporativa. Sin embargo, sí queremos aprovechar las ventajas de un sistema que desacople la configuración y los perfiles de los sistemas en los que se ejecutan.
Eso significa separar las configuraciones, las políticas y los perfiles del hardware o software en el que se implementan.
Es este conjunto el que se considera «artefactos de despliegue» y puede tratarse como si fuera código. Esto significa que puede almacenarse y gestionarse en repositorios, someterse a control de versiones y revisarse. Los artefactos pueden descargarse, clonarse y confirmarse del mismo modo que un desarrollador descarga, clona y confirma código desde y hacia un repositorio (como Github).
También deberíamos incluir los «artefactos de automatización». Se trata de los scripts y archivos asociados que describen las tareas de automatización correspondientes al conjunto de herramientas de automatización que elijamos. En Ansible, son los playbooks; en Chef, las recetas; y en Puppet, los manifiestos. O podría tratarse simplemente de un script de Python de toda la vida.
Para BIG-IP y un número cada vez mayor de sistemas alojados en la red, esto también incluye plantillas (iApp) que pueden describir con más detalle configuraciones más complejas o estandarizadas. En este caso, usar una plantilla puede resultar ventajoso, ya que permite utilizar opciones y servicios de aplicaciones que quizá aún no sean compatibles con el conjunto de herramientas principal.
Junto con los artefactos de despliegue, los artefactos de automatización conforman el conjunto que denominamos «infraestructura como código». Se presupone que puede aprovisionar un sistema y, posteriormente, ejecutar en él un proceso de automatización para configurarlo según sus necesidades.
Cuando se combina con un enfoque específico para cada aplicación en los servicios de red y de aplicaciones, el enfoque de infraestructura como código puede reducir drásticamente el riesgo asociado a las implementaciones frecuentes. Al aislar las configuraciones y limitar su impacto a un único sistema, se elimina prácticamente el impacto de una implementación fallida. Esto, a su vez, fomenta calendarios específicos para cada aplicación que se ajustan mejor a las necesidades de la empresa y a las demandas de los usuarios.
Para las organizaciones orientadas a la nube, adoptar un enfoque de infraestructura como código puede reducir las dificultades que conlleva migrar de un centro de datos a la nube o de una nube a otra. Dado que la configuración está desacoplada del sistema, en principio puede implementarse en un sistema similar en otro lugar.
Hay muchas buenas razones para hacer el esfuerzo de adoptar un enfoque de infraestructura como código, y muy pocas para no hacerlo. La infraestructura como código es una de las formas más ventajosas de conseguir la red ágil que las organizaciones necesitan para prosperar en una economía digital multinube e impulsada por las aplicaciones.
Sobre el autor
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 VittieArtículos relacionados del blog
Cree servicios públicos seguros, resilientes y preparados para la IA con F5 y AWS
Descubre cómo las organizaciones del sector público pueden modernizar de forma segura sus aplicaciones y soluciones de IA, al tiempo que gestionan los sistemas heredados, el cumplimiento normativo y el riesgo operativo.
Protección de los sistemas de IA: por qué la seguridad debe avanzar al ritmo de la innovación
Desde acelerar avances revolucionarios en medicina y educación hasta transformar la vida cotidiana, la IA está cambiando nuestra forma de vivir y trabajar. Pero también ofrece grandes oportunidades a los ciberdelincuentes.
Avanzar hacia la optimización digital tras la transformación
Descubre estrategias de optimización digital para garantizar políticas de seguridad coherentes, impulsar la madurez de la transformación digital y superar los retos de la transformación.
Proyecto de código abierto destacado: mayor observabilidad con F5 Cloud Logger iApp
En el punto de mira del código abierto: cómo aumentar la observabilidad. Lee el blog de F5 para descubrir cómo exportar fácilmente la telemetría de BIG-IP a plataformas modernas de análisis en la nube.
El estado de la entrega de aplicaciones en 2018: la transformación digital impulsa la automatización y la multinube pese a las preocupaciones de seguridad
Descubre las principales conclusiones del cuarto informe anual de F5 sobre el estado de la entrega de aplicaciones.
Estado de la entrega de aplicaciones en 2017: automatización, API y DevOps
Descubre el informe sobre el estado de la entrega de aplicaciones de 2017. Lee el blog retrospectivo de F5 sobre los inicios del auge de las redes declarativas y los flujos de DevOps.