6 ms·

I believe, for small shops, the real benefit of microservices is the logic split that forces good design and reduces cognitive load. You reap the scaling benef

I believe, for small shops, the real benefit of microservices is the logic split that forces good design and reduces cognitive load. You reap the scaling benefits way later, if ever.

serge2k 10y ago
> forces good design and reduces cognitive load Except splitting into microservices is an unnecessarily complex design choice. That's almost always worse, and the cognitive load comes in when you now need to figure out how to get this stuff right. The scaling benefits also require that you get it right, small flaws in your system become massive issues.
- rhizome 10y ago
  "Is your bicycle too slow? Get a helicopter!"
kornish 10y ago
Definitely agree – the polyglot aspect can also be useful for companies where different parts of their problem fit different tools. However, exercising proper software discipline and using languages with good/existent module systems, like OCaml or Go, can lead to the same modular results without the fixed overhead. If you don't have a full-time ops person or team, you almost always have no business running microservices.
nostrademons 10y ago
You can get that benefit by dividing your system up into libraries with defined, documented, tested APIs. There's no need to introduce all the complexity and failure modes of distributed systems just to force good design. When you need to scale, then you can easily throw your libraries behind an RPC framework and call it microservices, but there's no need to pay that cost until you actually face that problem.
- tunesmith 10y ago
  One caveat is that if you need to fix a bug in your library in an API-compatible way, you can't reach into all the codebases that are using your library. You can deploy a new version of the microservice, though.
  - kornish 10y ago
    I mean, you _can_ if you organize your code such that you can. For example, Google's monorepo lets maintainers of a library find all internal usages and fix them. This is one of the benefits Dan Luu notes in http://danluu.com/monorepo/ http://danluu.com/monorepo/.
    - nostrademons 10y ago
      I think he means that you can't force all teams that use your library to recompile and pickup the updated code, while if you deploy it as a service, you recompile and redeploy and everyone talking to your service gets the most up-to-date version. This is a real problem - I recall that Sanjay Ghemawat et al was working on it when I left Google, though I dunno if the solution they came up with is public yet. It's unlikely to seriously affect you unless you're Google-scale, though, by which time you've probably divided everything up into services and aren't taking advice from the Internet anyway. For companies that are a few teams working on a single product, it's easy enough to send a company-wide e-mail saying "Rebuild & redeploy anything that depends upon library X", and if you're doing continuous deployment or deploy only as a single artifact, the problem never affects you anyway.
      - eropple 10y ago
        > I think he means that you can't force all teams that use your library to recompile and pickup the updated code Does your CI system not automatically build dependent artifacts-- > It's unlikely to seriously affect you unless you're Google-scale, though --okay, whew. ;)
      - crooked-v 10y ago
the_gastropod 10y ago
Nothing about splitting your app into microservices _forces_ a good design. I've never seen microservices with well-defined seams. Every time, knowledge "leaked" between the apps, and any non-trivial change to the app required updating multiple repos, deployment synchronization, etc. Microservices are a tremendous burden that the vast majority of companies will not benefit from.
- FatalBaboon 10y ago
  I did not mean microservice as in "just make it many apps!". I meant as do not share databases and expose everything as APIs. It helps cognitive load because such apps can be reasoned about without reading code elsewhere.
  - AstralStorm 10y ago
    API is not enough, full contract has to be shared.
ajmurmann 10y ago
If you separate components wrong in the same code base is an easy fix. If you get them wrong between services you have s much larger problem. I'm not sure why you'd be more likely to get that right with services than within the same code base.
endgame 10y ago
I think this is actually a failure in mainstream programming languages, which make it far too easy to reach across what's meant to be a defined subsystem boundary and meddle where you shouldn't.
- AstralStorm 10y ago
  They also have to weak tools to automate enforcing contracts. Generally the only available tool is "assert".
manigandham 10y ago
"Logic" is vague and there a several layers you can implement this before even thinking about microservices. It can be as simple as a simple class, or maybe a larger class as a single-file service, or an entire namespace with a several classes, or a separate library easily referenced. All the "logic" split benefits without the ridiculous hassle of microservices.

