Analyzing your stack’s real costs

I was asked a few weeks ago to write about the relative costs of different platforms for a smallish service serving a very large scale (my model here was the very simple ipify that got up to 30 billion requests a month). I kept coming back to something fundamental, what economists call ‘externalities’: costs of a process that are not listed on the balance sheet. The classic externality is pollution. A company is profitable as long as it doesn’t count the cost of all the people it’s harming by belching out smog. The externality I often see not properly accounted for by tech executives is the cost of stress on the team.

Let’s take a simple example: a CTO gets pitched the adoption of Honeycomb to instrument and analyze performance. With Honeycomb, several classes of problems like storage running out will generate warnings before they cause failures. The CTO says no, and the annual budget is smaller by 100% of Honeycomb’s fees. All the nights, weekends, and extra long days that the team works, trying to fix things after they break, don’t appear on the budget at all. Maybe the CTO gets a bonus for keeping costs down. A few years later this company, that always met its budget goals, is spending hundreds of thousands a year in signing bonuses to replace team members who always quit within 2 years.

So, by failing to adopt tools we end up asking too much of our team, which saves money in the short term but costs more in the long term. But I’d say even _this** **_oversimplifies the depth of the problem.

Let’s start with some basic facts about the availability of labor in the technology market:

There are not enough Computer Science majors to fill the needs of the computing industry, and this gap is only going to get worse in the near future. And while CS programs are an okay way to get prepared to write code, there is no general secondary education path into a job in Operations.

Endless conference talks and papers have discussed the talent shortage that affects all technology companies. Tech companies do not provide beer taps and parental leave out of the goodness of their hearts. The fact is that a good software team is more than expensive to replace, it’s often impossible.

My favorite talk on this subject, ‘There is no talent shortage’ doesn’t actually deny the points made in this post. It confirms that hiring a skilled team is extremely difficult, and that we should instead focus on developing skills to create the team we need. This is a strong point! Two years of Angular experience doesn’t hold a candle to a developer who you’ve developed over the last two years.

How all of this relates to Heroku

One of the greatest misconceptions about Heroku is that it either doesn’t scale, or that when it scales it becomes too expensive to use. The reality is that all platforms entail cost, and Heroku is generally competitive with other services. But I’d submit that even discussing this is _asking the wrong question. _

I know lots of people who enjoy writing code, I know people who enjoy running code, I know Linux nerds who love clever server configurations. Even architects who delight in designing the best possible service topologies. I’ve never met anyone who claps their hands in delight at the idea of debugging a load balancer at 4AM.

The real question you should be asking about any platform, any service architecture, is ‘do my devs enjoy using this tool, does it save them headaches and stress, and does it help us solve the problem?’

Heroku offers a simple path to deployment, and easy interfaces for scaling your containers. Even better, it offers deep configurability allowing you to meet complex needs. When your team wants to try different architectures,or try different types of container for your code, with Heroku this is a simple configuration rather than hours of setting up new hardware or virtual machines. Probably most critically: with auto-scaling, your engineers are less likely to be woken up in the middle of the night to handle crises.

Think back on all the meetup talks, all the conference workshops, all the articles you’ve read. Think how many of them described being unable to find server space. How many described not being able to purchase RAM, or a stable data connection, or upgrading operating systems to apply security patches, or installing databases, or yes, configuring a load balancer. Now, compare how many you’ve seen from team leaders who were unable to hire the talent they needed.

So when you consider the cost of a tool like Heroku that lets your developers focus on business logic, that makes their lives easier and causes fewer late-night catastrophes; you’re likely not weighing the most important benefit: its effect on team happiness and retention of good engineers. A clean, containerized workflow will help you build the team you need to run your business, and the benefit of maintaining a team that loves their tools might be difficult to write on a balance sheet, but it’s massive!

For further reading on this subject, check out Shane Rostad’s writeup of a cost comparison of Heroku and AWS that comes to similar conclusions.

Full disclosure: Heroku paid me to write about this topic, this is a dream job for me because I’ve loved Heroku since I first started in web development. Since I have to use the tools I write about, no one can pay me to like something, and the views here are 100% my own.