You're looking at only infrastructure costs, but not at benefits. Being able to autonomously deploy an application in production increases your team's velocity by orders of magnitude, e.g. faster time-to-market, faster feedback loops, etc.
Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?
421–430 of 433 posts
Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?
#422Earlier 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?
You may think you want an alternative but you don't. The API is the main drawcard of k8s in the first place, if you are off in ECS land all you are doing is wasting a bunch of time on a dead-end. I would instead focus on getting to understand the basics of the API by using a hosted k8s service like GKE or EKS. Stick with some basic manifests, i.e deployments, services, ingress. Once you have some stuff running you ca…
I agree. I'd say the appeal of Kubernetes is the declarative configuration of your workloads. It's a language on its own that's incredibly versatile and exhaustive. This infrastructure abstraction layer is here to stay.
Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?
#423The answer to your question is this: _complexity does not go away, we just move complexity to another layer_.
Kubernetes buys the org some things but it is complex and you have to know how to write the app in a certain _way_ in order of the app to be "scalable, etc.".
There are no free meals or as someone smarter than me said long time ago "there is no royal road to learning".
Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?
#424Earlier quoted context omitted.
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 … varyi…
For sure, I had all this stuff before k8s as well
Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?
#425Earlier quoted context omitted.
EC2 instances are inherently unreliable and that's not a knock on them, that's exactly the contract that you get using them and you're supposed to plan your architecture around the fact that at any moment an EC2 instance could die. We lose about 2-3 EC2 nodes per day (not like our app stops, like Amazon's own instance health goes red) and we couldn't care less.
What percentage of EC2 nodes is that?
Empirically around 0.1%
Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?
#426"To Kubernetes! The cause of - and solution to - all of life's problems!"
Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?
#427Earlier quoted context omitted.
It's not drift, because the infra-as-code doesn't manage the image field (the application's CD pipeline does). You don't trawl through someone's shell history', you look at the CD pipeline history. Rollbacks are easy--you just deploy the prior version via your CD tool. I think you're assuming that invoking kubectl means invoking it directly from a user's command line , but kubectl can also be called in a CD script.
If you're using ArgoCD or something then sure, but bear in mind the original statement you made was directed at someone who is new to K8s, and given a command that can be executed from their shell, they would likely assume that's what you meant.
I'm not new to Kubernetes and I've been using containers since Solaris zones were introduced.
Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?
#428Kubernetes is not the solution to completely automating ops so that you don’t have to employ anyone
The solution to that is PaaS (Platform as a Service), and you can start a startup with almost no devops knowledge using things like Heroku and it’s myriad competitors from startups to AWS offerings.
Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?
#429Earlier quoted context omitted.
'kubectl delete -f dir/' will delete all resources in the directory.
Right, but the only resource you want to delete is no longer in that directory, so you’ve now deleted every resource you except the one you actually wanted to delete. :)
Ah, I slightly misunderstood. Still, you should always have your manifests under version control so this shouldn't ever be a problem :)
Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?
#430> 1) internal users: mainly developers by providing CI/CD > 2) external users: end users > > Nowadays we call people that do 1) DevOps and people that do > 2) SREs (so one could argue that the role of sys admins just > got more specialized). Both are called sysadmins. SRE is a specialized software engineering role -- you'd hire SREs if you wanted to create something like Kubernetes in-house, or do extensive customiza…
> DevOps is the idea that there shouldn't be separate "dev" and "ops" organizations, I agree with this definition of DevOps. However the vast, vast, vaaaast majority of real life uses of the term "DevOps" I've seen are just rebranded sysadmins. Sometimes it at least implies a more engineering approach to their coding. But in these institutions the Devs and Ops are very much separate groups of people, unfortunately.
I agree. I think the grandparent is maybe describing an ideal state, but in practice most "DevOps" and "SRE" positions I see go by on job boards are for either sysadmins who can do some automation and infrastructure as code, or possibly devs who know how cloud infrastructure and networking work, depending on your perspective.
If you're lucky the hiring manager might have at least read the Phoenix Project or the Google SRE books.