If you take microservices to mean more isolated and lightweight runtimes and moving away from “single bigass server”, then disagree. I remember multihour deployments where each team would have to stage and coordinate their rollouts with each other and it sucked, no one liked it.
If you mean how Uber famously had like 8000 microservices, more than 1 for each engineer, then sure. But it’s mixing up cause and effect. Aligning deployment boundaries with domain boundaries is, all things equal, a good idea. ZIRP-gorged unicorns would have found makework one way or another.
It’s fascinating to see how the other side thinks sometimes. Most of the places I’ve worked have been dogmatically averse to scarequote “microservices.”
I have seen microservices being used to decouple release management and deployment. To untie organizational dependencies. To separate cyber/dependency supply chain attack surface area. To reuse parts of the system in other projects. To take advantage of different platforms better suited for that specific job (e.g. most of backend in Typescript, ML/statistic parts in Python).
Never to borrow money, though. I participated in some talks with VCs and they never cared or knew they should care. Where do they give out money for using microservices?
There are tales of managers/VPs in FAANG getting promoted based on how many people they hired. More money allows more people which requires more coordination which leads to microservices.
The phrase "a ZIRP (zero interest rate policy) phenomenon" means something that [the speaker thinks] is egregiously inefficient but which people got away with because the cost of money was low.
VCs do care about these things, I remember hearing there was at least one well known VC that insisted that its startups all used AWS even for services that weren't cost competitive. They didn't want their startups to go viral and then not be able to scale, and if that meant some marginal businesses went from "profitable but unremarkable" to "unprofitable and dead" then so be it. This strategy worked because the sizes of the funds raised by the VCs were very large, and so investments were large, and so startups could afford to not think too hard about the costs of things.
So the path DHH is arguing goes:
1. ZIRP pushes investors into high risk assets like VC funds.
2. VC funds give out huge investments to software startups.
3. Startups do lots of expensive things without worrying about the cost.
4. Having lots of microservices is expensive and the cost isn't justified by the benefits.
5. Therefore, microservices are a ZIRP phenomenon.
AWS/Azure/GCP is suggested because it's easier to hire someone who can maintain it after the founders burn out or exit, and most importantly because the VCs have access to loads of free credits that can get you through the first year or two, effectively increasing their investment (and yours too).
Nothing stops you from just running an EC2 VM there, this has nothing to do with microservices. I never had a VC ask me about software system architecture, though yes they strongly suggested we use AWS, which we luckily did.
There are services on AWS that bring significant benefit even if your app is a monolith - managed DB, email service, queues, nowadays the ML things, and in the past DevOps pipelines and Git repos before that became free/available on GitHub.
Devs sometomes lose touch of the idea of modular libraries with package managers and OO interfaces, and end up tricked into using independently deploysble, independently managed modules for no good reason.
Google says zero interest rate policy. No idea how is it related to software architecture though.
Maybe it's one of those people who think that software engineers like to give themselves more work and headache just because, and can't imagine there's something other than his own experience?
But whenever I participated in this decision, it was under heavy scrutiny by multiple layers of tech and corporate leadership, and done only because it was the best way to solve our problems.
Zero interest rates -> huge surplus of capital looking for return -> investments in VC and tech -> explosion in tech projects without having to Keep It Simple Stupid -> explosion in complexity (i.e. micro services) and hiring.
Exactly. Zero interest rate policy where companies believed that there was no need to make money but to only burn it on VC money with complex systems all day long.
Look at the amount of complexity that micro-services has gotten banks like Monzo into; over 2,000+ and they are happy with it. [0]
An example of bad practices in software engineering which is just only for engineers to persuade their managers around increasing complexity for a increase in salary.
I think it’s more that because there was so much capital looking for an outlet, anyone could suggest any big large thing and the money would be made available. Vs tight times where every expenditure is scrutinized.
If the world is given no choice but to give you money, you're not going to be careful with that money. DHH argues that careful engineers would use microservices a lot less.
I don't think that's true, careful engineers like microservices/SOA because deploying a small fix doesn't necessitate testing and deploying everything else too, service outage is limited, and rollbacks easier. Careful engineers always test everything they are going to deploy - and I don't mean just running the unit test suite. Careful engineers also appreciate when internal implementation details aren't exposed to the rest of the system, interactions are monitored and audited, interfaces are strictly defined and enforced, and services are not bound to run on a single machine - security boundaries and contexts, reduction of attack surface.
I also don't think he's arguing for carefulness at all - he's saying that if it wasn't for the free money, engineers would be forced to move faster and break more things to make quick cash. Understandable from business investor perspective, but has nothing to do with careful engineering. He's basically saying "you're so careful I am not making my money, fuck all that and deliver already".
You don't have to test unrelated components if you tweak a monolith either. I suspect the feeling that microservices let you deploy faster come from the fact that such designs often conflate other things together, e.g. the CI system runs the entire test suite for everything regardless of what changed (due to transient CI workers losing their caches), there's one branch into which every change gets merged so you can't control when core library changes affect you, etc. But it doesn't have to be setup that way.
Ensuring implementation details don't get mixed up is indeed nice in some ways, but cuts both ways: it makes upgrading core libraries harder in case of security issues and such.
You definitely need to. I was bitten by stuff like the compiler/optimizer deciding to do it differently after the unrelated change, resulting in significant performance degradation and whole service outage. There was a bug in our code that just got surfaced, of course - but it was another team's code that I didn't even know about. Debugging and fixing it was a nightmare. That was when I jumped on the SOA train (wasn't called microservices yet).
Another time an unrelated change of another team created a security issue because they improperly used a singleton class from our team's code, and our code became vulnerable because of that. That one was caught during security approval, fortunately - we'd be fucked if it went from CI straight to prod, or if they tested only the changed parts.
It's not just about CI. It's about integration testing, user acceptance testing, security approval, etc. If your system goes from CI directly to production then yeah, maybe you don't need microservices that much - but there are still benefits.
From my years of experience with the industry, ideas like microservices were used way before zero interest rates, and will continue to be used, because they solve actual real problems many people have.
Not saying it's always the best approach - as I mentioned, where I worked it was always under heavy scrutiny and chosen only if it was the best approach, which wasn't always.
> From my years of experience with the industry, ideas like microservices were used way before zero interest rates, and will continue to be used, because they solve actual real problems many people have.
It is one of the many ways for a VC funded company to quickly run out of money.
Given that companies such as Uber and Monzo proudly report that they have thousands upon thousands of micro-services with other startups copying that due to the micro-services hype, I can only see that as a way to introduce more problems such as more operational costs and significant complexity to engineers.
Microservices was indeed a ZIRP idea taken to the extreme in many startups believing they could scale like Google, except that they could not afford to and most of them either bankrupted themselves or are still losing hundreds of thousands a month on this idea and are cutting down on the micro-services fad to save money.
Hmm... I know we're on a startup site, but that's really only a very small part of the business world. Microservice architecture/SOA as we used to call it is successfuly employed at many more traditional small, middle and large enterprises and it has nothing to do with interest rates at these places.
Yes, but it is now impossible to separate them from the hype (same as functional programming languages, cloud providers, etc.).
They will continue to be used, but their proliferation into contexts where they are not the best tool (MongoDB as a shining example) was very much a part of the ZIRP environment (the underlying reasons are numerous).
Hmm how many years are you going back? ZIRP in the USA began around 2008 and "microservices" as a word didn't really start being used until several years after that:
We can debate what DHH really means when he says microservices. Distributed systems are obviously a lot older than the term microservices. But I think he's talking about systems that compromise many services that don't obviously map to hardware or organizational boundaries, which was the original reason you'd split a program up across multiple independent servers. I have to admit I don't recall encountering that trend before 2011 or so. If you take an app written in the 2000-2010 era e.g. Jira, they're all going to be either monoliths or apps loaded into Java app servers.
It was called service oriented architecture before microservices, and the concept itself is way older in the mainframe world; not sure if it actually had a name because it was simply the way it needs to be done. Unix is basically microservices - and back in the 80s and early 90s even network services were built with the Unix philosophy, remember CGI? The Microsoft/Windows world was no stranger to it too - Corba (1991), D-COM (1996), SOAP (1998), WCF (2006) and now it's REST.
Software systems on mainframes were comparable to what we call serverless today - having more external interfaces (like HTTP servers) running on a computer would waste resources, there was one common external interface that invoked code on request based on configuration, and that code delegated heavily to specialized systems - since there wasn't even enough program memory and loading from disk was slow. Having multiple layers of backend systems was normal. Queues and batch job processing was usual too, and frontend systems usually provided precalculated data only, transactions were processed through the night.
Monoliths were actually the "cool new thing" started in late 90s and perpetuated by Java, PHP, Python and Ruby devs later on, they claimed it's easier to develop and deploy. Many people saw it as a conflict between corporate and startup software development practices - the boring engineers in suits always talking about service specifications and requirements for months VS the cool hackers that don't care and develop directly on prod server FTP to deliver a feature over the weekend. JIRA was one of these cool hacker startups.
I don't think the hackers were completely wrong and delivering quickly has value, but it's much more nuanced than "ZIRP bad because ZIRP made microservices", see also my other comment there: https://news.ycombinator.com/item?id=40334281
A very fuzzy pattern that has repeated itself in numerous industries: the easier money is to get/have, the less robust and exacting one has to be with the processes of attaining and maintaining it.
A clear example is with any of the numerous "high profile" VC-funded ventures. You can spend a lot of time and money over-engineering things, because you are not (and neither your boss or his boss and so on) involved in a feedback loop that is tightly coupled with the making of "real" money.
Your actions have no real consequences on the business unit as a whole, and no one is holding you to it. What tends to happen is it gets filled with "dreamers" and "schemers." Both who, rather than contributing to the health of the business, erode it for their own ends. Without there being a "tether to reality" so-to-speak, their actions no longer have to face reality a la profitability.
Generally, the consequences of this are many and I do not wish to enumerate on them (but I will drop these without going into any painstaking depth: organizations that are built primarily around key players' career interests, products made to that end, and even day-to-day choices that in the grand scheme of things mean nothing, but something as simple as choosing Redis as a primary relational database, all reverberate).
This is just my very sloppy attempt at putting intuition into words, but this is a pattern of varying magnitude that always emerges whenever money is detached from merit.
This happens in all sorts of personal and business contexts. Whenever the fruits of whatever labor are detached from its process, the less likely the processes used to attain and maintain it are "sound," sustainable, and so on.
Think of a lottery winner: he has just received a large sum of liquid cash, but he most likely neither has the ability to hold onto it or the know-how to grow it (much less make the same amount again). His decision-making and skillset is utterly detached from his gains. That sort of thing is only honed through a tight feedback loop.
The same can be seen with engineers who have only resided in corporate behemoths: drop them into a startup and they will likely flounder.
There is a much larger discussion to be had about human incentives, but I hope that you are able to make the intuitive jump yourself.
I think he's referring to a 'zero interest rate phenomenon,' a shorthand for an excess that happens when capital is cheap and complexity is rewarded and too easily funded. Supposedly, this leads engineers to choose overly complex solutions, hoping to be rewarded by getting large teams to manage, and gaining experience for their resume. This is in contrast to the scrappy, pragmatic, YAGNI architectural choices DHH regularly advocates. My own view is more pessimistic, that complex architectural choices are made even when the companies involved can't afford them.
If you mean how Uber famously had like 8000 microservices, more than 1 for each engineer, then sure. But it’s mixing up cause and effect. Aligning deployment boundaries with domain boundaries is, all things equal, a good idea. ZIRP-gorged unicorns would have found makework one way or another.