4 ms·

"In the olden days, a software application was built as a large monolith (...)" - people should stop writing this kind of shit. You can hear this nonsense from

"In the olden days, a software application was built as a large monolith (...)" - people should stop writing this kind of shit. You can hear this nonsense from some poor quality bloggers. People who are serious about it say things like "for most startups microservices is bad idea", "monolith should be starting point in most cases", "there is a price that comes with microservices", "modularised monoliths are often pefect fit" etc. this is coming not from random internet dudes but from Sam Newman author of "Building Microservices" and "Monolith to Microservices", Martin Fowler etc. Microservices/services/monoliths are one of design kinds, they best fit into different setups. References: * https://www.theregister.com/2020/03/04/microservices_last_resort/ https://www.theregister.com/2020/03/04/microservices_last_re... * https://www.youtube.com/watch?v=GBTdnfD6s5Q https://www.youtube.com/watch?v=GBTdnfD6s5Q etc.

dastbe 5y ago
you can see a similar lack of understanding when they use a browser-based test of http/1.1 vs http/2 to justify the improved performance of http/2 for service-to-service communication. what that test is really demonstrating is the fact that your browser hard limits the number of http/1.1 connections it will make much moreso than it limits the number of http/2 connections it makes.
- jeffffff 5y ago
  sure maybe the browser is limiting the number of http/1.1 connections, but it's not true that it doesn't limit the number of http/2 connections in a similar manner. it only creates one http/2 connection but due to multiplexing that is all it needs.
Zababa 5y ago
I especially dislike when people talk about microservices and scalability like they are a solution. Most companies won't see the kind of scale Facebook/Google/etc sees, not because they won't have that much clients, but also because there's a good chance that they don't need all clients in the same system. Most business don't benefit from the network effect. In that case, your scale is not the total sum of the size of all your clients like Facebook/Google/etc, it's just your biggest client! Also, I don't like how the discussion about "microservices" is drowning the discussion about plain services. Services are a natural consequence of Conway's law when your organization gets bigger. You can see parallels with the first wave of OO programming for software projects, where the goal of having a public interface and private internals was to make projects scale when 10/100/1000 times more people are working on it. This is exactly what's happening with services: a team maintain a public API, and private internals (and the developpers from the other team depend on the internals anyways because reality isn't that easy). Then it's easy to see what microservices are: ravioli code. In a way, services and microservices are OO programming in the Alan Kay sense: late binding, message passing, local retention and hiding of state.
- deleted 5y ago
  [deleted]
- jayd16 5y ago
  >the discussion about "microservices" is drowning the discussion about plain services. Yeah I think this really sets back the conversation when, in my mind, microservices are just services with the acknowledgement that minimum size should not factor into breaking off a new service.
- omegalulw 5y ago
  > In a way, services and microservices are OO programming in the Alan Kay sense: late binding, message passing, local retention and hiding of state. > This is exactly what's happening with services: a team maintain a public API, and private internals (and the developpers from the other team depend on the internals anyways because reality isn't that easy). Then it's easy to see what microservices are: ravioli code. This is a moot point. Following up on you OO example, there is not reason you can have separate public and private implementations within a (modularized) monolith. The biggest downsides of (modularized) monoliths lie in 1) scaling - e.g., you can independently scale and load balancer each service, 2) releases - you can have independent releases (at the risk of maintaining version compatibility).
- rualca 5y ago
  > Most companies won't see the kind of scale Facebook/Google/etc sees, not because they won't have that much clients, but also because there's a good chance that they don't need all clients in the same system. I feel this line of argument is disingenuous and is based on a mix of strong personal opinions and very limited to non-existent insight onto which problems other orgs experience. For starters, the main selling point of microscopes is not performance. It is organizational advantages. It is a way to draw clear and crisp lines regarding ownership and ops. Small teams are able to design and deploy and run and troubleshoot small bits of a large machine without wasting time in back-and-forths with other teams, and they can put in place safeguards so that if other teams screw up then their blast radius is limited. But regarding performance, let's not fool ourselves into believing that there's always a fatter network pipe and a beefier box to deploy to. Often there is, but often there simply isn't. Once you are forced to deploy your monolith into multiple instances, most of the criticism directed at microservices is rendered moot. Also, beefier boxes are far more expensive to operate, so let's not pretend there are no costs. Also, there's the reliability aspect. If you want to have a reliable service then you need redundancy, which means multiple deployments. Once you have to deal with load balancers serving traffic to multiple instances of your monolith, there is no longer a significant architectural and ops difference in whether you operate a monolith or shave a service or two out of it. Thus most of the criticism directed at microservices is rendered moot. Lastly, some orgs are ok with serving users in a very limited geographical region. That's perfectly fine. Other orgs might have users in different parts of the globe. Do you expect them to tolerate latencies in the 200-500ms range routinely, or do you find acceptable to reel in those latencies back to the 50ms territory by deploying a part of the service closer? I get the Monolith first principle, but you're fooling yourself if you believe that only FAANG-level companies can benefit from it.
