BusiRocket

Tecnología

Google Cloud

Google Cloud resuelve bien un problema concreto: dejar de administrar máquinas para administrar servicios. La base de datos se actualiza sola, el almacenamiento no se llena un domingo y el clúster reemplaza un nodo muerto sin que nadie se entere. Cuando ése es el problema, compensa. Cuando no lo es, es una segunda plataforma que mantener encima de la que sirve a los usuarios.

La prueba honesta es qué hace la carga. Con tráfico previsible y un solo servicio, un servidor bien configurado gana en simplicidad y en coste. Con varios servicios, equipos que publican por su cuenta y picos que no se pueden predecir, la orquestación se paga sola.

Donde está justificado, casi todo el valor está en las partes aburridas: peticiones y límites de recursos que reflejan uso medido y no suposiciones, comprobaciones de salud que fallan por los motivos correctos, secretos que nunca entran en una imagen, y manifiestos plantillados por entorno para que preproducción y producción se diferencien solo en lo que deben.

La experiencia detrás de esto es operar plataformas de ese tamaño sobre GKE, con Cloud SQL como base gestionada, Cloud Storage para el contenido servido e imágenes publicadas en Artifact Registry desde integración continua. La conclusión que sale de ahí suele ser usar menos infraestructura, no más.

Lo que decide la factura no es el precio por hora de las máquinas, es cuántas veces se transfieren datos entre zonas, cuántas réplicas están encendidas por si acaso y cuánto tiempo vive un entorno de pruebas que nadie apaga. Esas tres cosas explican la mayor parte de las sorpresas a fin de mes, y las tres se arreglan con decisiones de diseño, no cambiando de proveedor.

La parte que más se nota al entrar en un proyecto ajeno es cuánta infraestructura hay encendida que nadie sabe explicar: un clúster de pruebas de hace dos años, réplicas que se levantaron para un pico que ya pasó, cubos de almacenamiento sin política de ciclo de vida. Ese inventario es siempre el primer entregable, porque decide a la vez la factura del mes que viene y qué se puede tocar sin miedo.

Hechos concretos

  • Plataformas servidas desde GKE con Helm como unidad de despliegue y ficheros de valores por entorno: desarrollo, preproducción y producción, con promoción explícita.

  • Cloud SQL como base gestionada y Cloud Storage para el contenido servido, en un portal financiero de 24 millones de usuarios al año y 18.000 usuarios simultáneos en pico.

  • Imágenes publicadas en Artifact Registry y construidas en integración continua, no desde el portátil de nadie.

Proyectos hechos así

GKE

Entrega continua sobre Kubernetes y GKE

La capa que nadie ve: charts de Helm, migración a la Gateway API de GKE y flujos de despliegue por entorno para que un equipo de producto publique sin ser experto en clústeres.

Clientes bajo confidencialidad

  • kubernetes
  • gcp

Cómo trabajamos

Cuatro pasos, sin sorpresas

El mismo proceso en un encargo de tres semanas y en una plataforma de dos años.

  1. 01

    Alcance

    Una sesión para entender el proceso de negocio, no para enseñar plantillas. Salimos con prioridades y precio por fases.

  2. 02

    Arquitectura

    Modelo de datos, integraciones y presupuesto de rendimiento antes de escribir la primera pantalla.

  3. 03

    Construcción

    Entregas semanales en un entorno visitable. Lo que se aprueba se despliega, no se acumula.

  4. 04

    Operación

    Monitorización, copias verificadas y despliegues que cualquiera del equipo puede ejecutar.

Preguntas frecuentes

¿Merece la pena Google Cloud para mi proyecto?

Depende de qué haga la carga, no del tamaño de la empresa. Una web de contenido con tráfico previsible funciona mejor en un servidor bien configurado con certificados automáticos y copias probadas. Google Cloud empieza a rentar cuando hay varios servicios con ciclos de publicación distintos, variabilidad real de tráfico o requisitos de datos que un servidor único no cubre. Este mismo sitio corre como aplicación Node en un cPanel corriente, y es la recomendación correcta para lo que es.

¿Cuánto cuesta de verdad?

Más que la factura, y esa es la parte que sorprende. El coste real incluye actualizar el clúster, mantener la entrada de tráfico y que alguien lo entienda a las tres de la mañana. Ese coste va en la comparación junto al importe mensual, y es la razón por la que muchas veces la respuesta es usar menos infraestructura, no más.

¿Podéis haceros cargo de un proyecto que ya está en Google Cloud?

Sí, y se empieza por un inventario: qué servicios hay, qué los despliega, dónde viven los secretos y cómo se detiene hoy un despliegue malo. De ahí sale la lista de qué es seguro tal cual, qué hay que actualizar primero y qué saldría más barato simplificar que mantener.

¿Y si mañana queremos irnos a otro proveedor?

Se planifica desde el principio decidiendo qué se ata al proveedor y qué no. Contenedores, Helm y Postgres se mueven; una función propietaria pegada a un servicio concreto, no. La diferencia entre una migración de semanas y una reescritura se decide el primer día, no el último.

Siguiente paso

Hablemos de lo que tiene que hacer tu web

Respondemos en un día laborable con una propuesta de alcance por fases, o con la razón por la que creemos que no somos el estudio adecuado para el encargo.