4 ms·

This is complete bullshit, top to bottom. Microservices add complexity, they don't remove it. Monolithic architecture doesn't force tight coupling. Tight coup

This is complete bullshit, top to bottom. Microservices add complexity, they don't remove it. Monolithic architecture doesn't force tight coupling. Tight coupling doesn't depend on an architecture. Making a monolith crash-proof is easier than dealing with intermittently-functioning microservices. Being able to change microservices without that affecting any other services is a design goal, not an architectural feature. Microservices are not inherently more scalable than monoliths. They have to be designed that way. And monoliths can equally well be designed to be scalable (just add more instances!). When to use microservices? When one part of your monolith can easily be broken out and run on its own server as a service, and that would improve some performance bottleneck that you need because you can see a point where it will matter in the near future. Otherwise "never".

com2kid 6y ago
Microservices can solve a lot of organizational problems: 1. Fewer merge conflicts, easier branching/merging strategy. If you have 200 people checking into a monolith then it is easy to start stomping all over each other. 2. Large changes(say upgrading to a new major version of a library for security reasons) can result in the code base being in a state of conflict hell, or just frozen, while work gets done. With microservices you can upgrade them one at a time. 3. The build/test/deploy pipeline for any given team is shorter. Large code bases take a long time to build and run through tests. If instead everyone has to have well defined interfaces to their microservices then it is possible to test the interface points of a given microservice that is being committed to. 4. Serious screw-ups in one part of the code don't impact code in other places. If someone starts leaking memory in one microservice, then one part of the system has degraded functionality. Worst case it is a critical microservice and your system goes down. Best case it isn't on the golden path for users and it isn't a major outage. 5. It makes you think about deployment and configuration up front. I have seen major systems (billions of dollars, systems you've used in the past) where only tribal knowledge of how to "get it running" existed. There was no formal deployment plan, and deployments could take days. Microservices force organizations to solve deployment up front.
- bszupnick 6y ago
  I've worked on a large-scale micro-service architecture and I had a great time! I don't "pick a side" of this almost idealistic argument, but I do have some pushback for you: 1) You're right that there aren't merge conflicts, but you swap out merge conflicts with interface changes. Meaning let's say programmer A is working on Microservice B that consumes from Microservice C and she changes the "what I expect from Microservice C" interface. Who changes Microservice C? In THEORY it could be whoever "owns" it, or Programmer A, but in practice sometimes it falls between the cracks. 2/4) We ended up actually writing our own Python packages that did end up being shared amongst some of the microservices. If you want to abide by DRY (not juts as dogma but you just don't want to implement the same thing twice), you do need some shared code. Maybe that "breaks" the microservice "model" and we didn't do it "right"? Maybe. But with what we did, we still did have "internal Python package" updates intended for one Microservice that effected another This is all from my personal experience so it could be that we just didn't follow best practices or fell into some traps.
  - jeffbee 6y ago
    You don't change interfaces. It is that simple. There's not a paradox here. To change your RPC protocol in a distributed system, you may add optional fields to the request but you must not add required fields nor change the semantic meaning of any field. You can add new services and methods but you must not disable one that anyone calls.
    - marcus_holmes 6y ago
      Which is surely an argument for "never start a project using microservices"? Who knows exactly what their interfaces are going to be, across their entire project, on day 1, and gets that right every time?
      - com2kid 6y ago
        > Who knows exactly what their interfaces are going to be, across their entire project, on day 1, and gets that right every time? Same problem exists for binary interfaces, or source code interfaces. Or for a client system that talks to a cloud service. Or for a cloud service that exposes APIs for other cloud services to call. Technologies exist to version APIs. It is sad that JSON is the standard interchange format, since it is pretty miserable at this entire problem.
dec0dedab0de 6y ago
When to use microservices? When one part of your monolith can easily be broken out and run on its own server as a service, and that would improve some performance bottleneck that you need because you can see a point where it will matter in the near future. Otherwise "never". It might not meet the current definition of a micro service, but it makes sense when each bit of functionality is being developed/managed by different teams. Especially in a large company where there are many teams that cater only to other employees. That is, Instead of forcing everyone to choose the same language and architecture and everything, let each team spin up an API for whatever it is they are providing. I believe this was the original reason for micro services, and somehow it morphed into breaking applications into separate systems even when there is no real reason to do so. Another OK reason is when a particular service needs it's own change schedule.
- marcus_holmes 6y ago
  I think the real reason for using microservices is so that people get to play with K8s and put that on their resume. I get the "multiple teams" argument, but I don't think it's an architectural feature. To get multiple teams working on separate-but-connected code, you need to define the interfaces between those separate chunks of code. That's enforced by microservices, sure, but there's nothing stopping you from defining an immutable interface in the monolith too.
