6 ms·

Microservices - let’s replace as many interfaces as possible with the slowest, flakiest, most complex mechanism - the network layer. Why call a function when yo

Microservices - let’s replace as many interfaces as possible with the slowest, flakiest, most complex mechanism - the network layer. Why call a function when you can wrap that function in an entire application and call it via API? Why have a single database when we can silo our data across 200 mini databases? Why have a single repo when we can have 200 tiny repos?

agomez314 4y ago
Microservices solve many problems to those that understand the virtues and deficiencies of it - everyone else is just cargo-culting and committing themselves too much to something they don't understand (see Kubernetes).
bradhe 4y ago
> Microservices - let’s replace as many interfaces as possible with the slowest, flakiest, most complex mechanism - the network layer You do realise that most calls to block storage in AWS result in network traffic, right? The point is, abstraction is your friend.
- naasking 4y ago
  > The point is, abstraction is your friend. Yes, but the point they were making is that you don't have to abstract across a network boundary. A proper module system and package management can divide work and organization without introducing IPC overheads.
- Retric 4y ago
  Latency is additive. You get a small window within which people don’t notice and network calls quickly consume all of it. Micro services have a few advantages but unless you desperately need them it’s a huge hit to performance, productivity, and reliability unless it’s your only option. Netflix needed it because of their complicated network architecture with servers distributed inside various ISP’s, why do you?
- sidlls 4y ago
  Overcomplicated abstraction (e.g., DI frameworks) and unnecessary abstraction are not anyone's friends.
  - Sohcahtoa82 4y ago
    From what I understand, DI simply turns this: public class MyClass { private Dep myDep; void MyClass(){ this.myDep = GetDep(); } } into this: public class MyClass { private Dep myDep; void MyClass(Dep dep){ this.myDep = dep; } } Why this needs an entire framework is beyond me. It feels like all they do is convert explicit code into boilerplate which then becomes much harder to reason about.
    - confidantlake 4y ago
      I think the theory is when you want to change the dep you can do it in a config file instead of in the code. But I totally agree, I don't think the value is worth the cost.
KyeRussell 4y ago
The extremely oversimplified reason backing your apparent hate for microservices makes you about as bad as the people you’re arguing against. The OG proponents of microservices acknowledge that there’s a world of nuance and trade off. You’re really just arguing against the outer most few circles of cargo-culting magpie architects. Someone unfamiliar with the concept of cost and benefit shouldn’t be making architectural decisions in the first place.
ketchupdebugger 4y ago
> Why have a single repo when we can have 200 tiny repos? you could have a monorepo. you just need to build each service independently, which you can do with bazel/gradle/make or other build tools.
samsaga2 4y ago
Scalability and stability. You need to process more requests? Launch more virtual machines, easy. Your microservice is a shit and it crashes every second? Don't care, it will be relaunched automatically.
- esailija 4y ago
  Every single endpoint in a monolith can be deployed and scaled independently. In a single such deployment the rest of the endpoints are just dead code not costing anything except larger image. Also in many cases work should not be performed synchronously in response to http requests but in a background queue to keep your service robust and responsive. When taking a new order you should just place it in some queue and respond ASAP so there is zero chance you miss a customer order because of some error. In that case there is no difference in scaling a monolith or microservice as you can indepedently deploy 25 consumers for module X events or 10 consumers for module Y events and so on.
- nicolaslem 4y ago
  Monoliths can also scale horizontally and be restarted automatically when they fail. No need for microservices for that.
  - thatwasunusual 4y ago
    > Monoliths can also scale horizontally At a (potentially much) bigger cost.
    - speed_spread 4y ago
      Running costs or development costs? If you have a low-request / high complexity persistent application you may want to optimize for maintainability. Having all the code in one place _can_ make things easier to figure out in the long term.
      - 0x445442 4y ago
        Also there’s configuration management costs to consider, which usually ends up being a biggie.
hdjjhhvvhga 4y ago
> Why have a single database when we can silo our data across 200 mini databases? First, many orgs using, say, Kubernetes still run their database separately in a traditional way with replicas etc. Second, those who do run their DB inside Kubernetes, probably using an operator, gain scalability and additional resiliency (it also depends on the DB, but these days even PostgreSQL operator works quite reliably).
- sidlls 4y ago
  A common pattern in microservices architecture is that each service has its own database: that's what the person is referring to.
  - hdjjhhvvhga 4y ago
    Well, I'm of the same opinion as the guy that wrote this short piece in 2018: https://oprearocks.medium.com/blasphemy-multiple-microservices-shared-database-f525025a8a81 https://oprearocks.medium.com/blasphemy-multiple-microservic... Insisting on always having a separate db for each service is not a pattern, it's pure madness.
