Have you ever wondered what is platform as a service (Paas)? What does PaaS stand for? Last month, Senior Product Marketing Manager Forsyth Alexander compared PaaS to application platform as a service (aPaas) (there is a link to Forsyth’s comparison piece later in this blog). A fair question is how we got here in the first place, which is the question this blog answers. I’m also weighing in on the distinction between PaaS and aPaaS as an industry observer.

Paas Was Part of a Larger Trend

PaaS and aPaaS didn’t just happen. Whether you agree with the distinction between the two or not, cloud-native development was the next logical step following the availability of infrastructure as a service (IaaS). Of course, cloud-native development results in cloud-native applications (software as a service or SaaS), which is another huge trend. In fact, Gartner expects SaaS spending to exceed $85 billion in 2019. PaaS will reach about $19 billion in the same period.

Before IaaS became available, IT departments were sowing its seeds, using VMs to virtualize servers, which increased server utilization efficiency and provided the added benefit of allowing more than one operating system to reside on a single box. However, as enterprise data continued to grow exponentially, it became clear organizations would have to supplement their existing data centers with cloud.

It would take time for organizations to trust IaaS because they were used to managing and securing infrastructure themselves.

Meanwhile, brazen startups started offering SaaS options that put competitive pressure on traditional software companies which didn’t like the economic model subscriptions represented. Why would a company provide licenses, maintenance, and upgrades for a relatively low subscription fee when one could sell expensive licenses and annual software maintenance? As the SaaS-related pressure grew, traditional software vendors were forced to offer it as an option or become obsolete.

However, as traditional software vendors analyzed the economics of SaaS, they discovered they could decompose a monolithic offering into a core product and modules, which would provide customers with choice and the software vendor with several potential revenue streams. Today, traditional on-premises software is still alive and well, but even enterprise software vendors are pressuring their customers to move to SaaS and PaaS (if they are an application provider and cloud provider like IBM or Oracle).

Platform as a Service (PaaS) report

Why Platform as a Service and aPaaS Are So Popular

Fotango developed the first PaaS in 2005 which was the Zimki JavaScript web application development platform. However, Google ignited the PaaS space with App Engine in 2008.

The need for PaaS has been fueled by a few more trends than IaaS and SaaS including mobile, Agile, DevOps and CI/CD.

Specifically, mobile apps have been using cloud on the back-end, and more recently, developers and citizen developers have been using PaaS and aPaaS to build mobile and web experiences on the front end. Mobile testing tends to occur in the cloud via a third-party testing lab because building and maintaining such a lab in-house is too costly given the number of devices, operating systems, and browsers one must test apps against.

Dev and test are being done in the cloud and so is production, which leads to the next point: PaaS also helps facilitate DevOps and CI/CD.

DevOps and CI/CD require dev and IT ops to work as a cohesive team, which is best done using identical dev and production environments. While devs can use simulators and emulators to approximate a production environment, cloud environments can replicate production environments more accurately.

When everything is taking place in the cloud – dev, testing, ITops, etc. – application delivery accelerates. With PaaS and aPaaS, you get the development tools and infrastructure you need to build, test, and deploy applications. And, if you don’t like the idea of using someone else’s cloud, some vendors also offer private cloud options which run on an appliance behind a firewall.

Yet another reason to adopt PaaS and aPaaS is machine learning, because it requires a lot of data (thus considerable storage) and massively parallel computing resources, which are cheaper to use than a supercomputer.

PaaS and aPaaS Similarities and Differences

PaaS and aPaaS are conceptually similar because they enable people to focus on problem-solving without worrying about the infrastructure (PaaS) or worrying about coding (aPaaS). PaaS tends to assume one can code, aPaaS does not. In other words, PaaS targets professional developers and aPaaS targets citizen developers who can’t code, web developers familiar with HTML and JavaScript, and professional developers who want to save time.

The hierarchy of cloud options
The hierarchy of cloud options

As Forsyth pointed out, Gartner thinks aPaaS will overtake PaaS, but will that actually be the case? I believe there are two answers to that question: no and yes, both of which are time-based.

For the present time, the answer is no because many professional developers feel low-code is either beneath them or simply a toy. After spending several years learning how to code, I can’t say I blame them because professional developers actually know how code works. So, it’s also little incredulous to think that a developer would be completely be displaced by a low-code tool that hides the many complexities of application development behind visual tools and wizards. Low-code doesn’t actually replace developers.

Going forward I can foresee that, PaaS and aPaaS could converge because more professional developers will have to use low-code platforms to stay competitive. As we’ve seen over the past decade, development teams are advancing beyond Agile to DevOps and CI/CD so they can deliver value to customers faster. As software delivery cycles continue to shrink, hand-coding will be recognized as a barrier to speed and as a result, developers will use low-code tools where they can and hand-code that which low-code tools can’t handle out-of-the-box. PaaS providers will continue their mission of boosting productivity, so a convergence of PaaS and aPaaS appears to be on the horizon.

Whether PaaS or aPaaS becomes the name of a single, consolidated category is immaterial over the long-term, but in the short-term, the distinction between the two makes sense given their different target audiences.

PaaS and aPaaS Make Sense for MVPs

Many of today’s development teams are taking Agile to extremes out of necessity. Rather than just decomposing a monolithic application into smaller pieces, building it and hoping people will love it, the idea now is to build a minimum viable product (MVP) and get feedback on it as quickly as possible. In other words, there’s been a culture shift from perfection to iteration, thanks to the digital disruptors including Amazon, Facebook, Google, and Netflix.

Imagine investing millions of dollars in tools and talent just to build a product that flops? It’s happened enough that companies now realize that it’s better to build an MVP, learn from mistakes (“fail fast”), and keep moving forward.

PaaS and aPaaS are perfect for MVPs, because they expedite product delivery. And, there’s tons of app-related data to analyze and the tools to do it – all in one place. If you’re wildly successful, you can scale up ad infinitum because your app was built in the cloud, assuming your PaaS or aPaaS provider is up to the task.

Finally, PaaS and aPaaS have to stay a step ahead when it comes to new languages, tools, methodologies and paradigms. So, for example, if you’re using containers and microservices architectures, you’re covered. If not, no problem.

Bottom Line

PaaS and aPaaS make software development more efficient and effective. For now, a distinction between the two makes sense because they’re targeted at different audiences. However, as the landscape shifts, only one of the terms may stand.

PaaS and aPaaS have been logical steps in companies’ cloud migration strategies and they’ll become even more relevant as organizations digitally transform into more software-dependent and software-driven organizations.