I've seen both extremes. For instance I'm told github largely has a rails monolith and that they have to run headless instances of rails to do database leader election (although this statement implies they are trying to break things out).
I've also talked to junior engineers who want to make every function call a pubsub message.
I've heard principals from Amazon promote a model where one service is responsible for one entity.
What I've decided is that the services in your company should follow conway's law. Most of the problems with a monolith come when multiple teams with differing release cycles and requirements are making changes in a shared codebase and they are having trouble keeping their tree green. You should generally have one to a few services per team. Scoping a service to a team ensures that people can have true ownership.
For SREs microservices are harder, but they give SREs the control plane they need to do a good job. If communication happens between services rather than function calls, it's easier to instrument all services in a common way and build dashboards. It's simpler to spin up different instances connected to different datasources.
I agree wholeheartily that Conway's law is a very useful guiding principle for making "architectural" decisions.
I also think this applies much more broadly than just microservices vs monoliths. I recently moved ~40 repositories into just a few. What I've found is that anything that releases together (by teams and timeframe), should stay together. This helps ease modification of related components in an agile way, simplify tagging components, simplifies CI workflow (no multi-project pipelines).
Anything that breaks with this principle should have a concrete reason for it. If you need to combine the results of several teams into one large release, it may be easier to develop tooling for handling it all in one repository rather than developing tooling for handling many repositories. That's really the monorepo tradeoff.
Similarily, there are concrete reasons for breaking a service into smaller parts. Perhaps you want to horizontally scale a part of the service. Perhaps you need a part of the service to have a different lifecycle. But you're paying with increased deployment complexity, so you'd better get something worthwhile in return.
Hard agree. As an SRE, half the time my current company splits something off into its own service its for performance reasons driven by us. It’s just as often us working with the devs because we need X service off the primary database or Y service the ability to scale on its own as it is them having created a separate service of their own accord. Plus as an SRE, it’s a lot easier to wrap my head around what each service does on its own and what responsibilities are broken when its down than it is to understand the full workings of a monolith, and building monitoring around the smaller chunks is easier.
Obviously it’s possible to overdo it. Generally it seems that splitting out services as appropriate is more intelligent than just sitting down with the thought “we’re going to build a microservice architecture.” Goes back to the idea that gets banded around a lot that you should start with something as simple as possible and if you get in a situation where you are at the scale to need to rewrite then that’s a good sign for your business.
In case of rewriting the codebase it actually makes sense. Your organisation already has a codebase and complementary org structure. Any microservices rewrite should be tailored to the existing boundaries of teams for maximum effectiveness.
But the idea that interacting services can be built by different teams isn’t just dev ops complexity, it’s insanely complex managing that stuff because it involves humans.
Never mind that everyone building micro services just goes “fuck transactions and eventual consistency, I’ll go with maybe/probably my data gets corrupted over time” whoop.
It doesn't matter if it's multiple services or one monolith, once you have multiple teams on one product the complexity is already there. The argument is that microservices force it to be visible and dealt with while monoliths hide it until you blow your feet off.
Particularly, IMO, for internal business apps, microservices make it more likely that you can align products, business owners, and teams, whereas monoliths force complicated governance as well as multiteam products. And, in practice, the development teams and business owners aren't aligned, so you get a many-to-many web of requirements and approvals communication.
Who said anything about one monolith? I believe much more in starting with one service and splitting it when it becomes absolutely torture to work with... Make as few services as you can possibly handle and make absolute guarantees between them in terms of data consistency. This is basically what the article suggests in detail, but I assume you disagree with it?
Bounded contexts DO NOT need network partitions to be enforced BTW. For example, I'm pretty sure Google has all their source code in a single repo (or at least a LOT), how do they with a million developers stop people from intertwining everything? My guess is code reviews, hiring good people and tooling.
EDIT: sorry to the person who liked it I've rewritten this comment for clarity, and removed lots of words...
Very very few companies are actually like Google to the point where I'd say making an argument that assumes you are like Google is a fallacy. When you have a near infinite stream of ad money to pay developers million dollar salaries then amazing things are possible.
APIs shouldn't change in backward-incompatible ways. That's sorta the bedrock of a service oriented architecture. If teams have to communicate with each other through more than API documentation and can push responsibilities onto each other by making backwards-incompatible changes then you've kneecapped the entire benefit of a service oriented architecture from the get-go.
I'm not talking about backwards compatibility so much as adding features in parallel that span many services, which happens when you're closing a lot of sales deals when the salespeople don't say no to things :p
Sure, if you are independently building your service, or working a tight feedback loop with others on the product.
As others pointed out, it works for companies who operate and scale engineering teams. Good luck maintaining complex applications across tens to hundreds of developers.
Tens to low hundreds possibly, but micro services can make things much worse as you scale to thousands of developers. The ultimate limit of any design is how much any one person can understand both from both a complexity standpoint and a rate off change standpoint. It’s the same issue that pushed people from goto > functions > libraries > ... Eventually you need another layer of abstraction.
For very large companies doing mergers etc things are always going to be in flux in ways that the startup world tends to ignore.
You are correct and I agree with you. I have not worked in big projects, only small, so that’s where my beliefs come from.
I feel the problem is a software problem that should be solved by better development tools/languages rather than throwing up hands and pushing the problem into the operations domain.
I've also talked to junior engineers who want to make every function call a pubsub message.
I've heard principals from Amazon promote a model where one service is responsible for one entity.
What I've decided is that the services in your company should follow conway's law. Most of the problems with a monolith come when multiple teams with differing release cycles and requirements are making changes in a shared codebase and they are having trouble keeping their tree green. You should generally have one to a few services per team. Scoping a service to a team ensures that people can have true ownership.
For SREs microservices are harder, but they give SREs the control plane they need to do a good job. If communication happens between services rather than function calls, it's easier to instrument all services in a common way and build dashboards. It's simpler to spin up different instances connected to different datasources.