4 ms·

Best use I've found for microservices is highly isolated and well-defined stateless functions which make a significant (read compute intense) change to some dat

Best use I've found for microservices is highly isolated and well-defined stateless functions which make a significant (read compute intense) change to some data and drop it somewhere else e.g. image compression. Now you can use this microservice anywhere and just change a few params in how you call it and you have avatars, thumbnails, etc.

napsterbr 9y ago
So basically a library? :)
- philipkglass 9y ago
  It's like a library that you can call regardless of language ecosystem. I joined a company that had a large, old, and mature selection of services written in PHP. If I'd tried to rewrite that mature code in a different language I probably would have wasted a lot of time for little benefit. If I'd had to write new code in PHP just to access old code as libraries that would have been a problem too. But functionality was exposed over HTTP APIs that could be used from any language, any runtime.
- zerokernel 9y ago
  HTTP-as-an-ABI
- Neeek 9y ago
  Closer to command line tools in systems where you can just pipe output around in to whatever you want.
- crimsonalucard 9y ago
  Well you don't want to call a processor intensive task with a library. A separate service for these types of tasks is a better architecture. Although I'm not sure whether or not a task queue architecture with separate server workers executing code passed over from a central monolithic app server is still considered a "microservice" architecture.
- rtpg 9y ago
  well a library + deploying it into its own space so that it doesn't bring down your main app due to compute time. The operational part of microservices can end up being pretty important in these cases
- draw_down 9y ago
  No?
burlesona 9y ago
Yep, this has been my experience as well. When micro services work well they have a simple and well-defined API that is easy to keep backwards compatible as it evolves, and it tends to be something that evolves quite slowly compared to the primary application codebase. For the posters who said "like a library," yeah that's exactly the idea, but consider if you have an operation that can be done by a library but that has very different scaling characteristics compared to the rest of your system. Eg. you have one highly compute intensive operation while the rest of your system is IO bound. If you can split these apart it's easier to deal with scaling.
jbreckmckye 9y ago
Sounds like a candidate for serverless.

napsterbr 9y ago

So basically a library? :)

philipkglass 9y ago
It's like a library that you can call regardless of language ecosystem. I joined a company that had a large, old, and mature selection of services written in PHP. If I'd tried to rewrite that mature code in a different language I probably would have wasted a lot of time for little benefit. If I'd had to write new code in PHP just to access old code as libraries that would have been a problem too. But functionality was exposed over HTTP APIs that could be used from any language, any runtime.
zerokernel 9y ago
HTTP-as-an-ABI
Neeek 9y ago
Closer to command line tools in systems where you can just pipe output around in to whatever you want.
crimsonalucard 9y ago
Well you don't want to call a processor intensive task with a library. A separate service for these types of tasks is a better architecture. Although I'm not sure whether or not a task queue architecture with separate server workers executing code passed over from a central monolithic app server is still considered a "microservice" architecture.
rtpg 9y ago
well a library + deploying it into its own space so that it doesn't bring down your main app due to compute time. The operational part of microservices can end up being pretty important in these cases
draw_down 9y ago
No?

burlesona 9y ago

Yep, this has been my experience as well. When micro services work well they have a simple and well-defined API that is easy to keep backwards compatible as it evolves, and it tends to be something that evolves quite slowly compared to the primary application codebase. For the posters who said "like a library," yeah that's exactly the idea, but consider if you have an operation that can be done by a library but that has very different scaling characteristics compared to the rest of your system. Eg. you have one highly compute intensive operation while the rest of your system is IO bound. If you can split these apart it's easier to deal with scaling.

jbreckmckye 9y ago

Sounds like a candidate for serverless.