By Sun Jianbo, nicknamed Tianyuan at Alibaba.
In 2011, Adam Wiggins, a co-founder of the cloud application platform, Heroku, released the well-known methodology "The Twelve-Factor App" based on his experience in the hosting and O&M of millions of applications. Who would have known if they realized at that time that this declaration would become the inspiration of Software as a Service (SaaS) application development over the next few years. This declaration also helped Heroku carve out a role for itself in the Platform as a Service (PaaS) field, becoming the cornerstone for the standardized development of cloud applications.
Heroku is undoubtedly a great company that focuses on applications and developers. Its application-centric philosophy has been very beneficial to the wider community even until today. However, over the past two years, many Heroku users turned to other options. This is puzzling to many of us. With all that said, let's review the rise and fall of Heroku, covering both the good and the bad.
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.
With them, users could start from the development language, select the corresponding technology stack, and host applications in the cloud by using simple commands, such as "heroku create." Heroku provides options for all mainstream development languages. For DevOps personnel, their dream has been like this for years. With Heroku, software deployment and delivery are automatically triggered by code changes, with clear workflows and diverse release policies that are ready to use.
Heroku is responsible for maintaining the infrastructure behind applications without user intervention. But, this seemingly simple statement conceals a great deal of complexity. You can understand this simply by imagining the difficulties you would face if your software or system suffers from a security vulnerability, or if you have to maintain a database instance to use a database service. However, in Heroku, you are free from all these concerns.
With these powerful capabilities, Heroku became the de facto standard in the PaaS field. Neither the subsequent Cloud Foundry nor OpenShift was able to substantially surpass Heroku.
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.
At first, users can find that PaaS is just a little more expensive than building services on IaaS. Even more, when you realize that you can easily bind applications to high-availability PostgreSQL databases provided by Heroku, the investment definitely pays off. However, as your business logic becomes more complex and your deployment scale increases, your needs naturally change.
For example, to make your data more secure, you may need a PostgreSQL instance that can be accessed only from a private network. Heroku does not provide this feature by default, and therefore you must set up a Virtual Private Cloud (VPC) instance, which naturally has to be paid for use. As all your instances gradually come to have such additional requirements, the increased costs of meeting them are directly reflected in the unit price, and your total cost soars. At the same time, IaaS vendors are offering an explosively expanding range of capabilities. Today, almost all cloud service providers are providing database services and, in most cases, charge nothing for VPC instances used by these database instances.
On the other hand, Heroku has been a closed-source business platform since its founding 13 years ago. This means you can use Heroku only through its own platform. This results in a steep learning curve for new users, and many of them are unwilling to even try this product. As a result, the Heroku ecosystem does not offer sufficient auxiliary tools, and users must build their required functions independently if they are not officially available. In addition, recruiting or training Heroku experts results in high labor costs.
In contrast, in today's cloud native community, anyone can run Kubernetes in their own development environment with several simple commands. This allows developers to easily try out and dig into Kubernetes. Hence, developers actively integrate their infrastructures with the Kubernetes ecosystem, and various auxiliary tools are constantly being produced.
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.
In September 2017, Heroku finally supplemented support for runtime deployment based on Docker images. However, there are still many restrictions. The most significant restriction is that you must use Heroku's temporary storage. This means that you cannot compile complex stateful applications, such as ETCD and TiDB, by yourself.
The fundamental issue for Heroku is that the experience it provides to users is a black-box one. While it shields users from the infrastructure, it also strips them of the freedom to make changes. This is why even open source PaaS platforms based on a similar concept, such as Cloud Foundry, also have the same drawbacks.
In fact, what users expect is a "white-box" experience. They want to customize the infrastructure and replace or upgrade the existing functions of the platform in parallel, rather than simply build on the capabilities provided by the platform. Just like buying a car, if we are living in an area that gets a lot of snow, we would like to assemble snow tires rather than put chains on them.
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.
Then, what are the differences between both approaches?
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.
Despite of this, Heroku has its own closed ecosystem. In addition to the official add-ons that we mentioned previously, there are more than 4,700 Button applications that can be deployed to the Heroku platform with one click and more than 6,300 Buildpacks that can be used to customize runtime and building processes. These capabilities allow users to customize capabilities and register them with the official application market. This gives users access to an amazing number of customizations. However, this rich community has received a great deal of criticism. Out of curiosity, I analyzed these projects to identify the cause.
The following figures show project statistics for Heroku Buildpacks and Buttons.
As you can see, Buildpacks can only be used on the Heroku platform. The star ratings represent users' interest in the projects, while the number of downloads represents the actual usage. As shown in the figure, the number of stars and the number of downloads and deployments for more than 6,000 Buildpacks are less than 50, whereas only about 30 projects have more than 500 stars and 500 downloads and deployments.
Now, let's take a further look at the projects in Buttons. Since these projects can be deployed on platforms other than Heroku, I counted only their downloads and deployments in Heroku. As shown in the preceding figure, only 6 Button projects were deployed more than 500 times. This shows that the richness of the Heroku ecosystem is very shallow.
Then, we can barely say that the closed Heroku ecosystem has been a success.
Essentially, a Buildpack builds and packages processes. However, almost all projects have been built as images by using Dockerfile in the industry. Unlike Buildpacks, which can only be used on the Heroku platform, the emergence of Docker images and OCI container and image specifications has created a rich application packaging ecosystem based on container images. Docker Registry, which is used to store images, is also an image repository that is available to everyone. Numerically, the number of images in the official image repository alone exceeds 3 million, and thousands of images have been downloaded more than 1 million times. Well, this is probably what a successful ecosystem should be like.
In the Kubernetes ecosystem, Helm charts, which help package applications and can deploy CRD operators with one click, are similar to Heroku's Buttons. Similarly, a Helm chart hosting platform can be built as needed, and charts can run on any open source or commercial Kubernetes platform. Although no statistics are available, the content on chart hosting websites such as Helm Hub, Kubeapps Hub, and CloudNative App Hub seems to be remarkably successful.
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.
To ensure their continued relevance, they do not have to be built on Kubernetes, but they must provide the same openness and freedom as Kubernetes.
Kubernetes itself has never been able to create the perfect user experience and solve users' problems once and for all. The "white-box" experience of Kubernetes has caused unacceptable complexity for many business R&D and O&M teams. Many custom resource definition (CRD) operators in the community are isolated and unable to interact with each other. Additionally, they have led to much redundancy, such as the never-ending ingress implementations. All this shows that using Kubernetes alone is not the best choice for hosting cloud native applications. However, PaaS users who try to interface with Kubernetes seem to fall into the Heroku trap. This change makes the relationship between PaaS and Kubernetes more complicated and unclear.
Regardless of what has happened up to now, we still have a long way to go from Kubernetes to an application-centric future, and PaaS engineers around the world are looking forward to new technologies that can help us get there. The Alibaba Cloud cloud-native application platform team has been working on resolving this problem by "modeling" applications. This is also an important goal of the Open Application Model (OAM) project.
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".
OAM content is completely open source and can be found on GitHub. We have also developed oam-go-sd for the Go ecosystem so that you can implement OAM quickly and conveniently.
How Alibaba Won the State Technological Invention Award in China
Getting Started with Kubernetes | Pods and Container Design Modes
480 posts | 48 followers
FollowAlibaba Developer - December 9, 2020
Alibaba Developer - March 16, 2021
Changyi - April 14, 2020
Aliware - April 10, 2020
Alibaba Cloud Project Hub - November 16, 2021
Alibaba Clouder - July 27, 2018
480 posts | 48 followers
Follow
ACK One
Provides a control plane to allow users to manage Kubernetes clusters that run based on different infrastructure resources
Learn More
Container Registry
A secure image hosting platform providing containerized image lifecycle management
Learn More
Container Service for Kubernetes
Alibaba Cloud Container Service for Kubernetes is a fully managed cloud container management service that supports native Kubernetes and integrates with other Alibaba Cloud products.
Learn More
Elastic Container Instance
An agile and secure serverless container instance service.
Learn MoreMore Posts by Alibaba Cloud Native Community
