4 ms·

Your asks seem easily answered with docker + kubernetes. Actually, this is in fact the use case for kubernetes — a fault tolerant distributed system running arb

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 3y 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 3y 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 3y 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 3y 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.

NBJack 3y 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 3y 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 3y 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 3y 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.