3 ms·

As for me,I have been trying to discover that 5% that cannot be done without microservices.

by wg0 4y ago

bawolff 4y ago
Like any tool, there is nothing that cannot be done without microservices. However that doesn't mean they never make sense. Microservices have certain costs and certain benefits. I can believe there are certain situations where the benefits outweigh the costs. Its just not most situations. But that doesn't mean it never exists. I could believe it makes sense in extremely large apps with huge number of different groups working on them, where the communication complexity outweighs the other complexities microservices bring.
- qaq 4y ago
  That's very hypothetical. Building a distributed system just might always be way more resource intensive than comparable monlith regardless of number of developers involved.
avereveard 4y ago
Remove reliability intercorrelations, so for example that your cart api and payment gateway is up and collecting orders no matter to what happens to the front-end services. But then for perfect decorrelation you'd also need independent databases behind the microservices, and queues between them for horizontal communication,and few are actually going all in with that, and so fall in the 95% where they go trough te motion and the effort of splitting microservices,but reap no actual benefit from it.
kristopolous 4y ago
There's a bunch of things I'd like to have them do. If they could span across machines like clusters that would be amazing. If I could trivially package them up and deploy them locally with intrinsically less effort and wall-time then the old way, that'd be amazing. If I could somehow get the horizontal scaling promises and redundancy as some kind of built-in, like I can with say, memcache, that's be cool. If I could do these kinds of "hard" things with them more trivially, that'd be really nice. There's a lot of things I want them to do but it's a god-damn bull-riding rodeo every time I try to get there. And before you reply, I know you're an expert and can do all these things trivially. That's amazing. The vast majority of the industry creates a giant fragile spaghetti knot with them and I am not a full time k8s admin nor do I want this to be a career trajectory. It should be like you know, wine, ffmpeg, imagemagick, virtualbox, lua, qemu, redis, gnuplot, lvm2, gdb, ssh, sqlite; tools like that. It's pretty easy to get them to do really nice things. Those things deliver on their promises and potential pretty nicely. It's nice that nobody feels a need to hype curl or squid. They just work. Isn't that nice? I mean look at gdb's website: https://www.sourceware.org/gdb/ https://www.sourceware.org/gdb/ it doesn't even have CSS animations --- in fact, it doesn't even have CSS.
- freeone3000 4y ago
  Your asks seem easily answered with docker + kubernetes. Actually, this is in fact the use case for kubernetes — a fault tolerant distributed system running arbitrarily, simply packaged code. This has to be what you’ve tried — what issue are you running into?
  - NBJack 4y ago
    Kubernetes isn't something I'd put in the same sentence as 'easy'. Docker is a close contender for the same. I still recall the day when my local Docker builds necessitated a new router to properly manage streaming traffic at home while I downloaded a few GBs of layer images. Or the time I wanted to setup a 'simple' hosted Kubernetes cluster of my own in my lab for testing, only to discover the nightmare that is networking on it. Then there was the grim discovery that Docker containers were much more sensitive to the hosting environment than I had assumed, resulting in some fun "but it worked and tested fine" moments. Did they all work eventually for me? Yes. Was it simple? Not by my standards. If you find all that simple, kudos to you.
    - adql 4y ago
      When they say k8s is "easy" they mean "for developers", not people/automation running it. Like, compared to implementing hitless rollback over bare metal services k8s way is "easy", just set some stuff in YAML and have proper healtchecks in your app.
  - mplewis 4y ago
    The issue I encounter is the overhead in setting up a repeatable, easy-to-use dev environment, and working out the bugs locally before I push to a prod-like system.
  - kristopolous 4y ago
    trying to using the actual software to accomplish these actual tasks. You're right though, that is the promise of the software - it doesn't deliver. I wish I had infinite time to document all the issues. This isn't a small nuanced detailed thing - it falls deeply, systemically fundamentally short and in practice you still get the magical monolithic system it tried to kill but now with more obfuscation, complexity and a theatrical slight of hand to convince yourself it isn't that. Instead of the server being configured for the monolithic app, it's now extensively and carefully configured for the myriad of containers, hostnames, configurations and connections of the containers running the microservice app. It's in practice the same problem with a different costume. The other promise of it being a collection of smaller constrained services running on tcp ports talking to each other ... that's nothing new. You've invented the idea of computer networks.

