Anthos: descubriendo sus secretos.

Anthos es la solución propuesta por Google para desarrollar arquitecturas híbridas y, dentro de poco, también en arquitecturas multi nube. Anthos es una plataforma, un stack, un conjunto de piezas que nos permite modernizar nuestras aplicaciones y conectar nuestro data center con Google Cloud Platform (GCP).

En este post, vamos a abrir la tapa y ver qué es Anthos, sus elementos, sus fortalezas y cuándo merece la pena usarlo. Pero, antes de empezar a hablar de Anthos vamos a poner las bases necesarias para entenderlo. Veremos qué es la nube híbrida y cuando tiene sentido usarla. Una vez claros estos conceptos veremos la propuesta tecnológica de Anthos y los problemas que soluciona.

Preparados, listos, ¡ya!

¿Qué es la nube híbrida?

La nube híbrida o Hybrid Cloud consiste en hacer un puente entre los entornos on premise y el cloud público para poder ejecutar nuestros procesos en cualquiera de los entornos de la manera más integrada posible. Hablando a 100.000 metros de altura, se compondría de 3 piezas: entorno on premise, entorno en la nube y la conexión entre ellas (por VPN o conexión directa).

Esto es perfecto para las empresas con grandes volúmenes de carga en entornos on premise. Muchas de estas empresas quieren modernizar sus aplicaciones, pero aún no están preparadas para migrar completamente a la nube porque o no quieren o no pueden.

Por supuesto, que esto no es una solución perfecta en todos los casos. Vamos a ver algunos ejemplos en los que aplicar el enfoque de nube híbrida sí que tiene más sentido.

• Uso de la nube para picos de trabajo. Navidades, rebajas, acciones comerciales… siempre hay situaciones en las que necesitamos más potencia de procesamiento durante un tiempo limitado donde el pago por uso de la cloud pública es muy rentable.
• Recuperación de desastres. Consiste en tener tus aplicaciones preparadas para funcionar en la nube en caso de problemas, al tener la nube un modelo de pago por uso es perfecta para estos casos.
• Poder operar en nuevas regiones (por latencia o motivos legislativos). Gracias a su flexibilidad geográfica, trabajar en la nube es la mejor manera de extender nuestro negocio a otras zonas del planeta de forma segura, rápida y económica.
• Entornos efímeros para desarrollo, test y pre-producción, capacidad de crear entornos rápidamente y pagar solo cuando sea necesario hace que merezca la pena usar la nube.
• Procesos on premise por imperativo legal. Ciertos negocios tienen que ejecutar los procesos y mantener los datos en sus data center. Gracias a la hibridación pueden ejecutar el resto de las cargas en la nube, como el front end o el servir ficheros estáticos.

Mirándolo desde otro punto de vista, podemos considerar que la nube híbrida puede ser una manera de realizar la transición de on premise a la nube en la que hay un periodo de convivencia que se puede extender todo el tiempo que sea necesario.

Tradicionalmente, el camino a la nube se basaba en tres aproximaciones:

1. Lift and shift. Mover las máquinas virtuales desde el data center a un proveedor cloud sin realizar cambios. No siempre es posible y las mejoras no son grandes al no aprovechar todo el potencial de la nube.
2. Replatforming. Adaptación de los procesos a la nueva plataforma, en un punto intermedio entre las tres aproximaciones.
3. Refactoring. Enfoque más ambicioso que consiste en rediseñar todo para que sea cloud native.

El enfoque de la nube híbrida es diferente a estos tres caminos ya que busca modernizar las aplicaciones on premise para luego poder elegir dónde las queremos ejecutar. Otra diferencia importante es que podemos considerar la nube híbrida como una fase de transición o como un final, quedándonos en la nube híbrida todo el tiempo que queramos.

Gracias a las soluciones de nube híbrida es posible hacer la transición de manera sencilla y segura ejecutando cargas en los dos sitios de la manera más homogénea posible.

Rumbo a lo híbrido

Como ya hemos dicho al principio del post, Anthos no es un producto, sino una manera de hacer la nube híbrida según la visión de Google. Es una solución que va más allá de conectar dos entornos y poder establecer comunicaciones entre ellos de manera segura. Necesitamos que tanto en cloud como en on premise la manera de ejecutar nuestras aplicaciones sea similar.

Como vimos en este otro post, la mejor manera (o una de las mejores) de construir o modernizar aplicaciones consiste en ejecutarlas en microservicios sobre contenedores controlados por Kubernetes y usando Istio para quitarles todas esas tareas que no son propiamente de los microservicios. Para mejorar la observabilidad de nuestra infraestructura tendremos un sistema unificado como puede ser Stackdriver.

