Consultoría de Kubernetes: qué mirar antes de contratar

Casi todo lo que se escribe sobre contratar consultoría de Kubernetes lo escribe alguien que vende consultoría de Kubernetes. Esto es la lista de preguntas que yo haría si tuviera que contratarla, y algunas no le convienen a quien las responde.

Empiezo por declarar el sesgo, porque lo tengo. Trabajo como consultor cloud y me dedico a esto. Lo que no hago es vender horas de plataforma ni revender infraestructura, y esa diferencia cambia el consejo entero: quien factura por operar tu clúster tiene un interés estructural en que tu clúster necesite ser operado.

No digo que las consultoras lo hagan mal. Digo que conviene saber de dónde sale cada recomendación, y que hay una pregunta que lo revela en diez segundos. Está más abajo.

Antes de contratar nada: ¿necesitas Kubernetes?

Esta es la pregunta que se salta todo el mundo, y la que más dinero ahorra.

Kubernetes resuelve un problema concreto y lo resuelve bien: coordinar muchos servicios que escalan de forma distinta, se despliegan a menudo y tienen que sobrevivir a que se caigan máquinas. Si ese es tu problema, es la herramienta correcta y no hay mucho más que discutir.

El problema es que también es la respuesta por defecto de todo el sector a preguntas que no la necesitan. Estas tres situaciones no piden Kubernetes:

• Una aplicación, un despliegue al mes. La complejidad operativa de un clúster —red, almacenamiento, permisos, actualizaciones, observabilidad— es un coste fijo que pagas aunque solo corras un contenedor.
• Carga plana y pequeña. El valor de Kubernetes está en la elasticidad y en la densidad. Si tu carga no varía, estás pagando la orquestación sin usarla.
• Sin nadie que lo mantenga. Es el caso más caro y el más común. Un clúster sin un perfil que lo entienda no es una plataforma: es una deuda que además está en producción.

La alternativa honesta casi siempre existe. Un servicio gestionado de contenedores, una plataforma tipo PaaS o directamente unas máquinas bien configuradas con despliegue automatizado resuelven el 80% de los casos con una fracción de la complejidad. Lo cuento con más detalle, aplicado al coste real, en cómo elegir servidores cloud.

Si de esta sección solo te llevas una cosa: una consultoría que nunca te va a decir que no necesitas Kubernetes no te está asesorando, te está vendiendo.

Los tres momentos en que la consultoría sí vale la pena

Dicho lo anterior, hay tres situaciones donde traer a alguien de fuera se paga solo.

1. El clúster heredado que nadie se atreve a tocar

Alguien lo montó, funcionó, y esa persona ya no está. Ahora hay un sistema en producción que el equipo usa con miedo: se despliega a horas raras, nadie sabe qué pasa si se cae un nodo, y hay cambios que llevan meses aplazados porque el riesgo es desconocido.

Aquí el trabajo no es técnico, es de reducción de incertidumbre: inventariar qué hay, qué depende de qué, qué pasa si se cae cada pieza, y dejarlo escrito. Suele descubrirse que el 70% funciona bien y el miedo venía del 30% que nadie había mirado.

El orden que a mí me funciona es deliberadamente aburrido, y empieza por no tocar nada:

1. Leer antes que cambiar. Qué corre, con qué versiones, qué se despliega solo y qué a mano. Una semana de lectura ahorra un mes de sorpresas.
2. Probar la vuelta atrás en algo pequeño. Antes de cualquier mejora, comprobar que se puede deshacer un cambio. Si no se puede, ese es el primer trabajo, y no el que venías a hacer.
3. Arreglar primero lo que impide dormir, no lo que está más feo. Una copia de seguridad sin probar y un secreto en un repositorio son más urgentes que un manifiesto desordenado.
4. Dejar escrito lo que se decidió y lo que se descartó. Lo segundo importa más de lo que parece: sin eso, el siguiente vuelve a plantear lo mismo dentro de seis meses.

La señal de que va bien no es que el clúster cambie, es que el equipo empiece a desplegar en horario normal. El miedo es la métrica.

2. La factura que crece sin que crezca el negocio

Kubernetes facilita pedir recursos y no facilita devolverlos. El patrón clásico: cada equipo dimensiona su servicio por el pico que imagina, nadie revisa esos números después, y al cabo de un año el clúster corre al 15% de utilización con la factura al 100%.

Es de los trabajos con retorno más medible que existen —se ve en la factura del mes siguiente— y casi siempre es más de análisis que de ingeniería. Los cuatro sitios donde suele estar el dinero, por orden de lo que me he encontrado más veces:

