4 ms·

Being a new "convert" to microservices, and coming from a classic OOA/D/P background, I read these critiques with great interest. I keep waiting for one that sh

Being a new "convert" to microservices, and coming from a classic OOA/D/P background, I read these critiques with great interest. I keep waiting for one that shows me what I'm missing. What I'm finding, however, is that many of these authors have such a broad understanding of microservices are that they miss any benefit. Then, of course, they complain about there not being any benefit, natch. I suspect -- and what I have feared -- is that the term "microservices" has been co-opted and rebranded by a variety of vendors and proponents. The goal here is to sell products and services, not necessarily solve problems. There is certainly a huge wheel of hype in the technology world, where things become cool, then old hat, then abused, then nobody does them anymore, then they return under a new buzzword. Having said that, in the future I'm going to always make a point of defining exactly what I mean instead of just using the term "microservice". My current definition is something like this: - Pure FP - Unix Philosophy - Each microservice has less than 150LOC - Common code, types, and persistence functions are moved to shared libraries to reduce interop concerns Not sure if this makes a difference in the discussion, but I know that it will help me keep straight whether various authors actually have quibbles with microservices -- or are just re-applying their pre-existing OO thinking to a place where it doesn't necessarily map so well.

Thaxll 11y ago
"- Each microservice has less than 150LOC" Sounds like a nightmare, you know how much instances / vms you need if you spawn one thing for 150LOC?
- DanielBMarkham 11y ago
  Nobody said anything about 1 VM per microservice. You're using the term "service" in a way I did not intend (and which is a carryover from other kinds of services) This is illustrative of the point I was making. One of the big benefits of microservices is the total decoupling of the code from the underlying hardware. Things are glued together by Ops, not by code. So you might have all the microservices in one VM -- or spread copies of one critical microservice across a thousand vms. It's all configurable.
  - Thaxll 11y ago
    I don't understand properly the term micro service if services aren't separated in a "network" way.
    - bobjob 11y ago
      You have an entire A-Class network(127.0.0.0) within a single VM. That makes ~2^24 possible adresses and 2^16 ports. Isn't that enough of a network?
      - Thaxll 11y ago
        it's more like "Why would you put multiple process on the same instance instead of just using a monolith app, the overhead for IPC / network isn't worth it if you put every process on the same machine"
    - oldmanjay 11y ago
      The abstract notion of a service has nothing to do with an execution model. It simply means a well defined interface to some meaningful unit of functionality. Properly designed, the execution model is orthogonal and the service itself doesn't care if it's invoked in-process or not. It delegates that to some other manager, which probably has a service interface of its own. It's about sane abstract system boundaries, not mapping to real world facilities.
vskarine 11y ago
don't you think 150LOC is a bit extreme on the low side? I don't see how this is possible unless you compose services out of other services... and in that case it's probably a nightmare to debug anything. Can you elaborate a bit on types of things that this worked great for you?
- DanielBMarkham 11y ago
  I can't walk through a solution to a complex domain inside of a HN comment, but I can provide an overview of the theory. Take a large monolithic app or framework. What I've found is that if a problem is properly coded, while you may have tens or hundreds of thousands of LOC, the actual code doing the work is quite small, on the order of hundreds or thousands of LOC. The rest of it is all "wiring". Moving to pure FP means that a lot of the code structure of OOP disappears and you're left with just the critical pieces. This consists of composed functions performing translations on immutable chunks of data. Your functions become microservices and the composition of functions, scheduling, and moving around of data become Net/Dev Ops. There are many ways to fall off the path here. You start using mutable data, you start associating services with business domains, you start coupling microservices together more tightly than necessary -- there's a ton of ways you can accidentally screw up, and then you're probably better off with a monolithic app. Microservices should be like ls, cat, or chmod -- small pieces of composable functions that run directly in the O/S. They don't blow up the system when they fail, they do one thing and only one thing, they're configurable using command-line switches, they're transport-independent, and so on.
  - emilyst 11y ago
    From GNU coreutils: $ wc -l src/ls.c 4980 src/ls.c $ wc -l src/cat.c 768 src/cat.c $ wc -l src/chmod.c 570 src/chmod.c
    - codahale 11y ago
      Obviously, those are monoliths in dire need of decomposition.
  - 11y ago
cpitman 11y ago
Do you subscribe to the idea that services should correspond to "bounded contexts", ie a business domain? And if so, what do you do when a bounded context is too complex to fit into 150LOC?

Thaxll 11y ago

"- Each microservice has less than 150LOC" Sounds like a nightmare, you know how much instances / vms you need if you spawn one thing for 150LOC?

DanielBMarkham 11y ago
Nobody said anything about 1 VM per microservice. You're using the term "service" in a way I did not intend (and which is a carryover from other kinds of services) This is illustrative of the point I was making. One of the big benefits of microservices is the total decoupling of the code from the underlying hardware. Things are glued together by Ops, not by code. So you might have all the microservices in one VM -- or spread copies of one critical microservice across a thousand vms. It's all configurable.
- Thaxll 11y ago
  I don't understand properly the term micro service if services aren't separated in a "network" way.
  - bobjob 11y ago
    You have an entire A-Class network(127.0.0.0) within a single VM. That makes ~2^24 possible adresses and 2^16 ports. Isn't that enough of a network?
    - Thaxll 11y ago
      it's more like "Why would you put multiple process on the same instance instead of just using a monolith app, the overhead for IPC / network isn't worth it if you put every process on the same machine"
  - oldmanjay 11y ago
    The abstract notion of a service has nothing to do with an execution model. It simply means a well defined interface to some meaningful unit of functionality. Properly designed, the execution model is orthogonal and the service itself doesn't care if it's invoked in-process or not. It delegates that to some other manager, which probably has a service interface of its own. It's about sane abstract system boundaries, not mapping to real world facilities.

vskarine 11y ago

don't you think 150LOC is a bit extreme on the low side? I don't see how this is possible unless you compose services out of other services... and in that case it's probably a nightmare to debug anything. Can you elaborate a bit on types of things that this worked great for you?

DanielBMarkham 11y ago
I can't walk through a solution to a complex domain inside of a HN comment, but I can provide an overview of the theory. Take a large monolithic app or framework. What I've found is that if a problem is properly coded, while you may have tens or hundreds of thousands of LOC, the actual code doing the work is quite small, on the order of hundreds or thousands of LOC. The rest of it is all "wiring". Moving to pure FP means that a lot of the code structure of OOP disappears and you're left with just the critical pieces. This consists of composed functions performing translations on immutable chunks of data. Your functions become microservices and the composition of functions, scheduling, and moving around of data become Net/Dev Ops. There are many ways to fall off the path here. You start using mutable data, you start associating services with business domains, you start coupling microservices together more tightly than necessary -- there's a ton of ways you can accidentally screw up, and then you're probably better off with a monolithic app. Microservices should be like ls, cat, or chmod -- small pieces of composable functions that run directly in the O/S. They don't blow up the system when they fail, they do one thing and only one thing, they're configurable using command-line switches, they're transport-independent, and so on.
- emilyst 11y ago
  From GNU coreutils: $ wc -l src/ls.c 4980 src/ls.c $ wc -l src/cat.c 768 src/cat.c $ wc -l src/chmod.c 570 src/chmod.c
  - codahale 11y ago
    Obviously, those are monoliths in dire need of decomposition.
- 11y ago

cpitman 11y ago

Do you subscribe to the idea that services should correspond to "bounded contexts", ie a business domain? And if so, what do you do when a bounded context is too complex to fit into 150LOC?