40M
Migrar 40 millones de comentarios sin perder ninguno
Migración completa de la plataforma de comentarios de un medio de alto tráfico, con reversión instantánea.
- typescript
- nextjs
- kubernetes
- stripe
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
40M
Migración completa de la plataforma de comentarios de un medio de alto tráfico, con reversión instantánea.
Nivel 8
Plugin de cPanel y WHM con licencia MIT, multiinquilino, con tokens cifrados por usuario y un demonio supervisado por systemd. Sin cron.
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.
24M
Frontend, rendimiento y fiabilidad en producción sobre una plataforma de cotizaciones en tiempo real.
Cómo trabajamos
El mismo proceso en un encargo de tres semanas y en una plataforma de dos años.
Una sesión para entender el proceso de negocio, no para enseñar plantillas. Salimos con prioridades y precio por fases.
Modelo de datos, integraciones y presupuesto de rendimiento antes de escribir la primera pantalla.
Entregas semanales en un entorno visitable. Lo que se aprueba se despliega, no se acumula.
Monitorización, copias verificadas y despliegues que cualquiera del equipo puede ejecutar.
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.
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.
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.
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
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.
Usamos una cookie de analítica para saber qué páginas se leen. No hay publicidad ni perfilado, y sin tu permiso no se instala. Ver la política de cookies