• Peticiones de recursos infladas. Cada servicio declara lo que cree que necesita en el pico. Como nadie penaliza pedir de más, todo el mundo pide de más, y el planificador reserva esa capacidad aunque no se use. Comparar lo pedido con lo consumido de verdad durante un mes suele ser el hallazgo más grande y el más barato de corregir.
• Nodos dimensionados para el peor día. La consecuencia de lo anterior: si cada servicio pide de más, hacen falta más nodos. Un ajuste de peticiones se traduce en menos máquinas, no en un clúster más lleno.
• Almacenamiento que nadie borra. Volúmenes de servicios que se apagaron, copias de seguridad sin política de retención, registros de imágenes con todas las versiones desde el principio de los tiempos. No suele ser la partida mayor, pero es la que crece sola.
• Tráfico de salida. El coste que no aparece en ninguna comparativa de precio por hora y que sorprende al cerrar el mes. Servicios que se hablan entre zonas de disponibilidad distintas pagan por cada byte, y eso se arregla colocándolos bien, no comprando menos.

⚠️ Lo que no hay que hacer es apretar a ciegas. Bajar peticiones sin mirar el consumo real cambia un problema de coste por uno de disponibilidad, y ese se paga más caro. El orden correcto es medir un mes, ajustar con margen y volver a medir.

3. La migración que lleva seis meses sin arrancar

No arranca porque nadie quiere ser quien rompa producción, y cada mes que pasa la hace más grande. Lo que desbloquea no suele ser capacidad técnica, sino un plan por fases donde cada una se puede deshacer. Cuando la primera fase es reversible, la conversación cambia.

En la práctica, eso significa no empezar por lo importante. El orden que funciona:

1. Algo que no sea crítico y que ya esté contenerizado. Un servicio interno, un proceso por lotes, una herramienta del equipo. Sirve para que el camino completo —construir, desplegar, observar, revertir— exista de verdad antes de que importe.
2. Un servicio real, pero con la versión antigua todavía en pie. Tráfico repartido, o directamente un porcentaje pequeño. Aquí es donde aparecen los problemas que ningún entorno de pruebas enseña: tiempos de espera, límites de conexiones, configuración que estaba en un sitio que nadie recordaba.
3. El resto, ya con el camino recorrido. A estas alturas la migración deja de ser un proyecto y pasa a ser una rutina.

La pregunta que decide si el plan es bueno: en cada fase, ¿cuánto tardas en volver atrás y quién puede hacerlo? Si la respuesta a la segunda parte es «solo la consultora», no has migrado: has cambiado de dependencia.

Las seis preguntas

Estas son las que yo haría. Las dos primeras son incómodas a propósito.

1. ¿Alguna vez habéis recomendado a un cliente que NO adoptara Kubernetes?

La pregunta que revela el incentivo. Una consultora con criterio tendrá el caso a mano y lo contará con detalle, porque es de lo que está orgullosa. Una que venda plataforma dará un rodeo. No hay respuesta correcta única, pero la forma de contestarla dice mucho.

2. Cuando acabe el encargo, ¿qué puedo hacer yo sin vosotros?

La respuesta que quieres es concreta: desplegar, revertir, escalar, ver qué está fallando y a quién llamar. Si la respuesta es «nos llamas», el encargo no termina nunca — y eso puede estar bien si es lo que buscas, pero que sea una decisión y no una sorpresa.

3. ¿Cómo se despliega un cambio pequeño, de principio a fin?

Pide que te lo enseñen sin que ellos toquen nada. Si hace falta entrar por SSH, editar un YAML a mano o recordar un paso que no está escrito, el clúster no es mantenible: es mantenible por ellos. Es la prueba de cinco minutos que más cosas destapa.

4. ¿Cómo se deshace un despliegue que ha salido mal?

La vuelta atrás es la parte que se salta todo el mundo hasta que hace falta a las tres de la mañana. Si la respuesta implica improvisar, el riesgo sigue entero por mucho que el despliegue esté automatizado.

5. ¿Qué pasa con los datos?

Kubernetes orquesta procesos; los datos son el problema difícil. Bases de datos dentro o fuera del clúster, copias de seguridad, restauración probada —probada de verdad, no documentada—, y qué ocurre en una actualización. Si la conversación sobre almacenamiento es corta, es que no se ha tenido.

6. ¿Cuándo termina esto y cómo lo sabemos?

Un encargo sin criterio de terminación no termina. Pide entregables por fase y una definición de «hecho» que se pueda comprobar sin discutir. La bolsa de horas abierta sin criterio es cómoda para las dos partes y cara para una.

Qué mira una auditoría que sirve

Si lo que contratas es una revisión de lo que ya tienes, esto es lo que debería cubrir. Sirve además como lista para comparar propuestas: la que deje fuera la mitad de estos puntos está cotizando otra cosa.

Lo que se ve enseguida:

• Versiones y soporte. Qué versión de Kubernetes corre, cuánto le queda de soporte y qué hace falta para actualizar. Una versión fuera de soporte no es un problema hoy y es un problema urgente el día que aparezca un fallo de seguridad.
• Salud de los nodos y reparto de la carga. Si todo está en una zona, la alta disponibilidad es decorativa.
• Peticiones y límites de recursos, comparados con el consumo real.

