Cómo abordar una arquitectura multicloud con Google Cloud

Conoce los retos y oportunidades de armar una solución híbrida o multicloud con Google Cloud

Cada vez más empresas se inclinan por soluciones híbridas y multicloud con Google Cloud. Algunas son startups que buscan llegar a sus clientes donde están; otras son grandes empresas en busca de la mejor herramienta para resolver problemas, ofrecer alta disponibilidad o diversificar proveedores para reducir riesgos. Antes de lanzarte a armar una solución híbrida/multicloud (que suele ser parte de un proceso más amplio de modernización de aplicaciones), conviene conocer los posibles retos y oportunidades.

En este post profundizaré en estos temas para ayudar a entender quién es buen candidato para esta opción, qué retos debe tener en cuenta, qué soluciones existen y en qué situaciones conviene evitarla (al menos por ahora).

Definiciones

Empecemos con algunas definiciones:

• Nube pública – los servicios de cómputo bajo demanda y la infraestructura los gestiona un proveedor externo y se comparten con varias organizaciones a través de la Internet pública.
• Nube privada – la infraestructura está dedicada a una sola organización; puede alojarse en el data center de la propia empresa o en una instalación de colocation de un tercero.
• Nube híbrida – combina servicios on-premises, de nube privada y de nube pública de terceros, y orquesta la operación entre las distintas plataformas.
• Multicloud – combina múltiples servicios de cómputo y almacenamiento en la nube dentro de una arquitectura heterogénea; también hace referencia a la distribución de activos, software, aplicaciones, etc., en varios entornos cloud.
• Aplicación legacy – sistema de información, posiblemente basado en tecnologías obsoletas, pero crítico para la operación diaria; suelen ser aplicaciones monolíticas de tres capas, frágiles y difíciles de mantener y actualizar.
• Aplicación moderna – por lo general se refiere a una app compuesta por microservicios en una arquitectura N-Tier. Es tan confiable como debe serlo y puede actualizarse varias veces al día sin afectar la producción (una definición más amplia es la de la aplicación Twelve Factor).

Casos de uso

Esta no es una lista exhaustiva:

1. Etapa intermedia para mover infraestructura de TI cuya migración a la nube no es más que moderadamente compleja: por ejemplo, un cliente con una cantidad importante de servidores on-prem (normalmente Linux o Windows) establece una conexión por VPN o interconnect, y migra grupos de VMs a la nube (según los límites de los workloads de cada aplicación). A los clientes de la empresa los atiende una solución de nube híbrida con algunas aplicaciones corriendo on-prem y otras en la nube, hasta que todos los workloads se migren a la nube pública (nube híbrida).
2. El cliente quiere modernizar su solución, pero tiene aplicaciones y bases de datos muy difíciles de mover a la nube: por ejemplo, un cliente con un mainframe o una Oracle DB (esto último ya no es tan complicado) en su entorno de nube privada que quiere llevar la aplicación a una arquitectura moderna como Kubernetes (nube híbrida).
3. Requisitos regulatorios: por ejemplo, los requisitos de regionalidad de los datos pueden implicar que cierta información no pueda salir de las fronteras del país.
4. Cloudbursting: en este escenario, se aprovisiona capacidad adicional en la nube de forma automática y se escala si el entorno on-prem se satura. Esto suele pasar en retail durante eventos como Black Friday/Cyber Monday (nube híbrida).
5. Alta disponibilidad y disaster recovery (nube híbrida y multicloud).
6. Usar la nube adecuada para cada caso de uso: por ejemplo, tener Kubernetes y entornos de analítica de datos en Google Cloud Platform (GCP) y aplicaciones basadas en Microsoft en Azure.
7. Evitar el vendor lock-in.

Tech stack y capacidades necesarias

Veamos a fondo el tech stack y las capacidades que necesitas tener o construir, y los retos que esto puede suponer para las empresas en distintas etapas del camino:

Cómputo:

• Entender el entorno de nube privada — VMs y las distintas tecnologías a nivel del hipervisor: para empresas que ya están en una nube privada, esto obviamente no es problema. Para empresas digital native que no han tenido que lidiar con el tech stack ni con la política interna que implica implementar una solución cloud en un entorno de nube privada, puede ser un reto importante.
• Entender el entorno de nube pública: no es problema para las empresas digital native, pero puede generar problemas serios de seguridad y políticos internos para las empresas que hoy operan on-premises. Tendrán que aprender un nuevo stack con nuevas formas de gestionar VMs, autoescalado, etc.

Bases de datos y almacenamiento:

