En la bitácora repetimos una idea que aparece en casi todos los proyectos: el arranque no se define por la herramienta que elegís, sino por el orden en que tomás las decisiones. Contenedorizar todo de una vez, o saltar directo a un clúster administrado sin haber medido la carga real, suele costar semanas de retrabajo. Estas son las cinco cosas que documentamos como punto de partida concreto, con el resultado esperado de cada una.
Levantar qué procesos escriben en disco, qué rutas absolutas asume el código y qué dependencias de red existen entre componentes. Sin ese mapa, el contenedor arranca en local y falla en el clúster por motivos que nadie ve en el Dockerfile. El resultado es una lista corta de servicios que sí se pueden mover primero y cuáles necesitan refactor previo.
Kubernetes no es la respuesta automática. Para un servicio único con tráfico estable, un contenedor con reinicio supervisado alcanza y se opera con menos superficie de error. La decisión se documenta con criterios: cantidad de réplicas, tolerancia a caídas, necesidad de balanceo interno y frecuencia de despliegue. Así se evita montar un clúster que después nadie mantiene.
Definir subredes, reglas de ingreso y nombres de servicio resuelve la mitad de los incidentes de arranque. Si hay componentes que se comunican por colas, configurar reintentos con backoff y una cola de mensajes muertos desde el inicio evita que un consumidor lento arrastre al resto. Es más barato diseñarlo ahora que depurarlo en producción un viernes.
Métricas de latencia, tasa de error y saturación de recursos, más logs con identificador de traza. No hace falta acumular todo: alcanza con las series que vas a mirar durante un incidente. El resultado es poder comparar el comportamiento del servicio legado contra la versión en contenedor con datos, no con impresiones.
Definir la estructura de módulos que van a reutilizar los equipos y mover el estado a un backend remoto con bloqueo. Trabajar con estado local compartido por accidente genera planes que se pisan y recursos huérfanos difíciles de rastrear. El resultado es que dos personas pueden aplicar cambios el mismo día sin romper la infraestructura.
Cada uno de estos puntos tiene su entrada desarrollada en la bitácora, con fragmentos de configuración y capturas de paneles del estado inicial de un despliegue. Si querés ver cómo se aplican sobre un caso concreto, podés revisar los temas que cubrimos o empezar por los recorridos de referencia que armamos para equipos de plataforma.
No hay una fecha de inicio única ni un plan maestro que se cumpla al pie de la letra. Lo que sí aparece repetido en las notas es un orden de trabajo: primero entender qué corre hoy, después aislar, luego automatizar. Esta página describe ese punto de partida tal como lo registramos en la bitácora, sin prometer plazos ni resultados.
El arranque casi nunca empieza por elegir herramientas. Empieza por inventariar servicios legados, dependencias de red y supuestos que el código daba por sentados. Recién después tiene sentido discutir si conviene Kubernetes o algo más simple.
Antes de contenerizar nada, revisamos qué procesos escriben en disco, qué rutas absolutas usan y qué dependencias de red asumen. Ese relevamiento suele revelar que el servicio no es tan stateless como decía el diagrama. En las entradas sobre migración de un servicio legado a contenedores quedan ejemplos de estos supuestos que rompen la primera versión en el clúster.
La decisión no es "todo o nada". En la práctica se empieza por componentes con límites claros y bajo acoplamiento a estado local. Los servicios que mantienen sesiones en memoria o escriben archivos compartidos suelen quedar para una segunda etapa, cuando ya hay una red aislada y una política de configuración definida fuera de la imagen.
Separar entornos sin recompilar la imagen es una de las primeras cosas que se documentan. Eso implica definir variables, secretos y segmentación de red antes de exponer tráfico. Los errores más comunes que registramos aparecen justo acá: credenciales embebidas en la imagen, reglas de firewall copiadas de un entorno a otro y nombres de servicio resueltos por convención que nadie verificó.
La infraestructura inicial se describe con módulos pequeños y reutilizables: red, cómputo, almacenamiento y permisos. No se trata de cubrir todo el catálogo del proveedor, sino de tener una base reproducible. En la nota sobre Terraform con estado remoto explicamos por qué el backend local deja de servir apenas trabaja más de una persona sobre el mismo plan.
Instrumentar métricas, logs y trazas antes de mover el primer servicio a producción distribuida evita migrar a ciegas. La pregunta que guía esta etapa no es cuántas señales podemos recolectar, sino cuáles vamos a mirar durante un incidente. El artículo sobre observabilidad sin ruido desarrolla ese criterio de selección por valor operativo.
Cuando dos servicios empiezan a depender del tiempo de respuesta del otro, aparece la tentación de meter una cola. La decisión tiene consecuencias: hay que definir política de reintentos, manejo de mensajes muertos y claves de idempotencia. Sin esas definiciones, la cola amplifica errores en lugar de absorberlos, como se documenta en la entrada sobre reintentos y letras muertas.