4 ms·

Not really; if you have a few servers vs. a few containers the patch is the same with the difference that the server one is probably "live" patching on a runnin

Not really; if you have a few servers vs. a few containers the patch is the same with the difference that the server one is probably "live" patching on a running system and the docker one is patching it in the docker file and re-deploying which makes it an atomic change. It also really makes a difference if you are combining some tasks and ownership in a DevOps concept where it's not just developers handing off some binary and telling the operations team "good luck eh". That classic setup mostly brings finger-pointing problems and not really much of a solution. What a patch management concept would look like is much a more modern version of the server thing: you have some system that allows you to query all the servers "what is your current version of thing X" and if you then want to change that you build an updated machine image and deploy that to all those servers. Cattle, not pets.

mschuster91 4y ago
The problem is, most ops-focused people don't have much knowledge of the boatload of different application-side tooling, and most devs (especially those out of "coding bootcamps" or practical academia) don't have a single ounce of knowledge about OS management or even how basic UNIXoid fundamentals work. DevOps has always been more about companies attempting to "save" money by shoe-horning together roles that require completely different skill sets.
- busterarm 4y ago
  > and most devs (especially those out of "coding bootcamps" or practical academia) don't have a single ounce of knowledge about OS management or even how basic UNIXoid fundamentals work. I have to vehemently disagree with this statement. I had 10 years in IT before I did my bootcamp and quickly found myself in deployment engineer roles by accident. Most of my bootcamp cohort ended up at smaller companies wearing many hats and learning quickly where a good half of them are in deployment type roles by necessity. After an additional 10 years in this industry, I'm finding invariably that it's the FAANGs and companies hiring fresh grads out of the best schools where engineers aren't learning anything about the underlying systems. It's the feature factories where people put their headphones on, the heads down and code like their life depends on it. They do things like write microservices that implement basic functionality of opensource loadbalancers, because they've never heard of nginx or haproxy before, don't know how it solves their specific problem and wouldn't know how to configure it. When all you do is write code, every problem looks like it should be solved by writing code.
- oneplane 4y ago
  That hasn't been my experience in the last decade or so, and new people or people with different specialisations are indeed unlikely to be good at everything on the first day. Before the overlap between development and operations there were multiple teams involved in every step, everything was slow and expensive and you'd be lucky to deploy once a week. After making sure that where overlap exists the people that have the skills to work in that area can do what they need to do (i.e. build, verify, release and instrument the systems they are responsible for) we get every team releasing every system multiple times per day in small increments. This is both faster, easier for everyone, and worth the ROI on people and tech far more than trying to invent borders and fiefdoms between hyper-specialised teams.

mschuster91 4y ago

The problem is, most ops-focused people don't have much knowledge of the boatload of different application-side tooling, and most devs (especially those out of "coding bootcamps" or practical academia) don't have a single ounce of knowledge about OS management or even how basic UNIXoid fundamentals work. DevOps has always been more about companies attempting to "save" money by shoe-horning together roles that require completely different skill sets.

busterarm 4y ago
> and most devs (especially those out of "coding bootcamps" or practical academia) don't have a single ounce of knowledge about OS management or even how basic UNIXoid fundamentals work. I have to vehemently disagree with this statement. I had 10 years in IT before I did my bootcamp and quickly found myself in deployment engineer roles by accident. Most of my bootcamp cohort ended up at smaller companies wearing many hats and learning quickly where a good half of them are in deployment type roles by necessity. After an additional 10 years in this industry, I'm finding invariably that it's the FAANGs and companies hiring fresh grads out of the best schools where engineers aren't learning anything about the underlying systems. It's the feature factories where people put their headphones on, the heads down and code like their life depends on it. They do things like write microservices that implement basic functionality of opensource loadbalancers, because they've never heard of nginx or haproxy before, don't know how it solves their specific problem and wouldn't know how to configure it. When all you do is write code, every problem looks like it should be solved by writing code.
oneplane 4y ago
That hasn't been my experience in the last decade or so, and new people or people with different specialisations are indeed unlikely to be good at everything on the first day. Before the overlap between development and operations there were multiple teams involved in every step, everything was slow and expensive and you'd be lucky to deploy once a week. After making sure that where overlap exists the people that have the skills to work in that area can do what they need to do (i.e. build, verify, release and instrument the systems they are responsible for) we get every team releasing every system multiple times per day in small increments. This is both faster, easier for everyone, and worth the ROI on people and tech far more than trying to invent borders and fiefdoms between hyper-specialised teams.