Platform-as-a-service (PaaS) is a cloud computing model where a third-party provider offers a platform that its customers can use to develop, run, and manage their own apps. This way, developers and programmers don’t have to build and maintain the infrastructure that supports their software applications; all they need to access it is an internet connection.
PaaS didn’t just happen. 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.
Before IaaS became available, IT departments were sowing their 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 the cloud.
It would take time for organizations to trust IaaS because they were used to managing and securing infrastructure themselves.
Meanwhile, bold 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 providers like IBM or Oracle).
Fotango developed the first PaaS in 2005, 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 the cloud on the back-end, and more recently, developers and citizen developers have been using PaaS 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, 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 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.
Another term that is conceptually similar to PaaS, and often used interchangeably, is aPaaS. Both concepts 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 while aPaaS can also target 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.
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, it’s also a little incredulous to think that a developer would be completely displaced by a low-code tool that hides the many complexities of application development behind visual tools and wizards. But low-code doesn’t actually replace developers.
Going forward, 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. As a result, developers will use low-code and other modern development 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 the 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.
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 are 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.
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.
