6 ms·

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 hav

• ranting-moth 3y ago
  > Monoliths require alignment. So do microservices.
  • spicybright 3y ago
    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.
    • zerbinxx 3y ago
      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.
      • ilyt 3y 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
  • deleted 3y ago
    [deleted]
• wizofaus 3y ago
  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.
  • thrtythreeforty 3y ago
    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.)
    • twisteriffic 3y ago
      How do they avoid cycles in calls to dependencies? Some golden rule of "thou shalt only call services that are less abstract than thyself?"
      • ecshafer 3y ago
        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.
• papito 3y ago
  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.