Castañas en la nube, o qué significa que mi software sea Cloud Native

Gonzalo Fernández Rodríguez    28 junio, 2021
Cloud Native

Quienes llevamos años en el mundo del desarrollo software hemos sido testigos del uso de muchos términos por parte de fabricantes y vendedores (de humo en muchos casos), simplemente, por el hecho de que están de moda o se habla mucho de ellos (lo que los ingleses llaman el hype o la buzzword del momento). Términos como Machine Learning, Internet of Things, Blockchain, Serverless, y un largo etcétera.

Por supuesto, el término Cloud Native no iba a ser menos, y hoy en día está en boca de mucha gente que nombra este término en cuanto tiene oportunidad.  Conviene entonces saber qué significa Cloud Native y si realmente es un “palabro” de moda que nos hace quedar bien delante de nuestros clientes o es algo más que una moda pasajera. ¿Conocemos realmente qué hay detrás de una aplicación considerada Cloud Native para entender qué conlleva en términos de desarrollo/arquitectura, despliegue y operación? En el presente artículo vamos a intentar desvelar qué hay tras una aplicación o sistema Cloud Native.

El término Cloud Native es algo que va más allá de mover las aplicaciones on-premises, es decir, alojadas directamente en un data center a una infraestructura proporcionada por un proveedor Cloud (sea pública o privada). Lo que se conoce como “Lift & Shift” de aplicaciones a la nube no es más que un proceso en el que nuestras aplicaciones dejan de correr en la infraestructura on-premises de nuestro data center para pasar a correr en una infraestructura Cloud, pero, generalmente, sin ningún tipo de rediseño en la arquitectura de dichas aplicaciones, ni en las prácticas de construcción, despliegue y operación de las mismas.

Obviamente nos podremos aprovechar de unos beneficios básicos “out of the box” al usar infraestructura con mayor redundancia, con facilidades para realizar backups, actualizada con los últimos parches de seguridad, etc. Pero tenemos que tener en cuenta que nuestra aplicación no se va a convertir en una aplicación Cloud Native por el hecho de desplegarla en la nube. Si tienes un sistema que es una castaña y lo despliegas en un cluster EKS de kubernetes de AWS, ‘¡Enhorabuena!, ahora tienes una castaña kubernetizada’.

La Cloud ha cambiado las reglas del juego. No hace tantos años era necesario hacer un buen estudio de las capacidades (cómputo, red y almacenamiento) que necesitaríamos para que nuestro sistema ofreciera un servicio con garantías, realizar un pedido para cubrir dichas capacidades (a uno o varios proveedores) que podría tardar incluso meses en estar listo. Periódicamente, teníamos que evaluar el potencial crecimiento del sistema y volver a comprar más hardware si no queríamos que nuestros clientes nos abandonaran cuando aquello dejara de funcionar. Hoy en día es posible hacer todo esto con un par de clicks en una consola de administración o mejor aún con una llamada a un API (Application Program Interface) que nos permite además automatizar este proceso, y es que la cloud ha puesto a nuestra disposición las capacidades de cómputo, red, almacenamiento así como otros servicios más avanzados (bases de datos, sistemas de colas de mensajes, analítica de datos, etc.) como abstracciones definidas por software dando lugar a lo que se conoce como Cloud Computing que, en definitiva, viene a ser esos recursos de computación que necesitamos para construir nuestros sistemas (CPU, almacenamiento, red, etc.) pero disponibles en la red y que podemos ir consumiendo bajo demanda, ofreciendo una eficiencia en costes y una escalabilidad nunca vista antes.

Cloud Native es consecuencia de la necesidad de escalar

Está claro entonces que ha cambiado la tecnología sobre la cual construimos y desplegamos nuestros sistemas, ¿pero cuál es el motivo? Dar un único motivo quizás sería un poco arriesgado, aunque lo que sí podemos afirmar es que el Cloud Computing resuelve un problema de escalabilidad. En los últimos años, las soluciones digitales (plataformas de gaming, streaming de video, música, redes sociales, etc.) se consumen cada vez más desde distintos dispositivos, no solo PCs, hablamos de teléfonos móviles, tablets, Smart TVs e, incluso, dispositivos IoT (Internet of Things) que han ido creado diferentes escenarios de acceso a nuestros sistemas. Escenarios donde el número de peticiones y el volumen de datos va cambiando,  es decir, escenarios que requieren que nuestro sistema siga funcionando correctamente ante cambios de demanda de recursos, en definitiva, escenarios que requieren que nuestro sistema sea “escalable”.

Sin embargo, esto no es gratis, la gestión de esta escalabilidad en nuestros servicios se vuelve más compleja, los métodos tradicionales ya no sirven, necesitamos otra forma de hacer las cosas. Al igual que en su día surgieron los PCs y con ellos las arquitecturas cliente/servidor necesarias para aprovechar su capacidad de cómputo descargando así a los viejos “mainframes” de hacer todo el trabajo de nuestros sistemas, aparejado a este cambio tecnológico que llamamos Cloud Computing y para dar respuesta a la gestión de esa escalabilidad, surgen nuevos patrones de arquitectura y también nuevas prácticas para operar nuestros sistemas dando lugar al término Cloud Native.