I believe, for small shops, the real benefit of microservices is the logic split that forces good design and reduces cognitive load. You reap the scaling benefits way later, if ever.

serge2k 10y ago

> forces good design and reduces cognitive load Except splitting into microservices is an unnecessarily complex design choice. That's almost always worse, and the cognitive load comes in when you now need to figure out how to get this stuff right. The scaling benefits also require that you get it right, small flaws in your system become massive issues.

rhizome 10y ago
"Is your bicycle too slow? Get a helicopter!"

kornish 10y ago

Definitely agree – the polyglot aspect can also be useful for companies where different parts of their problem fit different tools. However, exercising proper software discipline and using languages with good/existent module systems, like OCaml or Go, can lead to the same modular results without the fixed overhead. If you don't have a full-time ops person or team, you almost always have no business running microservices.

nostrademons 10y ago

You can get that benefit by dividing your system up into libraries with defined, documented, tested APIs. There's no need to introduce all the complexity and failure modes of distributed systems just to force good design. When you need to scale, then you can easily throw your libraries behind an RPC framework and call it microservices, but there's no need to pay that cost until you actually face that problem.

tunesmith 10y ago
One caveat is that if you need to fix a bug in your library in an API-compatible way, you can't reach into all the codebases that are using your library. You can deploy a new version of the microservice, though.
- kornish 10y ago
  I mean, you _can_ if you organize your code such that you can. For example, Google's monorepo lets maintainers of a library find all internal usages and fix them. This is one of the benefits Dan Luu notes in http://danluu.com/monorepo/ http://danluu.com/monorepo/.
  - nostrademons 10y ago
    I think he means that you can't force all teams that use your library to recompile and pickup the updated code, while if you deploy it as a service, you recompile and redeploy and everyone talking to your service gets the most up-to-date version. This is a real problem - I recall that Sanjay Ghemawat et al was working on it when I left Google, though I dunno if the solution they came up with is public yet. It's unlikely to seriously affect you unless you're Google-scale, though, by which time you've probably divided everything up into services and aren't taking advice from the Internet anyway. For companies that are a few teams working on a single product, it's easy enough to send a company-wide e-mail saying "Rebuild & redeploy anything that depends upon library X", and if you're doing continuous deployment or deploy only as a single artifact, the problem never affects you anyway.
    - eropple 10y ago
      > I think he means that you can't force all teams that use your library to recompile and pickup the updated code Does your CI system not automatically build dependent artifacts-- > It's unlikely to seriously affect you unless you're Google-scale, though --okay, whew. ;)
    - crooked-v 10y ago

the_gastropod 10y ago

Nothing about splitting your app into microservices _forces_ a good design. I've never seen microservices with well-defined seams. Every time, knowledge "leaked" between the apps, and any non-trivial change to the app required updating multiple repos, deployment synchronization, etc. Microservices are a tremendous burden that the vast majority of companies will not benefit from.

FatalBaboon 10y ago
I did not mean microservice as in "just make it many apps!". I meant as do not share databases and expose everything as APIs. It helps cognitive load because such apps can be reasoned about without reading code elsewhere.
- AstralStorm 10y ago
  API is not enough, full contract has to be shared.

ajmurmann 10y ago

If you separate components wrong in the same code base is an easy fix. If you get them wrong between services you have s much larger problem. I'm not sure why you'd be more likely to get that right with services than within the same code base.

endgame 10y ago

I think this is actually a failure in mainstream programming languages, which make it far too easy to reach across what's meant to be a defined subsystem boundary and meddle where you shouldn't.

AstralStorm 10y ago
They also have to weak tools to automate enforcing contracts. Generally the only available tool is "assert".

manigandham 10y ago

"Logic" is vague and there a several layers you can implement this before even thinking about microservices. It can be as simple as a simple class, or maybe a larger class as a single-file service, or an entire namespace with a several classes, or a separate library easily referenced. All the "logic" split benefits without the ridiculous hassle of microservices.