Over the past decade or so, cloud computing services have been evolving at crazy speeds. It is almost impossible to keep track of all the information on every single advancement in the cloud ecosystem. But fear not—with this article, I hope to make your life a bit easier. If you are looking to understand a bit better what Platform as a Service (PaaS) is and its use cases, I am here to help!

In this post, I try to explain what Platform as a Service actually is, its advantages and disadvantages, what makes it different from other cloud computing models or services (i.e. IaaS and SaaS), how much it will cost you to utilize it, why it can help your organization build better applications, and more.

Let’s jump in!

A quick look into the history of PaaS

The concept of Platform as a Service was born in 2005, in private data centers, and built by SysAdmins. It was then officially launched in 2006 by the London-based company, Fotango, also known as “Zimki”. Zimki was a JavaScript web app development computing platform and its unique characteristic was that it eliminated the tedious tasks that always come with the development of services and web applications—for example, setting up firewalls, plugging load balancers, provisioning and renewing certificates, logging rotations, etc. Such tasks become repetitive when you create web applications and services. 

Except for Zimki, between the years 2005 and 2008, PaaS was still a new concept in software engineering. That was when upstart companies started popularizing the use of cloud computing services (PaaS, IaaS, and SaaS) and wanted to build their reputation on a platform model. 

PaaS had one clear goal: to make it possible for developers to use a single platform in order to build and run a complete application—from deploying updates, to database hosting. And that unique characteristic is what made it popular and helped it thrive from 2016 onwards, with the onset of the container era and the explosion of cloud-based unicorn startups. 

In order to understand those characteristics that make PaaS unique, we need to understand that there is not only one PaaS implementation per platform but rather a common scheme between them. Basically, this means that a PaaS platform is responsible for:

• providing an infrastructure—servers, network, storage
• bootstrapping and deploying servers—install and configure OS, install the desired runtime, as well as install security patches and keep them up to date.
• providing middleware services—database, messaging service, cache storage, etc. The types of middleware provided always depend on the choice of PaaS and its implementation.

PaaS is here to automate Ops and focus on Dev because this is where its use and tools bring value. Every service provider should aim to go further than simply deploying an app or a database and this is why PaaS was created to be more than just an abstraction of infrastructure or a cloud platform.  

What PaaS really brings to the table is the added value of user experience, which is crucial for the use of any cloud computing services. PaaS takes into consideration the Software Development Life Cycle (SDLC) and the developer experience, more than anything else.

• Is it easy to deploy an application with PaaS? What is the impact on the CI/CD pipeline? Does it integrate with Git repositories or with an existing pipeline?
• What is the customization level of a PaaS application? How to find the sweet spot between a way-too-complex platform with endless app configuration options and tools and a way-too-simple one that offers little to no application configuration options, without losing the core value of PaaS?
• Can applications be operated once they are deployed? How about app monitoring and alerting?
• Can the middleware be operated and monitored? What about app database backups? How seamless is the integration between the developer’s code and middleware?
• How resilient and scalable is a PaaS application? Can we use PaaS to create scalable applications and what happens if a data center fails?

All these questions are the core of what PaaS aims to achieve as a cloud service and in the case of Artifakt, specifically, these questions drive our entire product roadmap.

One of the reasons I am such a huge fan of using a PaaS solution is the fact that it offers big advantages compared to other computing services, like Database as a Service (DBaaS), object-based storage, and many others. We are not going to dive into the comparison between the characteristics and use of PaaS and other cloud computing models (i.e. IaaS and SaaS) in this article, but you can check this article we wrote!

Most of the added value that Platform as a Service brings is the fact that it provides developers with all the necessary tools to stay focused on what they do best: coding! Managing infrastructure or building complex solutions is not how you want to utilize your developers’ expertise. Not to mention that finding developers with this particular skill set is significantly difficult and expensive.  

There are plenty of narratives picturing this model as a technology that has reached its peak of effectiveness while others, rightfully so, point to a few disadvantages that come with using this model, including the inflexibility that comes with vendor lock-in, and the risk of financial viability. 

This last one, in particular, is extremely important. If you invest in the wrong provider which, unfortunately, runs out of business, this can force you into a mandatory migration, costing you money and many, many hours of work. 

The line isn’t always that clear

It is always easier to ask for the clear advantages and disadvantages of a given technology but the line between those two isn’t always clear. One characteristic of PaaS that is considered an advantage in one scenario might be a disadvantage in another—it really does depend on the use case. 

PaaS can have what we call a black box effect. Users and stakeholders can observe its behavior, the magic it creates, without the ability really understand or have a closer look at the internal mechanics, because this is not how this model works. PaaS allows you to create the magic and this is not compatible with using a frozen architecture. 

Another point we can mention here is the pricing. The pricing of PaaS services (see more below) is often considered an advantage for small companies, as they have all they need in a single toolbox, but a disadvantage for larger companies. This happens because most large companies can easily lose visibility of engineering use and costs and try comparing the cost of Platform as a Service to Infrastructure as a Service (IaaS). 

And yes, using a PaaS infrastructure definitely costs more than the equivalent of IaaS. However, PaaS consolidates all Ops and R&D costs in the same invoice with one price tag. We’ll go into more details on this later on. 

Many PaaS services, both hosted and self-hosted, offer unlimited and hourly access. However, the cost is one of the deciding factors. Typically, basic PaaS services cost from a few dollars to multiple thousands per month, depending on what you need. The idea behind the pricing model is to fit into your existing infrastructure at a low cost and scale the platform’s sizing and cost according to your real usage. 

PaaS can be extremely cost-effective in comparison to traditional data centers or cloud hosting providers when deployed correctly. In a way, PaaS acts like a host with a lot of extra goodies coming with the package! Because of its relatively low cost, it has been considered an alternative for hosting high-cost traditional applications as well as web applications.

Summing up

Whether I convinced you that Platform as a Service is the right option for you or not, I do hope that you enjoyed this article! PaaS is probably not the right model for every single scenario out there but it sure brings a lot of benefits. 

From its unique emphasis on SDLC and developer experience to its affordability, PaaS has a lot to offer as a cloud service. 

And remember, no matter which model you decide to adopt, make sure to always audit a provider thoroughly and, without losing sight of your goals, of course, give priority to the needs of your development team—they are the heart and soul of your product!