Probablemente uno de los términos más usados últimamente en el mundo tecnológico es el de “Cloud Native”, pero a la vez también uno de los mas confusos de entender o con el que probablemente haya mala interpretación de su significado, que sí es una tecnología (¡contenedores!), que si es un tipo de aplicación, que sí es una forma de trabajo, que si tú proveedor te brinda esa facilidad, pero lo que haremos ahora es tratar de tener adquirir un poco de mayor claridad respecto a este concepto y ver cómo podemos adaptarlo en el día a día.
La primera vez que tome conocimiento del concepto fue fácil asociarlo con algo relativo a las aplicaciones cloud y entendí originalmente que Cloud Native eran aplicaciones que estaban hechas para sacar partido de las características inherentes a la nube: escalabilidad, pago por consumo, etc; pero de igual manera me dí cuenta de 2 cosas: que eso no era todo pero que el concepto de cloud native se había vuelto un comodín para promocionar cierto tipo de tecnologías en concreto, como veremos más adelante así que empecé a investigar.
Una de las primeras cosas que debemos descartar al referirnos a lo que es Cloud Native o aplicaciones cloud native es a los procesos de migrar, en su forma actual (“as is”), a las aplicaciones que tenemos en este momento en nuestros servidores, en el on premise, por ejemplo una operación de lift and shift(*) de nuestros data centers hacia la nube no es un proceso cloud native, y, curiosamente una aplicación diseñada para usar Máquinas Virtuales tampoco podría considerarse cloud native por más que esta haga uso de elementos como almacenamiento elástico o capacidades de escalamiento, siendo que hasta hace pocos años este tipo de arquitectura, basado en máquinas virtuales, ha sido muy frecuente en diversas aplicaciones en organizaciones que iniciaban su camino hacia la nube.
Entonces ya tenemos dos premisas rudimentarias: no replicar las estrategias de diseño y programación frecuentes en el on premise, y tratar de aprovechar las características inherentes a la nube y con eso podríamos quedarnos pero, siempre podemos profundizar en el concepto a fin de obtener un verdadero entendimiento y que nos sirva para nuestros desarrollos futuros.
Así que mi primera para fue la Cloud Native Computing Foundation (CNCF), cuya definición reza así:
Las tecnologías “Cloud Native” empoderan a las organizaciones para construir y correr aplicaciones escalables en ambientes dinámicos modernos, como lo son hoy las nubes públicas, privadas o hibridas. Temas como contenedores, mallas de servicios, microservicios, infraestructura inmutable y APIs declarativas son ejemplos de este enfoque.
Estas técnicas permiten crear sistemas de bajo acoplamiento que son resilentes, administrables y observables. Combinado con técnicas de automatización robusta les permite a los ingenieros realizar cambios de alto impacto de manera frecuente y predecible con un mínimo esfuerzo.
La definición de Cloud Native, que ya introduce elementos tecnológicos concretos, es un interesante punto de partida, y podríamos estar tentados a quedarnos con ella, pero… en realidad ¿esto permite entender de qué se trata Cloud Native? y la verdad es que si bien es una definición razonable no nos provee un contexto, más allá de la tecnología, respecto a por qué necesitamos aplicaciones cloud native y/o qué es necesario para llegar a tener una aplicación cloud native.
En ese sentido el año pasado pude leer el libro de Cornelia Davis, Cloud Native Patterns, el cual recomiendo ampliamente pues plantea enfoques y diseño de estrategias para el desarrollo de aplicaciones cloud native, pero lo más importante es que antes de proveer estas recomendaciones se asegura de que el lector entienda de por qué se están desarrollando este tipo de aplicaciones y los requisitos qué debería incluir una aplicación cloud native. 
El libro pone un contexto, un marco teórico referencial de cuál es el entorno de las aplicaciones hoy en día, y las capacidades que debería tener una aplicación moderna para atender los requerimientos actuales y sacarles jugo a ciertas características de la nube, pero antes de avanzar con ello nos recuerda que nos proveedores cloud son falibles, que su SLA no es del 100%, por lo que debemos construir teniendo eso en mente, por lo que en resumen podemos concluir con este primer requisito:
Cloud Native espera que las aplicaciones que se desarrollen sean más robustas que la plataforma en la que se ejecutan.
O como la autora luego define:
“Cloud-native software is designed to anticipate failure and remain stable even when the infrastructure it’s running on is experiencing outages or is otherwise changing.”
Reto fuerte, ¿no? Bueno, lo interesante viene cuando nos plantea los retos/requisitos de las aplicaciones actuales
- Tolerancia cero a fallos
- Reducción de los ciclos de feedback
- Soporte móvil y multidispositivo
- Dispositivos conectados – Internet de las Cosas (IoT)
- Basadas en datos
Con estas premisas, Cornelia Davis va estructurando la interrelación entre estos elementos, y los organiza en el siguiente diagrama:
El cual se resume en esta definición:
“Cloud-native software is highly distributed, must operate in a constantly changing environment, and is itself constantly changing.”
Entonces, como dijimos, Cloud Native no es “mira, tengo aplicación en mi servidor actual y ahora me provisiono un nuevo servidor en la nube y ya está”, eso no es Cloud Native, estás usando la nube sí, pero Cloud Native es la capacidad de que tu desarrollo qué haces en la nube se valga de características que son más fáciles de hacer en la nube, esa es mi definición personal, sumando a lo que plantea la autora, por ejemplo qué las aplicaciones sean resilientes, escalables, tolerantes a fallos, que faciliten su despliegue, siendo esas características intrínsecas las que permiten satisfacer las necesidades del mundo actual.
Se habrán dado cuenta, que en esta explicación no hemos aterrizado en ninguna tecnología concreta (a diferencia de lo planteado en la definición de la CNCF), ni ningún proveedor de nube, nos hemos centrado en cuanto a las características de una aplicación, tanto en mi resumen personal como en el resumen de lo propuesto por Cornelia, y lo hemos planteado en términos de objetivos y características, por lo que, si nuestras decisiones se basan en estos criterios, estaremos bien.
Así que, como hemos visto, los objetivos están definidos, por lo que nuestro rol es determinar la mejor manera de alcanzarlos, por lo que vayamos paso a paso; prácticamente desde el inicio de mi aventura con la nube, había entendido que los modelos PaaS (Platform as a Service) son los que te brindan, preliminarmente, esa flexibilidad y características para lograr dichos objetivos, concretamente dos productos: el Google Application Engine de GCP y en el caso de Azure las Azure Web Apps; estos servicios te abstraen de la complejidad y ya tienen incorporadas ciertas características de resiliencia y escalabilidad, que facilitan el desarrollo de aplicaciones que cumplen los objetivos de cloud native.
Pero, y aquí viene la parte un poquito más complicada, es que lo que vamos a escuchar y leer, por diversas fuentes, es el mapeo constante entre el binomio “micro servicios + Kubernetes” como las bases de lo que es Cloud Native; y si puede que microservicios juegue un rol importante, debido algunos de los requisitos más avanzados de Cloud Native, como el de aplicaciones altamente cambiantes y para que estas sean altamente cambiantes no conviene que una aplicación sea muy grande sino que se conformen de módulos pequeños con despliegues independientes, y claro, una forma de lograrlo es mediante microservicios (lo cual nos puede llevar a otra discusión respecto a si “microservicios para todo”) contexto en el cual Kubernetes llega como una plataforma adecuada para el despliegue de microservicios, y en consecuencia (oh sorpresa) para desplegar aplicaciones Cloud Native.
En este contexto, debemos tener claro que la asociación Kubernetes=Cloud Native no es del todo exacta, o sea ¿una aplicación en Kubernetes puede ser Cloud Native? Sí, perfecto, pero no es la única forma.
Con kubernetes puedes lograr muchos requisitos que se mencionan como parte de Cloud Native, pero, como comentábamos antes, hay otras formas; una de ellas es mediante las plataformas PaaS arriba mencionadas, y la otra es mediante un enfoque serverless (especialmente de Functions as a Service), no dependiendo de un servidor puesto que básicamente no tienes que provisionar infraestructura (como vimos en artículos anteriores), al hacer uso de esta tecnología logras buena parte de los requisitos que debe tener una aplicación cloud native, siempre recordando que tienes que diseñar bien tu arquitectura alrededor de las peculiaridades tu plataforma, en todo caso en el contexto actual se habla poco de la opción serverless cuando se habla de Cloud Native, por lo que es bueno recordar esta opción.
En mi opinión personal por el lado de Serverless las cosas van a seguir creciendo mucho, como lo comente en el post anterior, va a haber mucho interés respecto a cómo se pueden desarrollar aplicaciones que saquen ventajas de la nube con las tecnologías serverless (Functions, BD, contenedores, etc) y a pesar que siempre es dicho explícitamente, serverless es “muy Cloud Native” a pesar que lo mas marketeado sea Kubernetes, entonces al final lo importante es ver lo que se requiere según tu necesidad, en algunos casos si, Kubernetes te va a cubrir perfectamente porque según el dimensionamiento es lo que va a requerir tu aplicación, en otros casos bastará un modelito modular y en ese caso puede ser un PaaS de los que he mencionado, y en otros casos la solución requerirá irnos por una solución serverless; pero al final en cualquiera de esos 3 casos tenemos opciones para poder cumplir con los requisitos para poder ser o nacer como Cloud Native.
Llegados a este punto, creo que ya tenemos la reflexión completa, y no queda sino recomendarles (a los interesados en el tema) la lectura del libro de Cornelia Davis, o en todo caso aprovechar la promoción de Oracle que esta ofreciendo la descarga de los capítulos en que justamente se discuten estos conceptos, nada mal ¿no? Como siempre dime que opinas sobre este tema.
(*) Proceso de llevar las aplicaciones, en nuestros datacenters, hacia la nube, procurando evitar el cambio de código, replicando en lo posible la infraestructura existente en el on premise.