Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?

news.ycombinator.com

Post reply on HN
Print view View original

321–330 of 433 posts

Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?

#321

Post by tricky777 »

jupp0r wrote: post #291
throwaway787544 wrote: post #93

Earlier quoted context omitted.

> but instead that operational load of running in-house software should be borne primarily by the developers of that software Go back and read a few DevOps books and blogs by the founders of it. We will always need separate disciplines for dev and ops, just like we need mechanical engineers and mechanics/racecar drivers. But we need them to work together and communicate better to solve problems better and not throw d…

The major point is that "mechanical sympathy" for how to operate software should be considered early in the development cycle. Fulfilling the business goals in operation should be a major design consideration that might warrant trade offs in other areas. Traditionally, this has been seen as more of an afterthought and DevOps solution to the problem is that involving the people who design and maintain software in its…

Generalization:

- each role in a company tries to optimize/nudge whole organization toward this role's convenience.

- specialization improves local optimum (advances certain role) at the cost of global optimum (everybody has to dance around new roles processes)

- joining seceral roles into one, creates the oposite result, optimum is searched at more global level (not necessarily found)

- Separation of responsibilities (aka creation of new role) can generate a fractal (e.g. tester of left winglets blue stipe's thickness meter)

- complete joining off roles will create homogenous chaos after n employees (everybody should do everything)

prediction: we will see constant experimentation, first roles will be split, then some will get joined. then split again. then joined again. (people cant search for local optimum and global optimum at the same time)

Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?

#322

Post by dijit »

dlp211 wrote: post #306
dijit wrote: post #261

Earlier quoted context omitted.

a single cluster supports approx 5,000 nodes, 110 pods per node~ The estimated maximum single cluster is 300,000 containers. That's pretty medium, I've ran more than a million processes before, and nomad has 1million containers as its challenge https://www.hashicorp.com/c1m borg can handle this easily.

I don't know anyone running 5k node K8S clusters. That said, borg (as an end user) appears to just keep scaling, but it uses a different model and makes different assumptions than K8S.

Sure. Most people have more clusters before they hit 5k nodes on a single cluster.

But I’ve been in situations where it would have been worthwhile. I’ve been in situations with 30,000 machines that needed to be controlled. Splitting them out into very many clusters would be a lot of wasted overhead in configuration, administration and because you lose nodes to masters.

Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?

#323

Post by jedberg »

DevOps is a philosophy, not a job role. It's the idea that developers deploy and operate their own code. An SRE is often someone who helps make that happen, by building the tools necessary for developers to operate their own code.

In a small organization, you can get away with a sysadmin running a Kubernetes cluster to enable that. In a larger org you'll need SREs as well as Operations Engineers to build and maintain the tools you need to enable the engineers.

Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?

#324

Post by onlyrealcuzzo »

etruong42 wrote: post #10
jmillikin wrote: post #6

> 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…

> so there are more niches where hiring someone to babysit a few hundred VMs is profitable This makes a lot of sense. The same thing happened in the past with new technology, such as the electronic spreadsheet: "since 1980, right around the time the electronic spreadsheet came out, 400,000 bookkeeping and accounting clerk jobs have gone away. But 600,000 accounting jobs have been added." Episode 606: Spreadsheets!, M…

In 1980 - there were 90M employees in the US. Now there's 151M.

Given that the US has transitioned out of manufacturing and into businesses services - I don't think much of this is explained by technology creating new jobs.

I think it's just explained by the workforce growing - and the shift in the US's role in the global economy.

Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?

#325

Post by fertrevino »

jeffwask wrote: post #77

First. DevOps is a culture not a job most places have so many DevOps roles because they are doing it wrong. In the olden days of 10 years ago, most operations teams worked around the clock to service the application. Like every day there would be someone on my team doing something after hours usually multiple. Tools like Kubernettes, Cloud (AWS, GCP, Azure) have added significant complexity but moved operations to mo…

The number of places that get the meaning of DevOps wrong is too high. So much that it is often easier to use it wrong in order to express an idea.

Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?

#326

Post by alias_neo »

jen20 wrote: post #187
alias_neo wrote: post #173

Earlier quoted context omitted.

The declarative approach is a more sustainable way to run Kubernetes. If you define some desired state in manifests and apply them to a cluster, they can be applied again to new clusters or the same one and Kubernetes will attempt to maintain the desired state. This state can be version controlled, written in stone, whatever you prefer and it can always be attained. When administrators start issuing imperative comman…

I find this to be a common misconception, stemming from a misunderstanding of what "declarative" means (especially common when people are discussing tools like Terraform). Firstly as you point out, there is a record of the state Kubernetes is being asked to maintain: it's in the API server as the spec of each resource. Secondly, using `kubectl` "patch" in the manner described is not making changes to the cluster stat…

You're correct, but, when approaching this from the human perspective, it's less about the technology and the reality and more about "do I have a record of the last state I asked the cluster to be in before I fucked it up?". Ultimately that's what matters. Auditability is great, but in practice, when the shit hits the fan, can I get the application that brings in our company's money, and our customers rely on to breath, back to the state it was after 5 years and 73 updates?

Updating the manifests, pushing them to version control and having CD deploy them encourages humans to "do the right thing".

It would be quite easy though to just tweak that one environment variable though while I patch in the new image version to update that one service; until the entire cluster dies and I can't retrieve the last definition and need an equivalent cluster up within the hour.

This is really more about the practice of writing down the state you want the cluster to be in (the spec) and showing it to the cluster, than just ordering it to do one thing without context.

In this sense, Declarative Vs Imperative is just a proxy term for "do I have a record of the state I asked the cluster to keep?"

Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?

#327

Post by rustyminnow »

bmn__ wrote: post #275
rustyminnow wrote: post #235

Earlier quoted context omitted.

Technically YAML is a superset of JSON - all valid JSON is valid YAML. So you could write all your configs in JSON and they'd work just fine.

> Technically YAML is a superset of JSON That's false. http://p3rl.org/JSON::XS#JSON-and-YAML

I'd like to amend my statement:

Technically YAML is (supposed to be) a superset of JSON - (almost) all valid JSON is valid YAML. So you could write all your configs in JSON and they'd (probably) work just fine (assuming you keep things relatively simple).

Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?

#328

Post by devonbleak »

bborud wrote: post #296
devonbleak wrote: post #294

Earlier quoted context omitted.

When my system is running happily on a single VM with no real robustness issues then I don't really need to solve those robustness issues, and certainly not by bringing in a complex distributed platform to run it on. Or when my lack of robustness isn't costing me enough to make it worth it to spend the engineering cycles to adopt that platform. One way or another I have to be at a scale where it actually makes sense…

There is a lot of ground between "runs on a single VM" to "runs on thousands of instances". In fact I would think most companies that deliver some online service fit into that category. For instance, I don't regard one of our products that runs in three availability zones and has 3-4 instances per AZ as being "large scale". It is still a small system. And it doesn't run in multiple AZs for performance reasons but bec…

Agreed it's mostly undifferentiated heavy lifting still, and agreed it /should/ be easier. It previously took my team something like a year to get our infra all autoscaling - something I've found other teams aren't as willing to invest in if they're just running on a handful of instances.

At ~12 instances probably still in "pets aren't so bad" territory.

Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?

#329

Post by alias_neo »

throwaway894345 wrote: post #256
sgarland wrote: post #240

Earlier quoted context omitted.

A patch is declarative in that it's an idempotent command which requires you to fully define the patch. It's still something that is being manually defined rather than contained in a file to be applied. Of course, if that file is just being locally held and modified on someone's laptop instead of committed to version control, it's a moot point. I will grant you that `kubectl delete -f` breaks my argument, since it's…

Yeah, my point is that whether you're changing a manifest and doing an apply versus a patch isn't relevant, the relevant bit is whether or not you have a version history and in both cases you do via your CD pipeline and via k8s deployment revision history. You can also commit to git, but I don't think there's much value in committing every image version change to git. Also, working in raw manifests isn't a panacea; i…

I agree with your points, but as I mentioned in another comment, if we take "imperative" and "declarative" as proxy terms for "I do or do not have a reference to the state I requested of the cluster OUTSIDE of the cluster"; my point is that updating the state, in full, by modifying the manifests and committing them to be deployed by your CD pipeline or otherwise is a better approach to ensuring you or someone else can rebuild your "empire" were it to unceremoniously burn to the ground.

Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?

#330

Post by jvanderbot »

gruez wrote: post #189
deeptote wrote: post #150

Earlier quoted context omitted.

Basically, "why technological innovation creates and transforms jobs, instead of causing unemployment".

...except that 400k in 1980 translates to 608k in 2017, if you factor in overall labor force size. That means even though there were 600k jobs "created", it's still a net loss. [1] https://fred.stlouisfed.org/series/CLF16OV

I think the point of the comment in discussion is:

"Though the spreadsheet was supposed to make clerks obsolete, it in fact just upgraded their job requirements to allow the operation of spreadsheets"

And probably their salaries too.

This is more in line with the discussion related to OP, as well, as devops employees exist, even though apparently it is automated.

Post reply on HN