Blog de desarrolladores de IBM

Siga los últimos acontecimientos con IBM Developer y manténgase informado.

La segunda parte de esta serie explora la creación de Cloud Foundry Foundation y los componentes del proyecto de open source Cloud Foundry


En la parte 1 de esta serie de tres partes, repasamos los primeros días de Cloud Foundry como un proyecto que comenzó en VMware y creció hasta convertirse en una plataforma como servicio (PaaS) líder, lo que dio lugar a una transformación ágil en la nube de muchas empresas. A lo largo de este recuerdo temprano, también te presentamos a los jugadores clave, las participaciones y contribuciones de IBM, así como también destacamos algunos puntos de desacuerdo iniciales.

En la parte 2 recordamos la creación de Cloud Foundry Foundation, una organización independiente sin fines de lucro con el respaldo de The Linux Foundation que posee toda la propiedad intelectual y código para Cloud Foundry. Además de resolver problemas legales, esa fundación ayudó a la transición de Cloud Foundry de un proyecto de software de open source bajo la tutela de una empresa a un proyecto que está abierto al mundo.

Además de comprender la evolución de Cloud Foundry a grandes rasgos, sus procesos y colaboradores, también es interesante ver la evolución de sus componentes principales. Después de todo, Cloud Foundry es un gran proyecto técnico con cientos de repositorios de GitHub y millones de líneas de código. ¿Cómo podemos entender esta enorme base de código? ¿Cuáles son los componentes clave? ¿Cómo han evolucionado? Sigue leyendo para obtener más información.

Cloud Foundry Foundation 2016-presente

Uno de los pasos que IBM tomó en casi todos los proyectos de open source en los que se involucró seriamente fue garantizar un modelo de gobernanza correcto que funcione para todos. Lo habíamos hecho para Linux, Java, Node.js y muchos otros proyectos de software de open source. Con Cloud Foundry bajo la dirección de una empresa, la necesidad de una gobernanza independiente fue un problema desde el principio que debía abordarse.

Sam Ramji, primer CEO de Cloud Foundry Foundation. En el CF Summit 2016 en Frankfurt, Alemania Sam Ramji, primer CEO de Cloud Foundry Foundation, en el Cloud Foundry Summit 2016 en Frankfurt, Alemania

Entonces, mientras los ingenieros de IBM participaron gradualmente en el dojo y comenzaron a contribuir cada vez más a varios aspectos de la base de código de Cloud Foundry, Chris Ferris junto con Todd More, trabajaron con sus contrapartes en Pivotal, SAP y algunos otros primeros adoptantes de Cloud Foundry para constituir un órgano de gobernanza con las normas y los procesos correspondientes. El resultado final fue la creación de Cloud Foundry Foundation.

Naturalmente, con una nueva base vinieron trabajos y dolores de cabeza. Por un lado, Cloud Foundry Foundation necesitaba contar con un líder y delegados asociados. No es un proceso fácil si alguna vez ha intentado contratar profesionales con experiencia técnica en el Área de la Bahía o donde haya escasez de talento tecnológico. Afortunadamente, la junta fundadora tomó una gran decisión al contratar a Sam Ramji (ahora VP Cloud Platform en AutoDesk) para ser el CEO.

Chip Childers (CTO) y Swarna Podila (Director) de Cloud Foundry Foundation CTO Chip Childers y Director Swarna Podila de Cloud Foundry Foundation

De manera confiable, pero también muy humilde e inclusiva, Sam dirigió la comunidad de Cloud Foundry en sus primeros años. Sam, que ocupó el papel principal en la Cloud Foundry Summit, fue el principal animador y la voz de la razón para ayudar a Cloud Foundry a cerrar la brecha entre un proyecto OSS interesante y un sistema operativo bien adoptado para aplicaciones en la nube. También contrató a un equipo sólido que incluía a Chip Childers, Abby Kearns y otros para completar la base en crecimiento, que ha florecido incluso cuando Sam decidió irse para ocupar un puesto ejecutivo en Google Cloud a fines de 2017.