csomar 4y ago
Cloudflare microservices (aka Worker) don’t inccur an extra network cost when they call one another. Good enough?
throwaway9870 4y ago
So you embed S3 into your app? Do you embed your ERP system? How about your marketing e-mail system? Your CRM? Do you use an in-process database? Everyone already has a service based architecture whether they want to admit it or not. The question is the efficiency and granularity of it. If you interface with any external systems that have data records (ERP, CRM, etc), your database is already spread out. You need to deal with it and be sure you understand the data efficiency and reliability of it. I don't know what a monolith is that people talk about. Please show me one that doesn't talk to anything else.
- JAlexoid 4y ago
  Microservices is not the same, though.
  - throwaway9870 4y ago
    I don't see that distinction being made. The counter argument is things like libraries vs microservices. Those articles ignore the common case that probably is true for 99% of the apps - we live in a service based architecture. The Internet is service based. Everything an app talks to is service based. So quit arguing about it. Microservices don't address any of the issues I ever faced or people on Hacker News talks about like mixing languages, building code around organizational structure, isolating faults, etc. Microservices are way to granular to address those issues well. The only time I ever wrote a microservice is when I had to wrap some stupid SiteMinder binary apache mod blob. Also, almost nobody writes a monolith, if they say they have a monolith they are probably lying. Do they have a database? S3? ERP, CRM, blah blah blah. Nobody in their right mind would build microservices, that is nuts unless they have some really special architecture. So can we quit the endless debates about stuff and instead focus on the real issue: how to build robust and maintainable service architectures? How to partition systems properly so you can manage avoiding having conflicting data? Eventually consistent systems, etc. This is as dumb as the CISC vs RISC debate I lived through in the 90s.
    - JAlexoid 4y ago
      Lucky you, that you haven't been hit by the purists. I am currently getting a hard intro into a microservice first architecture. Where customers are managed in one service, users are managed in a different one, user operations are in a third one. All have their own databases and much of the data is copied between them. There are microservices, that are used by only one other microservice. That's where we are now - arguing about the validity of "microservices are the best/first" approach. Microservices are defined as self contained, highly granular, separately developed and deployed horizontally scalable systems. Think about the debates about Linux vs Hurd, that's where we are.
ericalexander0 4y ago
The move to microservices is often more about scaling change management when an organization grows from tens to hundreds of engineers. Change management becomes the bottleneck when organizations exceed Dunbar's Number, and a "reverse Conway maneuver" is needed to counter excessive cost of coordination. https://cloud.google.com/architecture/devops/devops-tech-architecture https://cloud.google.com/architecture/devops/devops-tech-arc...
- Pamar 4y ago
  "when an organization grows from tens to hundreds of engineers" - point taken. My question then is: is this type of growth the norm, or is it exceptional? If I am, say, Tesla... do I need 1 order of magnitude more sw engineers when I start selling 10 times the cars I was selling 2 years ago?
- candiddevmike 4y ago
  Linux kernel has a huge amount of contributors with their own goals and they seem to coordinate just fine. Monoliths can scale, but they can't be "owned"/leveraged by leaders/sociopaths into a bigger budget/team/etc, IMO.
  - dralley 4y ago
    The linux kernel is more siloed than one might expect, a lot of code is architecture specific or in drivers, which facilitates having a wide group of maintainers.
    - mpweiher 4y ago
      EXACTLY. It shows that you can have a siloed monolith.
  - surajrmal 4y ago
    Linux development is absolutely hampered by being a monolith. Getting involved in Linux development is notoriously difficult. The average developer won't consider it even though there are many parts of the kernel which very much should be approachable. It is also hard to get some patches upstream if the goals of said patches don't align with everyone else's interests. There are even people exploring userspace schedulers to get around these challenges. There are also huge maintenance burdens that come from the lack of stable interfaces for modules. There is a reason there is a lot of excitement around ebpf. It is providing the sort of scaling that people have been needing for a while.
ranting-moth 4y ago
I've seen quite a few people use the argument that their system wouldn't cope otherwise when they reach the size of Google. If you are one of those, then I have news for you. 1. You are not going to reach the size of Google. Certainly not if you are engineering for it in your 2 person startup. But in case you do, see number 2. 2. Reaching Google scale means you'll have funding to hire good people to scale your software.
- foepys 4y ago
  If you plan your architecture carefully and modularize a lot, there is very little that will prevent you from branching out modules of a monolith into microservices when the time comes. If you produce spaghetti code with tightly coupled components, well, then you are going to have a problem.
  - ranting-moth 4y ago
    Especially in small startups, you need to make a sensible balance. If you only have funding for 2 months, you need to hack together whatever you can get away with. This is not against modularisation. By all means designs your system well. But don't lose sight of the goal.
    - foepys 4y ago
      If you bet everything on crappy code you will have to rewrite anyways and then I don't see why this discussion matters.