Por eso, cuando decimos que un sistema o una aplicación es Cloud Native, realmente no nos estamos refiriendo a si se ejecuta en una Cloud, sino a cómo ha sido diseñado para poder ejecutarse y operarse de forma correcta sobre una tecnología Cloud Computing, beneficiándose además de las ventajas de dicha tecnología.

Los sistemas Cloud Native se diseñan de tal forma que tengan la capacidad de crecer/decrecer de forma dinámica y de que se puedan actualizar, todo ello sin pérdida de servicio, lo que se conoce como «zero downtime» (zero downtime no significa un uptime perfecto, sino cumplir un objetivo por el cual no se percibe interrupción del servicio a lo largo del funcionamiento de una aplicación)[1].

Cloud Native según la CNCF (Cloud Native Computing Foundation)

Hoy en día los usuarios no tienen, o mejor dicho, no tenemos, la misma paciencia que hace años cuando veíamos totalmente normal que una página web tardase unos segundos en cargar, o que un vídeo en streaming tuviera cierta latencia, incluso que se detuviera de vez en cuando.  Cada día los servicios son más sofisticados y los usuarios demandan sistemas que funcionen con una percepción excelente, ya no son tan tolerantes, el nivel de escalabilidad proporcionado por la Cloud hace posible que aplicaciones de redes sociales, mensajería instantánea, streaming de vídeo o de audio permitan que millones de usuarios puedan conversar, subir fotos, vídeos, ver películas o escuchar música, todo al mismo tiempo. Eso sí, los usuarios no quieren fallos, necesitan que los servicios estén funcionado bien todo el rato, y esto es complicado en un entorno tan cambiante como es la Cloud.

La CNCF habla del término Cloud Native como un conjunto de tecnologías que nos permite construir y ejecutar aplicaciones escalables en entornos modernos y dinámicos como clouds públicas, privadas e híbridas. También nos dice que los sistemas resultantes son débilmente acoplados, resilientes, administrables, observables y que, además, con una buena automatización van a permitir que podamos introducir cambios de forma frecuente y predecible con poco esfuerzo.

En un entorno tan cambiante como es la cloud, va a ser necesario que diseñemos nuestros sistemas para que sean capaces de reaccionar ante posibles errores que puedan producir fallos en nuestros sistemas. Si conseguimos que nuestros sistemas tengan estos atributos que define la CNCF para las aplicaciones Cloud Native (escalables, débilmente acoplados, resilientes, maleables y observables), seremos capaces de mantener a nuestros clientes satisfechos proporcionándoles sistemas que funcionan de forma continua.

Si consideramos cada uno de estos atributos podremos ver cómo nos ayudan a conseguir que nuestros sistemas sean fiables y funcionen prácticamente sin interrupciones:

  • Escalabilidad: si diseñamos nuestros sistemas para que sean capaces de funcionar sin estado, conseguiremos que nuestros sistemas sean escalables y por tanto serán capaces de adaptarse ante un crecimiento inesperado de demanda de recursos, es una forma de “prevenir fallos”.
  • Acoplamiento débil: que nuestros sistemas estén débilmente acoplados evitando compartir dependencias como podría ocurrirnos cuando diseñamos un sistema basado en microservicios y terminamos generando un monolito distribuido (donde cambios en un microservicio no pueden ser hechos sin cambios en otros), permitirá que puedan evolucionar y escalar aquellos componentes o servicios (o microservicios) que se necesiten de forma independiente y, además, también logrará prevenir fallos derivados de los cambios necesarios en múltiples componentes si estuvieran acoplados.
  • Resiliencia: mediante la redundancia de componentes o la aplicación de ciertos patrones que eviten la propagación en cascada de fallos podemos hacer que nuestros sistemas sean más resilientes y por tanto puedan seguir funcionando aún cuando ocurran ciertos fallos, es decir, conseguiremos que nuestro sistema sea tolerante a fallos.
  • Administrable: si diseñamos nuestros sistemas de modo que puedan ser fácilmente configurables, conseguiremos poder cambiar ciertos comportamientos del mismo sin necesidad de desplegar una nueva versión del mismo, incluso podríamos eliminar posibles errores que hayan surgido.
  • Observable: por último, deberíamos de tomar medidas (métricas) de distintos indicadores de nuestros sistemas que podamos observar continuamente para poder predecir errores o comportamientos no deseados y actuar antes de que ocurran.

En resumen, Cloud Native ha venido para quedarse, para poder gestionar toda la complejidad que supone tener esa capacidad casi infinita que nos proporciona el Cloud Computing. Mediante la aplicación de patrones de diseño y prácticas de operación, conseguimos que nuestros sistemas sean incluso más fiables que la infraestructura Cloud sobre la que se ejecutan (por ejemplo un failover entre dos regiones de una Cloud) al mismo tiempo que el usuario tenga una confianza plena en el funcionamiento de nuestro sistema.


[1] Sobre la capacidad de planificar en base a la percepción de calidad del servicio por parte del usuario, existen una serie de libros escritos por ingenieros de Google, conocidos como SRE o Ingenieros de Resiliencia del Servicio, los cuales extienden el concepto de SLA, al mismo tiempo que añaden nuevos como SLI o SLO (https://sre.google/books/).

[2] https://github.com/cncf/toc/blob/main/DEFINITION.md#cncf-cloud-native-definition-v10.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *