Heroku: The Good and the Bad

A Cutting-Edge App-Centric Philosophy

Heroku was founded in 2007 and was one of the very first mature PaaS products. Heroku was also the first product to adopt an app-centric philosophy, helping many apps migrate to the cloud. This cutting edge philosophy made Heroku’s functions attractive to users from the very beginning.

Heroku Is No Longer of Great Value

As we all know, compared with Infrastructure as a Service (IaaS), which solely provides computing capabilities, PaaS is characterized by its service capabilities and a rich set of out-of-the-box add-on capabilities. Accordingly, PaaS solutions are generally more expensive. Despite of this, PaaS allows you to focus more on your actual business, so it naturally comes with a higher price tag. What’s more, PaaS solutions are usually billed based on the number of activated add-on capabilities. Therefore, they are even cheaper at the beginning, which was also true for Heroku.

The Black-Box Runtime Experience

Buildpack is another technology that is highly associated with Heroku. Before the introduction of the Docker image mechanism, we used Buildpack to manage the runtime building of user applications. This ultimately disassociated the PaaS runtime from the programming language. Undoubtedly, this was a smart approach. However, over the past decade, many disadvantages of the Buildpack model have been exposed.

  • On the other hand, you may be able to customize or find a third-party Buildpack to satisfy your needs, but its stability is not guaranteed. When a problem occurs, it is difficult to locally run a Buildpack to troubleshoot. In addition, error messages from the Heroku platform are not intuitive, and therefore you have to troubleshoot by checking logs, which makes it even more inconvenient to use.

The Emergence of Kubernetes

Kubernetes provides a truly white-box experience. It has never tried to shield the infrastructure. Instead, as a standardized access layer, it exposes the capabilities of the infrastructure layer through declarative APIs, giving users more options. In such an open environment, the management of complex and stateful applications in the cloud has finally been achieved. On the other hand, Kubernetes is not a PaaS solution. Compared with Heroku, which officially offers about two hundred add-ons to provide enhanced capabilities including databases, monitoring, logging, caching, search, analysis, and permissions, Kubernetes focuses on strong scalability and allows users to introduce additional capabilities by developing custom resource definition (CRD) operators.

Closed and Restricted vs Open and Free

As we all know, Heroku has been a “subjective” PaaS platform, and the 12-factor methodology imposes a strict requirement that applications must be cloud-native. This is reasonable and remarkable, on the one hand. However, if your ideas fail to evolve with time, a subjective approach can be dangerous. For example, even though containers and virtual machines are so popular today, Heroku insists that applications must run on Heroku Dynos. Although this unified approach greatly facilitates management, it also restricts users’ flexibility. More importantly, there are huge runtime differences between Heroku and other platforms, which has made many users feel that they are out of tune with the wider community.

The Future of Heroku

From these observations, the most important conclusion we can draw from Heroku’s past is that it was not open enough and missed the chance to build its own cloud native application ecosystem. However, now that the Kubernetes project has become the mainstream infrastructure for the industry, Heroku and its open-source successor Cloud Foundry will have to work hard to stay above water.


The Open Application Model (OAM) is a cloud native application model jointly developed by Alibaba Cloud and Microsoft. It provides a complete description of application-centric infrastructure and construction specifications, which has never been done before. By complying with these specifications, application managers can compile a self-contained and self-described “application definition file”.

Original Source:



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store