Rendimiento y datos
Desarrollo en Google Cloud
Construimos y operamos la mitad de atrás de un ecommerce sobre Google Cloud: contenedores serverless en Cloud Run, imágenes construidas por Cloud Build, credenciales en Secret Manager, y cada servicio con identidad propia.
Contenedores serverless, no un montón de VMs
Casi todo lo que un negocio de ecommerce necesita de una nube son unos pocos servicios pequeños que responden HTTP, guardan algo de estado, hablan con Shopify y entre ellos, y no cuestan nada cuando nadie está comprando. Cloud Run hace exactamente eso, y lo hace sin pedirte que operes un clúster.
Lo que separa un proyecto de Cloud Run que envejece bien de uno que se vuelve el problema de alguien es la capa aburrida: un build reproducible, un artefacto al que puedas apuntar, secretos que no viven en el repo, una service account por servicio en lugar de una llave de dueño, y un despliegue que puedas deshacer. Esa capa es la que construimos.
- Escala a cero
- Un servicio que solo corre cuando lo llaman no cuesta nada de madrugada. Para jobs de catálogo y herramientas internas, eso es casi todo el día.
- Identidad por servicio
- Cada servicio corre con su propia service account de IAM y solo con los permisos que su trabajo necesita, así un token comprometido no es la llave de todo.
- Un build trazable
- Cloud Build produce una imagen etiquetada en Artifact Registry, así cada revisión en producción se puede rastrear hasta un commit y no hasta la laptop de alguien.
Lo que cubre el trabajo
- Servicios en Cloud Run con contenedores, revisiones y control de tráfico
- Pipelines de Cloud Build desde un repositorio de GitHub
- Artifact Registry para imágenes versionadas y trazables
- Secret Manager para credenciales, conectado al runtime
- Roles de IAM y service accounts de runtime por servicio
- Buckets de Cloud Storage con acceso uniforme, CORS y reglas de ciclo de vida
Tecnologías
- Google Cloud Run
- Cloud Build
- Artifact Registry
- Secret Manager
- IAM
- Cloud Storage
- Node.js
- Docker
Dónde ayuda más
Una API detrás de una tienda
Un servicio Node.js al que llama tu tema o tu app de Shopify, que necesita ser rápido, barato en reposo y seguro de desplegar un viernes.
Cargas de catálogo y archivos
Importaciones, exportaciones, procesamiento de imágenes y subida de documentos que pertenecen a object storage y a un job, no a una petición web.
Servicios compartidos entre varias tiendas
Un backend sirviendo a más de una tienda, donde la configuración por tienda y la identidad por servicio importan por igual.
Cómo lo entregamos
Definir los servicios
Decidimos qué es un servicio y qué son tres, qué necesita estado, y qué puede ser un job en vez de un proceso corriendo permanentemente.
Build y registry
Un Dockerfile, un trigger de Cloud Build y un repositorio de Artifact Registry, para que un push se vuelva una imagen y una imagen se vuelva una revisión.
Identidad y secretos
Cada servicio recibe su service account y lee su configuración de Secret Manager. Nada sensible vive en el repositorio ni en un script de despliegue.
Operarlo
Health checks, logs estructurados, rollback por revisión, y una nota escrita de qué es cada servicio y con quién habla.
Desarrollo en Google Cloud
¿Necesitamos Kubernetes?
¿Cloud Run puede hablar con nuestra base de datos?
¿Cuánto cuesta operarlo?
¿También migran aplicaciones existentes?
¿Listo para empezar con desarrollo en google cloud?
Cuéntanos sobre tu tienda y tus objetivos. Volveremos con un plan claro y honesto y una cotización transparente.