Hacker News Reader

Comment by boltefnovor | Hacker News Reader

I prefer lower devops complexity and higher software application complexity. Any day.

Microservices is higher devops complexity in exchange for lower software application complexity. A really terrible deal IMO.

View on HN

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.

This is the first time I've heard of Conway's law used in a positive or at least non-negative way.

I don't think I ever read mention of conway's law as having positive or negative connotation.

The law itself is fine, it’s just that the organisation of most companies is abysmal, so your software is too.

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.

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.

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.

I actually think the opposite, Google haven’t launched anything apart from Mail and maps and those were skunkworks projects...

1000 people working on the same code base is human complexity too.

So is 1000 people trying to coordinate package versions and interface changes across 100 systems (throw in loosely typed languages for extra fun).

That assumes all services talk to all other services directly. a) they probably don't, and b) message busses can help a lot.

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.

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.

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.

I think whether that's the case is largely dependent on implementation.

It could increase or decrease software complexity. It could also increase or decrease devops complexity.

Reply on news.ycombinator.com