Implementación y uso de la nube moderna

Al migrar entornos existentes a la nube, o incluso al crear e implementar nuevos entornos en la nube, existen muchas alternativas. No hay una forma correcta o incorrecta.

En esta publicación revisaremos la forma en que se hizo en el pasado (también conocido como "vieja escuela") y revisaremos las opciones más modernas para implementaciones de entornos.

Implementación tradicional

Tradicionalmente, cuando teníamos que implementar un nuevo servicio o aplicación necesitábamos un entorno de desarrollo, prueba y producción en el cual generalmente considerábamos aplicaciones de 3 niveles. Estos se construyen a partir de una capa de presentación (como un servidor web o una implementación de cliente completa), una lógica empresarial (como un servidor de aplicaciones) y un nivel de almacenamiento de fondo (como un servidor de base de datos).

Dado que cada capa (o nivel) dependía del resto de las capas, cada actualización de software o adición de otro servidor (para alta disponibilidad) requería tiempo de inactividad para toda la aplicación o servicio. El resultado: un monolito.

Este proceso fue engorroso. Se necesitaron varias semanas para implementar el sistema operativo, implementar el software, configurarlo, realizar pruebas, obtener la aprobación del cliente comercial, tomar el mismo proceso para implementar un entorno de producción y finalmente cambiar a producción.

Este proceso era viable para implementaciones a pequeña escala o aplicaciones simples, que prestaban servicios a una pequeña cantidad de clientes.

Por lo general, nos enfocamos más en el lado del sistema de la implementación, quizás un solo servidor que contiene todos los componentes. Hasta que alcancemos las limitaciones de hardware (CPU / Memoria / Almacenamiento / Limitaciones de red) antes de comenzar a escalar (cambiar a hardware más nuevo con más CPU / Memoria / Almacenamiento / tarjeta de interfaz de red más rápida). Solo entonces podremos descubrir que esta solución no se escala lo suficiente para atender a los clientes a largo plazo.

Cuando reemplazar el tamaño de la máquina virtual no resuelve los cuellos de botella, comenzamos a escalar horizontalmente agregando más servidores (como más servidores web, clústeres de servidores de bases de datos, etc.). Luego nos enfrentamos a un nuevo tipo de problemas, cuando necesitamos eliminar todo el monolito, cada vez que planeamos implementar parches de seguridad, implementar actualizaciones de software, etc.

La migración de la arquitectura existente a la nube pública (también conocida como "elevación y cambio") es una opción viable y tiene sus propios pros y contras:

Pros:

Mantenemos nuestro método de implementación actual
Se requiere menos conocimiento del equipo de TI
Acortamos el tiempo que lleva implementar nuevos entornos
Probablemente podamos mantener nuestra inversión en licencias (BYOD “Bring your own license”)
Probablemente podamos reutilizar nuestras herramientas de implementación de software, monitoreo y respaldo existentes que usamos en la implementación local.

Contras:

El uso del modelo de compra más común "a pedido" o "pago por uso" es adecuado para patrones de uso desconocidos (como el desarrollo o el entorno de prueba), pero pronto resultará costoso utilizar este modelo de compra en entornos de producción, funcionando 24x7 (incluso cuando se usa el modelo de compra por horas), en comparación con la compra de hardware para el local y el uso del hardware sin límite de tiempo (hasta que finaliza el soporte de hardware)

Todavía estamos a cargo del mantenimiento del sistema operativo (actualizaciones, respaldo, monitoreo, implementación de varios agentes, etc.): cuanto más grande sea nuestra granja de servidores, mayor es la carga que tenemos en el mantenimiento, hasta que no escala lo suficiente y necesitamos departamentos de TI más grandes y reducimos el valor que aportamos a nuestra organización.

‍

Despliegue en el mundo moderno

El desarrollo moderno y la implementación de aplicaciones, también conocidas como "aplicaciones nativas de la nube", se centran en el servicio (en lugar de servidores con aplicaciones). Aprovecha los beneficios de las funciones y capacidades integradas de la nube:

Escala : creamos nuestros servicios para poder atender a millones de clientes (en lugar de varios cientos).

Elasticidad : nuestras aplicaciones son conscientes de la carga y pueden expandir o reducir los recursos de acuerdo con las necesidades.

Alta disponibilidad: en lugar de exponer un solo servidor en un solo centro de datos a Internet, implementamos nuestros recursos informáticos (VM, contenedores, etc.) detrás de un servicio de equilibrador de carga administrado, y distribuimos la implementación del servidor entre varias zonas de disponibilidad ( normalmente una zona de disponibilidad equivale a un centro de datos). Esto nos permite monitorear automáticamente la disponibilidad del servidor e implementar nuevos recursos informáticos cuando un servidor falla o cuando necesitamos más recursos informáticos debido a la carga del servidor. Dado que la nube ofrece servicios administrados (desde equilibradores de carga, puertas de enlace NAT, túnel VPN, almacenamiento de objetos, bases de datos administradas, etc.), nos beneficiamos de los SLA de los proveedores de la nube, que son extremadamente difíciles de obtener en los centros de datos tradicionales.

