I think I'm stupid, because for me this all seems overly complex. Why do the things get more and more complex instead of the opposite? Is it really the only way? Like said, I'm clearly stupid for not understanding it.
Complex systems are hard to replace, thus stay in place.
This is the way of all things unless there is a design constraint placed on simplicity. In mechanical engineering they design things to be cheap to manufacture: this is the design constraint.
Computers do not have constraints on them, you can burn resources or be as complex as you want: more powerful hardware is around the corner, and after all: why shouldn't abstractions be abstracted ad infinitum; as long as it's easier for people?
Damn, this is very good and clarifying. Like Gresham's law, but for software.
> why shouldn't abstractions be abstracted ad infinitum; as long as it's easier for people?
Not pessimistic enough. Should be: Even if it's no easier on anyone
VM is essentially just the last part and usually simpler too ("just connect it to switch like it is separate machine" is common solution"). Sure you still have some complexity around storage but that's just "here is a bunch of blocks", no need to make overlay filesystem or mount image layers.
Then we are at level of generic OS. The features docker/systemd/k8s uses were not "designed to make containers", they were designed to be used for anything you wanted, from as complex as containers to as simple as "let's put this processes in a cgroup so we can limit memory usage together. And with flexibility comes complexity.
Then we have a problem of both systemd and k8s/docker managing same interfaces so both have to play nice with eachother. And we get to even more complexity when kubelet-controlled containers also need to manage system stuff, like say networking via kube-router.
It would be simpler if say k8s' kubelet directly managed everything all at once but that means it would also have to do what systemd does (boot system, setup devices and partitions etc.) so while total complexity would be lower, the kubelet itself would be more complex.
Assume you have a $25k budget for a Dell server and $20k for attached storage . Go see what you can build on Dell.com's online configuration tool.
You could colocate everything you can buy for $45k in a half rack at a reputable datacenter for $750 per month including a burstable to 1gbit internet connection.
I estimate that at least 75% of the people who are commenting on these threads, will not have a product or service that could cause that server to choke on the load, nor saturate the 1gbit feed with legitimate traffic from their applications.
But they will instead recommend that for 600k/year in spend you over-engineer all aspects... I call it CVops instead of DevOps. CV being another word for resume...
I might borrow this, although I'm leaning towards Res[ume]Ops
Here's Tom Preston-Werner's "Readme Driven Development" in 2010:
https://news.ycombinator.com/item?id=17427593
https://tom.preston-werner.com/2010/08/23/readme-driven-deve...
// Same energy as Amazon 'Working Backwards':
https://www.allthingsdistributed.com/2006/11/working_backwar...
Then again we got a bunch of racks and our ops dept is 3 people.
We have few dozen different apps running on it, anything from "just a wordpress" to k8s cluster (mostly because our customers want us to deploy app they are paying us to develop on k8s).
So far the only actual value k8s provides is self-service aspect of it. Nothing that is running on it needs anything special to k8s, all of it is just "few app servers + one or few DB services".
Sure, there is value in not bothering ops to install yet another VM and plumb the network for it, but you need pretty big team for that kind of savings to be worth it.
There is also value in having complex app deployment centralized in one manifest that can be run on prod or on dev machine, but you can you know... not overcomplicate your apps massively by making a bunch of microservices for a thing that really should be just well structured single app. Again, not really a benefit for small (let's say below 50) teams, for bigger orgs, sure
> But they will instead recommend that for 600k/year in spend you over-engineer all aspects... I call it CVops instead of DevOps. CV being another word for resume...
It's a mix of bad goals and devs wanting to work on cool stuff. I did mildly overengineer a lot of things but about 8/10 out of them eventually became useful, but that's because I'm in ops so everything we do is long term by default.
AWS skills are as arcane or more than traditional hardware management skills; I’m not sure I could make the argument in good faith that you need less people overall with cloud.
An (anecdotal) example: I worked on an e-commerce SaaS platform responsible for 1% of internet traffic in 2011 with a team of 6 sysadmins, with 60~ developers working purely on the product.
My last company had 23~ “SREs” (that did not code aside from DSLs) operations staff handling AWS deployments.
And it always ends with a bunch of people doing essentially same thing but with different job title.
> AWS skills are as arcane or more than traditional hardware management skills; I’m not sure I could make the argument in good faith that you need less people overall with cloud.
The main difference is that it is impossible to dig deep. You can do the deep dive, almost to the bare hardware level when you own the hardware. If you just call a bunch of APIs you're essentially talking with black box.
Like, I do not exactly miss the time spent finding out why our Ceph cluster misbehaves and getting to some driver bug causing ~0.5-1% packet drop after few weeks running with irqbalance daemon on, but it is possible and it can be mitigated, meanwhile in cloud, black box, tough shit, live with it.