jeffbee 6y ago
Eh. Everyone I know has been on-board with microservices for decades, they just don't realize it. Does your organization have recursive DNS servers? You are using microservices. Does your organization use an RDBMS server instead of the built-in database features of your operating system? You are using microservices.
jayd16 6y ago
The article says the communication in a microservice is more complex. If you're writing a monolith with loose coupling of features, then its not that much more work to break those features out into a service. You might not be able to change the API of a service without affecting others but you should be able to deploy separately to meet the definition of a microservice.
- jeffffff 6y ago
  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.

com2kid 6y ago

Microservices can solve a lot of organizational problems: 1. Fewer merge conflicts, easier branching/merging strategy. If you have 200 people checking into a monolith then it is easy to start stomping all over each other. 2. Large changes(say upgrading to a new major version of a library for security reasons) can result in the code base being in a state of conflict hell, or just frozen, while work gets done. With microservices you can upgrade them one at a time. 3. The build/test/deploy pipeline for any given team is shorter. Large code bases take a long time to build and run through tests. If instead everyone has to have well defined interfaces to their microservices then it is possible to test the interface points of a given microservice that is being committed to. 4. Serious screw-ups in one part of the code don't impact code in other places. If someone starts leaking memory in one microservice, then one part of the system has degraded functionality. Worst case it is a critical microservice and your system goes down. Best case it isn't on the golden path for users and it isn't a major outage. 5. It makes you think about deployment and configuration up front. I have seen major systems (billions of dollars, systems you've used in the past) where only tribal knowledge of how to "get it running" existed. There was no formal deployment plan, and deployments could take days. Microservices force organizations to solve deployment up front.

bszupnick 6y ago
I've worked on a large-scale micro-service architecture and I had a great time! I don't "pick a side" of this almost idealistic argument, but I do have some pushback for you: 1) You're right that there aren't merge conflicts, but you swap out merge conflicts with interface changes. Meaning let's say programmer A is working on Microservice B that consumes from Microservice C and she changes the "what I expect from Microservice C" interface. Who changes Microservice C? In THEORY it could be whoever "owns" it, or Programmer A, but in practice sometimes it falls between the cracks. 2/4) We ended up actually writing our own Python packages that did end up being shared amongst some of the microservices. If you want to abide by DRY (not juts as dogma but you just don't want to implement the same thing twice), you do need some shared code. Maybe that "breaks" the microservice "model" and we didn't do it "right"? Maybe. But with what we did, we still did have "internal Python package" updates intended for one Microservice that effected another This is all from my personal experience so it could be that we just didn't follow best practices or fell into some traps.
- jeffbee 6y ago
  You don't change interfaces. It is that simple. There's not a paradox here. To change your RPC protocol in a distributed system, you may add optional fields to the request but you must not add required fields nor change the semantic meaning of any field. You can add new services and methods but you must not disable one that anyone calls.
  - marcus_holmes 6y ago
    Which is surely an argument for "never start a project using microservices"? Who knows exactly what their interfaces are going to be, across their entire project, on day 1, and gets that right every time?
    - com2kid 6y ago
      > Who knows exactly what their interfaces are going to be, across their entire project, on day 1, and gets that right every time? Same problem exists for binary interfaces, or source code interfaces. Or for a client system that talks to a cloud service. Or for a cloud service that exposes APIs for other cloud services to call. Technologies exist to version APIs. It is sad that JSON is the standard interchange format, since it is pretty miserable at this entire problem.

dec0dedab0de 6y ago

When to use microservices? When one part of your monolith can easily be broken out and run on its own server as a service, and that would improve some performance bottleneck that you need because you can see a point where it will matter in the near future. Otherwise "never". It might not meet the current definition of a micro service, but it makes sense when each bit of functionality is being developed/managed by different teams. Especially in a large company where there are many teams that cater only to other employees. That is, Instead of forcing everyone to choose the same language and architecture and everything, let each team spin up an API for whatever it is they are providing. I believe this was the original reason for micro services, and somehow it morphed into breaking applications into separate systems even when there is no real reason to do so. Another OK reason is when a particular service needs it's own change schedule.

marcus_holmes 6y ago
I think the real reason for using microservices is so that people get to play with K8s and put that on their resume. I get the "multiple teams" argument, but I don't think it's an architectural feature. To get multiple teams working on separate-but-connected code, you need to define the interfaces between those separate chunks of code. That's enforced by microservices, sure, but there's nothing stopping you from defining an immutable interface in the monolith too.

jeffbee 6y ago

Eh. Everyone I know has been on-board with microservices for decades, they just don't realize it. Does your organization have recursive DNS servers? You are using microservices. Does your organization use an RDBMS server instead of the built-in database features of your operating system? You are using microservices.

jayd16 6y ago

The article says the communication in a microservice is more complex. If you're writing a monolith with loose coupling of features, then its not that much more work to break those features out into a service. You might not be able to change the API of a service without affecting others but you should be able to deploy separately to meet the definition of a microservice.

jeffffff 6y ago
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.