41–50 of 76 posts
I don't disagree with everything he's said, but what contributions has he made that makes him so much of an authority on how I write code?
One advantage of a microservice architecture not mentioned in the article is the ability to scale services independently of other services. Being able to fire up more instances to address a bottleneck is often much simpler than managing threads in a monolith.
that is true in some very rare cases. CPU-intensive bits of the application should definitely be separated, so that they can scale independently. But that's not the main point of microservices.
One advantage of a microservice architecture not mentioned in the article is the ability to scale services independently of other services. Being able to fire up more instances to address a bottleneck is often much simpler than managing threads in a monolith.
that is true in some very rare cases. CPU-intensive bits of the application should definitely be separated, so that they can scale independently. But that's not the main point of microservices.
There's a dangerous, contagious illness that developers of every generation get that causes them to worry about architecture and getting "street cred" even more than they worry about solving business problems. I've fallen victim to this myself, because street cred is important to me. But it's a trap. An important meta-idea that encapsulates all of this is remember to solve your business problems as your first priorit…
I agree with you, but the opposite of this is also horrible. I'm working for a company where they only focused on business needs, and the result is horrible. Terrible, unwieldy codebases, full of bugs, have no security at all. It's hard to develop features, it suffers from feature creep, have absolutely no test coverage at all. It's important to find balance.
Earlier quoted context omitted.
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?
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 m…
$ wc -l src/ls.c
4980 src/ls.c
768 src/cat.c
570 src/chmod.cEarlier quoted context omitted.
I don't understand properly the term micro service if services aren't separated in a "network" way.
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?
Earlier quoted context omitted.
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 m…
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
The core banking services that actually move money around are isolated from the more "fluffy" customer facing ones that we want to be able to push updates to several times a day. We have to have incredibly rigorous procedures for updating services that control money, if we had a monolithic architecture then these procedures would have to be used even if the change was simply cosmetic.
There's a dangerous, contagious illness that developers of every generation get that causes them to worry about architecture and getting "street cred" even more than they worry about solving business problems. I've fallen victim to this myself, because street cred is important to me. But it's a trap. An important meta-idea that encapsulates all of this is remember to solve your business problems as your first priorit…
So when you don't have customers you get to anti-pattern and navel-gaze, because then, at least people are doing something.
Earlier quoted context omitted.
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 -- o…
I don't understand properly the term micro service if services aren't separated in a "network" way.
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.