4 ms·

it's not much more work but what's the point of it? the benefits of microservices seem to be the architectural separation of concerns and the downsides are from

it's not much more work but what's the point of it? the benefits of microservices seem to be the architectural separation of concerns and the downsides are from the distributed communication and deployment model, so in a lot of ways a monolith that is internally organized into loosely coupled components gets the best of both worlds. there are good reasons to split things out into separate services, especially if they no longer fit on a commodity server, but this rarely applies to the stateless webapps and rest/grpc services that 95% of people work on.

jayd16 6y ago
Sure. Microservices are a sometimes food. Microservices help you do heterogeneous deployment, scaling, and even design. There are some downsides so if you don't need it, don't do it. The problem I see with some of the backlash against it is that the complaints are often circular and inconsistent. The hardest part is writing a decoupled codebase, not the fixture of running part of the code in a service wrapper. Proponent of monoliths will claim its easier to build a monolith and you can organize your code too, but this is a contradiction. Either you're doing the hard decoupling work properly or you're simplifying things by keeping them coupled. To say you can do both at the same time is disingenuous. But that said, both styles have their pros and cons and they have their place.
- jeffffff 6y ago
  a lot of the backlash is a byproduct of the name and the marketing. i don't think anyone is arguing that splitting things into services isn't ever a good idea. lots of companies were doing it before anyone had ever said the word "microservices". then the microservices people came along and created this false dichotomy of monoliths vs microservices when in reality it's a spectrum. what happened to regular old not-so-micro services? it would be like if a nosql database added sql functionality but flipped the order of the clauses around and called it lqs instead, and then claimed it was the greatest thing since sliced bread and raved about how much better than sql it is. that is what people are reacting against. that and junior developers reading about microservices and deciding that regexservice needs to be a thing.
  - marcus_holmes 6y ago
    The problem here is K8s, to be honest. Microservices as an architecture has become synonymous with K8s deployment. K8s is overkill for anything that is smaller than, say, Twitter. But it's cool, so everyone wants to use it, so suddenly we get bullshit like TFA. It's like Agile. Agile has some great ideas. But now when people say "agile" they mean Scrum. And Scrum is so badly implemented in most places, used as an excuse to do all the things that the Agile Manifesto tried to warn us about in the first place. We end up at shittily-organised micro-waterfalls and everything is crap, but somehow that's "Agile". Same for microservices. There's some good ideas there, but most of the time it's implemented so badly, increasing complexity and reducing managability. We end up with thousands of lines of spaghetti YAML organising god-knows-how-many of instances of god-knows-what when all we needed was a simple webserver, file store and database. And somehow that's "better".

jayd16 6y ago

Sure. Microservices are a sometimes food. Microservices help you do heterogeneous deployment, scaling, and even design. There are some downsides so if you don't need it, don't do it. The problem I see with some of the backlash against it is that the complaints are often circular and inconsistent. The hardest part is writing a decoupled codebase, not the fixture of running part of the code in a service wrapper. Proponent of monoliths will claim its easier to build a monolith and you can organize your code too, but this is a contradiction. Either you're doing the hard decoupling work properly or you're simplifying things by keeping them coupled. To say you can do both at the same time is disingenuous. But that said, both styles have their pros and cons and they have their place.

jeffffff 6y ago
a lot of the backlash is a byproduct of the name and the marketing. i don't think anyone is arguing that splitting things into services isn't ever a good idea. lots of companies were doing it before anyone had ever said the word "microservices". then the microservices people came along and created this false dichotomy of monoliths vs microservices when in reality it's a spectrum. what happened to regular old not-so-micro services? it would be like if a nosql database added sql functionality but flipped the order of the clauses around and called it lqs instead, and then claimed it was the greatest thing since sliced bread and raved about how much better than sql it is. that is what people are reacting against. that and junior developers reading about microservices and deciding that regexservice needs to be a thing.
- marcus_holmes 6y ago
  The problem here is K8s, to be honest. Microservices as an architecture has become synonymous with K8s deployment. K8s is overkill for anything that is smaller than, say, Twitter. But it's cool, so everyone wants to use it, so suddenly we get bullshit like TFA. It's like Agile. Agile has some great ideas. But now when people say "agile" they mean Scrum. And Scrum is so badly implemented in most places, used as an excuse to do all the things that the Agile Manifesto tried to warn us about in the first place. We end up at shittily-organised micro-waterfalls and everything is crap, but somehow that's "Agile". Same for microservices. There's some good ideas there, but most of the time it's implemented so badly, increasing complexity and reducing managability. We end up with thousands of lines of spaghetti YAML organising god-knows-how-many of instances of god-knows-what when all we needed was a simple webserver, file store and database. And somehow that's "better".