Hacker News Reader

Comment by mabbo | Hacker News Reader

I spent a decade at Amazon (SOA all the things!) and then a year and a half at Shopify (single Rails monolith for all the things!).

I think both strategies have pros and cons. But critically, you need a company culture that supports whichever choice you've made.

If you have a company where each team gets to totally decide how they want to implement their stuff, sharing a monolith between teams can create a mess. Ownership issues to be resolved, code quality/style issues, operational issues. Monoliths require alignment.

View on HN

> Monoliths require alignment.

So do microservices.

I think GP's point on company culture is the right answer.

My only thoughts to add is monoliths can be aligned as well as microservices, if not a bit easier depending on the team.

You have to align microservices to talk to each other anyways, and there's no reason you can't make those boundaries work in one codebase instead of many.

That said ownership is more important in a monolith, whether that be a single team of architects or architects responsible for a specific well defined part of the code base.

Having a solid process for only allowing well thought out code in is a cornerstone to keeping alignment.

The worst thing is the many-monoliths/mini-monoliths problem that you get when each team thinks it has ultra special needs and absolutely must build everything from scratch, even if it’s a near duplicate of something someone else built 2 months ago.

building from scratch instead of using something that already fits pretty well is orthogonal to discussion as it happens both in monolith and microservices

Out of curiosity, do the microservices at Amazon typically call each other in an orchestrated fashion (i.e. microservice A knows it needs some particular functionality and knows to call microservice B to get it), or is in more asynchronous/"choreographed", where requests are available to a general pool of services, each of which handles as they need? It's hard to see how a library like the one posted about here would help much with the latter.

It is definitely the first one. Microservices at AWS typically grow boundaries at team boundaries, even if it would make much more technical sense for them to be combined. Each team knows which other team provides the APIs they need.

(Under the hood, the service may in fact be distributed to a large pool of resources. But a microservice doesn't shout into a void "hey could someone please handle a LaunchInstanceInRegion class??" - it's like using a library, but over the network.)

How do they avoid cycles in calls to dependencies? Some golden rule of "thou shalt only call services that are less abstract than thyself?"

In my experience building these type of microservices, it just doesn't really happen often. Team A is responsible for customer data, Team B is responsible for inventory data, so you are usually don't have situations where A calls B and vice versa. The checkout service knows to call A and B.

I have yet to work at a company where teams were so discipled in their silo with API version control and backward compatibility that it did not require cross-team alignment. This is largely a theory and a myth.

Reply on news.ycombinator.com