BOSH 2012-presente

Como se describe en la parte 1, al crear Cloud Foundry, los ex Googlers de VMware tenían el objetivo de formar la próxima versión del proyecto interno de Google Borg. Debido a que se rumoreaba que Borg era un programador y un administrador integral para la infraestructura y cargas de trabajo de Google, los diseñadores de Cloud Foundry decidieron dividir las preocupaciones y separar la gestión de la infraestructura de los bits que administraban las aplicaciones. BOSH se creó para proporcionar gestión de infraestructura, mientras que el núcleo de Cloud Foundry administraría los contenedores y las aplicaciones que se ejecutan en ellos.

Desde el comienzo del proyecto de software de open source Cloud Foundry, BOSH fue un hijastro problemático. El punto de diseño de BOSH estaba destinado a ser independiente de Cloud Foundry, pero al mismo tiempo, Cloud Foundry fue y siempre será la mayor carga de trabajo que BOSH tiene que gestionar. El diseño general es simple, pero el diablo está en los detalles. Al tomar un enfoque de agente para gestionar la infraestructura, BOSH puede verse dividido en un director central que está controlado por los operadores humanos y varios agentes que se ejecutan de forma semiautónoma en las máquinas virtuales gestionadas.

Dr. Nic Williams de Stark & Wayne, entusiasta inicial de BOSH y autor de The Ultimate Guide to BOSH Dr. Nic Williams de Stark & Wayne, uno de los primeros entusiastas de BOSH y autor de The Ultimate Guide to BOSH

Cuando los operadores envían comandos al director para una carga de trabajo desplegada en particular, el director debe recopilar todo el conocimiento que tiene sobre el clúster para la carga de trabajo y el estado de sus recursos asignados actualmente. Debe trazar un plan para lograr el nuevo estado deseado y luego debe emitir comandos a los diversos agentes para llegar a ese nuevo estado. Cuando los comandos requieren la creación de recursos de infraestructura o la eliminación de los existentes, los comandos se envían a una interfaz en la nube para aprovisionar, configurar y limpiar los recursos.

Aunque conceptualmente simple, en realidad no lo es. La complejidad proviene no solo de tener que lidiar con errores que pueden ser de naturaleza estocástica y dos componentes más que no he mencionado, sino también de la necesidad de soportar muchas infraestructuras. Exploremos brevemente y mencionemos cómo IBM ayudó a Pivotal a evolucionar BOSH hacia la mejor implementación de esa arquitectura.

El sistema BOSH está altamente distribuido en su ejecución, pero centralizado en su control. La complejidad proviene del hecho de que las abstracciones creadas podrían funcionar bien (a través de pruebas y ajustes) para una pequeña cantidad de infraestructuras, pero se volvieron poco sólidas con los otros dos componentes que también variaban: versiones e interfaces de proveedores de nube (CPI).

Dmitryi Kalinin de Pivotal, exjefe de proyecto de BOSH y jefe de proyecto durante la extracción y el auge de CPI Dmitryi Kalinin de Pivotal, exje de proyecto de BOSH y jefe de proyecto durante la extracción y el auge de CPI

Primero, BOSH solo es útil si puede desplegar y gestionar fácilmente el ciclo de vida del software en la nube (por ejemplo, Cloud Foundry, Maria DB, Prometheus y otro middleware distribuido de interacción compleja). Capturar las interacciones del software desplegado y la configuración de esos componentes de software es el trabajo de una versión de BOSH. Un paquete estructurado y una descripción de un software en la nube administrado por BOSH.

Empleando su propio lenguaje y términos, BOSH especifica estrictamente cómo se gestionan y empaquetan las «versiones» (como se las llama). Y debido a que todo el software en ejecución requiere un conjunto básico de primitivas del sistema operativo para abstraer los recursos subyacentes, todas las máquinas virtuales BOSH ejecutan un sistema operativo simplificado y común basado en Linux. Esto se llama célula madre BOSH.