Lo primero que tenemos que hacer es mover todas las cargas posibles (stateless y stateful) a un cluster kubernetes con Istio y los sistemas de observación que tengamos dentro de on premise. Con este paso, ya habremos modernizado nuestra infraestructura pero aún no podemos usar todo el potencial de la nube pública, en este caso GCP.

El siguiente paso sería conectarnos con nuestro entorno cloud mediante uno de estos tres tipos, según nuestras necesidades de conexión:

• Cloud VPN: La manera más sencilla y barata pero también la que menos garantía nos da en cuanto a latencia y velocidad. El tráfico va por internet de manera segura a través de un túnel IPsec.
• Partner Interconnect: Conexión a través de un partner a la red de Google, más flexible en cuanto a la velocidad contratada, los SLA son compartidos entre Google y el partner que ofrece el servicio. El tráfico no sale a internet.
• Direct Interconnect: Conexión directa con Google en múltiplos de 10Gb/s. Google nos ofrece SLA en todo el camino. El tráfico no sale a internet.

Por último, nos queda configurar nuestro Istio en nuestros clusters para que puedan encontrar y autenticarse correctamente entre ellos.

Los nuevos problemas

Llegados a este punto, el avezado lector estará pensando: “si con esta configuración puedo ejecutar kubernetes y compañia sobre cualquier plataforma e incluso conectarlas de forma segura... ¿para qué $%&¬ necesito Anthos?”

La respuesta a esta pregunta es la que vamos a intentar responder en lo que queda del post. Pero aquí va un spoiler: si bien puedes tener tu infraestructura híbrida sin Anthos donde quieras, Anthos te va a hacer la vida mucho más fácil según se complica tu infraestructura más y más y, eso amigos, es el quid de la cuestión. Como diría cierto ex presidente de España: “Anthos te va a hacer la vida mucho más fácil y mucho fácil. Cuanto más peor para ti, mejor; y cuanto más mejor para ti, también.

Seguro que se ha entendido perfectamente, pero, aún así, vamos a justificar nuestro razonamiento viendo los problemas más importantes de tener un entorno híbrido:

1. Configuración de Kubernetes. ¿Es correcta la versión que estoy usando? ¿Estoy siguiendo las buenas prácticas? ¿Es homogénea entre mis clusters?
2. Gestión de los clusters. Crear y configurar un cluster de Kubernetes es muy sencillo (bueno, no lo es, pero es asumible). El ir añadiendo nodos, reparándolos, subiendo las versiones, complica el asunto. Los namespaces nos permiten hacer separaciones lógicas dentro de un cluster pero no impiden que necesitemos crear más clusters (por departamentos, por localizaciones, por entornos). Controlar un cluster o dos puede ser viable, pero según crece el número cada vez nos llevará más tiempo el gestionarlo y tendremos más posibilidades de error.
3. Gestión del service Mesh. Con el service mesh nos ocurre lo mismo, al ir aumentando el número de clusters es más complicado de gestionar, por no hablar de las actualizaciones, el control de los certificados de seguridad o estar seguro de usar las prácticas correctas.
4. Gestión de la configuración. Definir la configuración de nuestros clusters es una tarea delicada que puede causarnos más de un dolor de cabeza. La distribución de cambios, aseguramiento de su aplicación y subsanamiento en caso de cambios no autorizados es complejo y aún no existe en Open Source una solución que nos ayude a hacer esta tarea más fácil.
5. Panel unificado. Cuando tenemos varios clusters on premise y varios en GCP es confuso el tener clara una idea del estado de nuestra infraestructura y nuestro service mesh, independientemente de dónde se ejecuten las cargas.

Como vemos, no solo es importante poder ejecutar en cualquier entorno, también hay que tener en cuenta la gestión, configuración y observabilidad de la infraestructura resultante.

Y entonces... llegó Anthos

La idea de Anthos es poder trabajar en varios entornos con las mismas facilidades con que trabajaríamos si solo estuviéramos en la nube. Esto no es nada fácil y será un camino largo por recorrer. Según van pasando los meses, Anthos va ganando piezas y funcionalidades para conseguir este objetivo.

Anthos nos va a permitir trabajar con los clusters de Kubernetes de manera homogénea permitiéndonos instalar en nuestro entorno on premise GKE on prem de forma que tendremos la opción de usar los clusters on prem de una manera muy similar a como lo hacemos en GCP. Mediante un agente vamos a poder conectar nuestro GKE on prem a GCP y, así, tener en el GKE hub todos nuestros clusters, pudiendo ver su información, enviar aplicaciones y gestionarlos desde la consola de GCP. Además de Kubernetes, gracias a Anthos Service Mesh nos será posible tener Istio de una manera gestionada en todos los clusters trabajando como una malla única. Otro punto importante a tener en cuenta es la gestión de la configuración que Anthos Config Management hace sencillo y robusto gracias al enfoque de Configuración como Código.

