4 ms·

Unless you have Netflix scale, or Netflix scale problems, why bother with micro-services? Most mid-scale problems don't demand a micro-services solution, with

by kayo_20211030 9mo ago

Unless you have Netflix scale, or Netflix scale problems, why bother with micro-services? Most mid-scale problems don't demand a micro-services solution, with data ownership, delineation of service responsibilities, etc. Monoliths with single-truth databases work just fine. Micro-services are an organizational convenience, and not a technology response to complexity. It's easier to manage groups of people than it is to manage complex technology. That's fine if you need it. Normally, it's not. If it works for you, sure, go ahead. If it doesn't, don't chase a topical orthodoxy.

MrDarcy 9mo ago
The ecosystem. Micro services are the most efficient way to integrate CNCF projects deeply with your platform at any size. Edit: Genuinely curious about the downvotes here. The concept directly maps to all the reasons the article author cited.
- 12_throw_away 9mo ago
  Hmm. Could you maybe elaborate on why integrating "CNCF projects deeply with your platform at any size" is so desirable?
- kayo_20211030 9mo ago
  I'm not following. What does CNCF have to do with it?
  - MrDarcy 9mo ago
    https://landscape.cncf.io/ https://landscape.cncf.io/ are micro services
- pjc50 9mo ago
  The French railway service?
IshKebab 9mo ago
The only reasons I've seen to use microservices: * It makes it easier to use multiple different languages. * You can easily scale different parts of your application independently. * Organisational convenience. Usually though you don't need any of that.
- teraflop 9mo ago
  > You can easily scale different parts of your application independently. Just to add that I think some people assume this is something they need, even when there's no basis for it. Do you actually need 1 instance that handles Foo-type requests, and 99 instances that handle Bar-type requests, or would you be fine with 100 instances that are capable of handling either Foo or Bar as necessary? The distinction only really matters if there is some significant fixed overhead associated with being available to serve Foo requests, such that running an extra 99 of those processes has a cost, regardless of how much traffic they serve. For instance, if every Foo server needs GBs of static data to be held in RAM, or needs to be part of a Paxos group, or something like that. But if your services are stateless, then you probably don't benefit at all from scaling them independently.
  - dilyevsky 9mo ago
    > But if your services are stateless, then you probably don't benefit at all from scaling them independently. Quite easy to run into hardware, OS or especially language runtime (looking at you Ruby, Python) limitations when pushing even moderately high traffic even for totally stateless applications
    - teraflop 9mo ago
      I don't really understand what you mean by this or how it relates to what I said. I certainly wasn't suggesting that you can vertically scale a service to handle unlimited traffic on a single instance. The point is that if you have stateless services, where the resources being consumed per request are mainly CPU and network bandwidth, then "scaling independently" is not a useful thing to do. You can just scale everything instead of artificially restricting which instances can handle which kinds of requests.
weitendorf 9mo ago
1. Principle of least privilege is very important if you are interacting with a large-ish number of third party APIs. It's not just about data ownership (ie one service per db) or even limiting blast radius (most likely you won't get hacked either way), it's eliminating a single point of failure that makes you a more attractive/risky target in case of a hack either directly on your infrastructure, or through a member of your team, or improperly wielding automation. 2. Having at least some level of ability ro run heterogenous workloads in your production environment (ie being able to flip a switch and do microservices if you decide to) is very useful if you need to do more complicated migrations or integrate OSS/vendor software/whip up a demo on short notice. Because oftentimes you may not want to "do microservices" ideologically or as a focal point for development, but you can easily end up in a situation where you want "a microservice", and there can be an unnecessarily large number of obstacles to doing that if you've built all your tooling and ops around the assumption of "never microservices" 3. If you're working with open source software products and infra a lot it's just way easier to eg launch a stalwart container to do email hosting than to figure out how to implement email hosting in your existing db and monolith. Also see above, if you find a good OSS project to help you do something much faster or more effectively, it's good for it to be easy to put it in prod. 4. Claude Code and less experienced or skilled developers don't understand separation of concerns. Now that agentic development is picking up, even orgs that didn't need the organizational convenience before may find themselves needing it now. Personally, this has been a major consideration in how I structure new projects once I became aware of the problem.
- CuriouslyC 9mo ago
  The architecture I like is either modular monoliths, or if you really need isolation, a FaaS setup with a single shared function library, so you're not calling from one function service to another but just composing code into a single endpoint that does exactly what you need. HTTP RPC is the devil.
  - weitendorf 9mo ago
    I generally agree although I think gRPC and using it with json is awesome, it's just that like with most of these tools, the investment in setup/tooling/integrating them into your work has to be worth what you get out of them. I actually used to do FaaS at GCP and now through my startup am working on a few projects for cloud services, tooling around them, and composable/linkable FaaS if you're interested! A lot of this logic isn't in our public repos yet but hit me up if you want a try fully automated Golang->proto+gRPC/http+openapi+ts bindings+client generation+linker-based-builds. A project we started for "modular monoliths" that need local state but not super high availability as databases is at https://github.com/accretional/collector https://github.com/accretional/collector, but I had to put it on pause for the past few weeks to work on other stuff and figure out a better way to scale it. Basically it's a proto ORM based on sqlite that auto configures a bunch of CRUD/search and management endpoints for each "Collection", and via a CollectionRepo additional Collections can be created at runtime. The main thing I invested time into was backups/cloning these sqlite dbs since that's what allows you to scale up and down more flexibly than a typical db and not worry as much about availability or misconfiguration.
