«Hemos creado un clúster Mesos de 70 000 nodos para nuestros desarrolladores, pero no lo usarán. ¿Puedes ayudar?» Este fue el comienzo de una conversación con el vicepresidente de operaciones de infraestructura de una empresa muy grande y famosa. Si bien fue una hazaña impresionante, también fue, con mucho, la configuración de infraestructura contenerizada más grande que había visto que no se había utilizado; lamentablemente, tampoco se
trataba de un incidente aislado.He hablado de este encuentro con un gran número de clientes, analistas, amigos, colegas, socios, inversores de capital riesgo y competidores. Todos hemos expresado experiencias similares y todos queríamos saber por qué es así. Al fin y al cabo, si se desperdician tantos recursos en nuestra industria, todos corremos un gran riesgo al no entender y resolver el problema. De lo contrario, la próxima ola de usuarios podría empezar a dudar de que los contenedores puedan ayudar a sus empresas, y todos tendríamos que empezar a pulir nuestros currículos
.Tengo que ser honesto: soy un desarrollador, un ingeniero y un tecnólogo al que le encanta crear productos y utilizar las últimas tecnologías. Por lo tanto, lo primero que busqué, en mi búsqueda por encontrar una respuesta a esta pregunta sobre los 70 000 nodos, fue en las tecnologías utilizadas. ¿Mesos era la tecnología equivocada? ¿Se implementó de manera incorrecta? ¿Usaron código abierto o código cerrado? ¿Hubo un SI involucrado? Preguntas como estas me vinieron primero a la mente. En retrospectiva, creo que probablemente esas fueron las preguntas equivocadas
.La respuesta me llegó cuando recordé un día de mi carrera profesional, hace 15 años: sentado en mi escritorio como promotor inmobiliario en un gran banco, recuerdo a vendedores vestidos impecablemente que entraban y salían a nuestras salas de reuniones para cortejar a nuestro vicepresidente de infraestructura y a su equipo. Eran de VMware, que en aquel entonces era la empresa dedicada a la infraestructura virtualizada. Yo solo trabajaba como desarrollador en un banco, pero ni siquiera mi jefe, ni su jefe, ni siquiera el jefe de su jefe, fueron invitados a ninguna de las cenas en un restaurante especializado en carnes que la gente de VMware organizaba casi todas las semanas. Los vendedores de VMware solo estaban interesados en los responsables de la toma de decisiones en materia de operaciones e infraestructura. Dos o tres meses más tarde, nuestro equipo recibió la noticia de que se había firmado un acuerdo con VMware y que pronto trasladaríamos nuestros servicios a las máquinas virtuales. Poco después, la mudanza se llevó a cabo en un par de fines de semana
.Entonces, un lunes por la mañana, los servicios de los que era responsable mi equipo se ejecutaban en máquinas virtuales, en lugar de en los viejos servidores sin sistema operativo, con luces azules parpadeantes y ventiladores ruidosos. Eso era todo. Toda nuestra infraestructura se virtualizó en cuestión de meses sin que los desarrolladores dijeran demasiado, y mientras estábamos poniendo una falsa resistencia a este cambio (¿y a quién le gusta el cambio, después de todo?) y al aceptar a regañadientes quedarnos en modo de espera durante un par de fines de semana, no pudimos diferenciar entre la configuración antigua y la nueva: todo seguía igual. Nuestros servidores de máquinas virtuales se comportaban y se sentían como servidores «reales». Estoy seguro de que no habríamos podido ver la diferencia en una prueba de doble ciego si alguien la hubiera realizado
.Recordar aquellos días me hizo preguntarme por qué la nueva ola de cambios en la infraestructura basada en contenedores no funciona de la misma manera. ¿Por qué no podemos crear un clúster de Mesos o Kubernetes en uno o dos fines de semana y enviar una nota a los desarrolladores con el tema: «Bienvenidos al futuro de la infraestructura? ¡De nada!
»?La respuesta, como todos sabemos, es que la contenedorización no va a funcionar sin la participación y la participación de los desarrolladores. Los desarrolladores tienen que crear aplicaciones para una configuración en contenedores, pero los contenedores, con API como las de Kubernetes expuestas a lo largo del ciclo de vida del software, son imprescindibles para que los desarrolladores y los operadores cambien la forma en que trabajan y se comunican entre sí. La razón por la que se creó un clúster brillante de 70 000 nodos que ejecuta Tumbleweed en lugar de aplicaciones empresariales es que las herramientas que hemos creado para esta nueva transición no abordan este cambio organizativo fundamental y esencial, la combinación de desarrolladores y operaciones. La emocionante realidad es que configurar una infraestructura en contenedores es cada vez más fácil, ya que hay una gran cantidad de soluciones de código abierto que permiten poner en marcha un clúster de Kubernetes. Si ya utiliza uno de los principales proveedores de nube, solo tiene que hacer un par de clics para tener su propio clúster en contenedores, gestionado, mantenido y facturado por minuto. Los equipos de operaciones pueden ver las ventajas de gestionar una infraestructura en contenedores: servidores de configuración única (no más «copos de nieve»), alta disponibilidad y resiliencia incorporadas y una mejor utilización de los recursos, por mencionar solo algunas. Los desarrolladores también ven el valor de ejecutar una configuración en contenedores: más influencia sobre el entorno en ejecución, mejor control sobre las bibliotecas y las dependencias y reducción de la brecha entre los entornos de producción y desarrollo, entre otros. Cada lado de esta ecuación (desarrollo y operaciones) tiene sus propios proveedores, herramientas y proyectos de código abierto que les ayudan con lo que se necesita para pasar a un mundo en contenedores, pero eso no es suficiente. Todavía nos falta el marco para que los desarrolladores y las operaciones trabajen juntos para que esto sea un éxito. Simplemente hay muy pocas herramientas y tecnologías disponibles, si es que hay alguna, que faciliten esta comunicación
.Todos estamos tan concentrados en nuestras áreas individuales de innovación, desde la red hasta el almacenamiento y la orquestación, que podemos perder el foco en el logro de los objetivos empresariales de nuestros clientes. En este entorno, las empresas de integración de sistemas, consultoría y servicios profesionales obtienen buenos resultados, ya que son las únicas que se centran en el resultado y en ofrecer resultados en toda la cadena de suministro de software, pero esto no es sostenible. Las tecnologías que exigen que los clientes paguen tanto por las consultorías para hacerlas funcionar no van a ser tecnologías revolucionarias. Reconozcámoslo: si la virtualización necesitara que McKinsey estuviera siempre presente en la nómina para que funcionara, hoy no existiría
la nube.Para que todos podamos beneficiarnos de una tecnología innovadora, como la contenedorización de la infraestructura, debemos pensar de manera más amplia que nuestras herramientas de un solo propósito o áreas de enfoque principales y repensar la forma en que creamos los productos para este sector. Esto es diferente de la revolución de la virtualización y la nube, y cuanto antes nos demos cuenta de ello, mayores serán los beneficios para nuestros clientes
.Devops no es solo un conjunto de herramientas fragmentadas o un sofisticado proyecto de «transformación digital», sino que es un método de trabajo colaborativo entre funciones, posibilitado por la tecnología. Por lo tanto, cualquier tecnología dirigida al mercado de DevOps, específicamente en lo que respecta a la contenedorización, también debe abordar antes que nada la mentalidad de colaboración continua. Por lo tanto, creemos todos productos teniendo esto en cuenta para iniciar y mantener una conversación entre desarrolladores
y operadores.Esta publicación se publicó por primera vez aquí