Arquitectura nativa en la nube: Diseño de aplicaciones escalables y resilientes

Las arquitecturas nativas de la nube han revolucionado la forma en la que se diseñan, desarrollan y despliegan aplicaciones en el entorno de la nube. Al aprovechar el poder de los servicios en la nube y las prácticas modernas de software, las organizaciones pueden construir aplicaciones altamente escalables, resilientes y eficientes.

En este artículo, exploraremos los principios y estrategias claves detrás de la arquitectura nativa en la nube y entenderemos cómo permiten el desarrollo de aplicaciones robustas que pueden prosperar en ese entorno.

Empecemos con una definición básica:

La arquitectura y las tecnologías nativas de la nube son un enfoque para diseñar, construir y operar cargas de trabajo que se construyen en la nube y aprovechan al máximo el modelo de computación en la nube.

¿Cómo se diferencian las aplicaciones nativas en la nube de los modelos más tradicionales basados en virtualización o servidores físicos?

Las aplicaciones nativas de la nube dejan atrás el concepto de virtualización y adoptan un nuevo paradigma desde el desarrollo de la aplicación misma. Aquí introducimos el concepto de los contenedores.

En Latinoamérica, este tema es aún desconocido para muchas organizaciones. Todas las semanas tengo conversaciones con CTOs o jefes de IT algunos que, incluso, ya operan en la nube y desconocen el concepto de correr aplicaciones en contenedores, así que creo que vale la pena explicar algunas de las características y beneficios de migrar nuestras cargas de trabajo y procesos de desarrollo a este paradigma.

Virtualización vs Contenedores

Observemos la imagen a continuación: ésta ilustra de manera muy general y sin entrar en tecnicismos la primera y gran ventaja de ejecutar aplicaciones en contenedores. A nivel de utilización de recursos en una máquina host en el paradigma de la virtualización (esquema a la izquierda), se crea una máquina virtual que incluye el sistema operativo completo. Esto tiene implicaciones en cuanto a los recursos que consume la máquina dentro del host.

En el esquema de contenedores, el sistema operativo es compartido por todos los contenedores y solo se accede a las funciones que el contenedor necesita. Esto quiere decir que los contenedores son ligeros y consumen menos recursos que una máquina virtual.

La segunda gran diferencia y también ventaja de los contenedores tiene que ver con la aplicación misma. Mientras que en el esquema de máquinas virtuales la capa de librerías y dependencias está separada, lo cual puede ser un dolor de cabeza para los administradores que se encargan de los procesos de despliegues ya que el no adoptar un estándar de documentación o recopilación de dependencias puede hacer que instalar la aplicación o actualizarla sea una tarea tediosa y manual; en el esquema de contenedores el código de la aplicación y sus dependencias viven dentro de un mismo repositorio. Esto permite no solo asegurarnos de que nuestra aplicación va a ejecutarse sin problemas, sino también automatizar el proceso de construcción de la imagen ejecutable y los procesos de despliegues y actualizaciones.

Una de las herramientas más populares para crear aplicaciones en contenedores es Docker, fácil de implementar y compatible con los sistemas operativos más usados.

Bien. Ya sabemos el primer factor diferenciador entre las aplicaciones tradicionales y las nativas de la nube Ahora hablemos de cómo el paradigma de la contenerización moderniza las aplicaciones a nivel de arquitectura.

Monolitos vs Microservicios

Una de las arquitecturas más comunes en el mundo de las aplicaciones tradicionales son los monolitos. La aplicación, y muchas veces las bases de datos, viven dentro del mismo entorno de una sola máquina virtual. Puede haber ciertas variaciones donde, tal vez, la base de datos viva en otra máquina virtual, pero esta decisión implica una inversión adicional y, por supuesto, el mantenimiento de este servidor con todo lo que esto implica.

No hay que ser muy técnico para entender las dificultades que estas arquitecturas traen: un cambio en el código de un módulo o una mala configuración del servidor puede romper toda la aplicación y dejar al negocio inoperable hasta que se resuelva el problema.

Ahora observemos la imagen a continuación que ilustra una arquitectura de microservicios montada en Google Cloud. Adoptar el desarrollo en contenedores nos permite modularizar nuestras aplicaciones y separar o agrupar sus funciones (por ejemplo, agrupar todo el código que tenga que ver con una función de carretilla de compras de un sitio eCommerce dentro de un servicio llamado shoppingCart).

Adicionalmente, veamos la separación de las bases de datos, lo cual permite atomicidad y aislamiento real a nivel de infraestructura. Esto cumple a cabalidad con concepto de separation of concerns. Cualquiera pensaría al ver este diagrama: “esto se ve más difícil de administrar”. Eso fuera cierto si la administración fuese manual, pero recordemos que la siguiente gran característica de las aplicaciones nativas de la nube es el poder de la orquestación y automatización, por lo que entra a escena el tan afamado término DevOps, el cual tocaremos más adelante.

Antes de hablar de DevOps, tenemos que tocar el tema de la orquestación, ustedes dirán: “¿orquestación de qué?”. Bueno, hablo de la orquestación de nuestros contenedores y de la infraestructura donde viven. Una aplicación con unos cuantos microservicios no es tan difícil de manejar, pero cuando hablamos de monstruos como Netflix, la orquestación de los microservicios juega un rol crucial en el mantenimiento y escalabilidad del servicio que prestan.

