Containership as an Alternative to Heroku

blog-background_0003_Layer-0.png

Introduction

For some time now, it’s been impossible to wade in the platform-as-a-service waters without giving serious consideration to Heroku’s offerings. Heroku burst onto the scene, immediately striking a chord with developers looking for a simple alternative to managing complex infrastructure upon which their applications ran. By abstracting away IaaS resources, Heroku empowers developers to focus on what matters most to them: their application. This mantra isn’t unique to Heroku, or even the PaaS space. When the containers-as-a-service market formed around the success of Docker (and more generally containerized workloads), many companies (Containership included) set out to reduce and remove the complexities related to cluster orchestration, allowing companies to focus on more easily deploying, managing, and scaling their services. Containers signify the dawn of a new age of cloud computing, and the mind-share of projects like Kubernetes act as an undertow, pulling developers away from traditional PaaS providers, quickly sweeping them towards CaaS vendors. While this change marks a fundamental shift in thinking, it has left many Heroku customers wondering if and when they should jump ship to a CaaS provider, such as Containership. While there are many similarities between Heroku and Containership, there are three main drivers of migration: performance, portability, and cost.

Performance

At it’s core, Heroku acts similarly to modern cluster schedulers, such as Kubernetes (albeit a drastically simplified subset). A single unit of work on Heroku is known as a “Dyno”, and is analogous to an individual container on systems like Containership. Heroku Apps and Containership services can be scaled horizontally, that is, they can run multiple instances to scale to meet demand. Each container has a specification which defines the maximum amount of CPU and memory resources consumed from the host system. While these resource constraints are customizable in Containership, Heroku only offers 4 variations of their Professional Dynos, as seen below:

Screen Shot 2017-08-29 at 7.33.18 AM

If your application needs to consume resources outside of these predefined sizes, you’re out of luck. Additionally, Heroku’s ambiguous CPU shares makes it hard to set accurate performance expectations. Containership simplifies this by allowing users to define whole CPU values for each container that is launched. For example, if you have a 4 CPU server, and you launch a container you’d like to consume a quarter of the server’s CPU, you simply define 1 CPU.

On Heroku, your workloads run on AWS servers, alongside other Heroku customers. While this type of multi-tenancy is beneficial for Heroku’s bottom line, it can negatively affect your application’s performance, as defined by the noisy neighbor problem. The inability to reserve dedicated resources for smaller Dynos forces customers to accept performance degradation as a tradeoff for deployment simplicity - a choice no business should have to make. Heroku automatically restarts Dynos daily, likely in an attempt to improve performance; however, if customers are unaware of this caveat, it could negatively affect their workloads and application stability. This is not the case with Containership. Since customers connect their own cloud provider accounts to Containership Cloud, they have ultimate control over how and where workloads run. Using the notion of “constraints”, users have fine-grained control of workload distribution. Containership automates the virtual machine lifecycle to simplify operational overhead, but remains powerful enough for system administrators and operators to break the chains of black-box solutions provided by PaaS vendors.

Portability

As mentioned above, Heroku piggybacks on AWS’s infrastructure. While Amazon itself has a dozen of supported regions, Heroku only supports two: US East and EU West. Containership, by comparison, allows customers to run in or across fourteen cloud providers, with support for deployment to over 65 regions. As the world continues to move towards a multicloud future, Heroku has struggled to keep pace with the demand for multi-region support. Multicloud and portability are paramount to building low latency and highly available cloud infrastructure.

Given that Heroku’s Dynos are a proprietary virtualization spec, it is not possible to clone or move a Dyno from Heroku, to a different PaaS provider. This type of stickiness is tactically deployed to lock Heroku’s customers into the platform, making it hard to migrate off in the future. Containership, on the other hand, has taken a different approach. The immutable artifacts deployed to Containership are simply Docker images; a widely adopted standard for any CaaS provider. Containership’s service specification is a superset of the Docker container definition, meaning the core properties (resources specifications, port reservation, etc) can also be easily translated to another provider abiding by the standards set in place by the OCI.

