Platform as a service (PaaS) emerged as a leading force in the ever-evolving quest to optimize software development. PaaS dates back to 2006 with Force.com, followed by Heroku, AWS Elastic Beanstalk, and DotCloud, which later morphed into Docker.
Although the PaaS sector has a substantial share $170 billion market Shared within the cloud industry, enterprises still struggle with manual deployment and workload lifecycle management today. So why isn't platform as a service more widely adopted?
Provide a PaaS experience across all workloads
PaaS platforms could be more versatile and I'm not talking about language and framework compatibility. While PaaS is often defined as a one-stop shop for deploying any application, there is a problem. By applications, what is typically implied here are 12-factor applications.
However, many workloads do not fit neatly into the mold of typical web applications; They come with unique requirements, such as batch processing jobs, high-performance computing (HPC) workloads, GPU-intensive tasks, data-centric applications, or even quantum computing workloads.
I won't go over all the advantages that PaaS offers. Still, businesses need to manage all of their workloads as simply as possible, and abstracting their deployment and management is the way to go.
A change is needed. First, companies adopting the PaaS paradigm must recognize that there will be no one-size-fits-all solution for workloads. In a recent speech on the topic, former Google engineer Kelsey Hightower reinforces this notion that a single, all-encompassing PaaS remains unlikely.
Enterprises adopting the PaaS paradigm must recognize that there will not be a one-size-fits-all solution for workloads.
He also used Workload API to designate a tool that provides this seamless “here's my app, run it for me” experience. I like the term “Workload API” because it clearly states the intent: running a specific workload. Compared to Platform as a Service (PaaS), which needs to be more precise and creates confusion that PaaS is a silver bullet to run anything. I will use this term for the rest of the article.
The second change for companies that want to provide a seamless deployment and management experience for all their workloads is to consider that each workload must have its workload API. For example, amazon lambda could be used for batch jobs, Vercel for the front, ai?hl=en” target=”_blank” rel=”noopener”>Vertex ai for machine learning models, and Korifi for web applications.
Now, let's explore how to choose workload APIs.