Las principales contribuciones de IBM a BOSH no solo fueron ayudar a hacer crecer el proyecto y lidiar con los esfuerzos de desarrollo diarios, sino también estirar y probar su diseño a escala. En primer lugar, al crear una de las primeras células madre de arquitectura no Intel (para la arquitectura Power) pudimos ayudar a probar, verificar y madurar los aspectos de las células madre de BOSH.

Equipo de IBM China Development Lab BOSH en el almuerzo de 2017 Equipo de IBM China Development Lab BOSH en el almuerzo de 2017

En segundo lugar, y quizás lo más importante, la CPI de BOSH se había diseñado para permitir extensiones, pero en realidad estaba integrada en el código del director. Trabajando en estrecha colaboración con Pivotal, ayudamos a extraer y a optimizar la interfaz de CPI, lo que resultó en un auge de las infraestructuras compatibles con BOSH (hasta 20 en el último recuento).

Finalmente, mientras que BOSH se probó para desplegar y gestionar entornos de Cloud Foundry compuestos de decenas a cientos de máquinas virtuales, el éxito de IBM Bluemix (el nombre anterior de IBM Cloud) llevó a múltiples entornos repartidos por todo el mundo, cada uno de los cuales comprendía de cientos a miles de máquinas virtuales. Naturalmente, la ley de los grandes números simplemente exige que las fallas y los problemas en estos sistemas a gran escala se conviertan en problemas cotidianos.

Al probar BOSH a esta escala, encontramos varias anomalías y problemas específicos de escala, que trabajamos con Pivotal para resolver. Un ejemplo específico fue la necesidad de un DNS nativo de BOSH, que era una característica que necesitaban los entornos que ampliaban los límites de PowerDNS, usado normalmente en los primeros despliegues de Cloud Foundry.

Runtime/Diego 2014-presente

Cada plataforma como servicio (PaaS) contiene un componente que toma decisiones sobre qué trabajos ejecutar, cuándo ejecutarlos y qué recursos asignar a cada trabajo. Este componente es similar a los núcleos del sistema operativo. Tales programadores o funciones de asignación de trabajos se han estudiado en las publicaciones sobre sistemas operativos. Según los trabajos, los recursos disponibles, el runtime esperado de los trabajos y otros parámetros, es probable que pueda escribir un algoritmo óptimo.

Por supuesto, en la práctica no se tiene una visión del mundo como un oráculo. Los trabajos llegan y se cancelan en momentos aleatorios. Por lo que es inútil optimizar para todos los casos. En cambio, los desarrolladores suelen implementar una solución alternativa al problema del embalaje en contenedores, lo que proporciona una solución casi óptima y permite cierta flexibilidad para hacer frente a las variaciones.

Matt Sykes y Michael Fraenkel, primeros ingenieros de CF y Diego Matt Sykes y Michael Fraenkel, primeros ingenieros de Cloud Foundry y Diego

Dentro de su núcleo, el código en runtime de Cloud Foundry incluía alguna implementación de este espacio conceptual de problema/solución, comúnmente conocido como Droplet Execution Agent (DEA). Sin embargo, esa implementación no permitió ninguna flexibilidad. Además, no estaba claramente separado de las API que estaban expuestas a otras partes del sistema.

Y para empeorar las cosas, como todas las partes de Cloud Foundry, el núcleo de runtime se escribió en el lenguaje de programación Ruby. Si bien es un gran lenguaje para la creación de prototipos y algunos componentes del sistema (por ejemplo, API), es subóptimo e ineficiente para otros componentes del sistema. Al mismo tiempo, el equipo de ingeniería de Cloud Foundry en Pivotal tenía experiencia en la reescritura de algunos otros componentes (por ejemplo, la CLI y el monitoreo del estado), utilizando Golang con resultados positivos.

