Hace 10 años, en el primer AWS re:Invent, en Red Hat hicimos un acto de fe con nuestra cartera de tecnología. Basándonos en el éxito de nuestras emblemáticas soluciones Red Hat Enterprise Linux y JBoss Middleware, lanzamos Red Hat OpenShift Enterprise 1.0, la oferta híbrida de plataforma como servicio (PaaS) de código abierto de Red Hat orientada a los desarrolladores empresariales.
Aquí estamos una década después. El código abierto es un motor clave para toda la innovación tecnológica, ya sea en el centro de datos o en la nube pública. Kubernetes es el estándar de facto para los contenedores y las plataformas nativas de la nube y el cloud computing está haciendo sentir su presencia en la TI empresarial. Red Hat OpenShift ha cambiado… solo un poco.
La evolución de OpenShift ha sido un viaje, pero uno que está lejos de terminar. Seguimos ampliando a nuevas plataformas y casos de uso, añadiendo nuevas capacidades, mejorando las características existentes y abriendo nuevos caminos para abordar las necesidades de TI emergentes. Dicho esto, para poder decir a dónde vamos, tenemos que entender de dónde venimos.
El origen de OpenShift
Aunque Red Hat OpenShift 1.0 estuvo disponible de manera general en noviembre de 2012, el concepto real comenzó mucho antes, con un desarrollo inicial que empezó a principios de 2010, y que luego se aceleró con la adquisición de Makara por parte de Red Hat a finales de ese año y que presentó Paul Cormier en Red Hat Summit 2011.
Los desarrolladores acudían en masa a los nuevos servicios de PaaS en la nube pública, como Heroku, que permitían el despliegue de aplicaciones de autoservicio y una mayor agilidad. Los CIOs, motivados por el mismo deseo de impulsar una mayor velocidad y agilidad para los desarrolladores en sus propias organizaciones, vieron el valor de PaaS como una vía para estandarizar las herramientas y los entornos de los desarrolladores de aplicaciones empresariales y crear una base de aplicación común, independientemente del propósito o la base de código de la aplicación resultante. Les encantaba el concepto de PaaS, pero estaban limitados en su capacidad de trasladar sus aplicaciones empresariales a la nube pública.
OpenShift Enterprise 1.0, al igual que toda la cartera de nubes híbridas de Red Hat en la actualidad, permitía a los clientes funcionar en cualquier entorno de la nube híbrida, incluidos sus centros de datos o cualquier nube pública. Construido sobre una base de Red Hat Enterprise Linux (RHEL), OpenShift podía desplegarse en cualquier lugar en el que RHEL estuviera certificado para funcionar y utilizaba contenedores Linux basados en RHEL para desplegar aplicaciones, mucho antes de que Docker existiera.
Sobre esta plataforma, los desarrolladores podían elegir los lenguajes y marcos de aplicación para desplegar sus aplicaciones, desde Java empresarial con JBoss Enterprise Application Platform 6 o Tomcat, hasta Ruby, Python, Node.js y otros. OpenShift era único en su momento, ya que ofrecía una plataforma PaaS totalmente de código abierto que ofrecía un montón de herramientas y capacidades políglotas para desarrolladores, construidas sobre la estabilidad y la seguridad mejorada de RHEL.
Sin embargo, como se dice, nada permanece igual.
Gears, Cartridges y… Kubernetes
Las siguientes versiones menores de OpenShift, así como la versión mayor de OpenShift Enterprise 2, añadieron una serie de características desarrolladas en la comunidad upstream de OpenShift Origin, desde capacidades mejoradas para desarrolladores y mayores controles administrativos hasta una mayor integración con OpenStack y otras plataformas de infraestructura. OpenShift utilizaba gears para ejecutar sus aplicaciones, que eran esencialmente el predecesor de OpenShift a los contenedores de Linux como los conocemos y amamos hoy.
Gears utilizaba tecnologías subyacentes en RHEL, como los espacios de nombres del kernel de Linux, cGroups y SELinux, para ofrecer una plataforma de aplicaciones altamente escalable y en contenedores con una postura de seguridad mejorada. OpenShift también añadió «cartridges» para llevar nuevos tiempos de ejecución de aplicaciones a la plataforma; esencialmente aplicaciones de terceros empaquetadas para ejecutarse en contenedores por partners de Red Hat y validadas para funcionar en OpenShift.
Aunque está muy lejos de las capacidades de OpenShift hoy en día, esto demostró la eficiencia y agilidad que se puede obtener mediante el uso de contenedores para el despliegue de aplicaciones, en lugar de tener que emitir máquinas virtuales (VM) para construir y desplegar aplicaciones y luego gestionar el ciclo de vida de esas VM a través de un equipo de desarrolladores. Esto también demostró lo importante que era (y sigue siendo) nuestro ecosistema de partners para el éxito de la plataforma.
Todo cambió con el auge de los contenedores Docker y, poco después, de Kubernetes. El lanzamiento del proyecto de código abierto Docker en 2013 resultaría ser un momento decisivo en la industria tecnológica. Aunque la tecnología de contenedores de Linux tenía raíces que se remontan a Unix y ya se utilizaba en soluciones como OpenShift, Cloud Foundry e incluso Heroku, Docker hizo que los contenedores fueran más sencillos y accesibles para los desarrolladores y facilitó enormemente el empaquetado de nuevas aplicaciones para su ejecución en contenedores.
Red Hat fue una de las primeras empresas en unirse a la comunidad Docker y contribuir al proyecto. RHEL se convirtió entonces en el primer sistema operativo Linux comercial en anunciar la compatibilidad con los contenedores Docker. Más tarde, Red Hat colaboró con la comunidad para impulsar el estándar de la Open Container Initiative (OCI) para el tiempo de ejecución de contenedores y el formato de empaquetado, que hoy es el estándar de la industria para todas las aplicaciones en contenedores.
Los contenedores, y, antes, los gears, no eran mucho más que formas únicas de empaquetar y ejecutar servicios de aplicaciones individuales. Sin embargo, la mayoría de las aplicaciones requerían la orquestación de múltiples microservicios y su vinculación para formar una aplicación más grande y sofisticada. Aquí es donde Kubernetes entró en escena como el estándar para orquestar y gestionar contenedores a escala. Red Hat se dio cuenta rápidamente de la importancia del proyecto, se unió a Google para lanzar la comunidad de Kubernetes y, con OpenShift 3, Kubernetes se convirtió en el motor fundacional de la plataforma OpenShift.
Operar plataformas inalterables con Operadores
La columna vertebral de Kubernetes de OpenShift ya estaba establecida, pero Kubernetes es, bueno, complejo. En los primeros días de OpenShift 3, trabajamos duro para abstraer la complejidad de la orquestación, pero el mantenimiento de la aplicación y la plataforma todavía podía ser un problema a escala. A principios de 2018, Red Hat adquirió CoreOS y con la empresa llegó su plataforma Tectonic, que integraba el sistema operativo CoreOS Container Linux, y el concepto de operadores de Kubernetes.
Los operadores de Kubernetes, construidos sobre Definiciones de Recursos Personalizadas (CRD, por sus siglas en inglés), proporcionaron un patrón o marco repetible para mantener y actualizar las aplicaciones nativas de la nube, tratando esencialmente todas las aplicaciones que se ejecutan en la plataforma como un servicio nativo de Kubernetes. Mientras tanto, la integración de RHEL con CoreOS Container Linux dio lugar a RHEL CoreOS, e hizo del sistema operativo un componente integrado de la plataforma OpenShift Kubernetes. RHEL CoreOS y el marco de trabajo del operador facilitaron el despliegue de la plataforma OpenShift y la entrega de servicios más complejos a la plataforma a través de la nube híbrida abierta y, en Red Hat Summit 2019, se lanzó Red Hat OpenShift 4.
En la actualidad, OpenShift 4 es la plataforma empresarial de Kubernetes líder del mercado, que destaca por la completa oferta de Red Hat OpenShift Platform Plus, que también incluye Red Hat Advanced Cluster Security for Kubernetes y Red Hat Advanced Cluster Management for Kubernetes. Con un fuerte énfasis en la abstracción de la complejidad y la creación de patrones repetibles para el mantenimiento de los servicios, OpenShift podría ahora mirar hacia la promoción de la forma en que los desarrolladores construyen, despliegan y actualizan su próxima generación de aplicaciones.
Servicios en la nube… y mucho más
Incluso antes del lanzamiento de OpenShift 1.0 en AWS:Reinvent 2012, Red Hat desplegó OpenShift como un servicio de nube pública beta, para dirigir los comentarios de los desarrolladores y aprender lo que se necesitaba para ejecutar un servicio de nube PaaS gestionado a escala. Como base de la nube híbrida abierta, OpenShift debía ejecutarse donde y como las necesidades del cliente lo dictaran, ya fuera totalmente gestionado o autogestionado. Poco después del lanzamiento del producto OpenShift Enterprise 1.0, Red Hat comenzó a lanzar servicios de nube OpenShift totalmente gestionados, primero con OpenShift Online y luego con OpenShift Dedicated. Esto condujo posteriormente a la ampliación de las colaboraciones con AWS y Microsoft Azure en servicios de nube OpenShift gestionados conjuntamente.
Hoy, Red Hat OpenShift Service on AWS (ROSA), Azure Red Hat OpenShift y Red Hat OpenShift on IBM Cloud hace hincapié en cómo la iteración actual de OpenShift se presta a un modelo de servicio gestionado. Las organizaciones de TI pueden obtener los beneficios de una plataforma de nube híbrida potente e innovadora, que puede traducirse fácilmente con las mismas habilidades y herramientas a través de su propio centro de datos y múltiples nubes públicas, con gastos generales y de mantenimiento limitados. El futuro de la TI empresarial no estará únicamente en la nube pública o en el centro de datos, sino que será una mezcla de estos entornos, y OpenShift está diseñado para responder a las demandas de ambos extremos.
Pero no, nos hemos detenido ahí. A medida que el edge computing crece en importancia para las empresas en casi todas las industrias, hemos diseñado modelos de despliegue para OpenShift para responder a estas necesidades. Esto incluye despliegues de clústeres pequeños y servidores de un solo nodo con OpenShift de un solo nodo, aprovisionamiento sin intervención para el hardware configurado con OpenShift o el recientemente introducido Red Hat Device Edger (construido sobre el proyecto MicroShift) que lleva Kubernetes de los servidores a los dispositivos edge. OpenShift se está reinventando de nuevo para abordar la siguiente ola de computación.
Estos son solo los elementos fundamentales de la plataforma: las capacidades para los desarrolladores en OpenShift también han evolucionado para satisfacer una variedad de demandas. OpenShift Serverless, Service Mesh, Pipelines o GitOps son ejemplos de cómo estamos cumpliendo con la nueva generación de requisitos de aplicaciones nativas de la nube.
¿Y qué es lo siguiente? Si miras la historia de OpenShift, dónde hemos estado, cómo empezamos y cómo hemos cambiado, creo que podemos responder de esta manera. Cualquiera que sea la próxima tendencia en computación o como sea que cambie la demanda empresarial de la nube híbrida, Red Hat OpenShift existirá en su core.
