Historia de Cloud Foundry – IBM Developer

Blog de desarrolladores de IBM

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

Esta serie de tres partes revisa las contribuciones de IBM y la evolución de la plataforma Cloud Foundry


En el verano de 2018, antes del inicio de la cumbre de Cloud Foundry en Boston, coescribí un artículo en el que señalaba algunos conceptos erróneos y hechos comunes sobre Cloud Foundry. Este artículo fue escrito en el contexto de un creciente movimiento de contenedores en el sector tecnológico.

Aunque Cloud Foundry usó contenedores, los organizó e hizo que fueran fáciles para los simples mortales, al ocultar gran parte de esa complejidad. Debido a ese hecho, parece que los usuarios no se dieron cuenta de que Docker y Kubernetes emergentes estaban solamente explorando una sección transversal del enorme conjunto de características que abordaba Cloud Foundry.

Profundización de Cloud Foundry Sesión «Profundización de Cloud Foundry» con Nima Kaviani

El artículo del año pasado fue popular, pero el entusiasmo por exponer las características primitivas que Cloud Foundry incorporó en su núcleo no se redujo. De hecho, Docker, y en particular Kubernetes, alcanzó el máximo entusiasmo, con un aumento de las adopciones que están eclipsando a todas las demás plataformas en menos de un año.

Quizás ahora sea el momento de considerar otra publicación introspectiva sobre el tema. Pero en lugar de enmarcarlo como una enumeración de las características y valores de Cloud Foundry, tal vez sea el momento de volver a la historia de esta gran plataforma y extraer algunas lecciones aprendidas que podrían ser útiles para esta comunidad y más allá.

Como miembro integral de la comunidad de Cloud Foundry con años de experiencia en el sector de TI y habiendo participado en varias comunidades de software de open source (OSS) (nuevas y maduras), es incluso un deber que debería estar obligado a cumplir.

Desarrolladores en Cloud Foundry Summit 2016 en Santa Clara Desarrolladores en Cloud Foundry Summit 2016 en Santa Clara

Naturalmente, como advertencia al lector, es importante revelar que mis opiniones y mi punto de vista son examinados con los lentes de mis experiencias, de mis colegas inmediatos, de mis colaboradores y de mi empleador: IBM Cloud.

En lugar de ocultar estas inclinaciones, las expondré cuando sea necesario. Así que sigue leyendo si quieres tener una perspectiva de la historia de Cloud Foundry desde el punto de vista de un IBMer.

Lo que espero lograr con esta serie de tres partes es doble. Primero, quiero crear un registro para la posteridad, que incluya tanto las contribuciones de IBM como la evolución de la plataforma Cloud Foundry.

Y segundo (y quizás la parte más útil de esta serie), quiero rescatar lecciones aprendidas que podrían ser importantes tanto para los miembros de la comunidad de Cloud Foundry como para otras comunidades en el mismo espacio, a medida que avanzamos.

Los inicios: hacia el 2012

Cloud Foundry fue creado en VMware por un grupo de exempleados de Google que buscaban duplicar la plataforma interna que Google usa para gestionar sus numerosos servicios y aplicaciones: Borg. Sin embargo, en lugar de crear otra plataforma patentada que beneficiaría solo a unos pocos, los líderes de la primera Cloud Foundry (incluida la gestión de VMware) decidieron hacer que la plataforma fuera open source.

IBM Cloud Foundry Day en Londres en 2018 IBM Cloud Foundry Day en Londres en 2018

Recuerdo la reunión en la que Derek Collison anunció el open sourcing de Cloud Foundry a finales de 2010 y una amplia disponibilidad del código de origen en las oficinas de VMware en Palo Alto. Recuerdo esto bien porque estaba trabajando en un proyecto de investigación para crear una plataforma como servicio (PaaS) en la nube llamada Altocumulus. No fue sorprendente que VMware también estuviera trabajando en un proyecto similar.

Después de todo, la nube fue el nuevo éxito en Silicon Valley. Si bien muchos se estaban enfocando en crear el software necesario para competir con la plataforma AWS EC2 en auge, muchos también estaban observando lo que vendría después y PaaS parecía ser la dirección correcta. Sin embargo, lo interesante del lanzamiento de esta nueva PaaS fue la parte de open source.

Cena del equipo de IBM Cloud Foundry en Basilea, Suiza, durante el Cloud Foundry Summit 2017 El equipo de IBM Cloud Foundry reunido para la cena en Basilea, Suiza, durante el Cloud Foundry Summit 2017

El equipo de software de IBM se interesó de inmediato y varias personas de IBM comenzaron a jugar con la primera versión de Cloud Foundry que inicialmente estaba completamente empaquetada en una memoria USB. Después de varias pruebas internas para configurar y ejecutar Cloud Foundry, el proyecto OSS captó la atención del equipo de tecnología OSS emergente dirigido por el Dr. Angel Díaz.

Los primeros esfuerzos de Doug Davis y Chris Ferris dieron sus frutos cuando Angel y su grupo decidieron formar un equipo de Cloud Foundry (bajo el liderazgo de Alex Tarpinian) y contratar a la nueva empresa administradora de Cloud Foundry: Pivotal.

Al mismo tiempo que esto sucedía, estaba surgiendo un nuevo actor empresarial en la nube. Bajo el liderazgo de Rob Mee, Pivotal, la firma de consultoría de software ágil con sede en San Francisco, heredó la base de código de Cloud Foundry. Esto encajaba perfectamente, porque Pivotal tenía un gran equipo de desarrolladores de Ruby y se había asociado con VMware.