Los primeros éxitos de la reescritura del monitoreo del estado (HM9000) y la creciente participación y crecimiento del equipo de software de open source de Cloud Foundry (que ahora incluía ingenieros de IBM, SAP y otros) empujaron al equipo de runtime a considerar la reescritura del código en runtime en Golang. Bajo el liderazgo de Onsi Fakhouri de Pivotal con la notable asistencia del equipo inicial (Michael Fraenkel, Matt Sykes, Alex Suraci, Eric Malm y otros) se creó un nuevo equipo de runtime, con el nombre cifrado de Diego (o DEA-in-go).

Julian Friedman de IBM Reino Unido, líder de los proyectos Garden y Eirini Julian Friedman de IBM Reino Unido, líder de los proyectos Garden y Eirini

Si bien la reescritura del núcleo de la plataforma Cloud Foundry tenía muchos objetivos, uno de los principales objetivos era permitir que la plataforma escale, satisfaciendo mejor las necesidades de crecimiento y de soporte de ingeniería. El equipo Diego Runtime había acumulado una deuda técnica donde tenía sentido contemplar la reescritura. Por supuesto, como en cualquier proyecto de software no trivial, el equipo Diego trabajó duro para entregarlo, pero tomó un tiempo conseguir que la plataforma resultante escalara a los niveles que el sistema de ejecución anterior había logrado a lo largo de los años.

Además de la complejidad de intentar cambiar el código en runtime a un «planificador moderno» que utilizaba un enfoque novedoso basado en subastas, el equipo también necesitaba abordar el mundo externo de los contenedores, que había progresado. En particular, la popularidad de Docker y Kubernetes dio lugar a plataformas alternativas emergentes de runtime de contenedores de open source. Un resultado positivo fue la creación de Open Container Initiative bajo el liderazgo y la guía de la junta de CNCF (Cloud Native Computing Foundation).

Para tratar con la Open Container Initiative, se escindió una nueva versión de la capa de gestión de contenedores (llamada Garden) y se trasladó a Londres bajo el liderazgo de Julian Friedman de IBM y sus colegas de Pivotal. Separar la gestión de contenedores y hacerla compatible con un estándar emergente ayudó a aclarar y simplificar la tarea que enfrentó el equipo Diego. También permitió que Cloud Foundry se alineara mejor con el resto del sector. Muy pronto, la capacidad de ejecutar imágenes de Docker directamente en Cloud Foundry fue posible.

Kubernetes 2015-presente

Como se mencionó anteriormente, mientras el equipo de runtime de Cloud Foundry estaba ocupado reescribiendo el núcleo, el resto del sector no se quedó quieto. Proyectos como Docker, y en particular Kubernetes, cobraron fuerza y se convirtieron en alternativas cada vez más viables al código en runtime del programador de Cloud Foundry. Por supuesto, las especulaciones fueron desenfrenadas, e incluso hubo esfuerzos para unir a los dos. Por ejemplo, el equipo dúo de IBM, Michael Fraenkel y Matt Sykes, creó rápidamente un prototipo para mostrar y validar la viabilidad de usar Kubernetes como programador para Cloud Foundry.

Sin embargo, el equipo Diego estaba dando los toques finales a su nuevo y brillante código en runtime, por lo que, naturalmente, cualquier cambio de dirección tan tarde en el juego se enfrentaría a retrocesos. Se acordó no buscar un código en runtime alternativo, sino hacer que el sistema de runtime de Diego escale a los niveles en los que estaría a la par o mejor que el antiguo sistema de runtime Ruby. Con esfuerzo y persistencia, el equipo Diego pudo lograr los objetivos e incluso agregar más funciones, como persistencia de almacenamiento, soporte SSH y redes de contenedores.

Simon Moser (IBM Alemania) y Julian Friedman (IBM Reino Unido) precursores del Proyecto Eirini Simon Moser (IBM Alemania) y Julian Friedman (IBM Reino Unido) precursores del Proyecto Eirini

