Heroku and Openshift have been the cornerstones of multiple internet services since their launches. Both of these services come under the Platform-as-a-Service (PaaS) category. While almost any application can be developed on either of the platforms, both of them offer different functionalities that make them more suitable for specific types of deployments. We compare the two services across some important metrics:
Openshift and Heroku started out as direct competitors. However, Openshift has moved to a container based deployment procedure. Openshift includes support for Kubernetes right out of the box, which makes it very easy to orchestrate container deployments and scale microservices as needed. Heroku Common Runtime is also catching up in this aspect with beta support for running docker based containers. Openshift’s container platform is more mature at the moment compared to Heroku’s container offering, with support for configurable scaling, health management and dynamically provisioned additional storage.
Different organizations have different kinds of needs for how they want to access the PaaS service. Both Heroku and Openshift offer different tiers of service targeted at different users. Openshift uses “Openshift Online” – a public offering, “Openshift Dedicated” – dedicated cloud platform for enterprise scale, and the general “Openshift Container Platform” – a self-hosted version of the Openshift platform. In contrast, Heroku uses Heroku Runtime, which is available in different pricing tiers. Heroku runtime is a combination of dynos, orchestration, log aggregation using Logplex, release management and certificate management. While Heroku does not provide self-hosting for their service, they do have Private Spaces for enterprise users – comparable to the Openshift Dedicated offering.
Because Openshift relies on Kubernetes, it is fairly easy to scale the application infrastructure. Pods can leverage horizontal scaling to keep up with the increase in demand. Heroku offers both horizontal and vertical scaling facility. Vertical scaling comes in handy when the application is architected such that it cannot be deployed correctly on more than one machine at a time. At that point the only thing developers can do is to throw more resources at the application. More can be learned about the tradeoffs here. Heroku has also started offering autoscaling of dynos recently. This feature is only currently available in performance-tier dynos and private spaces.
In the early days of Openshift, it was pretty limited in the types of runtimes it offered by default. Those runtimes were further limited by the older versions of programs they were running. It was possible to add new runtimes with cartridges, although it was not so simple. With the latest version, Openshift now leverages container based deployments. Several popular images are already available officially and anything else can be easily built using the custom builder.
Heroku offers the same number of official runtimes and an insane number of add-ons that blow away Openshift in this respect. Different types of services can be used to extend the platform beyond what it can achieve. Add-ons are available for data stores, logging, email/sms, analytics, testing, image/video processing and much more.
Compliance can be a nightmare even for the most well-read infrastructure designers. PaaS offers a sort of easy hack to help with this because it is possible to offload some aspects of compliance to the PaaS provider. Both Openshift and Heroku have guidelines for compliance that go into varying degrees of detail on various aspects. Critical compliance requirements like HIPAA require a great deal of investigation on part of the user. This has made services like Aptible popular.
One click deployments are an important feature when a user wants to share their application with someone else who can simply click on the deploy button and get their own version of the application. Openshift offers this functionality through query parameters in a URL. The user can click on the link and the platform uses a git based source or a template to deploy the application.
Heroku achieves the same task using Buttons. Heroku’s offering is much more robust in this area and includes community contributed buttons. Heroku also uses templates to implement this functionality. Heroku also offers Buildpacks to automate the build process for various languages and frameworks.
Openshift can be considered a more open-ended platform where the user has to put some planning effort to set up their container based infrastructure. Heroku goes for a more integrated approach with tightly joint offerings like Heroku DX and health management with Heroku OpEx that work without friction with the Heroku Runtime. Heroku offers collaboration and permissions management with Heroku Teams. Heroku also offers hosted Kafka as a service. Kafka is a beast of its own that can be used for queuing, pipelining in data analytics and coordination between various microservices.
What platform should be used for an application depends on the kind of work that application does, pricing factors for the expected number of users, ease of deployment, application architecture and the developer experience. Both of these platforms offer overlapping functionalities and it is better to gauge what fits one’s application before committing to either of them.