As for me,I have been trying to discover that 5% that cannot be done without microservices.

by wg0 4y ago

As for me,I have been trying to discover that 5% that cannot be done without microservices.

Like any tool, there is nothing that cannot be done without microservices. However that doesn't mean they never make sense. Microservices have certain costs and certain benefits. I can believe there are certain situations where the benefits outweigh the costs. Its just not most situations. But that doesn't mean it never exists. I could believe it makes sense in extremely large apps with huge number of different groups working on them, where the communication complexity outweighs the other complexities microservices bring.

qaq 4y ago
That's very hypothetical. Building a distributed system just might always be way more resource intensive than comparable monlith regardless of number of developers involved.

avereveard 4y ago

Remove reliability intercorrelations, so for example that your cart api and payment gateway is up and collecting orders no matter to what happens to the front-end services. But then for perfect decorrelation you'd also need independent databases behind the microservices, and queues between them for horizontal communication,and few are actually going all in with that, and so fall in the 95% where they go trough te motion and the effort of splitting microservices,but reap no actual benefit from it.

kristopolous 4y ago

There's a bunch of things I'd like to have them do. If they could span across machines like clusters that would be amazing. If I could trivially package them up and deploy them locally with intrinsically less effort and wall-time then the old way, that'd be amazing. If I could somehow get the horizontal scaling promises and redundancy as some kind of built-in, like I can with say, memcache, that's be cool. If I could do these kinds of "hard" things with them more trivially, that'd be really nice. There's a lot of things I want them to do but it's a god-damn bull-riding rodeo every time I try to get there. And before you reply, I know you're an expert and can do all these things trivially. That's amazing. The vast majority of the industry creates a giant fragile spaghetti knot with them and I am not a full time k8s admin nor do I want this to be a career trajectory. It should be like you know, wine, ffmpeg, imagemagick, virtualbox, lua, qemu, redis, gnuplot, lvm2, gdb, ssh, sqlite; tools like that. It's pretty easy to get them to do really nice things. Those things deliver on their promises and potential pretty nicely. It's nice that nobody feels a need to hype curl or squid. They just work. Isn't that nice? I mean look at gdb's website: https://www.sourceware.org/gdb/ https://www.sourceware.org/gdb/ it doesn't even have CSS animations --- in fact, it doesn't even have CSS.

freeone3000 4y ago
Your asks seem easily answered with docker + kubernetes. Actually, this is in fact the use case for kubernetes — a fault tolerant distributed system running arbitrarily, simply packaged code. This has to be what you’ve tried — what issue are you running into?
- NBJack 4y ago
  Kubernetes isn't something I'd put in the same sentence as 'easy'. Docker is a close contender for the same. I still recall the day when my local Docker builds necessitated a new router to properly manage streaming traffic at home while I downloaded a few GBs of layer images. Or the time I wanted to setup a 'simple' hosted Kubernetes cluster of my own in my lab for testing, only to discover the nightmare that is networking on it. Then there was the grim discovery that Docker containers were much more sensitive to the hosting environment than I had assumed, resulting in some fun "but it worked and tested fine" moments. Did they all work eventually for me? Yes. Was it simple? Not by my standards. If you find all that simple, kudos to you.
  - adql 4y ago
    When they say k8s is "easy" they mean "for developers", not people/automation running it. Like, compared to implementing hitless rollback over bare metal services k8s way is "easy", just set some stuff in YAML and have proper healtchecks in your app.
- mplewis 4y ago
  The issue I encounter is the overhead in setting up a repeatable, easy-to-use dev environment, and working out the bugs locally before I push to a prod-like system.
- kristopolous 4y ago
  trying to using the actual software to accomplish these actual tasks. You're right though, that is the promise of the software - it doesn't deliver. I wish I had infinite time to document all the issues. This isn't a small nuanced detailed thing - it falls deeply, systemically fundamentally short and in practice you still get the magical monolithic system it tried to kill but now with more obfuscation, complexity and a theatrical slight of hand to convince yourself it isn't that. Instead of the server being configured for the monolithic app, it's now extensively and carefully configured for the myriad of containers, hostnames, configurations and connections of the containers running the microservice app. It's in practice the same problem with a different costume. The other promise of it being a collection of smaller constrained services running on tcp ports talking to each other ... that's nothing new. You've invented the idea of computer networks.