cloud

El aprovisionamiento y la gestión de centros de datos a través de archivos de definición legibles por máquina es la premisa de lo que se conoce como infraestructura como código (IaC).

Fig. 1: Este diagrama define cómo la Infraestructura como Código interactúa entre el control de versiones, la automatización, las API o los servidores y hacia una infraestructura en la nube o un centro de datos local. Los conjuntos de códigos se pueden insertar o extraer dependiendo de la versión, actualización o cambio. (Crédito de la imagen: Karl Paulsen)

Si es una entidad de creación de medios, desea aprovechar la mayor cantidad de oportunidades posibles para avanzar en las etapas de creación de contenido. Uno de ellos es el desarrollo de un conjunto repetible de requisitos, centrado en las necesidades específicas del flujo de trabajo, de modo que se pueda operar más fácilmente en un modo “rutinario”.

La capacidad de personalizar o replicar esos modos de funcionamiento es ventajosa cuando se ejecutan múltiples conjuntos de procesos de forma simultánea o independiente. Los servicios en la nube o los centros de datos en las instalaciones pueden proporcionar conductos efectivos para tales oportunidades; sin embargo, tener que reconfigurar en función de los cambios sistémicos en la infraestructura puede llevar mucho tiempo, ser complejo y requerir recursos especializados, especialmente para procesos rutinarios y actualizaciones simples.

El aprovisionamiento y la administración de centros de datos a través de archivos de definición legibles por máquina es la premisa de lo que se conoce como infraestructura como código (IaC). En lugar de admitir configuraciones o soluciones de hardware físico directo basadas en herramientas de configuración interactivas, IaC utiliza “archivos” computecéntricos basados ​​en lenguaje de máquina para administrar esos procesos informáticos.

En un conjunto de soluciones basadas en la nube, IaC despliega recursos utilizando plantillas, es decir, archivos que pueden ser leídos por humanos y consumibles por máquina y que instruyen a los sistemas a configurar de forma autónoma su funcionalidad de forma prácticamente automática. Los proveedores de servicios en la nube ofrecen tales conjuntos de soluciones de IaC como una “opción integrada”, una que un usuario puede usar o ignorar.

Fundamentalmente, una vez que se crea una plantilla de código, el sistema de la nube toma esas instrucciones de código y las administra a los recursos de la nube sin ninguna intervención directa del usuario. Cualquier necesidad de actualizar los recursos solicitados o de reemplazar cualquiera de las cadenas de procesadores para lograr los objetivos se maneja como una función de fondo y, esencialmente, se convierte en una operación “sin intervención”. La figura 1 muestra los conceptos básicos del flujo de trabajo del usuario a través de los servicios, ya sea en la nube o en un centro de datos local.

Beneficios de IAC

Los beneficios para las aplicaciones y usos de IaC incluyen visibilidad, estabilidad y escalabilidad. Otros incluyen seguridad, verificación, repetibilidad y extensibilidad.

La repetibilidad, con seguridad, se logra cuando se utiliza la misma configuración en cada instancia de la plantilla. La verificación de que un aprovisionamiento determinado es estable y está listo para ejecutarse asegura que si hay una falla, la infraestructura puede revertirse a un estado conocido sin un colapso catastrófico de los componentes. Las operaciones pueden continuar o suspenderse temporalmente dependiendo de los flujos de trabajo prescritos.

La visibilidad permite al usuario obtener un punto de referencia claro sobre los recursos que se utilizan en la cuenta. Si algo cambia inadvertidamente, como una configuración incorrecta o un recurso eliminado accidentalmente, el mecanismo de estabilidad utilizado en una implementación de IaC puede ayudar a resolver ese cambio utilizando una combinación de una versión de administración de control actual o anterior.

La escalabilidad es igualmente importante. La construcción de una biblioteca en torno a conjuntos de códigos reutilizables se presta al modelo con plantilla, que se puede distribuir fácil y fácilmente a múltiples servicios a nivel mundial. En caso de que una región en particular necesite aumentar un producto inesperado, el puerto en la nube más cercano podría acelerar rápidamente los servicios y la infraestructura, en función de las plantillas que probablemente estén en uso en otro sitio geográficamente distante. Los usuarios no necesariamente tendrían que transportar datos a un sitio alternativo si el repositorio se puede poner en servicio en otra región.

Fig. 2 diagramas donde las plantillas, los scripts y las políticas se mantienen en un repositorio común, que puede relegarse adecuadamente a cada punto de presencia global, es decir, una zona de nubes o centro de datos. Cada una de las prácticas se puede insertar (o extraer de un repositorio) a las ubicaciones y funciones asociadas.

