I recently saw a tweet from DevOpsDays that absolutely blew my mind because it said something I knew was totally true, but had never put into words.
“there’s no economy of scale in software”
— Some Of The Trademarks Of Homosexuality (@aliceinfamous) August 20, 2019
software gets worse the more you bundle it up
so break everything up as small as possible@DevOpsDaysDFW @adrianco
“There’s no economy of scale in software”
I want to explain what this means and why it’s true for almost all software.
What is an economy of scale?
Adam Smith was the first to describe how economies of scale benefit societies in his 18th century book “The Wealth of Nations”. Libertarians like to talk about The Wealth of Nations, but it seems that none of them have bothered to read it, or look into how it shaped government policy after its release (including inspiring governments to implement new taxes.) There’s even a whole section about how governments are the only ones qualified to protect and feed the poor, so.
If we pose the question: “how does an advanced economy produce so many sewing pins?” We might assume the answer is ‘automation’, but Smith was writing in the 1700’s and there weren’t very many robots back then.
Smith observed that if people sit at a workbench and makes pins by themselves, they can make a few hundred a day. However if four people make pins together; one cutting the wire, another forming the pinheads, one sharpening and one packing pins, the team produces_ ten times as many pins._ This example demonstrates that when a group of people work on production, with the right organization, both efficiency and productivity of labor increase tangentially. The assembly line, automation, and kanban production tracking are all specific examples of economies of scale.
Additionally, almost everything gets cheaper to make as production volume increases. This is true for making shoes, pins, cars, books and a ton of other products. If you’re working in an assembly line, it is better to produce all the parts individually and then bring them to one central location to combine at the same time. This principle does not hold true for developing software.
Big, bad projects
When software projects get big, they get slow.
Fred Brook’s The classic text The Mythical Man-Month: Essays on Software Engineering still has lessons for us. In 1975, the text described how software projects become bigger, more complex, and manage to pull off miracles such as costing twice as much and finishing a year late.
The shortest explanation of why this happens is that bigger projects involve more communication between people and systems. Adding more people offers less benefit with each member because everyone involved has to communicate to move the project in the same direction.
Noted web developer Martin Fowler was an early proponent of what emerged as the modern solution three decades later; microservices.
As an aside, I will note that The Mythical Man-Month is full of sexist language and is the main source of the “10x engineer” myth which has been thoroughly disproven. If you’re seeking real and current knowledge on managing engineering teams I recommend Camille Fournier’s The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change.
The triumph of Lilliput: Microservices
While the definition isn’t perfectly consistent, in general, “microservices” means having individual applications with clear contractual responsibilities to each other. Think of it like making repairs to a house: if your air conditioning breaks, you know it has something to do with the air conditioning system. If your toilet won’t flush, you might plunge it or call a plumber. If your AC breaks, you don’t call a plumber. Likewise, if your sink is backed up, you wouldn’t call a contractor. With microservices, everything is broken up into smaller, granular segments so that when a part isn’t working right, it’s easy to find the broken code and, crucially, the team that can fix it.
Operations are part of the solution
In order for the software we create to really be separate, operations must be part of the solution. Microservices all running on one giant machine, using the same database connections, and gobbling the same RAM pool, will only offer some of the benefits of separation. It’s true that you’ll have an easier time reviewing and debugging code if your whole application is a small bit of code; but your tiny application will still have the opportunity to mess up other applications if they’re all sharing space and resources.
Another, probably more significant need for Ops support of small software is how empowered developers are to run the code they write. If all code is running on a monolith instead of microservices, how much access will every developer have to run new code? More than likely it will take several days for new code to get approved and deployed, leaving developers relying on half-built ‘staging’ or ‘test’ environments where crucial pieces are not like production.
https://thenewstack.io/honeycombs-charity-majors-go-ahead-test-in-production/
So software is not an economy of scale
As software projects get larger they get more complex and difficult to keep synchronized and moving in the same direction. Adding scale to a factory usually increases efficiency, but this is simply not true of software. If you keep your software projects as huge forbidding monoliths of complexity, doubling your number of programmers will only get you tiny gains in productivity.
Heroku is one way to break up the monolith
When you empower developers to create new microservices that meet their needs, they’ll produce clean components that can be clearly separated and defined.
Once they see the benefits of microservices, they can start to “chip at the monolith” and break up your initial product into microservices. How do we empower them to begin this big change?
Heroku is a great way to start down the path. While making it easy to spin up a new application, Heroku also forces devs to document their container’s dependencies. The result is a microservice that’s also portable.
Heroku has blazed a trail defining modern application architecture. Heroku separates your app from your Operations workload, and makes it easier to follow best practices for reliability and portability, as described in the 12-factor app.
Getting started is easy. Set up a Heroku account today and see how you can take a prototype all the way to production on a single platform.
Top comments (3)
This is probably the quintessential "high level" discussion for any software project, and the debates get more nuanced as you zoom in on the problems at hand.
Yeah this definitely shouldn't be affecting your day-to-day decisions about how you write code.
Monoliths are better than micro-services, except when they are not. And vice versa.
By using either architectural set-up you are simply exchanging one set of hard problems, with an other set of hard problems.
To extend the house analogy, then you want to remodel your bathroom you will need call a plumber, a electrician, etc. and try to get them all work together. In a monolith you would simply call WeRemodelBathrooms Inc.
The book Design It! by Michael Keeling is a good book about the subject of software architectures.