Arquitectura cloud para un SaaS B2B: decisiones que importan en los primeros 12 meses
Montar la infraestructura cloud de un SaaS B2B es una serie de decisiones que se van pagando o amortizando durante años. Estas son las que más impacto tienen en las primeras fases y cómo las abordamos en nuestros proyectos.
El coste de las decisiones tempranas
La infraestructura de un SaaS B2B no es neutral. Las decisiones que se toman en los primeros meses —proveedor de cloud, base de datos, modelo de despliegue, estrategia de datos— tienen un peso enorme en el coste operativo, la velocidad de iteración y la capacidad de escalar durante años.
El problema es que esas decisiones se toman con información incompleta, bajo presión de tiempo, y en un momento en que el equipo está más ocupado construyendo producto que pensando en infraestructura.
Este artículo recoge las decisiones de arquitectura cloud que más impacto tienen en las primeras fases de un SaaS B2B, desde la perspectiva de haber tomado —y cometido— muchas de ellas en proyectos propios y de clientes.
Decisión #1: proveedor de cloud
La elección entre AWS, Google Cloud y Azure es menos importante de lo que parece en las fases iniciales, y más difícil de cambiar de lo que parece una vez estás comprometido.
Los tres proveedores tienen los servicios fundamentales que necesita un SaaS B2B en fase inicial: cómputo, base de datos gestionada, almacenamiento de objetos, CDN, networking. Las diferencias relevantes están en:
Ecosistema de clientes y decisiones de equipo: si el equipo tiene experiencia sólida en uno de los proveedores, esa experiencia vale más que las diferencias técnicas entre plataformas. El proveedor que el equipo conoce bien se despliega más rápido, se opera con menos errores y tiene menor coste de formación.
Integraciones con el resto del stack: si el producto tiene dependencias fuertes con servicios específicos —BigQuery para analytics, Vertex AI para ML, Firebase para tiempo real—, Google Cloud puede ser la opción más natural. Si hay integración con Active Directory y productos Microsoft, Azure tiene ventajas.
Mercado objetivo: algunos sectores tienen preferencias de proveedor consolidadas. El sector financiero en Europa tiende a tener aprobaciones más rápidas para AWS y Azure que para Google Cloud. En entornos de investigación y academia, Google Cloud tiene una presencia fuerte.
Para la mayoría de SaaS B2B en fase inicial sin restricciones fuertes de sector o equipo, nuestra recomendación es Google Cloud Platform: mejor experiencia de desarrollo con herramientas como Cloud Run y Cloud SQL, modelo de red más predecible, y precios competitivos en las cargas de trabajo más comunes en SaaS.
Decisión #2: serverless vs. contenedores gestionados
Esta es la decisión que más afecta a la velocidad de iteración en las primeras fases.
Serverless —Cloud Functions en GCP, Lambda en AWS, Azure Functions en Azure— elimina la gestión de infraestructura casi por completo. No hay servidores que gestionar, el escalado es automático, el coste es proporcional al uso. Para muchos SaaS B2B en fase inicial, es la opción que permite moverse más rápido.
Las limitaciones son reales: arranques en frío, timeouts máximos, limitaciones de memoria, y —la más importante— un modelo de ejecución diferente del que los desarrolladores están acostumbrados que puede introducir bugs sutiles en aplicaciones con estado.
Contenedores gestionados —Cloud Run en GCP, Fargate en AWS, Container Apps en Azure— dan más control sin la complejidad de gestionar Kubernetes. El contenedor tiene el mismo comportamiento que en local, el despliegue es predecible, y el modelo de ejecución es familiar. Cloud Run en particular tiene características muy atractivas: escala a cero cuando no hay tráfico (coste cero en idle), escala automáticamente cuando hay carga, y no tiene arranques en frío problemáticos si se configura correctamente.
Nuestra recomendación para SaaS B2B en fase inicial: Cloud Run para el backend principal. La combinación de contenedor estándar, coste proporcional al uso y modelo de despliegue simple es difícil de superar. Serverless para funciones auxiliares —webhooks, procesamiento de eventos, tareas periódicas— donde el modelo de ejecución sin estado es un fit natural.
Kubernetes solo cuando el equipo tiene la madurez operativa para gestionarlo y la escala lo justifica. Para la mayoría de SaaS B2B, eso llega mucho más tarde de lo que se espera.
Decisión #3: base de datos
La elección de base de datos es donde más errores difíciles de revertir vemos en proyectos de SaaS B2B.
El error del NoSQL por defecto
Hubo una época en que MongoDB o Firestore parecían la respuesta por defecto para cualquier nuevo proyecto, bajo la promesa de esquema flexible, escalado horizontal y modelo de datos más natural para aplicaciones.
En la mayoría de SaaS B2B, esas promesas no se materializan y los problemas sí. El esquema flexible se convierte en inconsistencia de datos. El escalado horizontal raramente se necesita en las fases donde se tomó la decisión. Y la necesidad de joins entre entidades —que emerge casi siempre en cualquier aplicación de negocio— tiene soluciones costosas en NoSQL y simples en SQL.
La recomendación es directa: usa PostgreSQL por defecto. Es el sistema de base de datos relacional más avanzado de código abierto, tiene extensiones que cubren casos de uso muy específicos (PostGIS para datos geoespaciales, pgvector para embeddings, TimescaleDB para series temporales), y tiene un ecosistema de herramientas y conocimiento extenso.
En GCP, Cloud SQL para PostgreSQL o AlloyDB son las opciones gestionadas. AlloyDB es significativamente más rápido que Cloud SQL para cargas de lectura intensiva, pero tiene un precio más alto. Para la mayoría de SaaS en fase inicial, Cloud SQL es suficiente.
Multi-tenancy: cómo separar los datos de clientes
En un SaaS B2B, los datos de distintos clientes tienen que estar separados. Hay tres estrategias principales:
Schema por tenant: cada cliente tiene su propio schema en la misma base de datos. Buena separación de datos, gestión de migraciones más compleja.
Base de datos por tenant: cada cliente tiene su propia base de datos. Máximo aislamiento, coste más alto, más complejo de gestionar.
Row-level security: todos los clientes comparten las mismas tablas, con un campo tenant_id y políticas de seguridad a nivel de fila que garantizan que cada cliente solo ve sus datos. Más simple de gestionar, requiere más cuidado en la implementación para evitar filtraciones.
Para SaaS en fase inicial con pocos clientes y restricciones de presupuesto, row-level security en PostgreSQL es la opción más práctica. PostgreSQL tiene soporte nativo para Row Level Security (RLS) que hace que la separación sea transparente para la aplicación y verificable por la base de datos.
Decisión #4: CI/CD desde el primer día
El equipo que no tiene CI/CD desde el primer día paga ese coste en deuda técnica durante meses. Desplegar manualmente es lento, propenso a errores y no escala.
El pipeline mínimo viable para un SaaS B2B:
- Push a rama de feature → tests automáticos (unitarios + integración)
- Pull request → preview environment automático con URL única
- Merge a main → despliegue automático a staging
- Tag de release → despliegue automático a producción con approval gate
Cloud Build en GCP, GitHub Actions o GitLab CI son las opciones más comunes. La elección importa menos que tenerlo desde el principio.
Los preview environments son particularmente valiosos en SaaS B2B: permiten que stakeholders no técnicos —clientes piloto, el equipo de ventas— revisen features antes de que lleguen a producción, sin necesidad de coordinar accesos a staging.
Decisión #5: observabilidad desde el inicio
El equipo que solo añade observabilidad cuando algo falla en producción paga un precio alto: no sabe qué falló, cuándo empezó a fallar, ni si la solución que aplicó realmente funcionó.
Los tres pilares de la observabilidad:
Logs estructurados: logs en formato JSON con contexto suficiente —user ID, tenant ID, request ID, operación— para que cuando algo falle se pueda reconstruir la secuencia de eventos. Cloud Logging en GCP recoge automáticamente los logs de Cloud Run.
Métricas: latencia de las APIs (p50, p95, p99), tasa de errores, recursos consumidos (CPU, memoria, conexiones de base de datos), métricas de negocio (nuevos usuarios, conversiones, churn).
Trazas distribuidas: en sistemas con múltiples servicios, las trazas permiten seguir una request a través de todos los componentes y ver dónde se gasta el tiempo. Cloud Trace en GCP, o OpenTelemetry si quieres portabilidad.
Para SaaS en fase inicial, Cloud Operations Suite (antes Stackdriver) en GCP cubre los tres pilares con configuración mínima. No es la herramienta más avanzada del mercado, pero tiene la ventaja de estar integrada y no requiere infraestructura adicional.
Decisión #6: gestión de secretos y configuración
Las credenciales en el código son uno de los errores de seguridad más frecuentes en proyectos SaaS jóvenes. Secret Manager en GCP, AWS Secrets Manager o HashiCorp Vault son las opciones para gestionar credenciales, API keys y configuración sensible de forma segura.
El patrón que recomendamos:
- Variables de entorno para configuración no sensible (feature flags, timeouts, URLs de servicios propios)
- Secret Manager para credenciales y claves de API
- IAM para el control de acceso (qué servicios pueden leer qué secretos)
- Rotation automática para credenciales de base de datos y API keys que lo soporten
Nunca credenciales en el código. Nunca credenciales en variables de entorno de CI/CD sin cifrar. Nunca credenciales en ficheros de configuración commiteados al repositorio.
El coste de la infraestructura en las primeras fases
Un patrón que vemos repetidamente: equipos que sobredimensionan la infraestructura en las primeras fases por miedo a quedarse sin capacidad, y que pagan costes de cloud diez veces superiores a lo necesario.
Un SaaS B2B con 100 clientes activos y 10.000 peticiones diarias puede operar cómodamente con:
- Cloud Run: un servicio con mínimo 0 instancias (escala a cero), máximo 10, 1 CPU y 512MB de RAM. Coste: menos de 50€ al mes con uso normal.
- Cloud SQL PostgreSQL: instancia
db-f1-microodb-g1-smallpara empezar. Coste: 15-40€ al mes. - Cloud Storage: almacenamiento de objetos para assets estáticos. Coste: céntimos.
- Cloud Build: CI/CD. Coste: prácticamente gratuito a este volumen.
Total: menos de 150€ al mes para una arquitectura que puede escalar a decenas de miles de clientes con ajustes incrementales. La infraestructura no debería ser un coste significativo hasta que el negocio tiene tracción real.
Lo que importa en las primeras fases y lo que puede esperar
En los primeros doce meses de un SaaS B2B, el objetivo de la infraestructura es uno: no convertirse en el cuello de botella del equipo. Eso significa:
- Despliegue rápido y sin fricción (CI/CD)
- Disponibilidad suficiente para no perder clientes (99.9% basta)
- Costes proporcionales al negocio
- Capacidad de evolucionar cuando el negocio lo requiera
Lo que puede esperar: optimización de costes avanzada, redundancia multi-región, CDN global, bases de datos read replicas, Kubernetes. Todo eso tiene sentido cuando el negocio lo justifica. Invertir en ello antes es sobreingeniería que consume tiempo que debería dedicarse al producto.
La arquitectura cloud perfecta no existe: existe la arquitectura correcta para el momento y el tamaño del negocio. El trabajo del equipo de ingeniería es tomar las decisiones que den más opciones abiertas en el futuro, no las que parezcan más impresionantes hoy.
Etiquetas
Cuéntanos tu proyecto
Te ayudamos a encontrar la solución tecnológica adecuada, sin humo ni presiones.
Hablar con nuestro equipo