Fig. 2: El repositorio de código contiene las plantillas, los scripts y las políticas, que se pueden administrar adecuadamente (gestión de control de versiones).  Luego, los elementos se distribuyen a puntos de presencia globales (nube o centro de datos) cuando se requieren actualizaciones o cambios.
Fig. 2: El repositorio de código contiene las plantillas, los scripts y las políticas, que se pueden administrar adecuadamente (gestión de control de versiones). Luego, los elementos se distribuyen a puntos de presencia globales (nube o centro de datos) cuando se requieren actualizaciones o cambios.(Crédito de la imagen: Karl Paulsen)

Todo como código

Un enfoque similar es la práctica de tratar todos los componentes de la solución como código. Al almacenar configuraciones junto con el código fuente, en un repositorio y como un entorno virtual, los conjuntos de códigos pueden reciclarse o recrearse cuando sea necesario. Incluso los diseños del sistema se almacenarían como código en este modelo.

El modelo todo como código (EaC) mitiga la necesidad de instalar hardware físico y conexiones para cada actividad funcional o tarea. Obviamente, esto sería poco práctico, e imposible, en una atmósfera centrada en la nube. Por lo tanto, los conjuntos de habilidades físicas especializadas previamente requeridas y las prácticas de diseño se transforman en un entorno listo para el código.

Las aplicaciones nativas en la nube, una vez relegadas a modificaciones físicas, han cambiado todo el modelo de costos, lo que facilita la creación de una base de infraestructura “virtual” independientemente de la ubicación.

Declaraciones familiares

Al igual que IaC, un modelo EaC tiene declaraciones beneficiosas similares. La repetibilidad, incluida la capacidad de pasar de un proveedor de nube a otro, permite la recreación precisa del entorno que puede aprovechar aún más los nuevos conjuntos de características (como un rendimiento más rápido o un menor costo por ciclo). El código de infraestructura probado puede desarrollarse, validarse a escala (a través del modelado informático) y luego promoverse directamente a la producción con las expectativas, la confianza y la seguridad de que funcionará rápidamente y según lo diseñado.

El factor miedo, incertidumbre y duda (FUD) con respecto a la deriva de la configuración del servidor está prácticamente eliminado. Estos nuevos modelos pueden, literalmente, autocurarse a sí mismos a casi cualquier nivel, incluida una redistribución completa en caso de que un servidor falle o necesite parches para una operatividad continua. Dado que toda la infraestructura se desarrolla en código, una imagen espejo del sistema sin dependencias cruzadas se puede girar en el momento en que se detecta una anomalía. Las operaciones siguen funcionando.

Herramientas de infraestructura

Para que las soluciones en la nube sean prácticas, deben ser dinámicas. Los recursos de infraestructura caen en esa categoría. Es similar a tener infinitas capacidades de parcheo y barajado sin que un humano manipule activamente la funcionalidad. Es probable que cada proveedor de la nube tenga su propio “sabor” de IaC o EaC, dependiendo de sus conjuntos de características.

Tales conjuntos de herramientas permiten a los clientes de la nube especificar sus recursos de infraestructura necesarios sin tener que comprender realmente (lógica o físicamente) cómo están conectados entre sí. Las herramientas además permiten a los usuarios asignar qué recursos se necesitan, los límites de los parámetros (cuánto por cuánto tiempo) y cómo se deben configurar esos recursos para realizar tareas y actividades seleccionadas.

En las arquitecturas de plataforma como servicio (PaaS), los usuarios podrían usar la interfaz de usuario de una plataforma en particular para asignar o crear conjuntos de recursos y luego administrar esos recursos a lo largo de sus operaciones. De manera similar, los proveedores de soluciones de terceros fabricarían productos de interfaz gráfica de usuario (GUI) para administrar infraestructuras virtuales y en la nube y venderían esos productos a los consumidores. Sin embargo, el inconveniente era que estos eran servicios esencialmente “restringidos” (específicos) que requerían una inversión sustancial en especificaciones iniciales, diseño y pruebas antes de que pudieran implementarse.

Si bien podría decirse que la práctica de PaaS es práctica una vez configurada, y probablemente podría transportarse a varios otros proveedores de la nube, el modelo no era tan flexible. Las aplicaciones requerían mantenimiento y mantenimiento cuando se actualizaba un cambio sistémico en los modelos internos de la nube. A veces, los cambios afectaron las aplicaciones de PaaS y, a veces, el PaaS se “autoadaptaría”. Se trataba del tipo, uso y aplicaciones que se implementaron en ese momento para ese servicio en particular.

Fuente: https://www.tvtechnology.com/opinion/the-basics-of-infrastructure-as-code

Sobre el Autor

0 0 vote
Article Rating
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments