Surgió la plataforma como servicio (PaaS) como una fuerza líder en la búsqueda en constante evolución para optimizar el desarrollo de software. PaaS se remonta a 2006 con Force.com, seguido de Heroku, AWS Elastic Beanstalk y DotCloud, que luego se transformó en Docker.
Si bien el sector PaaS controla una importante cuota de mercado de 170 mil millones de dólares dentro de la industria de la nube, las empresas todavía luchan con la implementación manual y la gestión del ciclo de vida de la carga de trabajo en la actualidad. Entonces, ¿por qué no se adopta más ampliamente la plataforma como servicio?
Proporcionar una experiencia PaaS en todas las cargas de trabajo
Las plataformas PaaS podrían ser más versátiles y no me refiero a la compatibilidad de lenguajes y marcos. Si bien PaaS a menudo se define como una ventanilla única para implementar cualquier aplicación, existe un problema. Por aplicaciones, lo que normalmente se implica aquí son aplicaciones de 12 factores.
Sin embargo, muchas cargas de trabajo no encajan perfectamente en el molde de las aplicaciones web típicas; vienen con requisitos únicos, como trabajos de procesamiento por lotes, cargas de trabajo de computación de alto rendimiento (HPC), tareas intensivas en GPU, aplicaciones centradas en datos o incluso cargas de trabajo de computación cuántica.
No repasaré todas las ventajas que ofrece PaaS. Aún así, las empresas deben gestionar todas sus cargas de trabajo de la forma más sencilla posible, y abstraer su implementación y gestión es el camino a seguir.
Se necesita un cambio. En primer lugar, las empresas que adoptan el paradigma PaaS deben reconocer que no habrá una solución única para cargas de trabajo. En un discurso reciente sobre el tema, la ex ingeniera de Google Kelsey Hightower refuerza esta noción de que una única PaaS que lo abarque todo sigue siendo improbable.
Las empresas que adoptan el paradigma PaaS deben reconocer que no habrá una solución única para cargas de trabajo.
Él también usó API de carga de trabajo para designar una herramienta que proporcione esta experiencia perfecta de «aquí está mi aplicación, ejecútela por mí». Me gusta el término «API de carga de trabajo» porque establece claramente la intención: ejecutar una carga de trabajo específica. En comparación con la plataforma como servicio (PaaS), que debe ser más precisa y genera confusión de que PaaS es una solución milagrosa para ejecutar cualquier cosa. Usaré este término durante el resto del artículo.
El segundo cambio para las empresas que desean brindar una experiencia de implementación y administración perfecta para todas sus cargas de trabajo es considerar que cada carga de trabajo debe tener su API de carga de trabajo. Por ejemplo, Amazon Lambda podría usarse para trabajos por lotes, Vercel para front-end, Vertex AI para modelos de aprendizaje automático y Korifi para aplicaciones web.
Ahora, exploremos cómo elegir API de carga de trabajo.