• Para las empresas que hoy están en nube privada, el reto es aprender y elegir una base de datos cloud-native acorde a sus necesidades. Las opciones fáciles son migrar a SQL Server/PostgreSQL/MySQL gestionado, pero, según los objetivos de negocio y técnicos, algunas empresas pueden querer o necesitar moverse a tecnologías como Spanner, BigTable y BigQuery. Esto puede ser un reto.
• Mantener dos tech stacks al mismo tiempo no es fácil: una empresa con una aplicación on-prem basada en Oracle que quiere migrar a PostgreSQL tiene dos opciones, según la complejidad y las funcionalidades en uso. La primera es un lift and shift a una opción bare-metal, seguido de modernización. La otra es dejarla donde está, modernizar en la nube privada y luego migrar a la nube. En ambos escenarios, la empresa tendrá que operar dos tipos de DBs en paralelo hasta que la modernización esté completa y se pueda apagar una de ellas.

Networking:

• Hay diferencias importantes entre el networking en la nube pública y la privada — e incluso entre las distintas nubes. Por ejemplo, la VPC global de Google Cloud aporta un beneficio enorme para simplificar tu networking. Muchas empresas de nube privada necesitan aprender cómo funciona esto. También les cuesta decidir conscientemente no replicar en la nube pública la forma en que hacen las cosas en la privada.
• Configurar VPNs, partner-interconnect e interconnects puede ser sencillo en algunos casos, pero podría tomar semanas o meses, según la ubicación de la nube privada del cliente.

Seguridad:

• Implementar medidas de seguridad unificadas y listas para producción en entornos híbridos y multicloud puede complicarse. Cada proveedor de nube tiene medidas de seguridad distintas implementadas de formas distintas. La forma en que despliegas el software y lo pruebas en busca de vulnerabilidades durante el proceso de deployment puede ser un proyecto en sí mismo.
• Implementar sistemas de monitoreo de seguridad en múltiples nubes es todo un reto.

CI/CD:

• Construir de forma confiable un pipeline de Continuous Integration y Continuous Deployment (CI/CD) para construir, probar, asegurar y desplegar tanto la infraestructura (IaC, como Terraform o Pulumi) como las aplicaciones en múltiples entornos es un reto enorme. Además, exige Engineers y herramientas muy sofisticados y capaces.

Modernización:

• Decidir qué modernizar y cómo hacerlo en aplicaciones y DBs no es tarea menor y exige fases significativas de evaluación y planificación. Para los clientes de nube privada, aprender K8s y la mejor manera de trabajar con el sistema puede tomar meses o incluso años, además de un cambio organizacional importante.

Autenticación:

• El reto es manejar SSO Federation, AD Federation, etc. en múltiples plataformas a través de una única fuente de verdad.

Equipo:

• Es difícil encontrar Engineers/arquitectos con experiencia en múltiples plataformas, así que necesitas invertir en la capacitación de tus equipos.
• La alternativa es aprender y mantenerse al día en múltiples entornos, en un mundo cloud que cambia a toda velocidad, mientras se arman equipos separados con distintos perfiles y se intenta definir un proceso de negocio para que trabajen juntos de forma eficiente.

Costo:

• Al igual que montar un entorno multi-región de alta disponibilidad (HA), montar una solución multicloud o de nube híbrida puede salir hasta diez veces más caro. No se trata solo de levantar otra VM o base de datos y pagar por eso: las operaciones de Day 2 — orquestación, replicación, costo de egress de red y el soporte a las personas y mecanismos de estos sistemas — suman bastante.
• Las empresas necesitan pensar en FinOps y construir una cultura en la que los equipos gestionen sus costos de nube, cada uno se haga responsable de su consumo, un grupo central de mejores prácticas dé soporte y se logre una visión 360° del costo híbrido/multicloud.

Definir una solución

A estas alturas seguramente piensas que multicloud y nube híbrida son realmente difíciles, pero como esa es la dirección hacia donde va la industria, hay que encontrar una solución.

Es importante entender que este tipo de proyectos lleva tiempo, y luego trabajar siguiendo esta metodología:

1. Evalúa la cultura de tu empresa, tus prácticas de DevOps, tu tech stack, etc.
2. Planifica con base en los objetivos de negocio y tecnológicos de tu empresa, y en los resultados de la evaluación. Ten claro que habrá curvas de aprendizaje importantes, tanto dentro de tu empresa como con tus clientes, frente a los cambios que hagas en tu sistema. Esto puede tomar tiempo y necesitas dejar que las personas se adapten a las nuevas metodologías y a la nueva tecnología.
3. Migra/refactoriza: empieza despacio y en pequeño, deja que las personas fallen rápido, aprendan del error y mejoren. Si arrancas despacio, la velocidad irá aumentando de forma incremental. No intentes optimizar mientras cambias de plataforma, codebase, etc.
4. Optimiza una vez hecho el cambio inicial y con un nuevo sistema funcionando. Trabaja la optimización tanto desde la perspectiva del rendimiento como del costo.