- deleted 4y ago
  [deleted]
- shapefrog 4y ago
  Reaching Google scale means you'll be sat on a beach wondering how to spend your multiple billions - scale is someone else's problem, might as well leave something in it for the next person.

agomez314 4y ago

Microservices solve many problems to those that understand the virtues and deficiencies of it - everyone else is just cargo-culting and committing themselves too much to something they don't understand (see Kubernetes).

bradhe 4y ago

> Microservices - let’s replace as many interfaces as possible with the slowest, flakiest, most complex mechanism - the network layer You do realise that most calls to block storage in AWS result in network traffic, right? The point is, abstraction is your friend.

naasking 4y ago
> The point is, abstraction is your friend. Yes, but the point they were making is that you don't have to abstract across a network boundary. A proper module system and package management can divide work and organization without introducing IPC overheads.
Retric 4y ago
Latency is additive. You get a small window within which people don’t notice and network calls quickly consume all of it. Micro services have a few advantages but unless you desperately need them it’s a huge hit to performance, productivity, and reliability unless it’s your only option. Netflix needed it because of their complicated network architecture with servers distributed inside various ISP’s, why do you?
sidlls 4y ago
Overcomplicated abstraction (e.g., DI frameworks) and unnecessary abstraction are not anyone's friends.
- Sohcahtoa82 4y ago
  From what I understand, DI simply turns this: public class MyClass { private Dep myDep; void MyClass(){ this.myDep = GetDep(); } } into this: public class MyClass { private Dep myDep; void MyClass(Dep dep){ this.myDep = dep; } } Why this needs an entire framework is beyond me. It feels like all they do is convert explicit code into boilerplate which then becomes much harder to reason about.
  - confidantlake 4y ago
    I think the theory is when you want to change the dep you can do it in a config file instead of in the code. But I totally agree, I don't think the value is worth the cost.

KyeRussell 4y ago

The extremely oversimplified reason backing your apparent hate for microservices makes you about as bad as the people you’re arguing against. The OG proponents of microservices acknowledge that there’s a world of nuance and trade off. You’re really just arguing against the outer most few circles of cargo-culting magpie architects. Someone unfamiliar with the concept of cost and benefit shouldn’t be making architectural decisions in the first place.

ketchupdebugger 4y ago

> Why have a single repo when we can have 200 tiny repos? you could have a monorepo. you just need to build each service independently, which you can do with bazel/gradle/make or other build tools.

samsaga2 4y ago

Scalability and stability. You need to process more requests? Launch more virtual machines, easy. Your microservice is a shit and it crashes every second? Don't care, it will be relaunched automatically.

esailija 4y ago
Every single endpoint in a monolith can be deployed and scaled independently. In a single such deployment the rest of the endpoints are just dead code not costing anything except larger image. Also in many cases work should not be performed synchronously in response to http requests but in a background queue to keep your service robust and responsive. When taking a new order you should just place it in some queue and respond ASAP so there is zero chance you miss a customer order because of some error. In that case there is no difference in scaling a monolith or microservice as you can indepedently deploy 25 consumers for module X events or 10 consumers for module Y events and so on.
nicolaslem 4y ago
Monoliths can also scale horizontally and be restarted automatically when they fail. No need for microservices for that.
- thatwasunusual 4y ago
  > Monoliths can also scale horizontally At a (potentially much) bigger cost.
  - speed_spread 4y ago
    Running costs or development costs? If you have a low-request / high complexity persistent application you may want to optimize for maintainability. Having all the code in one place _can_ make things easier to figure out in the long term.
    - 0x445442 4y ago
      Also there’s configuration management costs to consider, which usually ends up being a biggie.

hdjjhhvvhga 4y ago

> Why have a single database when we can silo our data across 200 mini databases? First, many orgs using, say, Kubernetes still run their database separately in a traditional way with replicas etc. Second, those who do run their DB inside Kubernetes, probably using an operator, gain scalability and additional resiliency (it also depends on the DB, but these days even PostgreSQL operator works quite reliably).

sidlls 4y ago
A common pattern in microservices architecture is that each service has its own database: that's what the person is referring to.
- hdjjhhvvhga 4y ago
  Well, I'm of the same opinion as the guy that wrote this short piece in 2018: https://oprearocks.medium.com/blasphemy-multiple-microservices-shared-database-f525025a8a81 https://oprearocks.medium.com/blasphemy-multiple-microservic... Insisting on always having a separate db for each service is not a pattern, it's pure madness.

csomar 4y ago

Cloudflare microservices (aka Worker) don’t inccur an extra network cost when they call one another. Good enough?

throwaway9870 4y ago