Lo que hay que buscar a propósito:

• Permisos. Quién puede hacer qué, y cuántas cosas corren con más privilegios de los que necesitan. Es donde más veces he visto un cluster-admin repartido «temporalmente» hace dos años.
• Secretos. Dónde están las credenciales, quién las puede leer, y si alguna está en un repositorio. Esto se mira siempre, y casi siempre aparece algo.
• Red. Qué puede hablar con qué. Por defecto, en Kubernetes, todo habla con todo: si nadie lo ha restringido, un servicio comprometido llega a la base de datos.
• Copias de seguridad. No que existan: que se haya restaurado una. Una copia que nunca se ha probado es una suposición.

Y lo que casi nadie mira, que es lo que más duele después:

• Cómo se despliega de verdad, incluidos los pasos manuales que no están escritos y que solo conoce una persona.
• Qué pasa cuando algo falla a las tres de la mañana: qué avisa, a quién, y qué se hace. Si la respuesta es «lo vemos por la mañana», eso es una decisión legítima — pero que sea una decisión.
• Quién queda a cargo. La plataforma sostenible es la que encaja con el equipo que la va a mantener, no la que luce mejor en un diagrama.

Tres señales de alarma

Te dan un precio antes de mirar. Kubernetes es contexto puro: el mismo encargo cuesta muy distinto según qué haya montado. Un presupuesto cerrado sin auditoría previa significa que el margen de error ya va dentro, y lo pagas tú.

La propuesta empieza por la herramienta. Si lo primero que aparece es un stack —service mesh, GitOps, operadores, el catálogo entero— antes de que nadie haya preguntado qué te duele, estás comprando la solución de otro. Las herramientas son buenas; el orden está mal.

Nadie pregunta por tu equipo. La plataforma que puedes mantener depende de quién la va a mantener. Una solución excelente para un equipo de plataforma de cinco personas es una trampa para una empresa con dos desarrolladores y ningún perfil de sistemas. Si no preguntan por eso, están diseñando para un cliente genérico.

Qué deberías tener cuando acabe

Independientemente del alcance, un encargo bien hecho deja cuatro cosas, y las cuatro se pueden pedir por escrito desde el principio:

1. Un inventario de qué hay y por qué. Qué corre, qué depende de qué, qué decisiones se tomaron y qué alternativas se descartaron. Esto es lo que evita que el siguiente tenga que redescubrirlo todo.
2. El camino del cambio documentado y probado por ti. Desplegar y revertir, hechos por alguien de tu equipo mientras los de fuera miran.
3. Qué vigilar y qué hacer cuando salte. No un panel bonito: cuatro o cinco señales que de verdad indiquen que algo va mal, con qué hacer en cada caso.
4. La lista de lo que no se hizo. Todo encargo deja cosas fuera. Que estén escritas —con su motivo y su urgencia— es la diferencia entre una decisión y un olvido.

Y la opción que siempre está sobre la mesa: no hacer nada

Ninguna lista de este tipo la menciona, y es la que compite de verdad con contratar.

No hacer nada es una decisión legítima cuando el sistema funciona y el coste de vivir con él es menor que el de arreglarlo. Un clúster viejo pero estable, con poca carga y sin planes de crecer, puede seguir así años. El error no es dejarlo: es dejarlo sin saber qué estás aceptando.

Lo que sí conviene es poner número a tres cosas, y son las mismas que decidirán por ti dentro de un año:

• Cuánto cuesta el statu quo al mes, contando la factura y el tiempo que el equipo dedica a sostenerlo. Ese segundo número casi nunca está calculado y suele ser el mayor.
• Qué pasa el día que se caiga, y cuánto tiempo estaríais parados. Si nadie lo ha estimado, el riesgo no es que sea alto: es que es desconocido.
• Qué te impide hacer. Es el coste que no se ve: funcionalidades que no se lanzan porque tocarían la parte que da miedo.

Con esos tres números, la decisión de contratar o no deja de ser una corazonada. Y muchas veces la respuesta honesta es esperar — cosa que, otra vez, no le conviene decir a quien te está cotizando.

Y si lo que necesitas es una opinión, no un proyecto

Hay una situación muy común que no encaja en ningún presupuesto: tienes una decisión delante —adoptar o no, migrar o esperar, una propuesta de un proveedor sobre la mesa— y lo que necesitas no es que alguien la ejecute, sino alguien que la mire contigo y te diga lo que piensa.

Eso suele resolverse en una conversación y un informe corto. No hace falta contratar un proyecto para eso, y desconfía de quien te diga que sí.

Si es tu caso y quieres que lo miremos, cuéntame qué tienes delante. Y si lo que te interesa es el fondo técnico —cómo se construyen los sistemas que acaban corriendo en estos clústeres—, eso lo desarrollo en Spring Boot Avanzado, donde el ciclo de despliegue con Docker y Kubernetes es uno de los bloques.