so what do we use instead?
Hashicorp Nomad. Works on linux, windows, bsd's. Can work with docker, qemu, podman, jails workloads. Scales nicely, easy to troubleshoot, upgrades are trivial.
Google admits Kubernetes container tech is too complex
211–220 of 449 posts
Re: Google admits Kubernetes container tech is too complex
#212I remember trying out docker sometime back in late 2013. Something about it never fully stuck with me. I always felt like the final boundary for a piece software should be the process, not the computer. Plopping an entire VM into a zipfile and saying "here's your software" felt like lazy engineering to many of us at the time (and still today). For our current stack, the answer has been to make the entire business app…
> Horizonal scalability is simply a band-aid for poor engineering
And don't even get me started on having instances labeled "large" that have less memory and CPU capacity than my personal backup laptop (currently on loan to my 8yo for COVID reasons)...
Re: Google admits Kubernetes container tech is too complex
#213I remember trying out docker sometime back in late 2013. Something about it never fully stuck with me. I always felt like the final boundary for a piece software should be the process, not the computer. Plopping an entire VM into a zipfile and saying "here's your software" felt like lazy engineering to many of us at the time (and still today). For our current stack, the answer has been to make the entire business app…
> Horizonal scalability is simply a band-aid for poor engineering in most (not all) applications. Maybe if your app handles < 10k concurrent connections. Otherwise it is the most cost efficient solution and exists because it solves the scaling problem in the best way as of today.
VMs also autoscale.
Re: Google admits Kubernetes container tech is too complex
#214I remember trying out docker sometime back in late 2013. Something about it never fully stuck with me. I always felt like the final boundary for a piece software should be the process, not the computer. Plopping an entire VM into a zipfile and saying "here's your software" felt like lazy engineering to many of us at the time (and still today). For our current stack, the answer has been to make the entire business app…
I suppose your apps ran on windows. It isn't a problem (or at least it's a smaller problem) with windows ecosystem, especially enterprise one, since usually you're using same version and installation steps handled by infra with AD. Even without AD usually the installer and windows version is same, and Microsoft usually great at backwards compatibility. But it's not the case in linux, or at least non-enterprise / ldap…
Nixos fixes this issue (and then some). I wish it had won instead of docker. Maybe it took too long to become stable.
Re: Google admits Kubernetes container tech is too complex
#215I remember trying out docker sometime back in late 2013. Something about it never fully stuck with me. I always felt like the final boundary for a piece software should be the process, not the computer. Plopping an entire VM into a zipfile and saying "here's your software" felt like lazy engineering to many of us at the time (and still today). For our current stack, the answer has been to make the entire business app…
> Plopping an entire VM into a zipfile and saying "here's your software" felt like lazy engineering to many of us at the time (and still today).
At the risk of nitpicking, docker images aren't the equivalent of VM images, as they don't include a kernel.
Re: Google admits Kubernetes container tech is too complex
#216Removing ssh is stupid
They should remove the need for CONFIGURING ssh.
Now they have removed the entire control plane of the container. Hiw should a developer debug something then?
Re: Google admits Kubernetes container tech is too complex
#217I remember trying out docker sometime back in late 2013. Something about it never fully stuck with me. I always felt like the final boundary for a piece software should be the process, not the computer. Plopping an entire VM into a zipfile and saying "here's your software" felt like lazy engineering to many of us at the time (and still today). For our current stack, the answer has been to make the entire business app…
> Horizonal scalability is simply a band-aid for poor engineering in most (not all) applications. Maybe if your app handles < 10k concurrent connections. Otherwise it is the most cost efficient solution and exists because it solves the scaling problem in the best way as of today.
When you approach the limits of what your kernel can handle, then it may be time to split your workload across boxes or to carve smaller boxes out of your metal (and probably directly attaching NICs to the VMs to the host OS doesn't have to deal with them). Making your workload horizontally scalable is always a sound engineering choice.
But...
Splitting a horizontally scalable workload across a dozen virtual servers that are barely larger than the smallest laptop you can get from Best Buy, you are just creating self-inflicted pain. Chances are the smallest box you can get from Dell can comfortably host your whole application.
The fact remains the odds of you needing to support more than 10K simultaneous connections are vanishingly small.
Re: Google admits Kubernetes container tech is too complex
#218Earlier quoted context omitted.
I fully agree with your points and would sum them up as "Kubernetes has a steep learning curve, a (quite) large interface and ample opportunities to shoot yourself into the foot with it" (plus, they're very funny). However playing the devil's advocate here: If you actually took the steps of learning the basic abstractions, then for me it's really hard to see what you could still get rid of. If you actually go all-in…
> If you actually took the steps of learning the basic abstractions, then for me it's really hard to see what you could still get rid of. This argument basically sums up to "Developers just need discipline, and stop blaming the tools". While this is a sound argument on paper, the intrinsic complexity of software systems make it hard to pin the blame on developers. BTW This is the same argument Uncle Bob makes which i…
We are too proud to sometimes admit we simply „are not good enough at something”.
It’s always easier to shift the blame somewhere else.
Thats why some radical but correct concepts are so hard to push.
Re: Google admits Kubernetes container tech is too complex
#219Earlier quoted context omitted.
After that single node crashes, the app you're running on that one server will run a little more slowly.. How big should the one server that serves the whole of netflix be..?
Stackoverflow has always run on a couple of IIS instances. If you’re not bigger than them don’t worry. You can pretend to be Netflix or Google, and build your tech-stack like they do. Or you can stop wasting your resources setting up a tech stack that you’re never going to get a return of investment on.
Why a few though? Couldn't they do with just 1..? that would make people on HN more happier it seems.
Stack Overflow is not a unit of measurement that anyone would be able to take seriously or find useful? How many stack overflows is one asana? Or how many stack overflows is one trello?
Horizontal scaling, docker K8s have their own benefits that are many and obviously to the industry. you don't need to be google to deploy and use them. If you deploy one server for each app and each team vs deploying a common K8s cluster where is the higher investment? You claim more ROI with more physical hardware and more servers?
Re: Google admits Kubernetes container tech is too complex
#220I remember trying out docker sometime back in late 2013. Something about it never fully stuck with me. I always felt like the final boundary for a piece software should be the process, not the computer. Plopping an entire VM into a zipfile and saying "here's your software" felt like lazy engineering to many of us at the time (and still today). For our current stack, the answer has been to make the entire business app…
> Plopping an entire VM into a zipfile and saying "here's your software" felt like lazy engineering to many of us at the time (and still today). At the risk of nitpicking, docker images aren't the equivalent of VM images, as they don't include a kernel.
This isn't nitpicking at all, it's an important distinction!
Docker is not virtualization, it's just an abstraction that makes some Linux process isolation features easier to manage.
It also allows you to bundle whatever dependencies you have in the same bundle, but that is not the same as having a VM.