Construir el tech stack híbrido óptimo

Ninguna solución tecnológica del mercado lo resuelve todo. Tienes que evaluar tu stack y combinar soluciones para crear un tech stack híbrido completo.

Capa de aplicación:

GCP Anthos es una excelente solución que cubre varias de las piezas necesarias para operar la capa de código/aplicación de tu solución. Incluye las siguientes capas, que te permiten orquestar y correr clusters de Kubernetes e incluso VMs (en private preview) en GCP, AWS, Azure, nube privada y bare metal.

Capas de aplicación de Google Cloud Anthos

Anthos clusters, la capa de Kubernetes gestionada en la base del stack, hace que las operaciones de Day 2 sean mucho más fáciles que cuando corres tus propios clusters de Kubernetes open source.

Anthos Ingress es un controlador de Ingress multi-cluster alojado en la nube para clusters de GKE.

Anthos Service Mesh es un conjunto de herramientas que te ayuda a monitorear y gestionar un service mesh confiable, ya sea on-premises o en Google Cloud.

Anthos Config Management es un servicio de gestión de configuración y políticas que combina tres componentes: Policy Controller, Config Sync y Config Controller. Juntos, permiten que Anthos Config Management proteja y configure de forma continua tus recursos de Google Cloud y Kubernetes.

Anthos fleets (antes conocidos como environs) son un concepto de Google Cloud para organizar lógicamente clusters y otros recursos, lo que te permite usar y gestionar capacidades multi-cluster y aplicar políticas consistentes en tus sistemas.

Limitaciones: conviene tener en cuenta que el servicio se limita a controlar y monitorear únicamente las partes de tu solución que corren dentro del entorno de Anthos.

Capa de base de datos y almacenamiento:

• Si operas tus propias capas de almacenamiento y DB fuera del alcance del cluster, puedes apoyarte en servicios gestionados de DB como CloudSQL o RDS.
• Si operas la DB dentro de tu cluster de Kubernetes (por ejemplo, MySQL o MongoDB), agregas una carga operativa importante al correr tu propia DB en el cluster en lugar de usar las versiones gestionadas del proveedor cloud.

Seguridad + monitoreo:

• SIEM + monitoreo: busca herramientas que ofrezcan una solución multicloud/nube híbrida, como Splunk, Datadog o PagerDuty.
• Seguridad y gestión de secretos: por ejemplo, HashiCorp Vault y AWS Secrets Manager.

CI/CD:

• Soluciones del mercado como Gitlab y Jenkins funcionan en distintos entornos y te permiten construir y desplegar tanto contenedores como VMs.

Si no necesitas construir y desplegar VMs, échale un vistazo a spinnaker.

Aprovisionamiento de infraestructura:

• Algunas opciones son HashiCorp Terraform, Red Hat Ansible y Pulumi.

Para cerrar:

• Armar una solución híbrida/multicloud es muy difícil y muy costoso, tanto desde la perspectiva de personas y procesos como desde la tecnológica.
• Tecnologías como GCP Anthos dan soporte a una solución multicloud, pero ninguna tecnología por sí sola ofrece una solución end-to-end. Hay que tenerlo en cuenta al diseñar la arquitectura de tu solución.
• El proceso será más fácil para las empresas que ya corren Kubernetes en producción a escala, ya sea on-prem o en la nube.
• Será más difícil para:

  • Empresas que corren aplicaciones legacy monolíticas on-prem. Armar una solución híbrida y la transformación que se requiere en procesos de negocio, capacitación de personas y cambio en el tech stack puede tomar entre dos y diez años, según la complejidad y la escala del cambio.

    Hacia ahí va el mercado, y las empresas que pasan por este proceso ven un ROI significativo. Eso sí, al embarcarse en este camino, conviene moderar las expectativas y entender la magnitud del reto.

  • Startups con equipos pequeños: Kubernetes es interesante y emocionante, y tu startup quiere atender a cada cliente en cada entorno, pero los recursos son limitados y necesitas un producto funcional con la menor carga operativa y de costo posible. Dados los retos inherentes, enfócate primero en tener un producto viable (sin perder de vista la portabilidad de los workflows) y una base de clientes en una sola nube, usando la mayor cantidad posible de servicios totalmente gestionados. Cuando tu equipo sea lo suficientemente grande y la solución suficientemente estable, empieza a explorar cómo refactorizar y operar una solución multicloud.

Si quieres saber más sobre este tema y además ver una demo de cómo funciona Anthos en un entorno multicloud, regístrate en nuestro evento el 22 de febrero de 2022, a la 1 p.m. GMT.

No dudes en contactarnos si tienes preguntas o quieres conversar sobre tu camino hacia una aplicación moderna en un entorno híbrido o multicloud.