zmmmmm 9mo ago
well, that is the entire point of the article, literally the first sentence asks this question. If you're going to bring it up, maybe start from what the article says as your answer and go from there.

MrDarcy 9mo ago

The ecosystem. Micro services are the most efficient way to integrate CNCF projects deeply with your platform at any size. Edit: Genuinely curious about the downvotes here. The concept directly maps to all the reasons the article author cited.

12_throw_away 9mo ago
Hmm. Could you maybe elaborate on why integrating "CNCF projects deeply with your platform at any size" is so desirable?
kayo_20211030 9mo ago
I'm not following. What does CNCF have to do with it?
- MrDarcy 9mo ago
  https://landscape.cncf.io/ https://landscape.cncf.io/ are micro services
pjc50 9mo ago
The French railway service?

IshKebab 9mo ago

The only reasons I've seen to use microservices: * It makes it easier to use multiple different languages. * You can easily scale different parts of your application independently. * Organisational convenience. Usually though you don't need any of that.

teraflop 9mo ago
> You can easily scale different parts of your application independently. Just to add that I think some people assume this is something they need, even when there's no basis for it. Do you actually need 1 instance that handles Foo-type requests, and 99 instances that handle Bar-type requests, or would you be fine with 100 instances that are capable of handling either Foo or Bar as necessary? The distinction only really matters if there is some significant fixed overhead associated with being available to serve Foo requests, such that running an extra 99 of those processes has a cost, regardless of how much traffic they serve. For instance, if every Foo server needs GBs of static data to be held in RAM, or needs to be part of a Paxos group, or something like that. But if your services are stateless, then you probably don't benefit at all from scaling them independently.
- dilyevsky 9mo ago
  > But if your services are stateless, then you probably don't benefit at all from scaling them independently. Quite easy to run into hardware, OS or especially language runtime (looking at you Ruby, Python) limitations when pushing even moderately high traffic even for totally stateless applications
  - teraflop 9mo ago
    I don't really understand what you mean by this or how it relates to what I said. I certainly wasn't suggesting that you can vertically scale a service to handle unlimited traffic on a single instance. The point is that if you have stateless services, where the resources being consumed per request are mainly CPU and network bandwidth, then "scaling independently" is not a useful thing to do. You can just scale everything instead of artificially restricting which instances can handle which kinds of requests.

weitendorf 9mo ago

1. Principle of least privilege is very important if you are interacting with a large-ish number of third party APIs. It's not just about data ownership (ie one service per db) or even limiting blast radius (most likely you won't get hacked either way), it's eliminating a single point of failure that makes you a more attractive/risky target in case of a hack either directly on your infrastructure, or through a member of your team, or improperly wielding automation. 2. Having at least some level of ability ro run heterogenous workloads in your production environment (ie being able to flip a switch and do microservices if you decide to) is very useful if you need to do more complicated migrations or integrate OSS/vendor software/whip up a demo on short notice. Because oftentimes you may not want to "do microservices" ideologically or as a focal point for development, but you can easily end up in a situation where you want "a microservice", and there can be an unnecessarily large number of obstacles to doing that if you've built all your tooling and ops around the assumption of "never microservices" 3. If you're working with open source software products and infra a lot it's just way easier to eg launch a stalwart container to do email hosting than to figure out how to implement email hosting in your existing db and monolith. Also see above, if you find a good OSS project to help you do something much faster or more effectively, it's good for it to be easy to put it in prod. 4. Claude Code and less experienced or skilled developers don't understand separation of concerns. Now that agentic development is picking up, even orgs that didn't need the organizational convenience before may find themselves needing it now. Personally, this has been a major consideration in how I structure new projects once I became aware of the problem.

CuriouslyC 9mo ago
The architecture I like is either modular monoliths, or if you really need isolation, a FaaS setup with a single shared function library, so you're not calling from one function service to another but just composing code into a single endpoint that does exactly what you need. HTTP RPC is the devil.
- weitendorf 9mo ago
  I generally agree although I think gRPC and using it with json is awesome, it's just that like with most of these tools, the investment in setup/tooling/integrating them into your work has to be worth what you get out of them. I actually used to do FaaS at GCP and now through my startup am working on a few projects for cloud services, tooling around them, and composable/linkable FaaS if you're interested! A lot of this logic isn't in our public repos yet but hit me up if you want a try fully automated Golang->proto+gRPC/http+openapi+ts bindings+client generation+linker-based-builds. A project we started for "modular monoliths" that need local state but not super high availability as databases is at https://github.com/accretional/collector https://github.com/accretional/collector, but I had to put it on pause for the past few weeks to work on other stuff and figure out a better way to scale it. Basically it's a proto ORM based on sqlite that auto configures a bunch of CRUD/search and management endpoints for each "Collection", and via a CollectionRepo additional Collections can be created at runtime. The main thing I invested time into was backups/cloning these sqlite dbs since that's what allows you to scale up and down more flexibly than a typical db and not worry as much about availability or misconfiguration.

zmmmmm 9mo ago

well, that is the entire point of the article, literally the first sentence asks this question. If you're going to bring it up, maybe start from what the article says as your answer and go from there.