3 ms·

Yes but you need semi-competent people to manage it and have actual ops dept. Then again we got a bunch of racks and our ops dept is 3 people. We have few doz

by xani_ 4y ago

Yes but you need semi-competent people to manage it and have actual ops dept. 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.

dijit 4y ago
I’ve never seen a functioning org that has not had dedicated ops people for their cloud systems. 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.
- xani_ 4y ago
  That's also funny because one of selling points often starts with not needing to have separate ops people. 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.

by xani_ 4y ago

dijit 4y ago

I’ve never seen a functioning org that has not had dedicated ops people for their cloud systems. 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.

xani_ 4y ago
That's also funny because one of selling points often starts with not needing to have separate ops people. 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.