Observabilidad : en el pasado solíamos monitorear métricas básicas como CPU o carga de memoria, espacio libre en disco (o tal vez porcentaje de eventos de lectura / escritura). Hoy en día, agregamos cada vez más métricas para las aplicaciones en sí, como número de usuarios concurrentes, tiempo que se tarda en consultar la base de datos, porcentaje de errores en el archivo de registro del servidor web, comunicación entre componentes, etc. Esto nos permite predecir el servicio. fallas antes de que nuestros clientes las observen.

Contenedores y Kubernetes al rescate

El uso de la arquitectura de microservicios revolucionó la forma en que desarrollamos e implementamos aplicaciones modernas al dividir la arquitectura anteriormente compleja en componentes más pequeños y dividirlos por la tarea que cumplen en nuestra aplicación o servicio.

Aquí es donde los contenedores entran en escena. En lugar de implementar máquinas virtuales, con un sistema operativo completo y pilas de software completas, usamos contenedores. Esto nos permite empaquetar la cantidad mínima de binarios, bibliotecas y código, necesarios para una tarea específica (iniciar sesión en la aplicación, ejecutar la lógica empresarial, ingerir datos en un almacén de objetos o directamente en la base de datos back-end, ejecutar el modelo de informes , etc.)

Los contenedores permiten una mejor utilización del "hardware" existente mediante la implementación de varios contenedores (cada uno puede ser para un servicio diferente) en el mismo hardware virtual (o bare metal) y alcanzan casi el 100% de la utilización de recursos.

Los contenedores permiten que los pequeños equipos de desarrollo se centren en tareas o componentes específicos, casi por separado del resto de los equipos de desarrollo (los componentes aún deben comunicarse entre sí). Pueden actualizar líneas de código, escalar hacia adentro y hacia afuera según la carga y, con suerte, algún día podrán cambiar entre proveedores de nube (también conocido como "agnóstico de la nube").

Kubernetes, es el orquestador más común para ejecutar contenedores. Puede implementar contenedores de acuerdo con las necesidades (como la carga), monitorear el estado de cada contenedor en ejecución (e implementar un nuevo contenedor para reemplazar el contenedor que no funciona), actualizar automáticamente la compilación del software (mediante la implementación de contenedores que contienen nuevas versiones de código) , asegúrese de que ciertos contenedores se implementen por igual entre servidores virtuales (para carga y alta disponibilidad), etc.

Pros:

Disminuye el número de binarios y bibliotecas, mínimo para ejecutar el servicio.
Se puede desarrollar localmente en una computadora portátil y ejecutarse a gran escala en la nube (resuelve el problema de "se ejecuta en mi máquina")
Independiente del proveedor de la nube (a menos que consuma servicios del ecosistema del proveedor de la nube)

Contras:

Se necesita tiempo para aprender a envolver y mantener
Desafiante de depurar
Un gran porcentaje de los contenedores disponibles están desactualizados y contienen vulnerabilidades de seguridad.

Sin servidor (Serverless) / Función como servicio

Estas son nuevas formas modernas de implementar aplicaciones de una manera más rentable, cuando podemos tomar pequeñas porciones de nuestro código (también conocidas como "funciones") para realizar tareas específicas e implementarlas dentro de un entorno informático administrado (también conocido como "sin servidor") y paga por la cantidad de recursos que consumimos (CPU / Memoria) y el tiempo (en segundos) que se tarda en ejecutar una función.

Serverless se puede instalar dentro de la arquitectura de microservicio reemplazando las tareas que solíamos colocar dentro de los contenedores.

Adecuado para funciones sin estado (por ejemplo: no es necesario mantener el almacenamiento en caché de datos) o para escenarios en los que tenemos tareas específicas. Por ejemplo, cuando necesitamos invocar una función como resultado de un evento, como cerrar un puerto en un grupo de seguridad, o debido a un evento desencadenado en un servicio de monitoreo de seguridad.

Pros:

No es necesario mantener la infraestructura subyacente (recursos informáticos, sistema operativo, parches, etc.)
Escala automáticamente según la carga
Extremadamente económico en pequeña escala (en comparación con un contenedor)

Contras:

Limitado a un máximo de 15 minutos de tiempo de ejecución
Tamaño de almacenamiento de función limitado
Difícil de depurar debido al hecho de que es un entorno cerrado (sin acceso al sistema operativo)
Puede resultar caro a gran escala (en comparación con un contenedor)
Número limitado de lenguajes de desarrollo admitidos
Tiempo de inicio prolongado de la función ("Calentamiento")

Resumen

El mundo de la implementación de la nube está cambiando. Y esta es una buena noticia.

En lugar de flotas de servidores y centrarse en la infraestructura que podría no ser adecuada o rentable para nuestras aplicaciones, la implementación de la nube moderna se centra en aportar valor a nuestros clientes y a nuestras organizaciones al acortar el tiempo que lleva desarrollar nuevas capacidades ( "Time to market"). Nos permite experimentar, cometer errores y recuperarnos rápidamente ("fail safe"), mientras hacemos un mejor uso de los recursos (pagamos por lo que consumimos), pudiendo predecir las interrupciones y el tiempo de inactividad con anticipación.

‍

Este artículo fue escrito por Eyal Estrin, Cloud Architect y revisado por Tamir Dresher, System Architect

Traducido por Juan Pablo Vidalit