Hay una revolución en camino, de hecho tres revoluciones. La primera revolución is la creación de la nube, explicaremos qué es y por qué es tan importante. La segunda es el amanecer de DevOps, encontrarás que involucra y cómo está cambiando las operaciones de TI. La tercera revolucíon es la llegada de los contenedores. Juntas, estas tres olas de cambio están creando un nuevo mundo de software: El mundo de la nube nativa.
La creación de la nube
En los comienzos (Los 1960s), los computadores llenaron rack tras rack en centros de datos vastos, remotos y acondicionados con aire, y los usuarios nunca podrían verlos o interactuar con ellos directamente. Miles de usuarios podrían compartir la misma infraestructura de computación y cada uno podría recibir una factura por el monto de tiempo de procesador o recursos usados. Esto no era costo-efectivo para las compañias que compraban y mantenían su propio hardware de computación, entonces emergió un nuevo modelo de negocio donde los usuarios podrían compartir poder computaciones, pero apropiado y admnisrado por un tercero.
La idea central de la nube es esta: En vez de comprar un computador, compra cómputo. Es decir, en vez de de invertir grandes cantidades de capital en maquinaria física, simplemente compra tiempo en el computador de otra persona. Puedes comprar recursos informáticos sin procesar (como una instancia de Google Compute Enngine o una funcion AWS Lambda) y usarlos para ejecutar su propio software pero gradualmente puedes alquilar servicios de nube: esencialmente, el uso del software de otra persona.
Infraestructura como Servicio
Cuando usas infraestructura de nube para ejecutar sus propios servicios, lo que está comprando es Infraestructra como servicio (IaaS). No tienes que gastar capital en comprar, no tienes que contruir y no tienes que actuallizar. Es solo un servicio, como la electricidad o el agua. La computación en la nube es una revolución en la relación entre empresas y su infraestructura de TI.
Subcontratar el hardware es solo una parte de la historia; la nube también permite externalizar el software que no escribes: sistemas operativos, bases de datos, clustering, replicación, redes, monitoreo, alta disponibilidad, procesamiento de colas y flujos, y todas las innumerables capas de software y configuración que cubren la brecha entre código y CPU.
El amanecer de DevOps
Antes de DevOps, desarrollar y operar software eran esencialmente dos trabajos separados, realizados por dos grupos diferentes de personas. Los desarrolladores escribian software, y lo pasaban al equipo de operaciones, quienes ejecutaban y mantenian el software en producción. De hecho, los dos departamentos tenian objetivos e incentivos diferentes, y a menudo generaban conflicto entre sí. Los desarrolladores estaban centrados en el envío de nuevas características rápidamente, mientras que los equipos de operaciones estaban preocupados por hacer que los servicios fueran estables y fiables a largo plazo.
Los orígenes del movimiento DevOps se encuentran en los intentos de acercar a estos dos grupos juntos: para colaborar, compartir comprensión, compartir la responsabilidad de los sistemas confiabilidad y corrección del software, y mejorar la escalabilidad tanto de los sistemas de software como los equipos de personas que los construyen.
Aprendiendo juntos
Ambos equipos de desarrolladores y operaciones están aprendiendo cómo trabajar juntos. Están aprendiendo cómo diseñar y contruir sistemas, cómo monitorear y obtener retroalimentación de los sitemas en produccción, y cómo usar esa información para mejorar los sistemas.
La escala masiva de la nube y la colaboración, la naturaleza centrada en el código del movimiento DevOps ha convertido las operaciones en un problema de software. Al mismo tiempo, ha convertido el software en un problema de operaciones, lo que plantea estas preguntas:
- ¿Cómo implementa y actualiza el software en redes grandes y diversas de diferentes arquitecturas de servidor y sistemas operativos?.
- ¿Cómo implementa en entornos distribuidos, de manera confiable y reproducible usando componentes en gran medida estandarizados?.
La llegada de los contenedores
Para implementar una pieza de software, no sólo necesita el software en sí, también sus dependencias. Eso significa librerías, interpretadores, subpaquetes, compiladores, extensiones, entre otros. También necesita su configuración. Ajustes, detalles del sitio especifico, claves de licencia, credenciales de base de datos: Todo lo que convierte el software en bruto en un servicio utilizable. Para resolver estos problemas, la industria de tecnología tomó prestada una idea de la industria naval: el contenedor.
Poniendo el software en contenedores
El contenedor de software es exactamente la misma idea: un formato de empaquetado y distrbución que es genérico y generalizado, lo que permite gran capacidad de transporte, bajo costo, economía de escala y fácil de administrar. El formato de contenedor contiene todo lo que la aplicación necesita para ejecutar, integrado en un archivo de imagen que puede ser ejecutado por un container runtime.
¿Cómo se diferencia a una imagen de máquina virtual? También lo contiene todo lo que la aplicación necesita ejecutarse, pero mucho más pesado. Una imagen típica de máquina virtual es de alrededor de 1 GiB. Una imagen de contenedor bien diseñada, por otro lado, podría ser una cien veces más pequeña. Los desarrolladores no tienen que preocuparse sobre mantener diferentes versiones de software para ejecutar en diferente distrbuciones de Linux contra diferentes librerias y versiones de lenguaje. Lo único que depende el contenedor es el kernel del sistema operativo.
Los equipos de operaciones, encuentran su carga de trabajo más simplificada por los contenedores. En vez de mantener un extenso inventario de máquinas de varias clases, arquitecturas y sistemas operativos, todo lo que tienen que hacer es ejecutar un container orchestator: una pieza de software diseñada para unir muchas máquinas diferentes en un clúster: una especie de unidad sustrato de cómputo, que aparece para el usuario como una sola computadora muy poderosa en los que se pueden ejecutar los contenedores.
Funciones cloud y Funtenedores
Porque sólo pagas por el tiempo de ejecucción en incrementos de 100 milisegundos, el modelo FaaS (Functions as a Service) es perfecto para la computación que sólo se ejecuta cuando lo necesitas, en vez de pagar por un servidor de nube, que ejecuta todo el tiempo esté en uso ó no. Estas funciones cloud son más convenientes que los contenedores en algunas maneras (a través de algunas plataformas FaaS puedes ejecutar contenedores). Pero están mejor diseñadas para trabajos cortos, especialmente los que se integran con servicios de cómputo en la nube existentes. Por qúe no nos referimos a este modelo como sin-servidor? En realidad, no lo es: es sólo el servidor de algiuen. El punto es que no tienes que aprovisionar ni mantener ese servidor; el proveedor de nube se encarga de ello por ti.
Algunas cosas permanecerán centralizadas
¿Hay límites para DevOps? ¿O el equipo tradicional de operaciones TI centralizado desaparecerá por completo, disolviéndose en un grupo de consultores internos, entrenadores, instructores y solución de problemas de operaciones? Creemos que no, o al menos no del todo. Algunas cosas aún se benefician de estar centralizadas. No tiene sentido que cada equipo de aplicación ó servicio tenga su propia forma de detectar y comunicar sobre incidencias de producción. No tiene sentido que todos se reinventen su propia rueda.
Traducido de la compilación Next Architecture disponible en O'Reily.
Publicado en The Bucket of Notes: https://thebucketofnotes.hashnode.dev/la-revolucion-de-la-nube
Top comments (0)