Estos son los pilares de Anthos, sus piezas clave, pero no los únicos:

• GKE / GKE on-prem.
• Anthos Service Mesh.
• Anthos Config Management.
• Migrate for Anthos.
• Anthos Marketplace.
• Run for Anthos.

GKE on prem

De momento se puede ejecutar solo sobre servidores VCenter y, a diferencia de otras soluciones, aquí no hay que comprar nada de hardware, todo se soluciona mediante las instalación de una OVA (Open Virtual Appliance) en el servidor.

GKE nos permite tener, sin hacer nada, un sistema de gestión de clusters de Kubernetes listo para producción. Todo con las mejores prácticas y casi todas las ventajas de usar GKE en la nube, con funcionalidades como reparación de nodos o actualizaciones automáticas. Además, está integrado con muchas opciones de GCP como el registro de contenedores o Stackdriver.

Para poder hacer esto posible se crea un cluster especial llamado admin cluster que se encarga de gestionar el resto de clusters de GKE on prem y conectarse con la nube. Con este producto puedes gestionar la identidad como quieras, usando la de Google (Cloud Identity) u otra que prefieras.

La realización de la conexión entre este GKE y GCP se realiza mediante un agente implementado de forma que no se necesita disponer de una ip expuesta al exterior (con tener conexión a internet, vale). Una vez realizada la conexión tienes que autentificar a los usuarios con los credenciales de GKE on prem en la consola de Google. Puede parecer lioso, pero esto nos permite que cada usuario pueda tener permisos diferentes. Por decirlo de otra manera, cada usuario verá en la consola de GCP los clusters con los mismos permisos que tenga en el entorno on premise ya que necesita registrarlos con sus credenciales.

Desde la versión 1.1 puedes integrar los clusters con Stackdriver para usar el sistema de monitorización de GCP. Esto es muy interesante ya que nos ofrece una suite completa de observabilidad completamente gestionada.

En cuanto a los modos de red, tendremos dos opciones de configuración: el llamado modo isla (cada cluster tiene su espacio de direcciones y necesita usar servicios para comunicarse con el exterior) y el modo flat ip (todos los clusters comparten espacio de direcciones). El modo flat ip es relativamente nuevo y aún no está listo para ser usado en producción por lo que se recomienda el uso del modo isla.

Anthos Service Mesh

Istio gestionado y preparado para producción que podemos instalar fácilmente en nuestros clusters on premise o en GCP. Al ser un servicio completamente gestionado no nos tenemos que preocupar del aprovisionamiento y manejo de Istio en nuestros clusters. Esto nos quita mucha carga de gestión y nos da tranquilidad.

Centrado en la seguridad, se encargará de configurar los certificados por toda la malla de forma que minimizamos los posibles errores y aseguramos que los secretos se rotan de manera correcta entre toda nuestra red de microservicios.

Nos permite tener un Istio con las mejores prácticas y actualizado en todos nuestros clusters.

Es un producto muy nuevo que permitirá tener todo el service mesh controlado desde un panel de control en GCP (la monitorización solo funciona con los clusters en GCP).

Anthos Config Management

Considerada la pieza más innovadora de Anthos, Config Management no tiene correspondencia Open Source y su objetivo es cambiar la manera en la que controlamos la configuración de Kubernetes para poder tenerlo todo bajo control. Esto se consigue al usar la configuración como código, también conocido como CaC.

La solución propuesta es parecida a la que se usa en IaC o Infraestructura como Código, en la que usamos código para definir el estado deseado de nuestra infraestructura. Al tratarla como código podemos gestionarla con un repositorio git, saber quién realizó los cambios, volver a estados anteriores o reparar fácilmente algún desajuste. El código estará en un repositorio Git únicamente de forma que tendremos una única fuente de verdad para toda nuestra configuración.

En el caso de la configuración, nos aprovechamos de dos características de kubernetes:

• Objetos: En Kubernetes todo son objetos con propiedades, incluida la configuración de kubernetes. De esta forma podemos ver todo nuestro cluster como un conjunto de objetos, cada uno con su clase y con sus propiedades.
• Declarativo vs Imperativo: Decimos que un comando se da de forma imperativa cuando lo que definimos es la acción; por ejemplo, diciendo que queremos ejecutar fichero. Con los comandos declarativos lo que indicamos es el estado que deseamos y dejamos al sistema que se encargue de conseguirlo: en lugar de aumentar el número de pods de un servicio en 1, lo que decimos es que queremos un total de 6. Será kubernetes el encargado de hacer los cálculos para que el número sea 6 hasta que no le digamos lo contrario.

