Here's a startling fact: the average AWS bill per account is only about $80k per year.¹ The median bill is likely even less, since outliers like Netflix skew the average, spendingupwards of $300 million per yearin the cloud, while small and medium-sized businesses spend nowhere near that.
What most businesses spend a lot more on is paying developers: $80k/yr is not even a single developer's salary² Even a 12 person team of developers might cost $1.8 million dollars all in, nearly 20x the average cloud bill.
Put another way,most businesses are better off focusing on improving developer productivity than on shaving percentage points off their cloud bill.Arguably even Netflix could benefit from this advice:they employ over 2k engineers,atupwards of $225k per person,so at least $450 million in annual compensation, well exceeding their cloud spend.
So whydowe see such perseveration about cloud spending and such little discussion of what makes developers more productive? Several reasons:
- Developer productivity is hard to measure, while cloud spending is not.It's easy to point to an AWS bill and say "oh, we can reduce this number", but how do you know if switching to another language or using some new developer tool makes the team more effective? Of course, it doesn't make sense to optimize unimportant factors like spending on snacks and office chairs just because they're easy to measure, while ignoring the important yet harder-to-measure. But many organizations end up doing just that. In part this is a general phenomenon: people want an objective measure to guide improvements, and developer productivity has no agreed-upon measure, so it gets mostly ignored. That's not great, but there's something even more insidious going on…
- Default cynicism about claimed improvements in developer productivity.We live in a hype-driven world where a multitude of devtool startups and projects all claim to make the work drastically easier. Given the amount of noise, people understandably become inured to these claims, adopting a default position of skepticism. It makes sense as a heuristic, yet this has been taken too far, with a default assumption that all programming languages and technologies "more or less the same" and that developers are equally productive no matter what tools they're using. They're not. Software creation technologyhasseen huge advances over the course of its history (imagine trying to build Netflix in assembly language!), and we're not close to done yet. Paradigm shifts that bring about huge increases in capability are real, have happened many times before, and will again.
- Developer productivity isn't even the focus of the conversation.Most people will admit that developing for the cloud is more complicated and less productive than building a single-machine monolithic app. The cloud's selling points are elsewhere, like in not having to buy and manage hardware, scalability via software knobs, and greater system resilience if you know what you're doing. These benefits are big enough that organizations have been willing to trade off developer productivity. But even though that tradeoff has been made historically, it doesn't mean developer productivity is unimportant. Far from it. We ought to strive for both: the benefits of the cloud, and excellent developer productivity.
The worse productivity of the cloud compared to single-machine apps is also part of why developers will gripe about costs and make noise about moving away from using cloud services. Such moves may be justified in terms of cost savings, and that can be real (especially for companies heavily using various higher margin "value-add" services offered by cloud providers), but saving developer time and energy is often the bigger win.
What we're doing instead
ForUnison Cloud,we're doing something different. We're focused on building a more productive cloud platform which is a joy to use (and withsimple and predictable pricing).
By building on theUnison language,we get to completely eliminate entire classes of time-consuming work.Deployment is done with a single function call (no packaging or building containers), inter-service calls are as easy as local calls (and they're typechecked), storage is as easy to access as in-memory data structures (and it's typechecked), and lots more. We think the cloud should be simple and delightful to use, and we're making it happen.
Sound good?Join us.