5 ms·

I recently did some reading on microservices, since I had to create a multi-service deployment. I really don't understand how people are able to manage the com

I recently did some reading on microservices, since I had to create a multi-service deployment. I really don't understand how people are able to manage the complexity when they split every single small domain of an application into its own service. You have to re-invent layers that are normally provided to you by the database, you have to deal with a lot of extreme edge and failure cases and you also lose any ability to statically figure out how data flows through your application (codebase becomes harder to understand, fixing bugs will probably take longer). In our case, we have each application as a separate service. On top of that, we have some smaller supporting services to make certain things easier, but they're limited and their use makes sense outside of creating complexity for sport.

Nextgrid 7y ago
> I really don't understand how people are able to manage the complexity when they split every single small domain of an application into its own service. Most places using microservices use them because of the extra complexity and management overhead, as it gives them a reason to hire more engineers to deal with it, write blog posts about how “cool” they are and how they deal with the (self-inflicted) problems and downsides of microservices, get more funding to pay said engineers, etc. This reminds me of a company I used to work at. The product is just an e-commerce app, but somehow they now need 3 different languages, a Kubernetes cluster, and hundreds of engineers for something that used to be able to run on Heroku just a few years ago with no functional changes to the product. Yet somehow they keep getting funded despite bleeding money for over a decade so I guess the strategy must be working since investors are guzzling the kool-aid and are happy to pour more money for the engineers to be able to play around with new shiny toys.
- Kaze404 7y ago
  I thought you were talking about my last company until the "hundreds of employees" part. Makes me wonder if this is a common situation.
echelon 7y ago
Microservices are for companies with 500+ engineers. They help teams manage complex interdependencies by creating strong ownership boundaries, strong product definition, loose coupling, and allow teams to work at their own velocities and deployment cadences. If you're doing microservices with 20 people, you're doing it wrong. It's when you have 500 people that the average engineer doesn't need to know about the eventually consistent data model of your active-active session system. They just need your service API.
- james_s_tayler 7y ago
  What do you do if you have ~20 people and a decade old million line monolith that you're now bumping up against the limits of?
  - spand 7y ago
    Seems the solution would be to improve the thing rather than reimplement it as microservices.
    - pageandrew 7y ago
      Or split out an individual domain, particularly one you’re having pain with, into its own “micro”service.
      - james_s_tayler 7y ago
        I think this is going to be the approach we wind up taking. In reality there are maybe 1 ~ 3 hotpots in the domain that reveice many more transactions than the rest.
    - james_s_tayler 7y ago
      I think there are some things we can legitimately improve quite a lot under the current structure, and it seems there are other things that make certain improvements just untenable. Upgrading a major version of an ORM for instance. It seems there are certain key improvements that boil down to "the only way this can be improved would result in a big-bang release affecting the entire of the system and take a dedicated team quite a long time to do". It's just not palatable for anyone. For the parts we carve out as microservices we are essentially able to erase that technical debt. That comes at the cost of increased ops complexity. We're not ready or capable of having 50 microservices from an ops perspective, but we are capable of handling more on the order of ~5.
caro_douglos 7y ago
For me I’ve never been able to create micro services without running into what you’ve just said about the complexity from the tools themselves. As of right now I’m biased towards writing my sloppy code and seeing what part of it falls over. To me that’s the best way to not rabbit hole while debugging these micro service problems.
collyw 7y ago
The whole myth that micro services are simpler needs looked at. The way I look at it, a micro service application is basically a monolith with extra points of failure because of all the network connections between services. Each service may be simpler, but the complexity just gets pushed to the Devops layer.
- eeZah7Ux 7y ago
  You described the distributed monolith. All the problems of a monolith and all the problems of a distributed system. Services make sense when they map 1:1 with teams.
  - collyw 7y ago
    What are the problems of a (well designed) monoloith?
BerislavLopac 7y ago
Microservices are there because of Conway's Law. If you have a small team that takes care of all aspects of the system, microservices will cause you plenty of headache. It is usually better to keep things simple, as a monolithic system built using technologies that all the developers are familiar with. If you have a large, multidisciplinary team, microservices will allow you to split the team into smaller squads focussed on individual components and develop and deploy them independently from each other, choosing whichever technologies will provide the most benefit. Like any other architectural pattern microservices are not there for their own sake; they are solving a specific, concrete problem, which might be even more organisational than technological. If you don't have that problem, don't use microservices.
BrandoElFollito 7y ago
Home usage example, probably not that relevant. Time span is 20 years. I used to host everything on one machine. It got complicated quickly. I then split everything between VMs. Still difficult to maintain. I finally switched to docker where 70% of the containers are from Docker Hub, maintained by enthusiasts or the devs of the product. I trust them blindly, knowing they will do a better job than I do. 30% of the services are mine. Tiny images, tiny specialized code easy to maintain because there are few dependencies. Again, this is a home setup with a tolerant family who can spend a night without lights when I am struggling to roll back "obvious improvements"