Por un lado, tenemos todo en objetos que pueden ser consultados o modificados y, por el otro, la opción de decirle a Kubernetes el estado deseado.

Con Anthos Config Management tendremos en todos los entornos un agente que estará revisando todo el rato que el estado de los objetos de configuración es el correcto y, luego, cada Kubernetes de cada cluster se encargará de que se cumplan las condiciones definidas por sus objetos.

El flujo para hacer los cambios sería el siguiente:

1. Los encargados de la configuración modifican el repositorio que contiene la definición de todos los objetos de configuración y comitean el cambio.
2. Un proceso de aprobación opcional valida que los cambios son correctos y pasan a una rama productiva en el repositorio Git.
3. La nueva versión de la configuración llega a todos los agentes, que se encargará de aplicar los cambios indicando a todos los clusters los nuevos objetos de configuración.
4. Cada cluster se encargará de ajustarse para que esos parámetros se cumplan.

Ahora vamos a ver qué pasaría si alguien se salta este procedimiento y cambia un objeto a manita de un determinado cluster.

1. Sujeto caótico 1, con permisos de administración, modifica la configuración de un Cluster 7 añadiendo por error un namespace.
2. El agente de ACM detecta que la configuración facilitada por el Cluster 7 no coincide con la que está en el repositorio y vuelve a cambiarla para que coincida.
3. El namespace generado por error es eliminado y el universo vuelve a la tranquilidad…

Migrate for Anthos

Migrate for Anthos es la manera sencilla de meter en contenedores máquinas virtuales, ya sea desde servidores físicos, desde Compute Engine o desde otras plataformas como AWS.

Además de poder migrar cargas podemos hacer simulaciones y planificar las migraciones mediante la definición de cuadernos de migración.

Este servicio no tiene coste de licencia asociado a su uso, no es necesario tener la licencia de Anthos, aunque sí nos facturará por el consumo de recursos que usamos para la migración, como pueden ser las máquinas virtuales que controlan el proceso o el tráfico de red utilizado.

Run for Anthos

Una de las mayores ventajas de la nube es poder usar sus productos serverless para ejecutar código de manera segura, escalable y muy muy fácil. El serverless es un concepto genial que ha tenido históricamente un gran pero: el vendor lock in que nos dificulta cambiar de plataforma de manera sencilla.

Gracias a K-native (versión Open Source de Cloud Run) se pueden tener cargas serverless usando contenedores de una manera portable. Cloud Run es la versión gestionada que nos permite lanzar nuestros servicios desarrollados en contenedores en GCP, en nuestros clusters de kubernetes ahora permite también ejecutarlos en nuestros clusters on prem, todo ello de manera integrada y muy, muy sencilla.

Anthos marketplace

El marketplace de GCP es un sitio donde se puedeN encontrar soluciones listas para usar fácilmente. En él, tenemos soluciones gratuitas y de pago (con la facilidad de unificar el pago en nuestra factura de GCP). Gracias a unos filtros podemos seleccionar aquellas soluciones que están pensadas para ser ejecutadas en clusters Kubernetes, tanto en nube como en on prem.

Las soluciones tienen un apartado que nos permite configurar la solución y una documentación donde veremos cómo usarlas. En el momento en que estoy escribiendo este post hay más de 75 soluciones con el logotipo de Anthos… ¿Qué necesitamos para desplegar un cluster de Casandra en nuestro datacenter? Va a ser cuestión de un par de clicks….

Y esto ha sido todo (por ahora)

Para terminar vamos a ver una serie de conclusiones sobre Anthos:

• Componentes testados. Anthos se basa en un stack tecnológico que se sabe que funciona, que funciona bien, y que se ha convertido en una solución adoptada por empresas en todo el mundo.
• Nice to have. Una de las ventajas de esta propuesta es la libertad, gracias al uso de tecnologías Open Source tú puedes elegir si ejecutar tus cargas con o sin Anthos, con GCP o sin GCP, o ir cambiando según tus necesidades. Puede ser que ahora mismo no tengas suficiente complejidad para necesitar Anthos pero en unos años si. Usar Anthos es recomendable pero no necesario.
• Facilidad de gestión. Anthos nos permite gestionar todos nuestros cluster de manera unificada, incluyendo la observabilidad.
• Seguridad. Anthos ofrece servicios de soporte para la empresas (con lo importante qué es esto).
• Y aún queda mucho por andar. Anthos es un producto muy nuevo que irá mejorando en funcionalidades y componentes para solucionar más problemas.