Alex Tarpinian y Michael Fraenkel, dos de los líderes iniciales del equipo Cloud Foundry de IBM Alex Tarpinian y Michael Fraenkel, dos de los líderes iniciales del equipo Cloud Foundry de IBM

Naturalmente, esta nueva administración también significó un gran cambio para la base de código de Cloud Foundry, porque los ingenieros de Pivotal comenzaron a incluir sus opiniones. Sin embargo, el mayor cambio en ese momento fue que el equipo directivo sénior de Pivotal insistió en utilizar un proceso ágil y fuerte para guiar las direcciones de Cloud Foundry. Mientras tanto, IBM y otros grandes actores estaban dispuestos a invertir millones y a asignar decenas de ingenieros al proyecto. ¿Se trataba de un choque cultural esperando a que ocurriera?

Emparejamiento y procesos: 2014 hasta la actualidad

Quizás ningún aspecto del proceso que Pivotal utilizó para Cloud Foundry ha tenido más controversia que el emparejamiento. La programación en parejas es un valor ágil de larga trayectoria que dicta que todo el código (desarrollo o prueba) debe realizarse en pares. Si bien es interesante y novedoso para algunos, ha sido investigado y explorado durante mucho tiempo en las comunidades académicas e incluso se ha utilizado ampliamente en varias pequeñas empresas emergentes. Las consecuencias del emparejamiento son probablemente mayores que la dificultad o la utilidad en la práctica.

En primer lugar, la programación en parejas requiere que ambos ingenieros estén presentes al mismo tiempo y en la misma ubicación o, cuando se emparejan de forma remota, conectados a la misma línea de audio y video. Además de la consecuencia práctica de atar dos recursos para trabajar en el mismo código, los requisitos logísticos para el emparejamiento se convirtieron en un punto de discusión cuando más empresas internacionales, con desarrolladores distribuidos en zonas horarias de todo el mundo, se unieron a los esfuerzos de Cloud Foundry.

Sesión de emparejamiento Una sesión de emparejamiento

Para abordar las preocupaciones y reclamos en torno a su proceso, el equipo de gestión de Pivotal brindó oportunidades únicas para capacitar a ingenieros de todas las empresas al permitirles unirse y aprender el enfoque ágil de Pivotal para la ingeniería de software. Y así nació el programa dojo, que llegó a definir cómo los ingenieros se ponen al día y ayudan a contribuir a Cloud Foundry. Los primeros ingenieros de IBM en el proyecto Cloud Foundry, como Michael Fraenkel, Matt Sykes, Julian Friedman y yo, participamos en una parte de este programa. El compromiso de tiempo era a veces de cuatro a ocho semanas.

Además del enorme compromiso de tiempo y los costos potenciales, uno de los aspectos controvertidos del proceso de emparejamiento en ese momento era que los desarrolladores de dojo necesitaban participar personalmente en San Francisco y tenían que pasar una prueba para ser invitados. Conocida como RPI (Rob’s Pairing Interview), la prueba fue un ejercicio fundamental de programación de secretos comerciales que Rob Mee y el equipo de gestión capacitado usaron para determinar si los colaboradores potenciales (o en este caso los ingenieros de OSS de Cloud Foundry) tenían las habilidades y se encajarían en la cultura ágil de Pivotal.

Desarrollador moderno, Nima Kaviani de IBM, emparejamiento en la era de los trabajadores móviles Desarrollador moderno, Nima Kaviani de IBM, emparejamiento en la era de los trabajadores móviles

Con el tiempo, a medida que más ingenieros participaron en el proceso de dojo, las reacciones negativas iniciales o el rechazo disminuyeron, ya sea por los costos, por el compromiso o por lo que algunos percibían como barreras innecesarias para contribuir. El equipo de IBM presentó lo que aprendieron de sus experiencias y fue testigo de que el compromiso y los costos en general valieron la pena. De hecho, el proceso, aunque no era perfecto, tenía sus méritos, por ejemplo, un tiempo de aceleración rápido, calidad sostenida, empatía hacia todos los desarrolladores, ningún propietario y muchos otros.

Si bien el primer programa de dojo fue un largo camino para llevar a Cloud Foundry más allá del ámbito de los ingenieros de Pivotal, no ayudó a impulsar la comunidad. Quizás no acelerar las contribuciones fue algo bueno para Cloud Foundry en general en ese momento. Internamente, el proyecto estaba casi reescrito en un lenguaje nuevo y popular (pero apropiado para el software en la nube) llamado Golang.

Conclusión

En esta publicación se recordaron los inicios de Cloud Foundry, desde un ambicioso proyecto de open source creado en VMware por ex Googlers hasta el cambio a una nueva y ágil compañía llamada Pivotal. Resumí los primeros años bajo la dirección de Pivotal y el crecimiento inicial con la participación de empresas del sector más grandes como IBM, SAP, GE y otras. También revisé el proceso ágil único (para open source) que Pivotal insistió en usar y las ramificaciones de este proceso (tanto buenas como malas).

Patrocinadores de CF Summit 2017 con Abby Kearns, Executive Director de Cloud Foundry Foundation Patrocinadores de CF Summit 2017 con Abby Kearns, Executive Director de Cloud Foundry Foundation

La parte 2 de esta serie analiza la creación de una base y resume la historia y la evolución de los componentes principales del proyecto Cloud Foundry , por ejemplo, BOSH, Runtime/Diego, Extensions y el reciente avance con otros proyectos de open source como Kubernetes e Istio. Para cada una de esas áreas, observé cómo IBM y otros participantes pudieron contribuir y ayudar a Cloud Foundry a disfrutar del éxito que ha tenido.

Recursos relacionados: