When a company is trying to figure out infrastructure, details matter. One specific set of questions revolves around the use of container virtualization for efficient virtualized environments.
With the advent of the cloud, and then the commonality of virtual networks and microservices, container deployment is now a popular way to set up systems. Platform-as-a-Service is also appealing to many companies. But these two things are not the same.
Heroku vs Docker: A Comparison
In many ways, Heroku, Docker and other similar tools help companies to accomplish the same kinds of infrastructure goals. From the first view it looks like a question like “Github vs Gitlab”, but it’s not. The key is in how these technologies deliver this functionality: in terms of Heroku vs Docker, one does it through a PaaS model, while the other offers an open source solution that can be paired with other stack elements as needed.
Heroku delivers a “pre-packaged” set of environments – and then it controls those environments. Docker, on the other hand, allows in-house people to spin up images and provision them for active use.
These two models are vastly different. One appeals to a business model that’s based on doing things your own way and working around corporate licensing and vendor provisions. The other has to do with convenience and the safety of having vendor support.
So if a company wants to use a multi-cloud strategy aligning itself with various vendors for different segments, planners may want to utilize Heroku specifically for its virtualization, or they may want to go with AWS and throw Docker on top of it. It all has to do with what the company’s optimal stack is for engineering and development processes, and that has to do, in turn, with so many factors – the makeup of engineering and IT teams, the philosophy of the CIO, and what the company does – how the cloud and virtualization help that firm to sell products and services.
Here are some of the other differences between utilizing either Heroku or Docker in a corporate SOA.
The Issue of Price
Most CIOs are money-conscious, just like everybody else. Looking at capex and opex and opportunity cost of deployment helps to ensure good stewardship of company resources.
Heroku charges $25 per month for a unit with 512 MB of memory and one dedicated CPU.
By contrast. Docker is essentially free, though companies do have to pay for the platform. For instance, some put the cost of an equivalent resource from AWS at around $5.00.
Heroku, Docker, and Deployment Logistics
Heroku must use the platform’s app delivery system with proprietary infrastructure; Docker can run anywhere, on the cloud or on-premises. This frees up a business model significantly. It allows for change in a way that Heroku’s model does not. On the other hand, Heroku allows for easy setup – the client abdicates responsibilities to the vendor.
Another key difference has to do with the instances of container units and how they work. With Heroku, the engineer is abstracting the container and creating specific command structures for the container that are isolated. With Docker, the user has a central control of the underlying container image, which can be valuable in many different types of situations.
In word, as in deed, the platforms of Heroku and Docker are quite different. As many deployment tools they have their own names for the instances. Heroku calls its instances “dynos” instead of containers, and instead of images, it uses the word “slugs.” The slugs are also treated differently to a Docker image according to the Heroku model.
Coding is also different with Heroku, Docker and other tools. Docker uses Dockerfile with its own syntax and structure. Heroku uses “BuildPacks” that are based in Java, Python or other languages. Also, a Docker image contains data, files, dependencies and settings, whereas Heroku slugs contain prepackaged copies of an app, essentially, “built for the client” structures.
To recap, in a table:
|Higher cost||Lower cost|
Some Pitfalls with Heroku
This is not to suggest that Heroku can’t be an adequate company strategy for virtualization, but there are some potential problems that users should be aware of.
Giving up control is something that companies generally don’t like to do. There’s a lot that’s been written on the issue of ceding control in exchange for cost savings and convenience – starting with the rise of co-location as a service, and applying to many elements of cloud design and cloud provisioning. In general, companies started have a dialogue about private, public and hybrid cloud, where private cloud is often seen as the ideal, but tends to cost more money. It’s like that with Heroku too: in comparison to Docker, it tends to cost more money and require more of a “turning over the keys” approach – as (no pun intended) it promises a “turnkey” approach to clients.
In addition, Heroku systems may not load all of the dependencies, which can be a problem. That can add to the modern version of the age-old “DLL hell” as we’ll discuss below. One of Heroku’s strong points though, is that by creating a walled garden, the vendor is helping clients to organize container and virtualization structures – and you don’t generally get any of that with open source strategies. Companies that are looking for deployment automation without vendor lock, often stick to other tools such as DeployPlace.
Log visibility can also be an issue with Heroku. Teams may have to use an add-on to see log data that’s important. This is often seen as a nuisance step, but inadequate visibility can have consequences.
On the plus side, there’s also the caveat that Heroku has ‘smart containers’. What does this mean? Well it means that the dynos are running on a fully managed runtime environment. It also means that various languages can be used including Ruby, PHP, Python or other choices, and a custom-built pack can be used to deploy apps in various languages as well. Then there’s the Heroku developer experience that creates a proprietary approach to software delivery and CICD. Heroku also touts its security and compliance features and other elements of its data ecosystem that have been designed to support clients – for example, a company that is a covered business associate under HIPAA may more highly value the Heroku environment for its locked-down build. That’s something to consider in choosing Heroku vs Docker.
Some Pitfalls with Docker
Sometimes a problem happens with Docker images that are too big and less flexible for projects. An incremental approach and iterative design are important in Docker, and when that philosophy is lost, it becomes hard to wrangle large, bulky images that take on too much in one container. Poor design leads to ‘integration hell’ or the issues with dependencies that have always plagued distributed systems. It’s not hard to see why a lack of coordinates dependencies could be an issue. There’s so much that has to go into a container image, for example, that organization is always key. Libraries need to be there when they are needed, or those cobbled together pieces of code will not work.
Docker on Heroku: Another Option
In talking about Heroku and Docker, you have to also acknowledge a “third way” of doing business with virtual environments. This is the strategy of using Dockerized applications on Heroku, which appeals to some companies.
Using Docker on Heroku involves building a Docker image with Dockerfile and pushing it to Heroku with Heroku CLI.
These types of innovations are part of how savvy engineers are embracing a problem-solving approach and mixing and matching elements of a stack to create synergies. Docker on Heroku is now a thing!
This has been a rundown of some of the comparisons between Heroku and Docker as two very unique systems for container virtualization. As mentioned above, they each have their own jargon and their own structures – one is community-based, whereas the other is a vendor-licensed product. Check out the advantages and the disadvantages of both to see what’s right for your business.