So you embed S3 into your app? Do you embed your ERP system? How about your marketing e-mail system? Your CRM? Do you use an in-process database? Everyone already has a service based architecture whether they want to admit it or not. The question is the efficiency and granularity of it. If you interface with any external systems that have data records (ERP, CRM, etc), your database is already spread out. You need to deal with it and be sure you understand the data efficiency and reliability of it. I don't know what a monolith is that people talk about. Please show me one that doesn't talk to anything else.

JAlexoid 4y ago
Microservices is not the same, though.
- throwaway9870 4y ago
  I don't see that distinction being made. The counter argument is things like libraries vs microservices. Those articles ignore the common case that probably is true for 99% of the apps - we live in a service based architecture. The Internet is service based. Everything an app talks to is service based. So quit arguing about it. Microservices don't address any of the issues I ever faced or people on Hacker News talks about like mixing languages, building code around organizational structure, isolating faults, etc. Microservices are way to granular to address those issues well. The only time I ever wrote a microservice is when I had to wrap some stupid SiteMinder binary apache mod blob. Also, almost nobody writes a monolith, if they say they have a monolith they are probably lying. Do they have a database? S3? ERP, CRM, blah blah blah. Nobody in their right mind would build microservices, that is nuts unless they have some really special architecture. So can we quit the endless debates about stuff and instead focus on the real issue: how to build robust and maintainable service architectures? How to partition systems properly so you can manage avoiding having conflicting data? Eventually consistent systems, etc. This is as dumb as the CISC vs RISC debate I lived through in the 90s.
  - JAlexoid 4y ago
    Lucky you, that you haven't been hit by the purists. I am currently getting a hard intro into a microservice first architecture. Where customers are managed in one service, users are managed in a different one, user operations are in a third one. All have their own databases and much of the data is copied between them. There are microservices, that are used by only one other microservice. That's where we are now - arguing about the validity of "microservices are the best/first" approach. Microservices are defined as self contained, highly granular, separately developed and deployed horizontally scalable systems. Think about the debates about Linux vs Hurd, that's where we are.

ericalexander0 4y ago

The move to microservices is often more about scaling change management when an organization grows from tens to hundreds of engineers. Change management becomes the bottleneck when organizations exceed Dunbar's Number, and a "reverse Conway maneuver" is needed to counter excessive cost of coordination. https://cloud.google.com/architecture/devops/devops-tech-architecture https://cloud.google.com/architecture/devops/devops-tech-arc...

Pamar 4y ago
"when an organization grows from tens to hundreds of engineers" - point taken. My question then is: is this type of growth the norm, or is it exceptional? If I am, say, Tesla... do I need 1 order of magnitude more sw engineers when I start selling 10 times the cars I was selling 2 years ago?
candiddevmike 4y ago
Linux kernel has a huge amount of contributors with their own goals and they seem to coordinate just fine. Monoliths can scale, but they can't be "owned"/leveraged by leaders/sociopaths into a bigger budget/team/etc, IMO.
- dralley 4y ago
  The linux kernel is more siloed than one might expect, a lot of code is architecture specific or in drivers, which facilitates having a wide group of maintainers.
  - mpweiher 4y ago
    EXACTLY. It shows that you can have a siloed monolith.
- surajrmal 4y ago
  Linux development is absolutely hampered by being a monolith. Getting involved in Linux development is notoriously difficult. The average developer won't consider it even though there are many parts of the kernel which very much should be approachable. It is also hard to get some patches upstream if the goals of said patches don't align with everyone else's interests. There are even people exploring userspace schedulers to get around these challenges. There are also huge maintenance burdens that come from the lack of stable interfaces for modules. There is a reason there is a lot of excitement around ebpf. It is providing the sort of scaling that people have been needing for a while.

ranting-moth 4y ago

I've seen quite a few people use the argument that their system wouldn't cope otherwise when they reach the size of Google. If you are one of those, then I have news for you. 1. You are not going to reach the size of Google. Certainly not if you are engineering for it in your 2 person startup. But in case you do, see number 2. 2. Reaching Google scale means you'll have funding to hire good people to scale your software.

foepys 4y ago
If you plan your architecture carefully and modularize a lot, there is very little that will prevent you from branching out modules of a monolith into microservices when the time comes. If you produce spaghetti code with tightly coupled components, well, then you are going to have a problem.
- ranting-moth 4y ago
  Especially in small startups, you need to make a sensible balance. If you only have funding for 2 months, you need to hack together whatever you can get away with. This is not against modularisation. By all means designs your system well. But don't lose sight of the goal.
  - foepys 4y ago
    If you bet everything on crappy code you will have to rewrite anyways and then I don't see why this discussion matters.
deleted 4y ago
[deleted]
shapefrog 4y ago
Reaching Google scale means you'll be sat on a beach wondering how to spend your multiple billions - scale is someone else's problem, might as well leave something in it for the next person.