MicroLab vs Docker Compose vs Kubernetes local
Las tres cosas aparecen en la misma conversación —«¿cómo montamos el entorno local?»— y resuelven problemas distintos. Esta página dice cuál es cuál, sin fingir que las otras dos están mal: la mayoría de equipos acaban usando más de una, y MicroLab de hecho se apoya en Docker para la infraestructura.
<h2>En una frase</h2>
<ul>
<li>
<strong>Docker Compose</strong> declara un conjunto de contenedores y los
levanta juntos. Es la herramienta estándar para la infraestructura y para
sistemas que se ejecutan enteros en contenedor.
</li>
<li>
<strong>Kubernetes local</strong> (Kind, minikube, k3d) mete un clúster de
Kubernetes en tu máquina. Su razón de ser es parecerse a producción: probar
manifiestos, Helm charts, operadores y políticas.
</li>
<li>
<strong>MicroLab</strong> es un orquestador de escritorio para el bucle del
día: levanta los servicios de un flujo y, sobre todo, decide
<strong>a dónde llama cada uno</strong> —a otro servicio local, a la nube o a
un mock— reescribiendo las URLs sin tocar los repositorios.
</li>
</ul>
<h2>La tabla</h2>
<div class="legal-table-wrap">
<table>
<thead>
<tr>
<th>Criterio</th>
<th>Docker Compose</th>
<th>Kubernetes local (Kind)</th>
<th>MicroLab</th>
</tr>
</thead>
<tbody>
<tr>
<th>Para qué está pensado</th>
<td>Levantar contenedores declarados juntos</td>
<td>Reproducir Kubernetes en local</td>
<td>El bucle diario con varios servicios que se llaman entre sí</td>
</tr>
<tr>
<th>Cómo se describe el sistema</th>
<td>Un <code>docker-compose.yml</code> que escribes tú</td>
<td>Manifiestos o charts, más la configuración del clúster</td>
<td>Se autodetecta del repo (stack, puertos, infra, dependencias) y lo revisas</td>
</tr>
<tr>
<th>A dónde llama cada servicio</th>
<td>Configuración de cada repo, a mano</td>
<td>Descubrimiento del clúster; salir fuera se configura aparte</td>
<td>Por dependencia: local, nube o mock. La URL la reescribe el motor al arrancar</td>
</tr>
<tr>
<th>Bucle de cambio</th>
<td>Reconstruir la imagen; <code>compose watch</code> sincroniza o reconstruye</td>
<td>Construir, cargar en el clúster y desplegar (Tilt o Skaffold lo automatizan)</td>
<td>El servicio que tocas corre nativo, con recarga en caliente</td>
</tr>
<tr>
<th>Depurar</th>
<td>Enganchar el depurador al contenedor</td>
<td>Reenvío de puertos al pod</td>
<td>Proceso nativo: el depurador del IDE, sin intermediarios</td>
</tr>
<tr>
<th>Infraestructura común</th>
<td>Es su punto fuerte</td>
<td>Otro contenedor u operador dentro del clúster</td>
<td>La gestiona en Docker, con auto-remapeo cuando el puerto está ocupado</td>
</tr>
<tr>
<th>Simular un servicio ajeno</th>
<td>Otro contenedor con un servidor de stubs, configurado a mano</td>
<td>Igual, más manifiestos</td>
<td>Integrado: la dependencia se pone en <code>mock</code> y se define el stub</td>
</tr>
<tr>
<th>Parecido a producción</th>
<td>Medio</td>
<td>Alto, y es su motivo de existir</td>
<td>Bajo a propósito: optimiza el bucle, no la fidelidad</td>
</tr>
<tr>
<th>Compartir el montaje</th>
<td>El fichero, versionado</td>
<td>Manifiestos, versionados</td>
<td>El escenario se exporta a un fichero autocontenido e importable</td>
</tr>
<tr>
<th>Interfaz</th>
<td>Línea de comandos (más la de Docker Desktop)</td>
<td>Línea de comandos</td>
<td>Ventana y CLI, con la misma lógica detrás</td>
</tr>
<tr>
<th>Licencia</th>
<td>Código abierto</td>
<td>Código abierto</td>
<td>Propietaria: gratis para uso personal, de pago para uso en una organización</td>
</tr>
<tr>
<th>Requisitos</th>
<td>Un motor Docker</td>
<td>Docker y bastante memoria</td>
<td>Windows o Linux, y un motor Docker para la infraestructura</td>
</tr>
</tbody>
</table>
</div>
<h2>Quédate con Docker Compose si…</h2>
<ul>
<li>
Lo que necesitas es la <strong>infraestructura</strong>: bases de datos, colas,
cachés. Para eso no hay nada mejor, y MicroLab no lo sustituye — de hecho
<strong>lee tu <code>docker-compose.yml</code></strong> para saber qué tienes
declarado, y nunca lo escribe.
</li>
<li>
Tu sistema son dos o tres servicios estables que no tocas a diario. Levantarlos
todos en contenedor y olvidarte es más simple que cualquier otra cosa.
</li>
<li>
Necesitas que funcione igual en cualquier máquina y en CI, con una sola
herramienta y sin instalar nada más.
</li>
</ul>
<h2>Quédate con Kubernetes local si…</h2>
<ul>
<li>
Lo que estás desarrollando <strong>es</strong> Kubernetes: manifiestos, charts,
operadores, políticas de red. Probarlos fuera de un clúster no prueba nada.
</li>
<li>
Necesitas reproducir un comportamiento que solo aparece en el clúster —el
<em>service mesh</em>, un <em>ingress</em>, los límites de recursos—.
</li>
<li>
Ya tienes Tilt o Skaffold montados y el bucle de build no os duele.
</li>
</ul>
<h2>Coge MicroLab si…</h2>
<ul>
<li>
El flujo que pruebas pasa por <strong>varios servicios</strong>, y cada uno
llama a otros que no siempre quieres levantar.
</li>
<li>
Cambias a menudo <strong>a dónde apunta</strong> una dependencia —hoy contra el
entorno compartido, mañana contra el compañero que lo tiene levantado, pasado
contra un mock porque no hay VPN— y estás cansado de editar configuración en
repos que no son tuyos.
</li>
<li>
Quieres <strong>tocar y ver el efecto ya</strong>: el servicio en el que estás
corriendo nativo con recarga en caliente, y los demás de fondo en contenedor.
</li>
<li>
Cada persona que entra al equipo pierde su primer día con un
<code>LOCAL_SETUP.md</code> que nadie mantiene.
</li>
</ul>
<h2>Dónde MicroLab se queda corto</h2>
<p>Una comparativa que solo dice cosas buenas de quien la escribe no sirve de nada.</p>
<ul>
<li>
<strong>No se parece a producción</strong>, y no lo pretende. Si tu problema es
que algo falla solo en el clúster, esto no lo va a reproducir.
</li>
<li>
<strong>No habla Kubernetes.</strong> No lee manifiestos ni charts, ni está en
los planes.
</li>
<li>
<strong>Windows y Linux.</strong> El instalador de macOS llegará más adelante.
</li>
<li>
<strong>Está en beta</strong>, y se nota: cambia a menudo.
</li>
<li>
<strong>No es código abierto</strong>, y usarlo en el trabajo requiere una
licencia de pago. Compose y Kind son gratis para cualquier uso; esto es un
producto y hay que decirlo antes de que te lo encuentres.
</li>
<li>
<strong>Hay que describir cada servicio una vez.</strong> Se autodetecta casi
todo, pero la revisión inicial es trabajo que con un <code>compose</code> ya
escrito no tendrías.
</li>
</ul>
<h2>Lo que suele acabar pasando</h2>
<p>
Los tres conviven sin conflicto: <code>compose</code> para la infraestructura
común —que MicroLab lee y gestiona—, Kubernetes local para lo que de verdad es de
Kubernetes y para CI, y MicroLab para el rato en que estás cambiando código y
necesitas que el flujo entero responda sin montarlo a mano cada vez.
</p>
<p>
<a class="btn btn-primary btn-lg" href="/#download">Descargar MicroLab</a>
</p>
<p class="doc-meta">
Gratis para uso personal · Windows y Linux · Para uso en una organización, ver
<a href="/pricing">Precios</a> y los <a href="/terms">términos</a>.
</p>