Toine 5y ago
I've seen "confirmed" developers create one microservice for each entity/model they have. Everything is simple CRUD, absolutely no domain logic. Literally, a "user" microservice, with its User class and repository, 100 LOC, a "message" microservice with 80, etc. Aggressively arguing the superiority of their monster. Of course the services all shared the same db, completely missing the actual benefit of microservices. And every service was completey coupled to others and could not run on its own. How do you fix that ?
- davidw 5y ago
  > How do you fix that? You run away as fast as you can is what you do.
- keithnz 5y ago
  eventually they are just going to invent an actor framework
- anonymoushn 5y ago
  The user service team told us we were querying them too much, so we just stored usernames in addition to user IDs to avoid querying them, then later documents would have the wrong username on them if the user changed their username. One perspective is that we were negligent and caused a bug, but another possible perspective is that maybe the user service team should have caching instead of every other team building their own caching for the user service.
  - marsdepinski 5y ago
    They should send a cache-control header in the response or 304 Not-modified when queried with not-modified-since. The calling service should always be the one responsible for caching to save the network round-trip. And if you're going to duplicate data like usernames, get a message channel setup to propagate the changes into the system cloning data.
pankaj021 5y ago
This blog is not on why you should choose microservices, it's just about microservices communication, but let me start with saying I don't agree. I know a couple of friends from startups and they all build software using microservices. I have personally worked in large monoliths for close to 12 years (and last 4/5 years microservices). IMO, the biggest benefit of microservices is agility, you can build and deploy features incrementally and fast. Nowadays with slick frameworks like Spring boot, Nest.js and all the tooling around (like Kubernetes) building microservices is much easier than building monolith. In the monolith world, we had developed a sophisticated, in-house framework for concurrent and distributed task management and I don' see the need for that kind of framework in microservices. In the last 3 years, I had never come across a single developer working on a "cloud-native" microservices project who can confidently answer a single thread question - but developing an auto-scaling application based on the Kubernetes is a piece of cake. How do you expect them to write a well-behaved monolith? It's much easier to quote Sam Newman and Martin fowler, but sorry, I don't find all advice from pundits very practical. From Sam Newman's book "One of the things I see people having the hardest time with is the idea that microservices should avoid the use of shared databases. If a microservice wants to access data held by another microservice, it should go and ask that second microservice for the data. This gives the microservices the ability to decide what is shared and what is hidden, which allows us to clearly separate functionality that can change freely (our internal implementation) from the functionality that we want to change infrequently (the external contract that the consumers use)." How is this practical for each microservices to have its own database? Is it even possible in the cloud world where we consume databases as a service? The bottom line is - nowadays developing microservices is much easier than a monolith. You get lots of tooling - such as observability stack, resiliency out of the box. This just needs to be well supported by organization culture and practices (DevOps, SRE, incident management).

dastbe 5y ago

you can see a similar lack of understanding when they use a browser-based test of http/1.1 vs http/2 to justify the improved performance of http/2 for service-to-service communication. what that test is really demonstrating is the fact that your browser hard limits the number of http/1.1 connections it will make much moreso than it limits the number of http/2 connections it makes.

jeffffff 5y ago
sure maybe the browser is limiting the number of http/1.1 connections, but it's not true that it doesn't limit the number of http/2 connections in a similar manner. it only creates one http/2 connection but due to multiplexing that is all it needs.

Zababa 5y ago

I especially dislike when people talk about microservices and scalability like they are a solution. Most companies won't see the kind of scale Facebook/Google/etc sees, not because they won't have that much clients, but also because there's a good chance that they don't need all clients in the same system. Most business don't benefit from the network effect. In that case, your scale is not the total sum of the size of all your clients like Facebook/Google/etc, it's just your biggest client! Also, I don't like how the discussion about "microservices" is drowning the discussion about plain services. Services are a natural consequence of Conway's law when your organization gets bigger. You can see parallels with the first wave of OO programming for software projects, where the goal of having a public interface and private internals was to make projects scale when 10/100/1000 times more people are working on it. This is exactly what's happening with services: a team maintain a public API, and private internals (and the developpers from the other team depend on the internals anyways because reality isn't that easy). Then it's easy to see what microservices are: ravioli code. In a way, services and microservices are OO programming in the Alan Kay sense: late binding, message passing, local retention and hiding of state.

