Difficulties in Platform-as-a-Service Implementations — PaaS Series 2/3

Switching gears from the happy baobab trees in part one, 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.

Interoperability

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 Harnes, 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. Stay tuned for the final part of our blog series where we deploy to a PaaS.

Cheers and Happy Holidays,

-Ravi