5 ms·

How about just stop making microservices and go back to monoliths? Then you don’t have to shoehorn two things at the same time!

mabbo 3y ago
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.
- 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.
anotherhue 3y ago
Microservices: Software complexity solutions to human organisation problems. Remember when microservices were pitched as 'allowing you to use the right language for the job'? What a wonderful life the person who thinks a balkanised tech stack is good must have had. They're one undisciplined developer away from having production prolog.
- bheadmaster 3y ago
  One of the pros of microservices is that each individual microservice is so simple that it really doesn't matter what language it's written in because it can be easily rewritten.
  - dragonwriter 3y ago
    I disagree that this is the case; decomposing into microservices doesn’t mean that the functionality within a service boundary is trivial and easy to rewrite.
    - bheadmaster 3y ago
      Of course, there's a whole continuum of complexity between microservices and monoliths in real life. Much of that continuum is labeled as "microservices". I personally think that if microservice is doing something so complicated that the rewrite would take we-cannot-afford-that amount of time, then it should be split into multiple parts.
  - anotherhue 3y ago
    That assumes the service is doing something generic enough to be trivial in any language, in which case, why not just choose one? It's like we're advocating for the outcome of the Tower of Babel tale.
    - zerbinxx 3y ago
      I mean, ultimately most languages and frameworks are/should be at least intelligible and serviceable by your teammates. I’ve both been on teams where I cannot work on Jerry’s Fucking Insanity Factory API after he leaves even though it’s written in JS and I know JS, but this is some insane Rube Goldberg machine that only Jerry’s mind understands, I’ve also been on teams where someone will write their thing in Go or Rust and I don’t know those but I can at least maintain them, because they’re well abstracted and do nice things and their authors were not schizophrenic like Jerry
friendly_chap 3y ago
Hi, author here. I agree 100%. However after spending 10 years doing microservices everyone wants me to do microservices, despite me telling them what you just said. It's a positive feedback loop. This project is just an exploration of providing teams with a low (no?) cost way of doing microservices - I also kinda enjoy hacking on things like this. Still in progress though so use it at your own risk.
sim7c00 3y ago
i think a lot invest in microservices as the services require less programming skills. ofcourse, the whole thing requires skills, but little services with simple apis are easy to make.that makes hiring a lot easier and maybe cheaper. i love monoliths, but at my company (not a software dev place) its hard to do these things. most people dont understand threads and architecture of programs, but they can make some fastapi routes and hook them up to some functions. we can create complex things despite their lack in pure software dev skills. (i wish it was different! but u have to work to ur teams strength othetwise it will end in tears!)
est 3y ago
how about proper system design, make "procedure calls" workable both locally and "remotely" ?
gumballindie 3y ago
Even better, why not go back to modularity? Many microservices could be just that: self contained modules that you can swap in and out as you see fit.
tail_exchange 3y ago
It's really disappointing to see this kind of lazy oversimplification being the top comment on HN, as if monoliths were perfect and microservices didn't have any advantages over them. Yes, maybe the company you work at does not have a good reason to use microservices. But this doesn't mean the same goes for the rest of the industry. Being a nay-sayer and rejecting microservices in any circumstances is just as unreasonable as rejecting monoliths.
- civilitty 3y ago
  > Being a nay-sayer and rejecting microservices in any circumstances is just as unreasonable as rejecting monoliths. No. No no no no! Monoliths (modular or otherwise) are the default and if you have to ask, you don’t need microservices. Period. That’s not a lazy oversimplification, that’s hard earned experience. In over 15 years I’ve seen microservices singlehandedly kill the engineering momentum at nearly half a dozen companies. They’ve got a worse track record than techbro management. Literally the only time I’ve seen the architecture work well was when I was working at Azure on cloud infrastructure with a dozen teams working on a single product. The vast majority of developers never work on a project of that size and yet try to cargo cult microservices into companies with less than a dozen devs, let alone teams. Maybe your company is one of the few companies where microservices make sense (or you haven’t come to grips with the stockholm syndrome yet), but the hype around microservices have been a disaster for many more companies than they have helped in my career
  - tail_exchange 3y ago
    > No. No no no no! Monoliths (modular or otherwise) are the default and if you have to ask, you don’t need microservices. Period. That’s not a lazy oversimplification, that’s hard earned experience. But this is not what I am arguing. Yes, monoliths are the default, and unless you reached the point where you have thousands of engineers and teams working completely independently, you don't need microservices. I've also seen momentum being killed by microservices in smaller startups, and I've also seen large organizations operating with microservices wonderfully. My beef with this kind of comment is that it kills any interesting discussion about architecture into a "don't use microservices" circlejerk, which is not helpful to people who actually want to dive into this kind of architecture. As you said yourself, microservices do work well for large companies, so why pretend it doesn't?

