Danylo Mikula de Medidata Solutions lideró un cambio de procesos manuales a flujos de trabajo declarativos, reduciendo el tiempo de aprovisionamiento de clústeres en un 97%
Para muchos equipos de ingeniería empresarial, Kubernetes ha superado hace tiempo la etapa de innovación y se ha establecido en la categoría de infraestructura crítica cotidiana. Sin embargo, mantener esa infraestructura de manera eficiente, especialmente en múltiples clústeres y entornos, sigue siendo un desafío que ralentiza la entrega de funciones y aumenta el riesgo operativo.
En Medidata Solutions, un proveedor líder de soluciones SaaS y análisis de datos que respaldan la investigación clínica, este desafío era particularmente agudo. Gestionar infraestructura híbrida en entornos locales y de computación en la nube, incluyendo aproximadamente una docena de clústeres de Kubernetes y miles de máquinas virtuales, el aprovisionamiento de un clúster listo para producción era un proceso largo que podía llevar semanas de esfuerzo coordinado, involucrando configuración manual distribuida entre varios equipos. Las actualizaciones de aplicaciones de infraestructura a menudo se posponían porque los historiales de configuración no estaban centralizados, creando retrasos y, a veces, brechas de seguridad.
Eso cambió cuando Danylo Mikula, un arquitecto de DevOps e infraestructura con más de una década de experiencia en industrias reguladas, se unió al equipo de ingeniería de plataformas a finales de 2023 y se propuso renovar la forma en que se gestionaba la infraestructura. El mandato, como lo describe Danylo, era engañosamente simple.
"El objetivo no era introducir nuevas herramientas por el bien de la modernización. Era hacer que la infraestructura existente fuera más fácil de operar, mantener y escalar, sin aumentar el personal o la complejidad."
– Danylo Mikula, arquitecto de DevOps e infraestructura, Medidata Solutions
De pasos manuales a flujos de trabajo declarativos
El núcleo de la transformación se centró en consolidar procesos fragmentados en un modelo basado en GitOps. En lugar de que los ingenieros aplicaran configuraciones manualmente a cada clúster, los despliegues se trasladaron a repositorios con control de versiones, con Argo CD manejando la sincronización.
Los cuellos de botella que encontró existían en cada etapa. Las redes de contenedores requerían coordinación entre los equipos de ingeniería de plataformas y redes, con la configuración dispersa en las estaciones de trabajo de ingenieros individuales. Las aplicaciones de infraestructura se implementaban manualmente, con archivos de valores almacenados en máquinas locales. La gestión de secretos seguía enfoques manuales tradicionales, y los procesos de despliegue habían evolucionado orgánicamente con el tiempo sin coordinación centralizada. Al consolidar cada fase en gráficos de Helm con control de versiones y anulaciones específicas del entorno, Danylo redujo el tiempo por etapa de días a minutos.
La arquitectura que construyó Danylo seguía una filosofía de "definir una vez, desplegar en todas partes". Un repositorio central contenía definiciones de servicios compartidos que generaban automáticamente despliegues específicos del clúster, mientras que cada entorno mantenía solo sus anulaciones únicas. "En lugar de copiar archivos de configuración en una docena de clústeres", explica Danylo, "creamos un sistema donde agregar un nuevo servicio significaba escribir una definición y dejar que la automatización manejara el resto". Este enfoque cubrió docenas de componentes de infraestructura, desde almacenes de datos y sistemas de mensajería hasta herramientas de seguridad y monitoreo, al tiempo que redujo drásticamente el riesgo de desviación de configuración.
La distribución de secretos siguió el mismo principio: en lugar de inyección manual por clúster, la integración de Vault a través del operador Vault Secrets automatizó la sincronización, asegurando que los cambios fluyeran a través de un proceso controlado con registros de auditoría adecuados.
El resultado fue un cambio fundamental en la forma en que se gestionaba la infraestructura. El tiempo de aprovisionamiento se redujo a aproximadamente 30 minutos, una mejora de eficiencia del 97,6%. Las actualizaciones se volvieron consistentes y repetibles, y la incorporación de nuevos ingenieros requirió menos conocimiento tribal.
"Teníamos múltiples equipos contribuyendo a los mismos entornos, y la consistencia siempre fue una preocupación. El trabajo nos ayudó a pasar a un proceso predecible con una fuente compartida de verdad. Las mejoras no fueron solo técnicas, facilitaron la colaboración."
– Monik Gandhi, director de ingeniería en la nube
El factor humano en el cambio técnico
Los colegas señalan que el éxito del cambio no fue puramente técnico. GitOps no era familiar para todos al principio, y parte del esfuerzo implicó hacer que el enfoque fuera comprensible y utilizable para ingenieros que habían pasado años en flujos de trabajo imperativos.
"La arquitectura era sólida, pero lo que destacó fue cómo se facilitó la adopción. Tomarse el tiempo para guiar a los ingenieros a través del modelo significó que ahora cualquiera en el equipo podía desplegar o modificar la infraestructura sin necesitar años de contexto acumulado. La gente entendió no solo el 'cómo', sino el 'por qué'."
– Labhesh Potdar, gerente de ingeniería en la nube
Como resultado, las actualizaciones de infraestructura, previamente tratadas como riesgosas, se volvieron rutinarias. Los equipos ganaron confianza al ejecutar actualizaciones programadas porque los historiales de despliegue eran visibles y reproducibles.
Seguridad como efecto secundario
Las mejoras de seguridad fueron igualmente significativas. Anteriormente, mantener cronogramas de parches consistentes era desafiante porque las configuraciones de despliegue estaban distribuidas en toda la organización en lugar de estar centralizadas. Las transiciones de equipo naturalmente hacían que la continuidad de configuración fuera más difícil.
Con todas las configuraciones ahora con control de versiones, el equipo finalmente pudo mantener cronogramas de actualización consistentes y rastrear exactamente qué se estaba ejecutando dónde. La integración con HashiCorp Vault aseguró que los secretos se gestionaran de manera consistente en toda la infraestructura con rotación adecuada y controles de acceso, algo crítico para una empresa SaaS de atención médica que opera en entornos regulados.
Lecciones clave para líderes de ingeniería
Los patrones técnicos utilizados en la transformación no son novedosos por sí mismos: Helm, Argo CD y Vault son herramientas bien conocidas. Según Danylo, el impacto provino de cómo se estructuraron e introdujeron: de manera incremental, con atención a la experiencia del desarrollador y los hábitos organizacionales.
Para otros líderes de ingeniería que consideran un cambio similar, Danylo destaca tres lecciones:
Comience con el diseño del repositorio. La estructura de carpetas y las convenciones de nomenclatura influyen en la capacidad de mantenimiento a largo plazo. Hacer esto correctamente desde el principio ahorra una refactorización significativa más adelante.
Automatice solo lo que los equipos puedan entender y respaldar. La adopción importa más que la sofisticación. Un sistema más simple que los ingenieros realmente usen es más valioso que uno elegante que eviten.
Deje espacio para una transición gradual. Mover todo a la vez rara vez es sostenible. La adopción incremental permite a los equipos generar confianza e identificar problemas antes de que se agraven.
Mirando hacia adelante
El trabajo posicionó al equipo de plataforma de Medidata para escalar la infraestructura sin aumentos proporcionales en el esfuerzo manual. A medida que crece el número de clústeres y aplicaciones, el modelo declarativo se vuelve más valioso, no solo por la velocidad, sino también por la auditabilidad, la incorporación y la consistencia a largo plazo.
El enfoque ahora, dice Danylo, es extender el mismo enfoque declarativo a la observabilidad: construir SLI medibles y alertas automatizadas que hagan de la confiabilidad una práctica objetiva en lugar de una cuestión de intuición.
"GitOps no resolvió todos los problemas, pero hizo que las partes rutinarias de la infraestructura fueran menos frágiles y más predecibles. En grandes organizaciones de ingeniería, eso por sí solo puede desbloquear una eficiencia significativa."
– Danylo Mikula
Danylo Mikula es arquitecto de DevOps e infraestructura en Medidata Solutions con más de diez años de experiencia entregando soluciones de ingeniería de plataformas y en la nube en industrias reguladas. Su trabajo se centra en traducir los principios de DevOps en prácticas de confiabilidad medibles y repetibles, enfatizando flujos de trabajo declarativos, infraestructura como código y gobernanza impulsada por observabilidad. Ha contribuido con investigación sobre patrones de adopción de GitOps a conferencias científicas internacionales. Más sobre sus proyectos y trabajo técnico se puede encontrar en su sitio web personal, que muestra su experiencia práctica y enfoque de desarrollo de productos.