Since Containership is cloud agnostic and built on industry-best standards, we are able to offer our customers a best-in-class disaster recovery and migration tool, through our snapshotting product. Customers can automate scheduled backups of their entire infrastructure, choosing to restore a point-in-time backup when necessary. These backups can be used to clone or move workloads between regions of the same cloud provider, or even across providers entirely.

Imagine a scenario where request latency is killing your product. With Heroku, you’re limited to running in the two aforementioned AWS regions supported by their platform; but, what if your customers are in Asia? Wouldn’t it be great if you could best serve those customers as well by deploying your application to a region that geographically suits them best as well? With Containership you can. Ultimate portability means not sacrificing performance or stability for convenience.

Cost

Heroku resources, as compared to raw IaaS resources, are markedly more expensive. As the size of your workload increases, so does the premium you pay for the Heroku platform. As a quick example, I’ve calculated the estimated cost to run an Elasticsearch, Logstash, Kibana, Kafka, Zookeeper analytics stack to compare price differences between Heroku and Containership. The number of containers is as follows:

  • 3x Elasticsearch
  • 3x Logstash
  • 1x Kibana
  • 3x Kafka
  • 3x Zookeeper

Below is the Heroku cost breakdown when running all of the services as unmanaged Dynos:

Screen Shot 2017-08-29 at 6.54.30 AM

Heroku also offers a managed Kafka service. When utilizing managed Kafka to replace the Kafka and Zookeeper Dynos, the cost increases from $1175 to $2450, as seen below:

Screen Shot 2017-08-29 at 8.08.46 AM
Screen Shot 2017-08-29 at 8.09.37 AM

As you can see, the price of running this stack on Heroku will set you back about $1200 / month.

We can calculate the same cost on Containership by adding the cost of the underlying compute resources to the Containership Cloud platform cost of $8 / service.

Screen Shot 2017-08-29 at 8.18.08 AM

The stack requires 1 leader host, and 3 follower hosts of equivalent size T2 Small and M3 Large, respectively. This equates to 6 CPUs and 22.5GB memory. The total resource cost on AWS comes to $315 / month + $40 / month for the Containership Cloud platform, for a total of $355 / month. This simple example demonstrates a savings of ~$850 / month, or over $10k / year. Given that Containership Cloud also works with workloads running on-premise, if you have a few servers laying around, you can even cut out the cloud premium. While this is a simple example crafted to demonstrate savings, it is generally applicable when comparing Heroku and Containership from a cost perspective. As the number of services you’re running increases, so does the cost savings associated with running on Containership. An important distinction to make between the pricing structure is: Heroku charges per Dyno, whereas Containership bills per service. A service in Containership can have as many containers (replicas) running as you’d like, and the cost remains $8 / month for the service. When you scale your services up to meet traffic demand, your cost on Heroku will scale linearly, whereas with Containership, they will remain constant; you only pay for the computing power you are using.

Conclusion

As you can imagine, Containership has had great success transforming Heroku customers into Containership customers by saving them time and money, while increasing performance and peace of mind. While these advantages are a recipe for success, many still find themselves overwhelmed by the thought of learning complex distributed systems such as Kubernetes, or learning how to containerize their existing services. What many prospective customers don’t realize is that with Containership, your team doesn’t have to become experts in anything but their own application. Like Heroku, Containership abstracts away the complex IaaS resource management, and workload scheduling. We offer in-house professional services to containerize applications during the platform onboarding process. In the end, who wants to pay more for less? As a business, architecting for scale and flexibility from the beginning does not only have to make sense from a technical perspective, but it can also be advantageous financially. If your business is looking to save time and money, quit drowning in the Heroku platform, and climb aboard Containership.

Show Comments

Get the latest posts delivered right to your inbox.