4 ms·

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

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.

411111111111111 4y ago
Uh, what are you talking about? the article is talking about significantly reducing the complexity of running a destributed container platform...
shrubble 4y ago
You're not the one who is insane. 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...
- Frost1x 4y ago
  >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
  - _pob 4y ago
    I call it RDD - Resume Driven Development.
    - Terretta 4y ago
      About 12 years too late to claim RDD. Here's Tom Preston-Werner's "Readme Driven Development" in 2010: https://news.ycombinator.com/item?id=17427593 https://news.ycombinator.com/item?id=17427593 https://tom.preston-werner.com/2010/08/23/readme-driven-development.html https://tom.preston-werner.com/2010/08/23/readme-driven-deve... // Same energy as Amazon 'Working Backwards': https://www.allthingsdistributed.com/2006/11/working_backwards.html https://www.allthingsdistributed.com/2006/11/working_backwar...
- 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.
dijit 4y ago
Simple systems are easy to replace, thus are replaced often until eventually a complex replacement comes forth. 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?
- throwawaymaths 4y ago
  "Simple systems are easy to replace, thus are replaced often until eventually a complex replacement comes forth. Complex systems are hard to replace, thus stay in place." 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
xani_ 4y ago
Few reasons. Main one is that containers are a complex problem to implement. You need to mount a bunch of filesystems, set a bunch of limits what app running in container can and cannot do, and then do all the plumbing to network it (firewalls, redirects etcetera). 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.

411111111111111 4y ago

Uh, what are you talking about? the article is talking about significantly reducing the complexity of running a destributed container platform...

shrubble 4y ago

You're not the one who is insane. 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...

Frost1x 4y ago
>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
- _pob 4y ago
  I call it RDD - Resume Driven Development.
  - Terretta 4y ago
    About 12 years too late to claim RDD. Here's Tom Preston-Werner's "Readme Driven Development" in 2010: https://news.ycombinator.com/item?id=17427593 https://news.ycombinator.com/item?id=17427593 https://tom.preston-werner.com/2010/08/23/readme-driven-development.html https://tom.preston-werner.com/2010/08/23/readme-driven-deve... // Same energy as Amazon 'Working Backwards': https://www.allthingsdistributed.com/2006/11/working_backwards.html https://www.allthingsdistributed.com/2006/11/working_backwar...
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.

dijit 4y ago

Simple systems are easy to replace, thus are replaced often until eventually a complex replacement comes forth. 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?

throwawaymaths 4y ago
"Simple systems are easy to replace, thus are replaced often until eventually a complex replacement comes forth. Complex systems are hard to replace, thus stay in place." 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

xani_ 4y ago

Few reasons. Main one is that containers are a complex problem to implement. You need to mount a bunch of filesystems, set a bunch of limits what app running in container can and cannot do, and then do all the plumbing to network it (firewalls, redirects etcetera). 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.