mabbo 3y ago

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.

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.

anotherhue 3y ago

Microservices: Software complexity solutions to human organisation problems. Remember when microservices were pitched as 'allowing you to use the right language for the job'? What a wonderful life the person who thinks a balkanised tech stack is good must have had. They're one undisciplined developer away from having production prolog.

bheadmaster 3y ago
One of the pros of microservices is that each individual microservice is so simple that it really doesn't matter what language it's written in because it can be easily rewritten.
- dragonwriter 3y ago
  I disagree that this is the case; decomposing into microservices doesn’t mean that the functionality within a service boundary is trivial and easy to rewrite.
  - bheadmaster 3y ago
    Of course, there's a whole continuum of complexity between microservices and monoliths in real life. Much of that continuum is labeled as "microservices". I personally think that if microservice is doing something so complicated that the rewrite would take we-cannot-afford-that amount of time, then it should be split into multiple parts.
- anotherhue 3y ago
  That assumes the service is doing something generic enough to be trivial in any language, in which case, why not just choose one? It's like we're advocating for the outcome of the Tower of Babel tale.
  - zerbinxx 3y ago
    I mean, ultimately most languages and frameworks are/should be at least intelligible and serviceable by your teammates. I’ve both been on teams where I cannot work on Jerry’s Fucking Insanity Factory API after he leaves even though it’s written in JS and I know JS, but this is some insane Rube Goldberg machine that only Jerry’s mind understands, I’ve also been on teams where someone will write their thing in Go or Rust and I don’t know those but I can at least maintain them, because they’re well abstracted and do nice things and their authors were not schizophrenic like Jerry

friendly_chap 3y ago

Hi, author here. I agree 100%. However after spending 10 years doing microservices everyone wants me to do microservices, despite me telling them what you just said. It's a positive feedback loop. This project is just an exploration of providing teams with a low (no?) cost way of doing microservices - I also kinda enjoy hacking on things like this. Still in progress though so use it at your own risk.

sim7c00 3y ago

i think a lot invest in microservices as the services require less programming skills. ofcourse, the whole thing requires skills, but little services with simple apis are easy to make.that makes hiring a lot easier and maybe cheaper. i love monoliths, but at my company (not a software dev place) its hard to do these things. most people dont understand threads and architecture of programs, but they can make some fastapi routes and hook them up to some functions. we can create complex things despite their lack in pure software dev skills. (i wish it was different! but u have to work to ur teams strength othetwise it will end in tears!)

est 3y ago

how about proper system design, make "procedure calls" workable both locally and "remotely" ?

gumballindie 3y ago

Even better, why not go back to modularity? Many microservices could be just that: self contained modules that you can swap in and out as you see fit.

tail_exchange 3y ago

It's really disappointing to see this kind of lazy oversimplification being the top comment on HN, as if monoliths were perfect and microservices didn't have any advantages over them. Yes, maybe the company you work at does not have a good reason to use microservices. But this doesn't mean the same goes for the rest of the industry. Being a nay-sayer and rejecting microservices in any circumstances is just as unreasonable as rejecting monoliths.

civilitty 3y ago
> Being a nay-sayer and rejecting microservices in any circumstances is just as unreasonable as rejecting monoliths. No. No no no no! Monoliths (modular or otherwise) are the default and if you have to ask, you don’t need microservices. Period. That’s not a lazy oversimplification, that’s hard earned experience. In over 15 years I’ve seen microservices singlehandedly kill the engineering momentum at nearly half a dozen companies. They’ve got a worse track record than techbro management. Literally the only time I’ve seen the architecture work well was when I was working at Azure on cloud infrastructure with a dozen teams working on a single product. The vast majority of developers never work on a project of that size and yet try to cargo cult microservices into companies with less than a dozen devs, let alone teams. Maybe your company is one of the few companies where microservices make sense (or you haven’t come to grips with the stockholm syndrome yet), but the hype around microservices have been a disaster for many more companies than they have helped in my career
- tail_exchange 3y ago
  > No. No no no no! Monoliths (modular or otherwise) are the default and if you have to ask, you don’t need microservices. Period. That’s not a lazy oversimplification, that’s hard earned experience. But this is not what I am arguing. Yes, monoliths are the default, and unless you reached the point where you have thousands of engineers and teams working completely independently, you don't need microservices. I've also seen momentum being killed by microservices in smaller startups, and I've also seen large organizations operating with microservices wonderfully. My beef with this kind of comment is that it kills any interesting discussion about architecture into a "don't use microservices" circlejerk, which is not helpful to people who actually want to dive into this kind of architecture. As you said yourself, microservices do work well for large companies, so why pretend it doesn't?