Estas son (según Google) las aplicaciones modernas.

Que todo cambia muy rápido es algo que ya sabemos, y si, encima, estamos hablando de “cosas de ordenadores”, el término muy rápido se nos queda corto. Hoy en día queremos ejecutar nuestras aplicaciones de la manera más moderna posible y si pudiera ser, que siguiera estando a la última durante algunos meses…

Con aplicaciones modernas hablamos de aplicaciones que escalan y que son portables, fáciles de hacer y mantener gracias a la separación de funcionalidades y a la observabilidad de los sistemas.

En este post vamos a hablar de aplicaciones modernas y del stack que tendremos que usar para lograr este objetivo. Concretamente, vamos a hablar de la manera que nos propone Google que, de esto, sabe un poco.

Como podréis ver, en este post no vamos a citar ningún lenguaje de programación ¿Y eso? Esto va de cómo hacer las cosas, no de con qué y, por lo tanto, el lenguaje de programación es lo de menos (siempre que no uses ‘ese’ lenguaje que estás pensando). Una de las ventajas de usar este enfoque consiste en que se lleva bien con sistemas políglotas (aquellos que tienen servicios escritos en más de un lenguaje).

Infraestructura moderna

Google lleva mucho tiempo desarrollando su propia tecnología (con ayuda de otras soluciones Open Source) para solventar sus problemas, obteniendo buenos resultados con ello y, lo que es mejor, liberalizando gran cantidad de estas soluciones que se han convertido en los estándares de la industria. En este punto de la historia, la visión que vamos a exponer está aceptada casi unánimemente como la mejor manera de tener una infraestructura moderna y flexible.

Esta propuesta de infraestructura para aplicaciones modernas está basada en los siguientes conceptos:

• Uso de tecnologías Open Source. Esto nos da capacidad de migrar las cargas de un entorno o nube a otro ¡Minimicemos el vendor lock in!
• Contenedores Docker para ejecutar nuestras cargas, tanto stateless como stateful.
• Istio como service mesh para la separación de funciones.
• Los microservicios solo tienen que ocuparse de la lógica de negocio, separando las tareas de seguridad, conexión y telemetría.
• Unificación de la observabilidad: monitorización, logs y alertas.

Teniendo en cuenta esto, nos encontramos con que nuestra plataforma tendrá que tener las cargas de trabajo en contenedores Docker. Cada contenedor vivirá en un pod que contenga un proxy Envoy configurado por Istio para controlar las conexiones, la seguridad y el envío de telemetría. Todos los procesos se orquestan en clusters de Kubernetes y se usa Stackdriver (u otros productos) para monitorización y logs.

A continuación vamos a profundizar un poco en los componentes que podemos usar en Google Cloud Platform para seguir estas premisas.

Google Kubernetes Engine (GKE)

Kubernetes gestionado y securizado en GCP. Añade una capa de abstracción para manejar clusters fácilmente. Por describirlo con pocas palabras: “El kubernetes sin esfuerzo”. Uno de los productos estrella de GCP que cuenta con un montón de características sin, por ello, perder la compatibilidad con otros kubernetes. Veamos algunas de sus virtudes más importantes:

• Levanta clusters en pocos minutos, y en pocos clics gracias a la Consola web o de manera programática gracias a las APIs y el cliente de terminal gcloud.
• Elimina trabajo con opciones de autoreparación de nodos, auto actualización y auto escalado.
• Uso transparente de los elementos de GCP, VM (incluso con GTU y TPU), discos (hdd o ssd), balanceadores de carga, redes...
• Integrado con Stackdriver.
• Clusters multizona para alta disponibilidad.
• Kubernetes certificado para asegurar compatibilidad. Si algún día tienes que dejar de usar GKE podrás llevarte tus procesos fácilmente. Además, la gran mayoría de proveedores tienen versiones de Kubernetes gestionadas.
• Uso de máquinas *preemptive de bajo coste para cargas no críticas.
• Integrado con Cloud Run. Pudiendo ejecutar contenedores en modo serverless gracias a K native.

Istio

Posiblemente, el más famoso de los service mesh, Istio funciona perfectamente con Kubernetes y nos ofrece aislar las funciones de conexión, seguridad, control y observación de nuestros servicios.

¿Por qué es necesario un service mesh? Con el cambio de monolitos a microservicios se ganó en facilidad de desarrollo, pero gran parte de esa complejidad se trasladó de las aplicaciones a la comunicación entre los servicios: descubrimiento de los mismos, control de red, seguridad de las comunicaciones, monitorización… Según crecía nuestra red de micro servicios cada vez costaba más controlarlos y por eso se empezó a pensar en mallas de servicios (aka service mesh) como una solución para estos problemas, una manera de quitar complejidad y gestionarla uniformemente.

