7 ms·

I don’t think anyone is claiming that microservices are inherently faster. Instead it is a strategy to keep software loosely coupled and enable very large syste

I don’t think anyone is claiming that microservices are inherently faster. Instead it is a strategy to keep software loosely coupled and enable very large systems to be built by parallel teams while maintaining productivity and quality both technically and organisationally. That said, I’m a strong proponent of monolithic architectures until scale becomes a problem.

klodolph 6y ago
It’s also a strategy to isolate failures and to use resources efficiently. I’ve had a very positive experience working on a team that deployed a collection of microservices. That said, it was large scale, and most of the “micro” services were only conceptually micro; they were large in terms of resource usage. We also had excellent tooling.
- josephg 6y ago
  There are strategies other than microservices to break a problem up into small pieces, manage resources and isolate failures. I've consistently heard good things about Erlang/OTP.
  - klodolph 6y ago
    Not resource management. Resource efficiency. If you have a monolith, you have less control over the service’s shape—the CPU, RAM, IO footprints. If you break it up into smaller microservices, the footprints are smaller and you have more options for how you schedule them. There is a tradeoff here—services that are too small have high overhead. Services that are too large are inefficiently scheduled. Services that are way too large force you to spend money buying the massive machines needed to run them.
    - jandrewrogers 6y ago
      This assertion is making a lot of unwarranted assumptions about the software architecture of a monolith. You can have a monolith and total control over the resources at the scale of an entire machine. This can be extraordinarily resource efficient in a way microservices never are, and is often the default case when designing systems like databases or data infrastructure. A monolith easily achieves 10x throughput of what microservices will do on the same hardware. Which is why people build monoliths, they can be extremely efficient. Microservices are usually about trading resource efficiency for organizational convenience.
      - klodolph 6y ago
        It’s “a possible strategy”, and whether the strategy is appropriate depends on the particulars of your service. > A monolith easily achieves 10x throughput of what microservices will do on the same hardware. If we’re gonna talk about unwarranted assumptions, this one takes the cake. I’ve seen services spun up where the resources to run them simply didn’t exist in our data centers. As monoliths, their throughput was effectively zero. The cost tradeoff was “buy bigger servers and wait until they arrive” versus “spend engineering resources and stop buying bigger servers.” Again—this is going to depend on the particulars. The better answer is not necessarily obvious.
  - jacquesm 6y ago
    Erlang/OTP is as close to a formalized microservice architecture as you can get. And in my opinion also the only one that gets it right.
  - orclev 6y ago
    It's because Erlang abstracts the difference between distributed and centralized services. In Erlang everything is message passing, and Erlang doesn't much care if the components passing messages are running on the same server or multiple ones in a DC, it will route the messages either way. In many ways Erlang is the ultimate micro-service, to the point where the entire language is built around it.
- klingon78 6y ago
  You don’t have to have microservices in the end result, but you could develop and test them as microservices, then have them automatically rewritten into a monolith, perhaps with a subset of their functionality, if that would fit better. Similarly, you could do TDD on a high percentage of the code by using injection, then automatically rewrite the code into static methods, as Atwood was saying they needed for performance, if that’s what would help. Code generation, etc. got a bad name over the years as people tended to use it to balloon the eventual source, like that of many autogenerated config files today, but it can be used to do almost anything.
thesimon 6y ago
A quite good strategy I've found is moving one bounded context (from domain-driven design) into one microservice. You don't end up with lots of network calls for one use case and still have good maintainability.
- blowski 6y ago
  I think, theoretically, that's close to what you're "supposed to do". The problem is genuinely identifying and limiting those bounded contexts in such a way that business and technology sticks to consistently.

klodolph 6y ago

It’s also a strategy to isolate failures and to use resources efficiently. I’ve had a very positive experience working on a team that deployed a collection of microservices. That said, it was large scale, and most of the “micro” services were only conceptually micro; they were large in terms of resource usage. We also had excellent tooling.

josephg 6y ago
There are strategies other than microservices to break a problem up into small pieces, manage resources and isolate failures. I've consistently heard good things about Erlang/OTP.
- klodolph 6y ago
  Not resource management. Resource efficiency. If you have a monolith, you have less control over the service’s shape—the CPU, RAM, IO footprints. If you break it up into smaller microservices, the footprints are smaller and you have more options for how you schedule them. There is a tradeoff here—services that are too small have high overhead. Services that are too large are inefficiently scheduled. Services that are way too large force you to spend money buying the massive machines needed to run them.
  - jandrewrogers 6y ago
    This assertion is making a lot of unwarranted assumptions about the software architecture of a monolith. You can have a monolith and total control over the resources at the scale of an entire machine. This can be extraordinarily resource efficient in a way microservices never are, and is often the default case when designing systems like databases or data infrastructure. A monolith easily achieves 10x throughput of what microservices will do on the same hardware. Which is why people build monoliths, they can be extremely efficient. Microservices are usually about trading resource efficiency for organizational convenience.
    - klodolph 6y ago
      It’s “a possible strategy”, and whether the strategy is appropriate depends on the particulars of your service. > A monolith easily achieves 10x throughput of what microservices will do on the same hardware. If we’re gonna talk about unwarranted assumptions, this one takes the cake. I’ve seen services spun up where the resources to run them simply didn’t exist in our data centers. As monoliths, their throughput was effectively zero. The cost tradeoff was “buy bigger servers and wait until they arrive” versus “spend engineering resources and stop buying bigger servers.” Again—this is going to depend on the particulars. The better answer is not necessarily obvious.
- jacquesm 6y ago
  Erlang/OTP is as close to a formalized microservice architecture as you can get. And in my opinion also the only one that gets it right.
- orclev 6y ago
  It's because Erlang abstracts the difference between distributed and centralized services. In Erlang everything is message passing, and Erlang doesn't much care if the components passing messages are running on the same server or multiple ones in a DC, it will route the messages either way. In many ways Erlang is the ultimate micro-service, to the point where the entire language is built around it.
klingon78 6y ago
You don’t have to have microservices in the end result, but you could develop and test them as microservices, then have them automatically rewritten into a monolith, perhaps with a subset of their functionality, if that would fit better. Similarly, you could do TDD on a high percentage of the code by using injection, then automatically rewrite the code into static methods, as Atwood was saying they needed for performance, if that’s what would help. Code generation, etc. got a bad name over the years as people tended to use it to balloon the eventual source, like that of many autogenerated config files today, but it can be used to do almost anything.

thesimon 6y ago

A quite good strategy I've found is moving one bounded context (from domain-driven design) into one microservice. You don't end up with lots of network calls for one use case and still have good maintainability.

blowski 6y ago
I think, theoretically, that's close to what you're "supposed to do". The problem is genuinely identifying and limiting those bounded contexts in such a way that business and technology sticks to consistently.