Having a PaaS is mainstream today, but how did we get here?
The baobab trees in Madagascar are some of the most captivating trees on earth in my opinion. If you want to enjoy your very own baobab, there are lots of items to execute on even getting the climate and soil right and then waiting for a long time before you can have your magical baobab moments. If Madagascar is too far away, can make your way down to central Florida and enjoy the Tree of Life in Disney’s Animal Kingdom as you and the family snap several Instagram worthy pictures and move on.
Since this is not (well mostly not) a travel blog, having a Platform-as-a-Service aka PaaS allows us to focus on the enjoyable parts of software development without having to worry about the immense ecosystem of choice and combination of getting the environment right. The rise of PaaS’s over the last several years have ushered in mainstream and opinionated ways of running software.
What is a PaaS?
A Platform-as-a-Service aims to provide all of the application infrastructure that your application needs to run. Application infrastructure differs from physical infrastructure [e.g storage, compute, networking] as application infrastructure is software that powers your software. The famous “Pizza-as-a-Service” diagram does a great job discerning the differences between the IaaS/PaaS/SaaS delineations.
There are linage of PaaS’s that predate Heroku, but for many Heroku was the first PaaS that was mainstream and accessible to the general public. Adam Wiggins, one of the co-creators of Heroku is also famous for The Twelve-Factor App which has been a pillar in the creation and development of many cloud native applications. After Heroku’s acquisition by SalesForce in 2010, PaaS providers starting to spring up and become mainstream.
Major PaaS providers today center around traditional PaaS offerings from OpenShift and Cloud Foundry camps to abstraction platforms such as DC/OS. Public cloud providers can argue that an aggregate of their services can constitute a PaaS but for portability sakes, we can focus on more traditional PaaS offerings. Heroku started out as a platform to develop Ruby on and similar to the PaaS platforms that followed has become more polyglot to address a wider share of your workload.
How do I know a PaaS when I see one?
Platform-as-a-services are all about developer experience. The first big sign that you are using some sort of PaaS is an application catalog. Imagine the application catalog as menu that you can order up via self-service exactly what you and your application need. The Pivotal Marketplace is organized well showing off what can be run inside one of Pivotal’s offerings. Vendors can also publish to the application catalogs. Most of the time you are getting a more operationally baked version of a package if in a public catalog.
PaaS offerings have varying levels of opinion and guardrails that can be configured. Let’s say for example your organization has hardened versions of certain application infrastructure e.g Apache Kafka. Your platform engineering team can easily package a hardened version and have the hardened version available in an application catalog such as the DC/OS Universe. If your application requires some sort of Kafka infrastructure, spinning up the infrastructure is as simple as point and click. No need for approvals, the approved version is right there and capacity allowing will spin up quickly.
For the enterprise, narrowing down on application infrastructure choice is a prudent move. The less technology you have to support the greater the ability to focus. PaaS’s also can serve as a bridge to the hybrid /multi cloud world. A PaaS platform most likely can run cross infrastructure providers aka portable; this was a big purchasing point a few years ago. If your application can run in a PaaS and the PaaS can be installed on generic infrastructure, realizing a hybrid/multi cloud architecture is within reach.
Similar in fashion in how your applications need to be maintained, a PaaS is still a platform that needs to be maintained. The Cloud Foundry organization has Bosch which can be used in several fashions to upgrade/maintain the platform and potentially the applications running in a Cloud Foundry PaaS. Platform-as-a-Service’s gives you all the tools to run your applications with ease. Adding Harness to the mix can make your Continuous Delivery experience seamless with a PaaS running the application on the back end.
PaaS and Harness – Better Together
At Harness, we support OpenShift and Pivotal Cloud Foundry deployments. Potentially your PaaS has some sort of Continuous Integration opinion on how to build/package/push the deployable. As you know that is only part of your application journey. A deployment / Continuous Delivery scenario is what the Harness Platform is built for; the orchestration and automation of all the confidence-building steps for success and failure e.g roll-back. Coupling Harness with a PaaS is a match made in heaven.
Like any fast-moving technology, the PaaS landscape has been facing challenges. In the next part of the series, we will take a more critical look at PaaS’s today. With Kubernetes quickly becoming the application operating system and public cloud vendors fighting for your workload, how does the outlook look like for traditional PaaS’s. Be sure to stay tuned and always don’t forget to check out / take Harness for a spin. Your baobab dreams are closer than you think.