En general, a fines de 2016 y principios de 2017, el proyecto Diego estaba alcanzando sus avances y varios clientes de Cloud Foundry Foundation lo estaban desplegando y usando. Había alcanzado su máxima emoción en 2017. A fines de ese año, no era una cuestión de si cambiar o no a Diego, sino cuándo. Sin embargo, el mundo también había evolucionado. Kubernetes se vio más como una capa de orquestación de contenedores sin procesar. Había madurado y se convirtió en un sistema de runtime viable para microservicios, bajo el liderazgo de Google, Microsoft, IBM y otros.

A medida que los proveedores y usuarios comenzaron a adoptar Kubernetes para sus necesidades de microservicios, se hizo cada vez más claro que se necesitaría un acercamiento, que los ingenieros de IBM habían notado anteriormente y habían creado un prototipo. Con la versión del proyecto Fissile, otro miembro de la fundación, SUSE, había demostrado de forma independiente que la versión de Cloud Foundry se podía contener y ejecutar sobre Kubernetes. La pregunta era ahora cuándo la Fundación Cloud Foundry debería adoptar enfoques para permitir oficialmente este acercamiento.

Jeff Hobbs y Vlad Iavanov de SUSE Jeff Hobbs y Vlad Iavanov de SUSE

Se iniciaron varios esfuerzos, incluidos los intentos de tratar a Kubernetes como un IaaS y, por lo tanto, utilizar el mecanismo de interfaz de proveedor de nube (CPI) de BOSH. Si bien uno de estos esfuerzos tuvo éxito, no fue nativo de las herramientas de Kubernetes ni de la forma en que la comunidad de Kubernetes gestiona sus cargas de trabajo. Así que era hora de revivir la capacidad de sustituir el núcleo en runtime. Bajo el liderazgo de IBM (Julian Friedman, con la ayuda de Simon Moser), así como de SAP (Bernd Krannich) y SUSE (Jeff Hobbs y Vlad Iavanov), se inició otro esfuerzo para crear un sistema de runtime de Kubernetes para Cloud Foundry.

Después de las demostraciones iniciales, los puntos de prueba y varias extensiones de la plataforma aprobadas por Cloud Foundry Foundation a través del CF-Extensions Project Management Committee, quedó claro que estos proyectos experimentales eran prometedores y se convertirían en extensiones y adiciones viables. Así nació el proyecto Eirini. Hoy en día, el proyecto Eirini avanza con fuerza y tiene como objetivo lanzar una vista previa de la tecnología a mediados de 2019 y quizás un despliegue completo para el cliente a finales de año.

Conclusión

Como muchos grandes proyectos de open source exitosos, los primeros días de Cloud Foundry estuvieron llenos de problemas «políticos» y de proceso. Cuando los líderes de Pivotal asumieron la administración de Cloud Foundry en los primeros días, el proceso ágil y sólido que utilizaron se convirtió en un gran beneficio, así como una molestia para algunos, impidiendo su adopción y crecimiento. Cloud Foundry Foundation se fundó para aliviar algunos de los problemas iniciales y permitir una mayor apertura y flexibilidad para los colaboradores.

Además, las bases de código grandes son, por definición, difíciles de comprender y evolucionan de manera que las hacen aún más difíciles de comprender. A medida que Cloud Foundry creció hasta convertirse en lo que es hoy, surgió de forma natural una estructura organizativa simple (después de varios intentos). Esa estructura permanece hasta el día de hoy con las siguientes agrupaciones: Runtime, BOSH y Extensions. Con cada grupo de proyectos trajo claridad de propósito y gobernanza.

Abby Kearns en CF Summit Boston en 2018 Abby Kearns en Cloud Foundry Summit Boston en 2018

Si bien la mayoría de los problemas y la evolución discutidos aquí son fácilmente reconocibles en otros proyectos de open source, la dinámica y las soluciones quizás sean diferentes. Entonces, lo que quiero hacer para la parte final de esta serie es resumir la estructura actual que gestiona Cloud Foundry (runtime, BOSH y extensions), enumerar algunos otros componentes diversos a los que IBM ha contribuido en gran medida y llamar la atención sobre algunas lecciones aprendidas que tanto esta comunidad como otras comunidades pueden utilizar en el futuro.