Cloud Native: ¿Una necesidad para las organizaciones?

Nos encontramos en una época donde las organizaciones se encuentran en medio de la transformación más importante de la historia. Estamos llegando al punto donde casi todas las empresas comienzan a migrar sus cargas de trabajo a la nube. Con esta migración empezamos a ver la necesidad de rediseñar los sistemas y arquitecturas para aprovechar por completo el potencial de la nube. Es por este motivo, que es esencial hablar del Cloud Native, también conocido como aplicaciones nativas de la nube. ¿Por qué es tan necesario?

Beneficios del cloud computing

La esencia de la nube es poder obtener recursos informáticos bajo demanda, ya sea en minutos o hasta en cuestión de segundos. En lugar de días o semanas que se podría tardar en incrementar recursos en un entorno on-premise…

Lo cual también se ven implicado los costos, ya que, en un entorno de nube se paga únicamente por el incremento o los nuevos recursos informáticos. Si en algún momento se dejan de usar estos recursos, también se deja de pagar por ellos (pagas solo por lo que usas). A diferencia de un entorno on-premise, donde si inviertes en recursos nuevos y posteriormente se dejan de usar es muy poco probable que se pueda recuperar esa inversión y en algunos casos puede llegar a convertirse de inversión a gasto para una organización.

Microservicios y cloud native ¿es lo mismo?

A menudo se asume que los microservicios y aplicaciones nativas de la nube es lo mismo, pero en realidad, los microservicios son solo un patrón arquitectónico que se puede usar al crear aplicaciones nativas de la nube.

Las siguientes son algunas de las arquitecturas de cloud native más populares que existen, se describen ventajas y desventajas de su uso.

Microservicios

Un único microservicio está diseñado para realizar una sola acción, un microservicio nunca debería de manejar consultas de saldos y también recarga de saldos. Identificar la mejor manera de diseñar una aplicación nativa de la nube en un conjunto de microservicios bien diseñados no es una tarea fácil.

Los microservicios generalmente se integran entre sí a través de interfaces REST o sistemas de mensajería (por ejemplo, ActiveMQ). Actualmente, está tomando mucha relevancia los servicios gRPC por su rapidez en la comunicación. Aunque aún tiene algunas desventajas importantes por lo que actualmente es recomendado principalmente para comunicación interna.

Es probable que un microservicio orientado a la web use una interfaz REST o GraphQL, pero es más probable que uno interno use un sistema de mensajería como Apache Kafka o mediante el protocolo gRPC. Los sistemas de mensajería generalmente son muy resistentes a los problemas de la red, ya que una vez que el sistema de mensajería ha aceptado el mensaje, lo almacenará hasta que se pueda procesar con éxito.

La promesa clave de la arquitectura basada en microservicios es que cada microservicio se puede implementar, actualizar y escalar de forma independiente. Lo que permite a los equipos que manejan microservicios trabajar en paralelo y realizar actualizaciones sin la necesidad de coordinarse.

Esto es un gran desafío, ya que llega a ser común que en lugar de construir microservicios se terminen construyendo monolitos distribuidos donde al final llegan a surgir dependencias y se pierden los beneficios que otorga una arquitectura de Microservicios.

Monolitos. ¿Cómo influyen en el cloud native?

Los monolitos están fuertemente asociados con arquitecturas de aplicaciones anteriores a la de microservicios (solo hay una aplicación para construir, implementar y administrar). Se puede llegar a considerar un anti-patrón para las aplicaciones nativas de la nube, pero por los siguientes motivos es que es considerado para el cloud native.

• Los monolitos son el tipo de aplicaciones más simple de construir. Si bien los servicios individuales no se pueden escalar de forma independiente, siempre que el monolito haya sido diseñado para escalar, esto puede no ser un problema.
• Existen muchos monolitos y muchas empresas los están trasladando a la nube.

Lo importante con un monolito es asegurarse de que, a pesar de la colocación de servicios en un solo artefacto de implementación, el monolito pueda iniciarse lo suficientemente rápido como para permitir el escalado dinámico y reiniciarse si hay una falla en la aplicación.

Función como servicio (FaaS)

La función como servicio (Faas), más comúnmente conocido como serveless, es una arquitectura en la que se crea un servicio como una función que se ejecuta cuando se produce un evento. FaaS promete que puede implementar la función en una nube, y es iniciada y ejecutada por el disparador del evento, en lugar de tener que ejecutar la función. Por lo general, los proveedores de nube pública que admiten FaaS solo cobran por el tiempo que se ejecuta la función. Esto llega a ser muy atractivo si el evento es relativamente poco común, ya que no hay costo financiero en tener un sistema en funcionamiento cuando ocurre un evento poco común.

El desafío con esta arquitectura es que la función debe de iniciarse rápidamente y, por lo general, también debe terminar de ejecutarse rápidamente; como resultado, no es adecuado para procesos de larga duración.

Eventos

A menudo, pensamos en los servicios como un endpoint REST o SOAP. El problema con este enfoque es que una llamada REST o SOAP es implícitamente síncrona y propensa a problemas si el proveedor de servicios funciona con lentitud o falla.

Cuando se proporciona una API externa a una aplicación móvil o un navegador web, una API REST suele ser la mejor opción. Sin embargo, para servicios con comunicación interna, existen muchos beneficios al usar un sistema de mensajería como Kafka y usar eventos asíncronos en su lugar. Un sistema de mensajería que puede garantizar que el mensaje sea entregado y permite que el cliente y el servicio se desacoplen, de tal manera que un problema con el proveedor del servicio no impida que la transacción sea finalizada con éxito; solo significaría que se va a procesar más tarde.

Conclusión sobre el cloud native

Como podemos observar, existen diferentes tipos de arquitecturas de aplicaciones que pueden implementarse como Cloud Native. Basado en las necesidades de cada organización se deberá de adoptar y diseñar la arquitectura adecuada. En muchas ocasiones me ha tocado ver que las empresas quieren adoptar lo que esta moda… Tener en mente que lo que este de moda, no precisamente puede ser lo que necesita nuestra empresa.

Existirán necesidades donde una arquitectura basada en monolitos será mejor en costo-beneficio que cualquiera del resto de las arquitecturas mencionadas. Pero también existirán otras necesidades donde una arquitectura basada en microservicios traiga más beneficios a la organización.

Julio González, consultor técnico en SOAINT.