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 has 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. 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.
Difficulties in Platform-as-a-Service Implementations
PaaS vendors have been facing a lot of competition these days. The belief that choice does not equal opinion sometimes is brought up to step away from / choose less opinionated platforms.
With the meteoric rise of Kubernetes and the Kubernetes ecosystem, aka the operating system for your cloud-native applications, why even leverage a “bloated PaaS”?
Kubernetes is King
PaaS vendors are embracing Kubernetes as much as anyone out there. Red Hat OpenShift, a PaaS, has been including Kubernetes as the orchestrator since 2016. A modern argument against leveraging a PaaS is the explosion in the Kubernetes ecosystem.
An early argument for a PaaS was the source to image [s2i in OpenShift terms] process. With source to image, a developer did not have to know the intricacies of Docker Compose. Though as time went on, the Docker/Kubernetes ecosystem has become more mature and the growing number with folks with skills e.g Certified Kubernetes Administrators/Application Developers [CKA/CKD] are growing.
With the CKA/CKD certifications, digging into the course curriculums, they are very similar to certifications that PaaS vendors offer. Non-functional requirements such as monitoring, logging, and troubleshooting in the CKA/CKD certifications represent maturity in the market.
PaaS vendors also bring up portability as a crucial differentiator. If you are running Pivotal Cloud Foundry on-prem, you could run PCF on AWS/Azure/etc. On the other hand, if your workload runs on Kubernetes, once you have a conformant Kubernetes cluster you should be able to run your workload on another cluster. The same can’t be said for PaaS vs PaaS vendors.
Your workflows from one PaaS to PaaS typically wouldn’t run 1:1. For example, your workload on Pivotal Cloud Foundry would not transfer into OpenShift and vice versa. This is a given though because the two platforms are so different. There is an overlap in application catalog items for both PaaS’s.
Though the configuration of the application infrastructure to get to run on the PaaS [e.g scaling and deployment rules] will be different on different platforms. To even muddy the waters more, the IBM + Red Hat acquisition brings one of Cloud Foundry’s biggest contributors [IBM] together with Red Hat, the vendor behind OpenShift. How the two firms will merge strategy around PaaS’s is yet to be seen. No matter what your organization chooses, Harness has your back.
Don’t Fear with Harness
At Harness, we can help you and your organization maximize the value of your technology decisions and platforms. The orchestration of steps to get your applications into the wild has incrementally been made easier with PaaS’s. Sprinkle some of the Harness magic to the equation, Harness can supercharge your Kubernetes and non-Kubernetes based PaaS’s with the power of Continuous Delivery. Get a free trial of our Continuous Delivery platform.