Ahora viene un micro-resumen de cómo funciona Istio. Para poder realizar sus tareas, Istio inyecta en cada pod un contenedor con un proxy (llamado envoy, como dijimos antes) de ayuda que se encarga de capturar todas las conexiones tanto entrantes como salientes para enrutar, asegurar la conexión y enviar los datos de telemetría. Además de estos “minions” para cada contenedor necesitamos un panel de control que se ocupe de controlarlos, inyectarlos y actualizarlos, una especie de titiritero que mueve los hilos.

En este panel de control tenemos tres componentes principales:

• Pilot. Gestiona las conexiones, tablas de enrutamiento. Cada proxy tendrá toda la información necesaria para enrutar las conexiones salientes (a qué servicios se puede conectar, cuántas réplicas, políticas de enrutamiento)
• Mixer. Telemetría, políticas. Para enviar los datos de la conexión a los sistemas de telemetrías (configurables mediante plugins) y revisar que se cumplen las políticas de cuotas y conexiones.
• Citadel. CA para la conexión segura entre los microservicios gracias al protocolo de securización mutua mTLS. Cuando activamos la seguridad entre nuestros servicios se dice que se aplica una política de confianza cero en la red ya que todas nuestras comunicaciones irán cifradas aunque todo el tráfico se transmita por nuestra red interna.

Es importante destacar que Istio puede enviar los datos a muchos recolectores de datos gracias a su sistema de plug ins. Dentro de GCP lo normal es usar su integración con StackDriver pero hay otras opciones que son igual de válidas. Como cambiar entre sistemas de telemetría no afecta al código de nuestras aplicaciones, desacoplamos completamente la parte de procesado y la de observabilidad.

¡Ojo a esto! Una vez que tenemos nuestras aplicaciones corriendo en este stack podemos no solo moverlas a cualquier otro entorno, sino que también podemos conectar los entornos para que trabajen conjuntamente.

Esto lo podemos hacer en gran medida gracias a Istio. Istio nos permite conectar los servicios de diferentes clusters de varias maneras, abriendo la puerta a entornos híbridos o multi nube:

• Cada cluster con su panel de control. Al tener replicados los clusters de control eliminamos un punto de fallo al replicar los paneles y aumentamos la carga de gestión.
• Compartiendo paneles de control en la misma red. Los pods acceden a los servicios en otros clusters directamente.
• Compartiendo paneles de control en distintas redes. Cada cluster tiene su Gateway para enrutar llamadas de otros clusters. Todos los citadels se configuran con el mismo root CA (autoridad certificadora raíz) para que funcione el mTLS (el mismo protocolo que usamos para conectarnos a webs seguras, pero en su versión dual).

Cloud Run

La versión gestionada de K native nos permite ejecutar cargas serverless sobre kubernetes o sobre la plataforma serverless de GCP, pudiendo elegir donde ejecutamos nuestros procesos. Gracias a este servicio tenemos las ventajas de los productos serverless como App Engine o Cloud Functions sin la limitación de lenguajes, librerías y el odioso vendor lock in. Si se puede ejecutar en un contendor, lo podemos ejecutar en Cloud Run.

Con Cloud Run podemos elegir cuántas llamadas puede atender cada contenedor, el uso de memoria o CPU, definir qué servicios o personas pueden ejecutarlo y ver fácilmente logs, trazas y métricas. Todo muy serverless, todo muy portable.

Stackdriver

La solución cloud gestionada para la observabilidad de los recursos de GCP (y otras fuentes gracias a sus conectores). Colecta datos de manera que no afectan al rendimiento de los componentes, analiza y monitoriza tu infraestructura en tiempo real, capacidad de crear tus propios indicadores, alarmas, métricas... Además, te permite crear dashboards con los datos de varios proyectos.

Una de las características que más gustan es el poder enviar subconjuntos de datos a BigQuery en streaming para luego poder analizarlos en caso de ser necesario. Fácil, potente y muy recomendable.

Marketplace

El marketplace de GCP nos permite encontrar soluciones listas para instalar con solo un click. Dispone de soluciones en MV, en contenedores y soluciones listas para cargar en Kubernetes.

Además de soluciones gratuitas nos encontramos con soluciones de pago que tienen integrado el coste en GCP. En una sola factura tendremos agrupados todos los costes, facilitándonos la vida. ¿Necesitas un cluster de Casandra para tu Kubernetes? Está a solo 3 clicks de distancia.

Todo muy bonito pero... ¿de verdad es portable?

Todos estos componentes tienen su versión OpenSource de forma que cuando queramos podemos llevarnos nuestras cargas a otro entorno, ya sea on premise u otra nube.

• *Instalable sobre cualquier kubernetes certificado.
• ** Istio tiene conectores para muchísimos servicios de telemetría, podemos configurar esta parte de manera sencilla con los servicios que más nos gusten sin tener que tocar el código de nuestros servicios.

Como hemos visto, hacer las cosas bien no es tan complicado como parece y los beneficios merecen mucho la pena. Gracias a conceptos como la contenerización, las mallas de servicios y los sistemas de telemetría, podemos soñar con un futuro en el que nuestras aplicaciones no se queden obsoletas… tan pronto.