Author | Sun Jianbo (Tianyuan) Alibaba technical expert
In 2011, Adam Wiggins, co-founder of Heroku, released the famous "The Twelve-Factor App" based on his experience in hosting and operating millions of applications. I wonder if they thought at that time that this manifesto would become an enlightenment book for SaaS application development in the next few years. At the same time, it also established Heroku's position in the PaaS field and became the cornerstone of the standardization of application development on the cloud.
Heroku is undoubtedly a great company with a focus on apps and developers, and the "app-centric" philosophy has benefited us to this day. In the past year or two, however, we've seen many Heroku users look for alternatives. This can't help but make us wonder, looking back at the "cloud native" in full swing today, where is Heroku's "gain" and "loss"?
Advanced concept of "application-centric"
Founded in 2007, Heroku was one of the first mature PaaS offerings. Heroku is also the first product to call out "application-centric" and help applications migrate to the cloud on a large scale. It is around this advanced concept of "application-centric" that Heroku has features that have been very attractive from the beginning:
-
Users can directly start from the development language, select the corresponding technology stack, and use a simple command like heroku create to host the application on the cloud. For mainstream development languages, you can find corresponding choices in Heroku. From code changes to automatically triggering software deployment and delivery, clear workflow, and diverse release strategies , until many years later, it has been the dream function of DevOps;
-
**Users don't need to care what the infrastructure behind the app is, Heroku takes care of maintaining everything behind it. **There is a huge complexity behind this seemingly simple statement. Imagine the dilemma brought to you when a software or system has a security vulnerability, or you have to maintain a database when you want to use a database service. instance. And in Heroku, you don't need to worry about all this trouble;
-
**High availability and elasticity as additional capabilities. **The services hosted on the Heroku platform have additional capabilities such as high availability. What is even more surprising is that applications that meet the 12-factor also naturally have the ability to expand and shrink, which can easily withstand burst traffic. It is tantamount to the existence of black technology.
**It is such a powerful capability that makes Heroku the de facto standard in the PaaS field. ** Neither the follow-up Cloud Foundry nor OpenShift seem to have substantially surpassed Heroku.
Heroku is no longer good value for money
As we all know, compared to IaaS, which only provides pure computing power, PaaS, which is famous for its service capabilities and provides many out-of-the-box additional functions, has always been generally expensive. After all, PaaS allows you to focus on the business itself, and it's okay to be a little more expensive. Not to mention that PaaS is usually charged based on the number of additional capabilities activated, and is even cheaper to start with, as is Heroku.
At first, users may feel that it is just a little more expensive than building services on IaaS themselves. When you find that your application can easily bind to the highly available PostgresSQL database provided by Heroku, you may even feel that it is worth the money. However, as the business logic becomes more complex and the deployment scale becomes larger, the requirements will naturally change. For example, in order to make user data more secure, you may need a PostgresSQL instance that can only be accessed by a private network, and Heroku does not have this function by default. You must configure a VPC to do this, and you will naturally have to pay extra for this VPC. This type of demand gradually covers each of your instances, and the increased cost directly becomes the increased unit price, and the cost rises rapidly. At the same time, the capabilities of IaaS vendors are exploding. Today, almost all cloud providers offer database services, and VPCs for these database instances are usually free.
On the other hand, **Heroku has been a closed-source commercial platform since its birth 13 years ago, and everything about Heroku can only be played on its own platform. ** This undoubtedly creates a high threshold for newcomers to learn and get started, and even many people are reluctant to experience the product. This also leads to the lack of supporting tools for the surrounding ecology. As long as the capabilities are not provided by the official, users have to develop them themselves. However, whether it is recruiting Heroku skilled workers or training from scratch, this undoubtedly brings a lot of labor costs.
In contrast to today's cloud native community, anyone can run Kubernetes in their own development environment with a few simple commands, and developers can easily experience, learn, and accumulate experience. The infrastructure actively connects with the Kubernetes ecosystem. Various tools around it are also constantly prospering and evolving.
Black box runtime experience
When it comes to Heroku, another representative technology is undoubtedly Buildpack. Before the advent of the Docker image mechanism, using Buildpacks to manage the runtime builds of user applications makes the runtime of PaaS ultimately language-independent, which is undoubtedly a very smart approach. However, over a decade later, the Buildpack model has exposed many problems.
-
On the one hand, the number of officially supported Buildpacks is small and there are many restrictions. For example, the operating system only supports the Ubuntu distribution of Linux; some Ubuntu installation packages cannot be used without installing them in the Buildpack; relatively small development languages (such as Elixir) are all Not supported; or your application contains multiple languages, which becomes complicated to use;
-
On the other hand, you may be able to customize or find a third-party Buildpack to meet your needs, but no one is there to guarantee its stability. Once a problem occurs, it is difficult for you to run the Buildpack locally to troubleshoot the problem, and the error information on the Heroku platform is not directly exposed, and the log troubleshooting is even more inconvenient.
In September 2017, Heroku finally supported runtime deployment based on Docker images. However, so far there are still many limitations. The biggest limitation is storage, which can only use Heroku's temporary storage, which almost determines that you can't. Write complex stateful applications like etcd and TiDB yourself.
The essence of everything is that the experience Heroku provides to users is a black box. While shielding the infrastructure for users, it also makes users lose the freedom to transform. This is why even a PaaS platform like Cloudfoundry with a very similar concept, even if it is open source, still has the same drawbacks.
**In fact, users like "white boxes", they want to be able to customize the infrastructure, and can replace or transform the existing functions of the platform in parallel, rather than only building on the capabilities provided by the platform. **Like we bought a car, in the extreme weather of rain and snow, we hope that we can change snow tires instead of only adding snow chains.
Emergence of Kubernetes
Kubernetes is such a white-box experience. It never tries to shield the infrastructure, but as a standardized access layer, it exposes the capabilities of the infrastructure layer through declarative APIs, leaving the choice to users. It is in such an open world that the management of complex stateful applications has finally landed on the cloud. On the other hand, Kubernetes is not a PaaS. Compared with Heroku, which officially provides nearly 200 add-ons (plug-ins) to enhance capabilities including database, monitoring, logging, caching, search, analysis, permissions, etc., Kubernetes emphasizes strong scalability and hopes that users themselves Any ability can be added by writing a CRD Operator.
So, what is the difference between these two approaches?
Closed, restricted vs open, free
It's no secret that Heroku has always been a "subjective" PaaS platform, and the 12-factor represents the hard-line view that applications must be cloud-native, which is unquestionably true and remarkable. But if ideas don't keep up with the times, then "subjectivity" becomes dangerous. Just like containers and virtual machines are quite popular today, Heroku still insists that applications can only run on Heroku Dynos. While this unification has greatly facilitated administration, it has also caused users to lose a lot of flexibility and, more importantly, the huge differences in runtimes that start to make many users feel "out of tune" with the wider community .
However, Heroku has its own closed ecology. In addition to the officially maintained Add-ons mentioned above, there are more than 4,700 Buttons applications that are convenient for users to deploy to the Heroku platform with one click, and custom runtime and build processes. There are more than 6300 Buildpacks, both of which allow users to customize and apply for registration in the official application market. The number is really amazing. How can such a prosperous community be criticized? Out of curiosity, I analyzed these projects as a whole.
The following two figures are the project statistics of Heroku Buildpack and Buttons:
We can see that Buildpack can only be used on the Heroku platform, so the number of stars represents everyone's concern for the project, and the number of downloads represents the frequency of use by users. In the figure, the number of stars and downloads and installations of more than 6,000 Buildpacks are both within 50, while the number of projects with more than 500 stars and 500 downloads and deployments is only about 30. Let's look at the projects in Buttons. Since these projects can also be deployed to other platforms other than Heroku, we only look at the deployment and downloads on Heroku to reflect your frequency of use. In the figure, there are only 6 Buttons projects that have been deployed more than 500 times. indivual. It turned out that all this was just superficial prosperity.
Faced with such a statistic, it is difficult for us to say that Heroku's closed ecosystem is successful.
Buildpack is essentially the construction and packaging of the process, and almost all of the same work industry has been solved by building images through Dockerfile. Unlike the closed ecosystem where Buildpack can only be used on the Heroku platform, the emergence of Docker images and OCI container and image specifications has greatly promoted the full prosperity of application packaging based on container images. The Docker Registry used to store images is also an image repository that anyone can build. From a numerical point of view, the number of mirror images on the official mirror warehouse alone exceeds 3 million, and thousands of mirrors have more than 1 million downloads. This is the power that a successful ecosystem should have.
In the Kubernetes ecosystem, Helm Chats, which help package applications and deploy CRD Operators with one click, are similar to Heroku's Buttons. Likewise, the hosting platform for Helm Charts is free to build, and Chart itself runs on any open source or commercial version of Kubernetes. While there are no clear stats, content from Charts hosting sites like Helm Hub, Kubeapps Hub, CloudNative App Hub, and others seem to have been quite successful.
The future of the Herokus?
From the above observations, the most important lesson of Heroku in the past is that it was not open enough and missed its own cloud-native application ecosystem. And after the Kubernetes project became the infrastructure mainstream, Heroku and its open source successor Cloud Foundry still struggled to get out of the "willful neglect" dilemma. The key to this dilemma is not whether they are built on K8s, but whether they can bring the same openness and freedom as K8s.
However, on the other hand, Kubernetes itself was never an end-user experience or something that end users wanted. The "white box" experience of Kubernetes itself is bringing "too complicated" problems to more and more business R&D and operation and maintenance. And a large number of CRD Operators in this community are like chimneys, isolated from each other, cannot be linked, and have a lot of redundancy (for example: the endless Ingress implementation in Kubernetes). This all goes to show that pure use of Kubernetes is not the "standard answer" for hosting cloud-native applications. And those PaaS builders who are trying to "write an interface for K8s" seem to be stuck in the Heroku predicament again. This change also makes the relationship between PaaS and Kubernetes increasingly complex and unclear.
From Kubernetes to the bright future of "application-centric", PaaS engineers around the world are actually expecting a new technology to bridge the gap. The approach of Alibaba Cloud's native application platform team is to solve this problem by "modeling" the application, which is also an important purpose of the Open Application Model (OAM) open source project.
finally
The OAM (Open Application Model) open application model is the model of Alibaba and Microsoft for cloud-native applications. It is the first time to fully elaborate the "application-centric" infrastructure and construction specifications. Application managers can write a self-contained, self-describing "application definition file" as long as they follow this specification.
OAM related content is completely open source on github , and we also wrote oam-go-sdk for the Go ecosystem to facilitate and quickly implement OAM.
At present, the Alibaba team is contributing and maintaining this technology upstream. If you have any questions or feedback, you are very welcome to contact us upstream or DingTalk.
way of participation:
- Scan the code to enter the Chinese discussion group of the OAM project
( Dingding scan the code to join the exchange group )
" Alibaba Cloud Native focuses on micro-services, serverless, containers, Service Mesh and other technical fields, focuses on popular cloud-native technology trends, and implements large-scale implementation of cloud-native, and is the technology circle that understands cloud-native developers best."