> There are 2,000 people at the company. About 500 of those are in the engineering organization Within that 500, about 150 work on the broadest definition of “infrastructure engineering,” things like developer tools, compute and orchestration, networking, security engineering, and so on

> Unless we can increase YoY growth by 5-10%, they expect us to improve free cash flow by 5-10% each year,

> Growth in the primary business line is shrinking

You know what group is in for imminent downsizing once the investors insist you try to reconcile the shrinking revenue with the increased profit expectations? Those 150 infrastructure engineering employees. They're going to be looking at the fact that they can't directly attribute revenue to 40% of their most expensive subset of employees (Maybe second to executives, but guess who gets to make this decision).

And then all the inhouse tooling to make that monolith work will slowly rot. They'll say something like "Oh, well we expect people operating to give some percentage of their time to maintaining common infra", but that mostly won't happen, as individual product units insist on feature churn.

Then this will go on for maybe another 3 years, at which point getting a change in is hell because your test suites don't work, your onboarding docs are missing a thousand tiny details and security is randomly finding a team to upgrading that damn mysql database which now has a RCE vulnerability, except all the common tooling is all a big ball of yarn that everything depends on everything else and can't be updated without refactoring the whole lot.

And then you'll wonder why it takes 3 months to ship a button that takes users to a static page in your application.

Slightly exaggerated, but I've seen this pattern too many times, so I'm generally for a lot more autonomy for teams, at the risk of some duplication.

One of the things that I liked when React landed on the scene in the Javascript world is that it led us to think about composition and modularity in a more rigorous way. It didn't force us to change how we organized our file systems or repositories, but it did force us to think about how we built our components in a way that ultimately prevented problems that we often see in large codebases.

What I often see missing in the monolith-vs-microservice debate is that breaking a poorly designed monolith into microservices will lead to poorly designed microservices, but if you invest in improving the modularity of your monolith, there's a lot of potential to improve the pain without needing to migrate to microservices.

That said, I am not a microservices detractor. In fact, for new projects, I like to start out by asking whether microservices would be our best option. However, having been involved in some monolith-to-microservice transitions, I have seen that if you don't approach it with the right mindset, you're going to spend a lot of engineering time and be no better off.

“Monolith or microservice?” is the maw so many teams cannot debate their way out of. I encourage my team to think in terms of domain (like DDD), similar to the author’s approach of demarcating by “business unit.”

If something is a coherent domain and can (mostly) stand alone, keep it all together in the same service; otherwise, make a new service for your new domain. The trick, of course, is knowing how broad a domain to cut out of your web of services and responsibilities.

> Business units should always operate in their own code repository and monolith.

> Except for new business unit monoliths, we don’t allow new services.

This assumes that your business will not change, that there are perfectly developed interfaces between "business units" (whatever that term means, it's not particularly clear from the doc how large these are).

It's nice to say "1 team -> 1 application" but that ignores many realities on the ground. Sometimes domains are "solved" or stable, freeing up a team to work on something else. Should they smash their new work into the same application as their old work just because? What do we do when a team dissolves (ie laid off) but their application cannot be shut down?

This article is ok as a case study but is hardly sound advice in general. It does list some specifics about the business being discussed, but then waxes poetic about the entire industry backpedaling from microservices because of interest rates? The only worthwhile thing to take away from this article is that each business is different and should weigh the tradeoffs for themselves.

No