deleted 5y ago
[deleted]
jayd16 5y ago
>the discussion about "microservices" is drowning the discussion about plain services. Yeah I think this really sets back the conversation when, in my mind, microservices are just services with the acknowledgement that minimum size should not factor into breaking off a new service.
omegalulw 5y ago
> In a way, services and microservices are OO programming in the Alan Kay sense: late binding, message passing, local retention and hiding of state. > This is exactly what's happening with services: a team maintain a public API, and private internals (and the developpers from the other team depend on the internals anyways because reality isn't that easy). Then it's easy to see what microservices are: ravioli code. This is a moot point. Following up on you OO example, there is not reason you can have separate public and private implementations within a (modularized) monolith. The biggest downsides of (modularized) monoliths lie in 1) scaling - e.g., you can independently scale and load balancer each service, 2) releases - you can have independent releases (at the risk of maintaining version compatibility).
rualca 5y ago
> Most companies won't see the kind of scale Facebook/Google/etc sees, not because they won't have that much clients, but also because there's a good chance that they don't need all clients in the same system. I feel this line of argument is disingenuous and is based on a mix of strong personal opinions and very limited to non-existent insight onto which problems other orgs experience. For starters, the main selling point of microscopes is not performance. It is organizational advantages. It is a way to draw clear and crisp lines regarding ownership and ops. Small teams are able to design and deploy and run and troubleshoot small bits of a large machine without wasting time in back-and-forths with other teams, and they can put in place safeguards so that if other teams screw up then their blast radius is limited. But regarding performance, let's not fool ourselves into believing that there's always a fatter network pipe and a beefier box to deploy to. Often there is, but often there simply isn't. Once you are forced to deploy your monolith into multiple instances, most of the criticism directed at microservices is rendered moot. Also, beefier boxes are far more expensive to operate, so let's not pretend there are no costs. Also, there's the reliability aspect. If you want to have a reliable service then you need redundancy, which means multiple deployments. Once you have to deal with load balancers serving traffic to multiple instances of your monolith, there is no longer a significant architectural and ops difference in whether you operate a monolith or shave a service or two out of it. Thus most of the criticism directed at microservices is rendered moot. Lastly, some orgs are ok with serving users in a very limited geographical region. That's perfectly fine. Other orgs might have users in different parts of the globe. Do you expect them to tolerate latencies in the 200-500ms range routinely, or do you find acceptable to reel in those latencies back to the 50ms territory by deploying a part of the service closer? I get the Monolith first principle, but you're fooling yourself if you believe that only FAANG-level companies can benefit from it.

Toine 5y ago

I've seen "confirmed" developers create one microservice for each entity/model they have. Everything is simple CRUD, absolutely no domain logic. Literally, a "user" microservice, with its User class and repository, 100 LOC, a "message" microservice with 80, etc. Aggressively arguing the superiority of their monster. Of course the services all shared the same db, completely missing the actual benefit of microservices. And every service was completey coupled to others and could not run on its own. How do you fix that ?

davidw 5y ago
> How do you fix that? You run away as fast as you can is what you do.
keithnz 5y ago
eventually they are just going to invent an actor framework
anonymoushn 5y ago
The user service team told us we were querying them too much, so we just stored usernames in addition to user IDs to avoid querying them, then later documents would have the wrong username on them if the user changed their username. One perspective is that we were negligent and caused a bug, but another possible perspective is that maybe the user service team should have caching instead of every other team building their own caching for the user service.
- marsdepinski 5y ago
  They should send a cache-control header in the response or 304 Not-modified when queried with not-modified-since. The calling service should always be the one responsible for caching to save the network round-trip. And if you're going to duplicate data like usernames, get a message channel setup to propagate the changes into the system cloning data.

pankaj021 5y ago

This blog is not on why you should choose microservices, it's just about microservices communication, but let me start with saying I don't agree. I know a couple of friends from startups and they all build software using microservices. I have personally worked in large monoliths for close to 12 years (and last 4/5 years microservices). IMO, the biggest benefit of microservices is agility, you can build and deploy features incrementally and fast. Nowadays with slick frameworks like Spring boot, Nest.js and all the tooling around (like Kubernetes) building microservices is much easier than building monolith. In the monolith world, we had developed a sophisticated, in-house framework for concurrent and distributed task management and I don' see the need for that kind of framework in microservices. In the last 3 years, I had never come across a single developer working on a "cloud-native" microservices project who can confidently answer a single thread question - but developing an auto-scaling application based on the Kubernetes is a piece of cake. How do you expect them to write a well-behaved monolith? It's much easier to quote Sam Newman and Martin fowler, but sorry, I don't find all advice from pundits very practical. From Sam Newman's book "One of the things I see people having the hardest time with is the idea that microservices should avoid the use of shared databases. If a microservice wants to access data held by another microservice, it should go and ask that second microservice for the data. This gives the microservices the ability to decide what is shared and what is hidden, which allows us to clearly separate functionality that can change freely (our internal implementation) from the functionality that we want to change infrequently (the external contract that the consumers use)." How is this practical for each microservices to have its own database? Is it even possible in the cloud world where we consume databases as a service? The bottom line is - nowadays developing microservices is much easier than a monolith. You get lots of tooling - such as observability stack, resiliency out of the box. This just needs to be well supported by organization culture and practices (DevOps, SRE, incident management).