«Hemos creado un clúster Mesos de 70 000 nodos para nuestros desarrolladores, pero no lo van a utilizar. ¿Puede ayudarme?» Este fue el principio 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 mayor instalación de infraestructura contenerizada que había visto que no se había utilizado ni, lamentablemente, fue
un incidente aislado.He hablado de este encuentro con un gran número de clientes, analistas, amigos, colegas, socios, capitalistas de 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 ni resolver el problema. De lo contrario, la próxima ola de adoptantes podría empezar a dudar de que los contenedores puedan ayudar a sus negocios, y todos tendríamos que empezar a pulir nuestros currículums
.Debo ser honesto: soy desarrollador, ingeniero y tecnólogo al que le encanta crear productos y utilizar las últimas tecnologías. Así que, el primer lugar en el que busqué, en mi intento de encontrar una respuesta a esta pregunta de 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 implicado? Preguntas como estas le 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, hace 15 años: sentado en mi escritorio como promotor inmobiliario en un gran banco, recuerdo a vendedores vestidos de manera impecable que iban y venían a nuestras salas de reuniones y cortejaban a nuestro vicepresidente de infraestructura y a su equipo. Eran de VMware, en aquel entonces la empresa de infraestructuras virtualizadas. Yo solo era un desarrollador en el banco, pero ni siquiera mi jefe, ni el suyo, ni siquiera el jefe de su jefe estaban invitados a ninguna de las cenas en un restaurante de 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 de operaciones e infraestructuras. Dos o tres meses después, nos dijeron a nuestro equipo que se había firmado un acuerdo con VMware y que pronto pasaríamos nuestros servicios a las máquinas virtuales y, poco después, la mudanza tuvo lugar en un par de fines de semana
.Entonces, un lunes por la mañana, los servicios de los que era responsable mi equipo funcionaban en máquinas virtuales en lugar de en los viejos servidores básicos 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 mucho, y mientras poníamos una falsa resistencia a este cambio (¿y a quién le gusta el cambio, al fin y al cabo?) y al aceptar a regañadientes estar en espera durante un par de fines de semana, no podíamos diferenciar entre la configuración antigua y la nueva: todo era igual. Nuestros servidores de máquinas virtuales se comportaban y se sentían como servidores «de verdad». Estoy seguro de que no habríamos podido notar 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 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: «Bienvenido 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 compra de los desarrolladores. Los desarrolladores necesitan crear aplicaciones para una configuración en contenedores, pero es inherente a los contenedores, con API como Kubernetes expuestas a lo largo del ciclo de vida del software, es imperativo que los desarrolladores y los operadores cambien su forma de trabajar y comunicarse entre sí. La razón de un brillante clúster 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 los desarrolladores y las 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 le permiten poner en marcha un clúster de Kubernetes. Si ya utiliza uno de los principales proveedores de nube, está a solo un par de clics de tener su propio clúster en contenedores, gestionado, mantenido y facturado por minuto. Los equipos de operaciones ven las ventajas de gestionar una infraestructura en contenedores: servidores de configuración única (no más «copos de nieve»), alta disponibilidad y resiliencia integradas y mejor utilización de los recursos, por nombrar solo algunos. Los desarrolladores también ven el valor de ejecutar en una configuración contenerizada: más influencia en el entorno de ejecución, un mejor control de las bibliotecas y dependencias y reducir la brecha entre los entornos de producción y desarrollo son algunos de ellos. Cada lado de la 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 contenerizado, pero eso no es suficiente. Todavía nos falta el marco para que los desarrolladores y las operaciones trabajen juntos y que esto sea un éxito. Simplemente hay muy pocas herramientas y tecnologías disponibles, si es que las hay, que faciliten esta comunicación.
Todos estamos tan centrados en nuestras áreas individuales de innovación, desde la red hasta el almacenamiento y la orquestación, que podemos dejar de centrarnos en el logro de sus objetivos empresariales por parte de nuestros clientes. En un entorno así, a las empresas de integración de sistemas, consultoría y servicios profesionales les va bien, ya que son las únicas que se centran en el resultado y en la entrega a lo largo de la cadena de suministro de software, pero esto no es sostenible. Las tecnologías que requieren que los clientes paguen tanto a las consultoras para que funcionen no van a ser tecnologías innovadoras. Seamos sinceros: si la virtualización necesitara que McKinsey estuviera siempre presente en la nómina para que funcionara, hoy no habría nube
.Para que todos nos beneficiemos de una tecnología innovadora, como la contenedorización de infraestructuras, tenemos que 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, mayores serán los beneficios para nuestros clientes.
Devops no es solo un montón de herramientas fragmentadas o un proyecto elegante de «transformación digital», sino 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 torno a la contenedorización, también tiene que abordar la mentalidad de colaboración continua antes que nada. Así que, creemos todos los productos con eso en mente para iniciar y mantener una conversación entre los desarrolladores y los operadores.
Este post se publicó por primera vez aquí