Elevating PaaS Utilization beyond 12-Factor Applications

Sylvain Kalache
Contributor

Sylvain Kalache is the co-founder of Holberton, an edtech company training digital talent in more than 10 countries. An entrepreneur and software engineer, he has worked in the tech industry for more than a decade. Part of the team that led SlideShare to be acquired by LinkedIn, he has written for CIO and VentureBeat.
More posts by this contributor

  • 6 strategies for running more effective startup board meetings
  • For companies that use ML, labeled data is the key differentiator

Platform-as-a-service (PaaS) emerged as a leading force in the ever-evolving quest to streamline software development. PaaS dates back to 2006 with Force.com, followed by Heroku, AWS Elastic Beanstalk, and DotCloud, which later transformed into Docker.

While the PaaS sector commands a substantial $170 billion market share within the cloud industry, companies still grapple with manual deployment and workload life cycle management today. So why isn’t platform-as-a-service more widely adopted?

Providing a PaaS experience across all workloads

PaaS platforms could be more versatile, and I am not speaking of language and framework compatibility. While PaaS is often defined as a one-stop shop for deploying any application, there is a catch. By applications, what is usually implied here is 12-factor applications.

However, many workloads don’t neatly fit the mold of typical web apps; 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 provides. Still, companies should manage all their workloads in the easiest way possible, and abstracting their deployment and management is the way to go.

A shift is needed. First, companies embracing the PaaS paradigm must recognize that there won’t be a one-size-fits-all workload solution. In a recent discourse on the topic, former Google engineer Kelsey Hightower reinforces this notion that a single, all-encompassing PaaS remains improbable.

Companies embracing the PaaS paradigm must recognize that there won’t be a one-size-fits-all workload solution.

He also used workload API to designate a tool that provides this seamless “here is my app, run it for me” experience. I like the term “workload API” because it clearly states the intent: to run a specific workload. Compared to platform-as-a-service (PaaS), which needs to be more accurate and leads to this confusion that PaaS is a silver bullet to running anything. I will use this term for the remainder of the article.

The second change for companies wanting to provide a seamless deployment and management experience for all their workloads is considering that each workload should have its workload API. For example, Amazon Lambda could be used for batch jobs, Vercel for front end, Vertex AI for machine learning models, and Korifi for web apps.

Now, let’s explore how to pick workload APIs. entirely.

Related Posts