Nextgrid 7y ago

> I really don't understand how people are able to manage the complexity when they split every single small domain of an application into its own service. Most places using microservices use them because of the extra complexity and management overhead, as it gives them a reason to hire more engineers to deal with it, write blog posts about how “cool” they are and how they deal with the (self-inflicted) problems and downsides of microservices, get more funding to pay said engineers, etc. This reminds me of a company I used to work at. The product is just an e-commerce app, but somehow they now need 3 different languages, a Kubernetes cluster, and hundreds of engineers for something that used to be able to run on Heroku just a few years ago with no functional changes to the product. Yet somehow they keep getting funded despite bleeding money for over a decade so I guess the strategy must be working since investors are guzzling the kool-aid and are happy to pour more money for the engineers to be able to play around with new shiny toys.

Kaze404 7y ago
I thought you were talking about my last company until the "hundreds of employees" part. Makes me wonder if this is a common situation.

echelon 7y ago

Microservices are for companies with 500+ engineers. They help teams manage complex interdependencies by creating strong ownership boundaries, strong product definition, loose coupling, and allow teams to work at their own velocities and deployment cadences. If you're doing microservices with 20 people, you're doing it wrong. It's when you have 500 people that the average engineer doesn't need to know about the eventually consistent data model of your active-active session system. They just need your service API.

james_s_tayler 7y ago
What do you do if you have ~20 people and a decade old million line monolith that you're now bumping up against the limits of?
- spand 7y ago
  Seems the solution would be to improve the thing rather than reimplement it as microservices.
  - pageandrew 7y ago
    Or split out an individual domain, particularly one you’re having pain with, into its own “micro”service.
    - james_s_tayler 7y ago
      I think this is going to be the approach we wind up taking. In reality there are maybe 1 ~ 3 hotpots in the domain that reveice many more transactions than the rest.
  - james_s_tayler 7y ago
    I think there are some things we can legitimately improve quite a lot under the current structure, and it seems there are other things that make certain improvements just untenable. Upgrading a major version of an ORM for instance. It seems there are certain key improvements that boil down to "the only way this can be improved would result in a big-bang release affecting the entire of the system and take a dedicated team quite a long time to do". It's just not palatable for anyone. For the parts we carve out as microservices we are essentially able to erase that technical debt. That comes at the cost of increased ops complexity. We're not ready or capable of having 50 microservices from an ops perspective, but we are capable of handling more on the order of ~5.

caro_douglos 7y ago

For me I’ve never been able to create micro services without running into what you’ve just said about the complexity from the tools themselves. As of right now I’m biased towards writing my sloppy code and seeing what part of it falls over. To me that’s the best way to not rabbit hole while debugging these micro service problems.

collyw 7y ago

The whole myth that micro services are simpler needs looked at. The way I look at it, a micro service application is basically a monolith with extra points of failure because of all the network connections between services. Each service may be simpler, but the complexity just gets pushed to the Devops layer.

eeZah7Ux 7y ago
You described the distributed monolith. All the problems of a monolith and all the problems of a distributed system. Services make sense when they map 1:1 with teams.
- collyw 7y ago
  What are the problems of a (well designed) monoloith?

BerislavLopac 7y ago

Microservices are there because of Conway's Law. If you have a small team that takes care of all aspects of the system, microservices will cause you plenty of headache. It is usually better to keep things simple, as a monolithic system built using technologies that all the developers are familiar with. If you have a large, multidisciplinary team, microservices will allow you to split the team into smaller squads focussed on individual components and develop and deploy them independently from each other, choosing whichever technologies will provide the most benefit. Like any other architectural pattern microservices are not there for their own sake; they are solving a specific, concrete problem, which might be even more organisational than technological. If you don't have that problem, don't use microservices.

BrandoElFollito 7y ago

Home usage example, probably not that relevant. Time span is 20 years. I used to host everything on one machine. It got complicated quickly. I then split everything between VMs. Still difficult to maintain. I finally switched to docker where 70% of the containers are from Docker Hub, maintained by enthusiasts or the devs of the product. I trust them blindly, knowing they will do a better job than I do. 30% of the services are mine. Tiny images, tiny specialized code easy to maintain because there are few dependencies. Again, this is a home setup with a tolerant family who can spend a night without lights when I am struggling to roll back "obvious improvements"