9 ms·
"Write it all yourself" - Install software onto your machines Package managers, thousands of them. - Start services SysVinit, and if shell is too complicate
by slackfan 5y ago
"Write it all yourself"
- Install software onto your machines
Package managers, thousands of them.
- Start services
SysVinit, and if shell is too complicated for you, you can write totally not-complicated unit files for SystemD. For most services, they already exist.
- Configure your virtual machines to listen on specific ports
Chef, Puppet, Ansible, other configuration tools, literally hundreds of them etc.
- have a load balancer directing traffic to and watching the
health of those ports
Any commercial load balancer.
- a system to re-start processes when they exit
Any good init system will do this.
- something to take the logs of your systems and ship them to
a centralized place so you can analyze them.
Syslog has had this functionality for decades.
- A place to store secrets and provide those secrets to your services.
A problem that is unique to kubernetes and serverless.
Remember the days of assuming that your box was secure without having to do 10123 layers of abstraction?
- A system to replace outdated services with newer versions ( for either security updates, or feature updates ).
Package managers.
- A system to direct traffic to allow your services to communicate with one another. ( Service discovery )
This is called an internal load balancer.
- A way to add additional instances to a running service and tell the load balancer about them
Most load balancers have built up processes for these.
- A way to remove instances when they are no longer needed due to decreased load.
maybe the only thing you may need to activelly configure, again in your load balancer.
None of this really needs to be written itself, and these assumptions come from a very specific type of application architecture, which, no matter how much people try to make it, is not a one-size-fits-all solution.
- ferdowsi 5y agoI'm personally glad that Kubernetes has saved me from needing to manage all of this. I'm much more productive as an applications engineer now that I don't have to stare at a mountain of bespoke Ansible/Chef scripts operating on a Rube Goldberg machine of managed services.
- cjalmeida 5y agoThis x10. Each such setup is a unique snowflake of brittle Ansible/Bash scripts and unit files. Anything slightly different from the initial use case will break. Not to mention operations. K8s give you for free things that are a pain to setup otherwise. Want to autoscale your VMs based on load? Trivial in most cloud managed k8s.
- zdw 5y agoInstead, you can now admin a Rube Goldberg machine of Helm charts, which run a pile Docker containers which are each their own microcosm of outdated packages and security vulnerabilities.
- kube-system 5y ago> Rube Goldberg machine of Helm charts I love k8s but I do want to say that I hate the 'standard' way that people write general purpose Helm charts. They all try to be super configurable and template everything, but most make assumptions that undermine that idea, and I end up having to dig through them to make changes anyway. I have found much more success by writing my own helm charts for everything I deploy, and putting in exactly the amount of templating that makes sense for me. Much more simple that way. Doing things this way has avoided a Rube Goldberg scenario.
- cyanydeez 5y agoyour argument seems to be "its ok if youre rube goldberg" just wait till you have a predecessor
- kube-system 5y agoThat's the opposite of my argument. I'm saying that the predominant style is Rube Goldberg, but Helm charts don't have to be written that way. Instead of writing an unreadable mess that is 90% template, just template the 5% that you need, and the whole thing is very readable.
- cyanydeez 5y agothats what you are hearing. what everyone else is hearing: "_my_ code is self documenting, so obviously its more legible!"
- orf 5y ago“ For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software.” Or… you could not. https://news.ycombinator.com/item?id=9224 https://news.ycombinator.com/item?id=9224
- bcrosby95 5y agoSo you have a version of Kubernetes that is as easy to use as Dropbox? Where do I sign up for the beta?
- orf 5y agohttps://aws.amazon.com/eks/ https://aws.amazon.com/eks/
- breakfastduck 5y agoThat comment has aged brilliantly. Thanks for that!
- adamrezich 5y agohow is quoting this here relevant? nobody's saying k8s isn't successful or going to be successful—the argument is whether its complexity and layers of abstraction are worthwhile. dropbox is a tool, k8s is infrastructure. the only similarity between this infamous post and the argument here is that existing tools can be used to achieve the same effect as a product. the response here is "that'll never catch on" (because obviously it has), rather it's "as far as infrastructure for your company goes, maybe the additional complexity isn't worth the turnkey solution"
- orf 5y ago"You don't need Kubernetes, for a Linux user you can already build a custom solution quite trivially by setting up a custom package repo then build and distribute your application using apt, then configuring SysVinit to monitor your services, whilst using Ansible to configure iptables rules in combination with a simple load balancer you can manage yourself, then use syslog to monitor logs across all your machines whilst hand-waving away secrets management as a problem with 'serverless'" Yes, you could. Some people do. Others don't, because even if you need a small portion of the features a turnkey solution is likely a better choice in the long run than hand-rolling your own mix of 15+ different technologies to achieve the same thing.
- mplewis 5y ago> Remember the days of assuming that your box was secure without having to do 10123 layers of abstraction? Yep, I remember when I deployed insecure apps to prod and copied secrets into running instances, too.
- rhacker 5y agoRemember how the ops team kept installing Tomcat with the default credentials?
- puffyvolvo 5y agoThis was the funniest point in that comment to me. Read the intended way, it's borderline wrong. Read as "remember when people assumed security without knowing" is basically most of computing the further back in time you go.
- jchw 5y agoI can setup a Kubernetes cluster, a container registry, a Helm repository, a Helm file and a Dockerfile before you are finished setting up the infrastructure for an Apt repository.
- zdw 5y agoMy experience is the opposite - an APT repo is just files on disk behind any webserver, a few of them signed. Setting up all the infra for publishing APT packages (one place to start: https://jenkins-debian-glue.org https://jenkins-debian-glue.org ) is far easier than trying to understand all the rest of the things you mention.
- jchw 5y agoI mean, Kubernetes is just some Go binaries; you can have it up and running in literal seconds by installing a Kubernetes distribution like k3s. This is actually what I do personally on a dedicated server; it’s so easy I don’t even bother automating it further. Helm is just another Go binary, you can install it on your machine with cURL and it can connect to your cluster and do what it needs from there. The Docker registry can be run inside your cluster, so you can install it with Helm, and it will benefit from all of the Infra as Code that you get from Kubernetes. And finally, the Helm repo is “just files” but it is less complex than Apt. I’ve been through the rigmarole for various Linux package managers over the years and I’m sure you could automate a great deal of it, but even if it were as easy as running a bash script (and it’s not,) setting up Kubernetes covers like half this list whereas setting up an Apt repo covers one item in it.
- tomc1985 5y agoYeah I don't understand where all this fictional .deb and APT "complexity" is coming from. Everything uses standard abstractions that are decades old at this point..... oh no, you have to make some directories! You have to put a manifest file in the right place! Oh my god, now you have to run a command!
- mlnj 5y agoExactly, an autoscaling cluster of multiple nodes with everything installed in a declarative way with load balancers and service discovery, all ready in about 10 minutes. Wins hands down.
- rhacker 5y agoSo instead of knowing about K8s services, ingests and deployments/pods I have to learn 15 tools. Ingests are not much more complicated than an nginx config, services are literally 5 lines each pod, and the deployments are roughly as complicated as a 15 line docker file.
- smoldesu 5y agoIf you're familiar with Linux (which should be considered required-reading if you're learning about containers), most of this stuff is handled perfectly fine by the operating system. Sure, you could write it all in K8 and just let the layers of abstraction pile up. Or, most people will be suited perfectly fine by the software that already runs in their box.
- echelon 5y ago> most of this stuff is handled perfectly fine by the operating system No, you have to write or adopt tools for each of these things. They don't just magically happen. Then you have to maintain, secure, integrate. k8s solves a broad class of problems in an elegant way. Since other people have adopted it, it gets patched and improved. And you can easily hire for the skillset.
- emerongi 5y agoI work in a small company, we don't have a sysadmin, so mostly we want to use managed services. Let's say we want a simple load balanced setup with 2 nodes. Our options are: - Run our own load balancing machine and manage it (as said, we don't want this) - Use AWS/GCP/Azure, setup Load Balancer (and rest of the project) manually or with Terraform/CloudFormation/whatever scripts - Use AWS/GCP/Azure and Kubernetes, define Load Balancer in YAML, let K8S and the platform handle all the boring stuff This is the simplest setup and already I will always go for Kubernetes, as it's the fastest and simplest, as well as the most easily maintainable. I can also easily slap on new services, upgrade stuff, etc. Being able to define the whole architecture in a declarative way, without actually having to manually do the changes, is a huge time-saver. Especially in our case, where we have more projects than developers - switching context from one project to another is much easier. Not to mention that I can just start a development environment with all the needed services using the same (or very similar) manifests, creating a near-prod environment.
- mlnj 5y agoThere was some project where one wrote all of that (essentially what Kubernetes does) in like 8k lines of bash script. Brilliant, yes. But there is not way I want any anything similar in my life. I am not the biggest fan of the complexity Kubernetes is, but it solves a problems there is no way I want to solve individually and on my own.
- AlexCoventry 5y agoI think the point of the blog post in the OP is that it should be a bunch of bash scripts with very few interdependencies, because most of the requirements in the grandparent comment are independent of each other, and tying them all together in a tool like kubernetes is unwieldy.
- Thaxll 5y agoHave you ever tried to package things with .dep or .rpm? It's a f** nightmare. A place to store secrets and provide those secrets to your services. "A problem that is unique to kubernetes and serverless. Remember the days of assuming that your box was secure without having to do 10123 layers of abstraction?" I remember 10 years ago things were not secur, you know when people baked their credentials in svn for example.
- rantwasp 5y agolol. as someone who has packaged stuff I can tell you that this K8S is orders of magnitudes more complicated. Also, once you figure out how to package stuff, you can do it in a repeatable manner - vs K8s which you basically have to babysit (upgrade/deprecations/node health/etc) forever and pay attention to all developments in the space.
- orf 5y agoFROM python:3.8 RUN apt install libsomething ENV RELEASE=production COPY . . RUN poetry install CMD ["poetry", "run", "server"] What would be the rpm/deb equivalent of those 6 lines? Would it work on MacOS?
- rantwasp 5y agolet’s unpack this for a while. what is python:3.8? is this reproducible? what is apt? where is the install coming from? What about poetry? Yeah it’s cool for shits and giggles but when this thing breaks you’re going to be in a world of pain for the rpm equivalent: python setup.py bdist_rpm wat?
- gtaylor 5y agoOh my. I'm not sure that I'd use Python to make a point about easy interop with distro package managers. It quickly descends into a nightmarish hellscape if you have more than a few dependencies or, different versions of python, or god forbid: C extensions.
- tlrobinson 5y agoThis is supposed to be an argument against Kubernetes?
- slackfan 5y agoNope, just an argument against the "you must write all of this yourself" line. :)
- staticassertion 5y agoYou're making their point for them.
- ratorx 5y agoSome of these are decent points, but a couple are misleading. The security one is the big one. Things were just not as secure (and did not need to be as secure) “back then”. K8s has a lot of complexity, and security should definitely be simpler so it’s harder to misconfigure, but not doing anything is not viable. Saying “Package Managers” is fine until you realise they solve only part of the problem. The mainstream ones are good tools to update package (and dependencies) from version X to Y. When you’re running a distributed system, it’s often not that simple if you want to be reliable. Coordinating a slow global update of your application from version X to Y (safely) is pretty tricky and I’m not aware of good self-contained solutions to this.