Si quieres aprender más sobre cómo ellos logran Dominar el caos de su arquitectura, dejo este video en Youtube, el cual es muy interesante.

Vista de alto nivel de la arquitectura de Netflix.

El orquestador más usado y conocido por las organizaciones que corren aplicaciones nativas de la nube es Kubernetes o K8s (de cariño). Hablar de K8s requiere un artículo completo dedicado al tema, así que ahora no entraré en mucho detalle. Si tu organización tiene interés en K8s, ponte en contacto conmigo y podemos coordinar un workshop de K8s gratis.

Lo que debemos saber en el contexto de este artículo es que cada proveedor de nube (GCP, AWS, Azure y otros) tienen su propia adaptación de Kubernetes ya que es open source. En GCP tenemos dos versiones de Kubernetes, GKE Standard y GKE Autopilot, cuya diferencia principal radica en cuánto control se requiere en temas de escalabilidad.

Si quieres el control total, opta por la versión Standard y, si quieres que Google se encargue, pues opta por la versión Autopilot. Un punto muy importante de correr tus aplicaciones nativas en la nube es el optar por servicios regionales, lo cual garantiza alta disponibilidad, así como también acercar tu aplicación a los usuarios de una región en particular.

Adicionalmente, Google Cloud ofrece un PaaS para ejecutar aplicaciones en contenedores llamado Cloud Run (yo soy muy fan de éste). Cloud Run es un servicio serverless que permite ejecutar contenedores sin estado (stateless) y es ideal para equipos de desarrollo que no quieren preocuparse por administrar infraestructura o no quieren esto en su lista de preocupaciones, sino que simplemente buscan agilidad y velocidad en sus procesos de integración y despliegues.

DevOps

El término DevOps ha cobrado mucha fuerza en los últimos tiempos, gracias a la adopción de los paradigmas antes mencionados. En sí, DevOps es tanto una mentalidad como un rol en la organización: es una mentalidad porque todas las áreas IT de la empresa deben cambiar sus procesos y metodologías para adoptar el modelo DevOps de manera exitosa; y es un rol porque en la actualidad hay mucha demanda por contratar personas con este perfil.

Pero en sí ¿qué hace un ingeniero DevOps? En términos simples, un ingeniero DevOps es un administrador de infraestructura que sabe programar (por eso la unión de las palabras Developer y Operations). Ahora bien, el DevOps no necesariamente debe saber programar para crear software: sus tareas de desarrollo usualmente se limitan a automatizar procesos de CI/CD (Integración y Entrega continuas), automatizar de procesos de gestión de infraestructura a través de IaC, familiarizarse con las metodologías de desarrollo de software y el ciclo de desarrollo en general e implementar mecanismos de monitoreo necesarios para validar el correcto funcionamiento de las aplicaciones entre otras tareas.

Esto quiere decir que si tu organización se quiere preparar para modernizar sus aplicaciones y ejecutar cargas de trabajo nativas de la nube, también deben pensar en los cambios organizacionales que deben suceder. Esto puede significar dos cosas:

• Preparar al personal existente para adoptar la mentalidad DevOps.
• Contratar personal nuevo con experiencia en DevOps.

La decisión radica en cuán grande sea el impacto del cambio y el nivel de experiencia requerido para realizarlo.

IaC (Infraestructura como código)

El último tema que quisiera tocar es IaC o Infraestructura como código. Uno de los grandes problemas que muchas empresas enfrentan al adoptar la nube son los costos fantasma.

¿Qué son los costos fantasma? La nube ofrece muchísimos servicios y para que un desarrollador o administrador pueda utilizarlos solo requiere los permisos adecuados, habilitarlos e integrarlos a las aplicaciones. Lo anterior significa que llevar un control o inventario de los servicios que se usan puede ser una tarea difícil y, a veces, nos podemos llevar sorpresas inesperadas a nivel de costos.

Una manera efectiva y automática de controlar este problema es implementar IaC, que no es más que un repositorio de código que los administradores utilizan para crear, actualizar o eliminar recursos de la infraestructura en la nube. Además, permite tener una sola fuente de verdad sobre el estado de la infraestructura que se puede replicar en diferentes entornos (dev, qa, prod).

Con IaC, podemos crear y administrar recursos de red, cómputo, almacenamiento, bases de datos e incluso pipelines de CI/CD cuando se adoptan procesos de DevOps. Éste debe de ser un paso importante a considerar cuando tu organización decida adoptar la nube o modernizar la infraestructura que ya se corre en la nube. Tus administradores y departamento de finanzas te lo agradecerán.

En términos de IaC, recomendaría Terraform que, por lo general, ya viene integrado en los servicios de los proveedores de nube más grandes.

Conclusión

La arquitectura nativa en la nube se ha convertido en un factor determinante para el desarrollo de aplicaciones modernas que aprovechan la escalabilidad, flexibilidad y resiliencia de la nube. Al adoptar los principios y tecnologías nativas en la nube, las organizaciones pueden acelerar la innovación, mejorar la agilidad de sus equipos y alcanzar mayor eficiencia de costos.

Espero que esta guía sea de ayuda. ¡Éxito en tus proyectos!