Greenfield suena a libertad: campo vacío, sin lastre heredado, todo nuevo. En la práctica significa primero que no hay nada. Ni clúster, ni pipeline, ni estado de Terraform, ni migración de base de datos, ni secretos. Este artículo va detrás de la pregunta de por qué justo esa parte de un proyecto se subestima con tanta fiabilidad, por qué aun así sienta bien construirla, y en qué orden abordarla para que al final haya un producto y no solo unos cimientos.
Contenido
- Seis semanas hasta la fecha, tres de ellas en la sala de máquinas
- Lo que realmente falta en el campo verde
- Por qué la estimación de los cimientos se queda corta
- Por qué el trabajo en los cimientos se siente como avance
- Tiempo hasta el primer beneficio
- Primero el recorrido completo: el esqueleto andante
- Lo que debe existir el primer día y lo que puede esperar
- ¿Cuán delgados pueden ser unos cimientos?
- Las tres decisiones que arrastran todo lo demás
- Lo que pasa si los cimientos llegan más tarde
- Dónde encaja Vela Atlas
- FAQ
- Conclusión
- Fuentes
Seis semanas hasta la fecha, tres de ellas en la sala de máquinas
La escena se repite en casi todo arranque de proyecto. Un equipo recibe seis semanas hasta el primer estado presentable. El repositorio está vacío, el dominio está aclarado, la motivación es alta. Tras tres semanas hay un clúster funcionando, la pipeline está en verde, el módulo de Terraform está bien recortado. Lógica de negocio todavía no hay ninguna.
Nadie se ha relajado por el camino. Cada una de esas tres semanas estuvo llena de trabajo real y necesario. El problema no nace de un mal trabajo, nace de que ese trabajo nunca apareció en el plan con su tamaño real.
En la reunión de estado aparece entonces una frase que todos conocen: la infraestructura ya está, ahora empieza lo bueno. Para el cliente eso se lee como medio proyecto sin resultado visible. Y la mitad del presupuesto se ha ido.
Lo que realmente falta en el campo verde
En un plan, «setup» suele ser una línea. Desplegada, esa misma línea se ve así:
- Cuenta de cloud, organización, proyectos o cuentas por stage
- Identidades y permisos: quién puede desplegar, cómo se autentica la pipeline sin claves permanentes
- Red: VPC, subredes, tráfico saliente, acceso privado a la base de datos
- Clúster de Kubernetes, node pools, autoscaling, límites de recursos
- Registro de contenedores con su autenticación desde la pipeline y desde el clúster
- DNS y certificados, incluida la renovación automática
- Ingress o gateway, y con ello la pregunta de qué es accesible desde fuera
- Secretos: dónde están, cómo llegan al pod, cómo se rotan
- Base de datos, usuarios, permisos, backups y una herramienta de migración con su primera baseline
- Descripción del despliegue, es decir, charts de Helm o equivalente, configurable por stage
- CI/CD: build, test, construir la imagen, firmarla, desplegarla, y eso para cada stage
- Logging, métricas, un endpoint de health que diga algo con sustancia
- Entorno de desarrollo local que se acerque lo suficiente al objetivo
Son más de una docena de temas, y cada uno necesita una decisión, una implementación y una prueba. Ninguno es difícil. Aun así, sumados son semanas.
Más importante que la longitud de la lista es su propiedad: nada de lo que hay en ella distingue tu producto de la competencia. El usuario no paga por el ingress. Paga por lo que viene después.
Por qué la estimación de los cimientos se queda corta
Aquí actúan juntos tres mecanismos, y los tres tiran en la misma dirección.
Primero, los cimientos se estiman como una sola posición aunque son un paquete. La línea «montar la infraestructura» se valora a ojo, como recuerdo de la última vez. Lo que se estima es entonces el recuerdo del caso normal y no la suma de las piezas. Quien estima la lista de arriba línea por línea acaba regularmente en un múltiplo.
A eso se añade que cada decisión arrastra decisiones posteriores. La elección del ingress determina cómo se emiten los certificados. Eso determina si el DNS tiene que automatizarse. Eso determina quién necesita permisos de escritura sobre la zona. Esas cadenas son invisibles al estimar, porque en ese momento solo se ve el primer paso.
Y «terminado» significa en los cimientos algo distinto que en una funcionalidad. Una funcionalidad está terminada cuando funciona. Una pieza de infraestructura solo está terminada cuando es reproducible, igual en todos los stages y sigue ahí después de reconstruirla. La distancia entre «funciona en mi clúster» y «vuelve a funcionar igual después de terraform destroy y terraform apply» suele ser la parte mayor del trabajo.
A eso se suma un cuarto punto, más difícil de agarrar. En el campo verde no hay excusa para no hacerlo bien. En un sistema existente te frena el lastre heredado. Al principio no te frena nada, y justo eso es la invitación a dejar crecer el alcance.
Por qué el trabajo en los cimientos se siente como avance
Este trabajo tiene una propiedad que la lógica de negocio no tiene: devuelve respuesta al instante. Un terraform apply pasa o no pasa. Un pod se pone Ready o no. Una pipeline está verde o roja. Cada uno de esos momentos se siente como una pieza de trabajo cerrada.
La lógica de negocio no devuelve esa respuesta. Si el cálculo de precios es correcto a nivel de dominio, nadie lo sabe con seguridad después de dos horas. Eso resulta menos satisfactorio, y por eso la atracción hacia la sala de máquinas es real, especialmente entre desarrolladores con experiencia.
A eso se añade el deseo de hacerlo mejor esta vez. Uno conoce los puntos que dolieron en el proyecto anterior y quiere resolverlos limpiamente desde el principio. Es un buen instinto. Solo se vuelve caro cuando cae sobre un proyecto que todavía no ha entregado ni una línea de dominio, porque entonces optimizas para problemas que tu producto ni siquiera tiene.
La pregunta honesta en esta fase es esta: ¿estoy resolviendo un problema que tenemos hoy o uno que tuvimos en el proyecto anterior?
Tiempo hasta el primer beneficio
La mayoría de los proyectos mide el avance por tickets cerrados. Ese número sube con fiabilidad en las primeras semanas, aunque el usuario no saque nada de ello. Una pregunta más honesta es: ¿cuántos días pasan entre el primer commit y el momento en que un usuario real puede hacer algo que le sirva?
No es una métrica oficial salida de un framework. Las conocidas métricas DORA miden otra cosa, en concreto la rapidez con la que una organización ya en marcha entrega cambios. Para el arranque de un proyecto, el simple número de días hasta el primer beneficio real sigue siendo la magnitud más expresiva que puedes llevar, y tiene un efecto secundario agradable: no es negociable. Un equipo puede discutir sobre el grado de madurez de una pipeline, sobre este número no.
Si la llevas contigo desde el primer día, la discusión cambia. De «todavía nos falta GitOps» se pasa a «cuántos días cuesta GitOps y si retrasa el primer beneficio».
Primero el recorrido completo: el esqueleto andante
La contramedida más eficaz es antigua y viene de los primeros tiempos ágiles. Alistair Cockburn acuñó el término Walking Skeleton y lo desarrolló en «Crystal Clear» (2004).
No se refiere ni a un prototipo ni a un módulo terminado, sino a un camino. Algo mínimo recorre la ruta completa por todas las piezas implicadas, y lo hace antes de que ninguna de esas piezas se amplíe. Lo que ese camino haga a nivel de dominio es secundario. Lo importante es que toque cada pieza una vez, porque con eso queda demostrado que encajan entre sí.
Llevado a un arranque en la nube de hoy: existe un camino continuo desde un commit hasta una URL accesible en el entorno de destino, antes de que nada de eso se amplíe. El endpoint puede ser trivial. Lo decisivo es que esté realmente desplegado.
Un recorrido así está superado cuando esta secuencia funciona sin tocar nada a mano:
# 1. Cambio en el código, un único commit
git commit -am "add version endpoint" && git push
# 2. La pipeline se ejecuta entera sin intervención manual
# 3. El cambio es accesible en el entorno de destino
curl -s https://api.dev.example.com/version
# {"version":"2026.08.05-a1b2c3d"}Si esos tres pasos funcionan, la suposición más arriesgada del proyecto queda comprobada: que las piezas encajan siquiera entre sí. Todo lo que viene después es ampliación, y la ampliación se puede negociar, aplazar y priorizar. Un recorrido completo que falta no se puede negociar, bloquea todo.
La pipeline correspondiente puede ser ridículamente pequeña al principio. Ese es exactamente el punto:
name: deploy
on:
push:
branches: [main]
jobs:
ship:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: ./mvnw -B package
- run: docker build -t $REGISTRY/api:${{ github.sha }} .
- run: docker push $REGISTRY/api:${{ github.sha }}
- run: helm upgrade --install api ./chart --set image.tag=${{ github.sha }}Sin test gate, sin firma, sin nivel de aprobación, sin matriz sobre tres stages. Todo eso llega, pero llega después del primer recorrido completo y no antes.
Lo que debe existir el primer día y lo que puede esperar
La pregunta más difícil de esta fase no es qué se necesita. Al final se necesita casi todo. La pregunta es qué parte de ello tiene que estar antes del primer trozo de dominio.
| Tema | Antes de la primera lógica de negocio | Puede esperar | Por qué |
|---|---|---|---|
| Cuentas de cloud por stage | sí, al menos dos | endurecimiento de producción | Separarlas después significa volver a desplegarlo todo |
| Autenticación de la pipeline sin claves permanentes | sí | proceso de rotación | Quien empieza con claves de larga vida las cambia después en todas partes a la vez |
| Clúster | sí, en su versión más pequeña | autoscaling, node pools por workload | El tamaño es un número, la existencia es un proyecto |
| Base de datos más herramienta de migración | sí | réplicas de lectura, tuning | La primera migración fija la baseline, sin ella los stages divergen enseguida |
| CI/CD hasta el entorno de destino | sí | niveles de aprobación, firmas, test gates | Eso es el recorrido completo en sí |
| DNS y TLS | sí, para un entorno | wildcards, varios dominios | Sin una URL accesible no hay respuesta |
| Gestión de secretos | sí, en forma simple | gestión externa de secretos, rotación | El camino del secreto al pod tiene que existir una vez |
| Logging y endpoint de health | sí | tracing, dashboards, alerting | Sin logs depuras a ciegas |
| GitOps | no | sí | Cambia el procedimiento de despliegue, no la accesibilidad |
| Service Mesh | no | sí | Resuelve problemas que un servicio único no tiene |
| Más stages allá de dev | no | sí | Un entorno basta para el primer recorrido completo |
| Concepto de backup y recuperación | no | antes del paso a producción | Necesita datos reales para tener sentido |
La columna de la derecha es la más importante. Explica por qué un tema tiene que estar pronto, y ese motivo es casi siempre el mismo: si se añade más tarde, hay que reconstruir sustancia que ya existe. Todo lo que después se puede añadir de forma aditiva no pertenece a la primera semana.
¿Cuán delgados pueden ser unos cimientos?
Hay un criterio útil que viene del platform engineering. Matthew Skelton y Manuel Pais acuñaron en «Team Topologies» el término thinnest viable platform. La gracia está en la palabra «thinnest»: una plataforma no se mide por todo lo que sabe hacer, sino por lo poco que puede llegar a contener para que los equipos avancen igualmente sobre ella. Cada capacidad que está dentro tiene que mantenerla después alguien, y esa cuenta rara vez aparece en la estimación de construcción.
Para el arranque de un proyecto se puede plantear como pregunta: ¿cuáles son los cimientos más delgados sobre los que el dominio avanza hoy? No los más delgados de los que uno puede responder, y tampoco los más completos que uno podría construir.
El criterio es tan útil porque gira la discusión desde el gusto hacia un propósito. «Necesitamos un service mesh» es una cuestión de fe. «Avanza el dominio hoy sin service mesh» tiene respuesta, y con un servicio único la respuesta es sí.
Las tres decisiones que arrastran todo lo demás
No todas las decisiones pesan igual. Tres determinan tanto trabajo posterior que conviene tomarlas de forma consciente y temprana. El resto puede ir evolucionando.
La primera es la separación de los entornos. Que dev, staging y prod estén en cuentas o proyectos separados o solo separados por namespaces decide sobre permisos, redes, imputación de costes y sobre lo peligroso que es un despiste. Cambiarlo después significa crear cada recurso de nuevo.
La segunda es el camino de la pipeline hacia la nube. Que la pipeline se identifique con tokens de vida corta o con una clave permanente no es una formalidad. Un camino se apaña desde el primer día sin ningún secreto en el repositorio, el otro genera un proceso de rotación que alguien tiene que operar. No todos los proveedores dan las dos opciones, así que eso entra en la decisión de proveedor.
La tercera es el procedimiento de despliegue. Que la pipeline despliegue directamente o que un agente en el clúster tire de Git un estado deseado cambia dónde está la verdad y qué aspecto tiene un rollback. Ambas opciones son defendibles. Caro solo se vuelve el cambio a mitad de proyecto, porque toca cada stage y cada chart.
Todo lo demás, desde la elección del ingress hasta la herramienta de migración, se puede sustituir después con un esfuerzo asumible. Merece la pena decir esta distinción en voz alta una vez en el equipo, para que el tiempo de discusión fluya hacia donde cambia algo.
Lo que pasa si los cimientos llegan más tarde
La posición contraria a este artículo está extendida y suena razonable: primero construir el dominio, en local, sin nube, y la infraestructura llega cuando haya algo que desplegar. Eso ahorra tiempo al principio y solo desplaza el trabajo.
En la práctica ese camino cuesta en tres puntos. Para entonces, las suposiciones del entorno local están firmemente ancladas en el código, por ejemplo rutas de archivo, zonas horarias o una base de datos que en el test responde distinto que la real. Segundo, el primer deploy cae en la fase en la que la fecha ya aprieta, y el trabajo de infraestructura bajo presión de fechas es la variante más cara. Tercero, durante todo ese tiempo falta la respuesta de un entorno real, y así encuentras tarde justo los errores que se originan allí.
Cuánto trabajo hay entre un deploy que funciona y la preparación real para producción es un tema propio. El camino hasta allí está descrito en De desplegado a listo para producción.
Dónde encaja Vela Atlas
La lista del segundo capítulo es notablemente parecida de un proyecto a otro. El dominio es nuevo cada vez, los cimientos casi nunca. Justo ahí apunta Vela Atlas: configuras tu proyecto, nube, base de datos, stages y servicios, y recibes los cimientos ya desplegados en lugar de como tarea.
Está incluido lo que arriba figura en la columna «antes de la primera lógica de negocio»: Spring Boot como armazón de servicio, Terraform para la infraestructura, un clúster de Kubernetes con Helm y ArgoCD, una pipeline de CI/CD, una base de datos con migraciones, y además un manual que explica las decisiones tomadas. Eso vale sobre todo al arrancar nuevos proyectos greenfield, donde ese armazón básico hay que levantarlo desde cero y cuesta rápidamente semanas antes del desarrollo propiamente dicho.
Como nube hay tres proveedores a elegir: Google Cloud, AWS y Scaleway. Scaleway es la opción europea cuando los datos no deben salir del continente. Lo que eso significa en concreto está en Scaleway ya está.
El punto no es que nadie pueda construir estos cimientos por su cuenta. Casi cualquier equipo con experiencia puede. El punto es que esas semanas no producen nada que distinga el producto de otro.
FAQ
¿No es esto un argumento contra la arquitectura limpia?
No. Es un argumento contra el trabajo de arquitectura sin respuesta. Un diseño que nunca ha entregado nada está sin comprobar, por muy limpio que parezca. El recorrido completo entrega la respuesta sobre la que se puede seguir diseñando con sentido.
¿Cómo se estiman los cimientos de forma realista?
No como una sola posición. Coge la lista de temas sueltos, estima cada línea por separado y suma. El total será claramente mayor que la sensación de estómago, y justo esa diferencia es el importe que falta con regularidad en los proyectos.
¿Vale esto también para brownfield?
Solo en parte. En un sistema existente los cimientos ya están, pero cambiarlos sale más caro. La trampa en el sistema existente es otra: la gran modernización que corre en paralelo al día a día y nunca termina.
¿Merece la pena si solo tenemos un único proyecto?
El esfuerzo aparece igual en el primer proyecto. Lo que se añade cuando hay varios proyectos es la consistencia entre ellos. Con un único proyecto cuenta sobre todo cuándo aparece el primer beneficio.
¿No resuelve ya el problema una plataforma gestionada como Cloud Run o App Service?
Para un único servicio sin estado a menudo sí, y entonces ese es el camino más honesto. En cuanto entran varios servicios, una base de datos con migraciones, stages separados y permisos, buena parte de la lista vuelve a aparecer igualmente, solo que en otro sitio.
¿Y los asistentes de IA, no escriben ellos los cimientos sin más?
Escriben las piezas sueltas rápido y casi siempre de forma aprovechable. Lo que no te quitan es la decisión de qué piezas tienen que encajar entre sí, y la comprobación de si el resultado es reproducible. La ganancia de tiempo está al teclear, no al decidir.
Conclusión
Los proyectos rara vez fracasan por una mala arquitectura. Fracasan porque el presupuesto se agota antes de que se haya entregado el primer beneficio. En el campo verde el peligro es mayor, porque allí nada frena y todo parece posible.
El siguiente paso es poco espectacular: apunta cuántos días pasaron en tu último proyecto entre el primer commit y el primer beneficio real. Ese único número cambia el orden en el que empiezas la próxima vez.
Fuentes
- Alistair Cockburn: «Crystal Clear: A Human-Powered Methodology for Small Teams» (2004), sobre el Walking Skeleton
- Team Topologies (Matthew Skelton, Manuel Pais): What is a Thinnest Viable Platform (TVP)?
- DORA: métricas de rendimiento de entrega, como delimitación frente a la cuestión del arranque de proyecto descrita aquí
Todos los ejemplos de este artículo son propios y están recortados a propósito a lo imprescindible.