At first glance, a Heroku vs Kubernetes comparison might seem odd. They're starkly different technologies and target completely separate groups. One is designed to get code out the door quickly, while the other is designed to grow and scale with your business. But at Fairwinds, we frequently find engineering teams using one when they should be using the other.
To help clarify the big differences, let's examine both Heroku and Kubernetes from a high-level.
Heroku provides a great developer experience. It's simple, easy to use, and ideal for developers who just want to write code and ship it off to prod. Heroku’s straightforward framework enables developers to get code out the door quickly.
However, with Heroku, you don't get any real orchestration. There aren't options in terms of how your application scales or how it interacts with other applications you might be deploying to the cloud. Further, Heroku’s opinions dictate how you architect your application, making any future migration impossible without a code rewrite.
But for simple, siloed applications, Heroku’s simplicity and opinionation can reduce operational toil. If your application consists of a single binary, and just needs to scale up and down in response to latency, Heroku might be the perfect choice.
Kubernetes is much more flexible in terms of how your application scales. Further, Kubernetes is open source. If you write your application around Kubernetes, you can deploy it on premise or to Google, Amazon, and any other cloud provider. It's completely vendor agnostic.
Kubernetes is also feature-rich enough to grow with your company. The core components of Kubernetes can handle 90% of use cases, and the open platform allows any third-party to extend its functionality to suit their needs. Of course, all that flexibility comes with a steep learning curve, so be prepared to invest in training your engineers, and consider finding a partner to help you find the configuration and toolset that best suit your organization.
Heroku is usually the developer's choice for Hackathons. If you're looking to put a proof of concept together with a few buddies over the weekend, Heroku is perfect for a prototype. You can simply push your code, without worrying about provisioning machines, networking, or scaling.
Ultimately, if you're a small team in start-up mode, just trying to get an MVP out the door and in front of a user, Heroku is a great place to start. It's simplicity and ease of use mean you can spend your time focused on building a great product.
If you have a business that's scaling quickly, needs to be future-proof, and needs to grow with the market, you'll quickly experience Heroku's limitations. In these scenarios you'll want a more mature orchestration platform like Kubernetes.
We've found there are two main drivers for making the switch from Heroku to Kubernetes:
1. Cost
When your application gets to a certain level of scale in terms of number of users and volume of traffic, you'll be paying a premium for Heroku that no longer makes sense. Heroku is, in the best case, 2x the price of Amazon.
For example, at an early startup with dozens or hundreds of users, your cloud bill will hardly make a dent in your budget, especially relative to things like payroll. However, once you hit a certain level of scale, expect to start hearing about cloud costs from your CFO.
At the point that you’re spending 10s to 100s of thousands of dollars a year, you should consider getting off Heroku — the money you'd save from switching to another cloud provider could free up enough budget for a new employee!
2. Complexity
Eventually your application will have complex needs that Heroku can't satisfy.
For instance, oversimplistic autoscaling is a common frustration for Heroku users. Say your application needs to scale up based on the size of a message queue backlog running on another service. Heroku can't handle that — it can only scale based on request latency.
Networking and orchestration needs can also quickly become too complex for Heroku, especially if your application consists of several independent sub-applications and microservices. As an example, consider Netflix’s video streaming platform: there’s a browsing application to navigate their video library; the recommendation engine decides which videos to surface; a search engine allows you to look for things manually; and finally, a video streaming service kicks in once you make a decision. All these different services need to talk to each other, scale independently, fail gracefully, and ultimately produce a single user experience. This kind of orchestration is exactly where Kubernetes shines.
If you anticipate hitting a certain level of cost or complexity in the near future, it’s worth thinking about making the switch. We hope this helps clarify when it’s appropriate to use Heroku, and when teams should consider using Kubernetes.
To learn more about how to switch to Kubernetes, check out Migrating from Heroku to Kubernetes via GKE.
