Organizaciones con objetivos diametralmente opuestos. De todos los tamaños, países y sectores. Todas adoptando Kubernetes. Existen motivos —fuera del ámbito exclusivamente técnico— que respaldan la brutal adopción de este popular orquestador. El objetivo de este post pasa por compartir algunos de los más significativos.

Despliegues manuales. Desarrolladores accediendo a entornos productivos. Scripts que solo entiende aquel fulano que se fue de la empresa. Java. Una política de versionado pobre o inexistente. Aquella caja de Pandora disfrazada de parche de seguridad. Las historias de terror pre-Kubernetes existen y están ahí para movilizar a los managers.

Por si fuera poco, las ofertas de empleo continúan degenerando y ahora parecen cartas a los Reyes Magos: AWS, Azure, OpenStack, Jenkins, Docker, Kubernetes, Elasticsearch, Perl, Python, Ruby, Bash, Ansible, Puppet, Terraform, Chef… El candidato idóneo está obligado a acumular experiencia sobre todas estas tecnologías.

El mercado se ha vuelto loco y el miedo a quedarse fuera por no dar la talla es tan real como ridículo. Así pues, cada día más empresas se suman a esta agotadora tendencia por sufrir el stack más absurdo.

No obstante, la rigidez en el stack es un lujo al alcance de muy pocas organizaciones. La ausencia de esta, en cambio, se suele disfrazar de “salario emocional”. Este problema —aunque organizacional— encaja a la perfección con una solución basada en contenedores.

Las arquitecturas orientadas a microservicios suelen favorecen una eventual explosión del stack tecnológico. Cada pocos meses aparecerá la oportunidad de emprender nuevas aventuras con un framework o lenguaje distinto. La distancia aparente entre este nuevo juguete y el entorno de producción es un Dockerfile.

Este esfuerzo por ampliar horizontes supone un coste operacional difícil de asumir. De ahí que Kubernetes también imponga sus propias normas con el objetivo de automatizar y simplificar las operaciones:

  • Siempre son contenedores. Los artefactos, por lo tanto, siempre tienen la misma forma: imágenes de Docker.
  • Los logs van a stdout y stderr. Un problema menos para la aplicación, ya vendrá alguien a recogerlos.
  • Comprobar y exponer el estado de los procesos. ¿Está listo para atender peticiones? ¿Hace falta otra instancia del proceso? Responder a estas preguntas de manera programática permite a la plataforma tomar decisiones que hasta ahora eran manuales.

El discurso de marketing de los cloud providers ha calado. Ya no importa si uno tiene la suerte de hacer negocio con un número modesto de peticiones y poco tráfico. Si la API no está preparada para recibir una bestialidad de consultas por segundo, parece que está mal diseñada. Para sorpresa de nadie, Kubernetes complace esta ambición de escalar sin coste aparente. Todos los días pueden ser como el Prime Day para Amazon, pero sin métricas.

En definitiva, no acumular malas prácticas es imposible y las más difíciles de identificar están enquistadas en todo el sector. La falta de experiencia acumulada hace que el factor humano sea problema y solución al mismo tiempo, no existen respuestas absolutas. Amazon, Google y Microsoft marcan el ritmo, pero resulta casi imposible diferenciar entre señal y ruido cuando todo es nuevo.

Es difícil de percibir en un primer vistazo, pero tanto Kubernetes como otras tecnologías complementarias se han diseñado con estas miserias en mente. No están limitadas a un contexto estrictamente técnico, sino que acaban forzando un modelo alternativo que obliga a rediseñar y transformar toda clase de procesos. Ya sea a puñetazos o no, vale la pena estudiar el impacto de un producto así en el entorno profesional.