Qué construimos con él
Google Cloud es donde los contenedores que construimos consiguen realmente un sitio donde ejecutarse. Kubernetes gestionado, almacenamiento de objetos, bases de datos gestionadas, balanceo de carga y terminación TLS, además de la identidad y la red a su alrededor.
La razón para usar una plataforma gestionada no es que salga más barata por CPU; a menudo no lo es. Es que las actualizaciones del plano de control, la rotación de certificados y el parcheo de nodos dejan de ser el trabajo de alguien. En un equipo pequeño esa es la diferencia entre que la infraestructura sea una preocupación de fondo o sea una persona.
Dónde encaja
Bajo la historia de despliegue: contenedores construidos en CI, empaquetados con Helm y aplicados a un clúster gestionado. El código de aplicación sigue siendo portable: nada en él sabe en qué nube está, y eso es deliberado.
Cuándo lo recomendamos
Para productos que necesitan un clúster de verdad, autoescalado o servicios de datos gestionados, y para equipos que preferirían no ser dueños de las partes poco diferenciadas de administrar servidores.
No somos dogmáticos sobre qué nube. El diseño que buscamos es uno donde la elección sea reversible: contenedores, Kubernetes y Helm son portables, así que un cambio es una migración de servicios gestionados y no una reescritura. Si ya estás en otro proveedor, o si tus requisitos de cumplimiento apuntan a un sitio concreto, ese suele ser el argumento más fuerte.
Para un único servicio pequeño con tráfico estable, un clúster de cualquier tipo es más de lo que el trabajo necesita: un runtime de contenedores gestionado es menos que operar y menos que equivocar.
