Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?
331–340 of 433 posts
Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?
#332Kubernetes in a sense is very similar to Linux back in the 2000s - it was nascent technology in a hot market that was still absolutely evolving. The difference now is that everyone knows the battle for the next tier of the platform is where people will be able to sell their value (look at RedHat selling to IBM for the saddled legacy of maintaining an OS as a tough growth proposition). For a while people thought that…
Works fine on my cluster. Marking as "can't reproduce".
Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?
#333DevOps has its days numbered. What you see is the wide adoption of DevOps in every industry. This trend is likely to plateau and decline in the next couple of years, after which DevOps practices are taken for granted and become rather an expectation from customers. The DevOps problem only needs to be solved once, public cloud providers are almost there.
Companies that say they’re doing DevOps are like countries with ‘Democratic’ in their name.
Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?
#334The premise of your question is invalid. Have you ever tried setting up a Kubernetes cluster and deploying apps in it? Kubernetes doesn't save work, it adds work. In return, you get a lot of benefits, but it wasn't designed to reduce human work, nor was it designed to eliminate devops jobs. It was designed for scalability and availability more than anything. Most people using Kubernetes should be using something simp…
Anybody who watched "Kubernetes: The Documentary" knows the answer: https://youtu.be/BE77h7dmoQU Kubernetes only exists, because Google lost the Cloud Wars, and this was their Hail Mary pass.
No post body was provided.
Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?
#335> The platform of choice is mostly Kubernetes these days
Is it? These days I see SAM or Serverless Framework or other FaaS solutions all around me and it seems that everyone is migrating away from ECS/EKS/containers, it might be my own particular bubble though.
Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?
#336Earlier quoted context omitted.
throwaway787544 deleted their reply to this post. My response was as follows: --- > So you're familiar with Six Sigma then? Value stream mapping? TPS? > W.E. Deming? Martin Fowler? There's more to DevOps than deployments > and CI/CD. None of those have any relationship to DevOps. > I haven't worked at Google, but I expect somebody gave you some tools > and some access to cloud infra and said "good luck". I was on Bor…
Responding to the inlined kubectl command mentioned above: As an outsider, that command looks really easy to mess up. * shell interactions with quotes * double quotes * interpolating into image namespace with no autocomplete * easy to forget an argument * do you get autocomplete against the deployment name? Comparison: C# declaration of a complex type - it's less complex than the `kubectl` command above, but IDEs off…
Normally you're never going to run a kubectl command in prod that changes anything except for kubectl apply -f. The yaml file may or may not be script or template generated but it's likely. In a lot of shops they're just going to write to a wrapper around the kubernetes API in whatever language the shop uses whether it be python, go or whatever. And there are plenty of linters for the yaml and ways to test without impacting prod.
Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?
#337Earlier quoted context omitted.
Asking as someone who has only tipped his toes into devops lately and is looking to learn K8, what is considered a reasonable "lightweight" alternative to Kubernetes these days?
K8s ate everyone else. The alternative is to use a heroku like sass
In my particular market sector it seems everyone is using some form of cloud functions (SAM, Serverless Framework etc), and migrating away from K8S/containers.
Regarding PaaS stuff like Heroku, the only people I know that are still using that are solo hackers.
Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?
#338Earlier quoted context omitted.
Exactly. I am consulting with a startup right now that chose to go everything docker/k8s. The CTO is half-shocked/half-depressed by the complexity of our architecture meetings, although he used to be a banking software architect in his previous assignments. Every question I ask ends up in a long 15 minutes monologue by the guy who architected all of it, even the most simple questions. They are soon launching a mobile…
60 containers sounds like an architecture problem, not a Kubernetes problem. Kubernetes does not stop you from running 1 container in 1 pod receiving ingress and talking to a database.
Presuming too (it's hard to tell) that they mean 60 different types of containers. One of my clusters currently has ~311 containers, but that's mostly due to replication.
If I count actually different containers (like, unique PodSpecs, or so), that count drops to ≈30. Even that is "high", and from an architectural standpoint, it isn't really a number I'd use. E.g., we have a simple daemon, but it also has a cronjob associated with it. So it has "2" PodSpecs by that count. But architecturally I'd call it a single thing. How it implements itself, that's up to it.
A lot of our "unique PodSpec" count, too, comes from utility type things that do one thing, and do it well. Logging (which comes from our vendor) is 3 PodSpecs. Metrics is another 3. We have a network latency measurement (literally ping shoved into a container…): PodSpec. A thing that checks certs to ensure they don't expire: PodSpec. HTTP proxy (for SSRF avoidance): PodSpec. A tool that rotates out nodes so that their OSes can be patched: PodSpec. Let's Encrypt automation (a third party too): 3 PodSpecs … but hey, it does its job, and it's a third party tool, so what do I care, so long as it works the API between me and it suffices (and honestly, its logs are pretty good. When it has had problems, I've usually been able to discern why from the logs). DB backup. But most of these don't really add much conceptual overhead; any one is maybe tied (conceptually) to our applications, but not really to all the other utilities. (E.g., there isn't really coupling between, say, the cert renewer and the logging tooling.) A confused/new dev might need to have it explained to them what any of those given tools do, ofc., but … many of them you can just Google.
… in previous jobs where we didn't use Kubernetes, we mostly just ignored a lot of the tasks that these tools handle. E.g., reboot a VM for patches? It was a custom procedure, depending on VM, and what is running on that VM. You needed to understand that, determine what the implications were … etc. And the end result was that reboots just didn't happen. K8s abstracts that (in the form of PDBs, and readiness checks) and can thus automate it. (And ensure that new loads don't need TLC that … an app dev realistically isn't going to be given the time to give.)
If we needed a common thing on every node? That would be rough. We did finally get to having a common base VM image, but even them, all of the per-app VM images would need to be rebased on the newer one, and then all rolled out, and who/how would one even track that? And … in practice, it didn't happen.
Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?
#339Because it solves 5 problems while creating 4 more in the most complicated way possible. Seriously. It makes some things better, no question, but it is very complicated for some (most) people and is very time-consuming.
Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?
#340Kubernetes is a Google scale solution. Lots of teams said “hey if Google does it then it must be good!”…but forgot that they didn’t have the scale. It caught on so much that for whatever reason it’s now the horrendous default. I’ve worked on at least 3 consulting projects that incorporated K8s and it slowed everything down and took way too much time, and we got nothing in return - because those projects only needed s…
You don't even end up spending time on Kubernetes, because k8s is just part of the solution, a container scheduler. You have to bring logs, monitoring, a container registry ,as well as a CI system with custom jobs and do integration of everything.
This is true. But I had to bring all those things anyways, when I didn't run on k8s. I still needed some form of all of that. (Though "container registry" might be "package store", or something, depending on specifics of the implementation. Some form of artifact store.)
And with-k8s and without-k8s to me is pretty similar: we vendor or FOSS most of it. The major cloud vendors all have container registries (of … varying quality…); similarly, at a previous company we used S3+a small shim as a Python package store. (We later moved to a vendored solution.)
ELK for logs meant having a daemon set up per VM. Easier in k8s where I can push a DaemonSet to the entire cluster. With VMs … it's a per-app nightmare, really. Even then, that's really not perfect. In practice, in both situations, I feel like you end up having to integrate the apps with the metrics/logs providers. There's just not a common format. Sometimes, there are some libraries, e.g., there's some stuff for Prom's HTTP metrics APIs. Logs … eugh. Nothing amazing; getting structured logging requires per-app changes regardless of what you do. Sure, in either VM or k8s, you can just "suck up syslog/journald / docker logs", but what format are those in? They're not, is the answer, and I find most places do a "one text log per line" assumption (and then have stuff with multiline logs that just gets destroyed/corrupted/lost by the logging daemon) and it misses out on any sort of structured logs. jsonlines through those channels is a slight step up, but usually requires app changes.