5 ms·

> 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

> 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 customization of an existing solution. If you hire an SRE to do sysadmin work, they'll be bored and you'll be drastically overpaying. DevOps is the idea that there shouldn't be separate "dev" and "ops" organizations, but instead that operational load of running in-house software should be borne primarily by the developers of that software. DevOps can be considered in the same category as Scrum or Agile, a way of organizing the distribution and prioritization of tasks between members of an engineering org. --- With this in mind, the question could be reframed as: if projects such as Kubernetes are changing the nature of sysadmin work, why has that caused more sysadmin jobs to exist? I think a general answer is that it's reduced the cost associated with running distributed software, so there are more niches where hiring someone to babysit a few hundred VMs is profitable compared to a team of mainframe operators.

etruong42 4y ago
> 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!, May 17, 2017, Planet Money
- deleted 4y ago
  [deleted]
- deeptote 4y ago
  Basically, "why technological innovation creates and transforms jobs, instead of causing unemployment".
  - gruez 4y ago
    ...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 https://fred.stlouisfed.org/series/CLF16OV
    - mkoubaa 4y ago
      This is a weak argument, since it ignores the productivity gains in all the industries that necessitated more accountants. Accountants don't only do each other's taxes, so more productivity in accountants is an indicator for a more productive economy
    - jvanderbot 4y ago
      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.
- onlyrealcuzzo 4y ago
  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.
  - chii 4y ago
    workforce grows as more is goods and services are produced. So the real question is - whether the ratio of different roles changed vs total population.
- aitchnyu 4y ago
  ATMs caused a decrease in teller transactions, but led to an explosion of bank branches.
shawnz 4y ago
essentially Jevons paradox
- normie3000 4y ago
  https://en.m.wikipedia.org/wiki/Jevons_paradox https://en.m.wikipedia.org/wiki/Jevons_paradox
throwaway787544 4y ago
> 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 dead cats over walls. You can of course give devs more powerful tools, more access and agency to enable them to develop the software better. Sentry.io is a great example of what is needed; makes everyone's life easier, devs can diagnose issues and fix bugs quickly without anyone in their way. That doesn't require operations work because it's just simplifying and speeding up the triage and debug and fix and test phases. It's the fundamental point of DevOps.
- jmillikin 4y ago
  My second job in large-scale software was at Google, which used the "DevOps model" since before DevOps was named. I have no need to read a blog on it. You want the person who designs the car to know what a car is, and to be able to diagnose basic issues like "the fuel gauge says 'empty' and engine won't start". And there's no analogy to an Indy car driver in software, every distributed system is self-driving. The most popular alternative to "DevOps" is a team of developers who do not run the software, and may not even have the skills or capabilities needed to boot up the server process. They do their development in an IDE, run unit tests to verify functionality, and do not have permission to log in to the production environment. Meanwhile the "ops" side consists of people who may know basic shell scripting, or some Python if they're a go-getter, but are unable to read stack traces or diagnose performance excursions.
  - deleted 4y ago
    [deleted]
  - jmillikin 4y ago
    throwaway787544 deleted their reply to this post. My response was as follows: --- > So you're familiar with Six Sigma then? Value stream mapping? TPS? > W.E. Deming? Martin Fowler? There's more to DevOps than deployments > and CI/CD. None of those have any relationship to DevOps. > I haven't worked at Google, but I expect somebody gave you some tools > and some access to cloud infra and said "good luck". I was on Borg-SRE. My job was to build the tools and maintain the cloud infra. > If you're lucky there was a small army of ops people behind the > scenes keeping things running for you The point of having an SRE team is to avoid having a "small army" of ops people. Manual operation of compute infrastructure is uneconomical at scale. > if you weren't lucky you were expected to know how to correctly build > and run complex systems at scale by yourself Google does expect its developers to understand basic principles of distributed systems, yes. > > every distributed system is self-driving > > I didn't know Google was in the bridge selling business. What I mean is that when your service runs 24/7 and downtime is reported in the New York Times, there is no room for manual action during normal operation. The system must have the capacity to maintain itself and self-recover.
jupp0r 4y ago
SREs don't normally write Kubernetes alternatives. They are the people who operate/write automation that interacts with/advise teams how to run their software on/ Kubernetes to solve business problems like ensuring availability.
jghn 4y ago
> DevOps is the idea that there shouldn't be separate "dev" and "ops" organizations, I agree with this definition of DevOps. However the vast, vast, vaaaast majority of real life uses of the term "DevOps" I've seen are just rebranded sysadmins. Sometimes it at least implies a more engineering approach to their coding. But in these institutions the Devs and Ops are very much separate groups of people, unfortunately.
- thewileyone 4y ago
  Agreed. The DevOps that I'm familiar with is two job descriptions in one job, one headcount, one pay.
- 0xBDB 4y ago
  I agree. I think the grandparent is maybe describing an ideal state, but in practice most "DevOps" and "SRE" positions I see go by on job boards are for either sysadmins who can do some automation and infrastructure as code, or possibly devs who know how cloud infrastructure and networking work, depending on your perspective. If you're lucky the hiring manager might have at least read the Phoenix Project or the Google SRE books.

etruong42 4y ago

> 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!, May 17, 2017, Planet Money

deleted 4y ago
[deleted]
deeptote 4y ago
Basically, "why technological innovation creates and transforms jobs, instead of causing unemployment".
- gruez 4y ago
  ...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 https://fred.stlouisfed.org/series/CLF16OV
  - mkoubaa 4y ago
    This is a weak argument, since it ignores the productivity gains in all the industries that necessitated more accountants. Accountants don't only do each other's taxes, so more productivity in accountants is an indicator for a more productive economy
  - jvanderbot 4y ago
    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.
onlyrealcuzzo 4y ago
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.
- chii 4y ago
  workforce grows as more is goods and services are produced. So the real question is - whether the ratio of different roles changed vs total population.
aitchnyu 4y ago
ATMs caused a decrease in teller transactions, but led to an explosion of bank branches.

shawnz 4y ago

essentially Jevons paradox

normie3000 4y ago
https://en.m.wikipedia.org/wiki/Jevons_paradox https://en.m.wikipedia.org/wiki/Jevons_paradox

throwaway787544 4y ago

> 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 dead cats over walls. You can of course give devs more powerful tools, more access and agency to enable them to develop the software better. Sentry.io is a great example of what is needed; makes everyone's life easier, devs can diagnose issues and fix bugs quickly without anyone in their way. That doesn't require operations work because it's just simplifying and speeding up the triage and debug and fix and test phases. It's the fundamental point of DevOps.

jmillikin 4y ago
My second job in large-scale software was at Google, which used the "DevOps model" since before DevOps was named. I have no need to read a blog on it. You want the person who designs the car to know what a car is, and to be able to diagnose basic issues like "the fuel gauge says 'empty' and engine won't start". And there's no analogy to an Indy car driver in software, every distributed system is self-driving. The most popular alternative to "DevOps" is a team of developers who do not run the software, and may not even have the skills or capabilities needed to boot up the server process. They do their development in an IDE, run unit tests to verify functionality, and do not have permission to log in to the production environment. Meanwhile the "ops" side consists of people who may know basic shell scripting, or some Python if they're a go-getter, but are unable to read stack traces or diagnose performance excursions.
- deleted 4y ago
  [deleted]
- jmillikin 4y ago
  throwaway787544 deleted their reply to this post. My response was as follows: --- > So you're familiar with Six Sigma then? Value stream mapping? TPS? > W.E. Deming? Martin Fowler? There's more to DevOps than deployments > and CI/CD. None of those have any relationship to DevOps. > I haven't worked at Google, but I expect somebody gave you some tools > and some access to cloud infra and said "good luck". I was on Borg-SRE. My job was to build the tools and maintain the cloud infra. > If you're lucky there was a small army of ops people behind the > scenes keeping things running for you The point of having an SRE team is to avoid having a "small army" of ops people. Manual operation of compute infrastructure is uneconomical at scale. > if you weren't lucky you were expected to know how to correctly build > and run complex systems at scale by yourself Google does expect its developers to understand basic principles of distributed systems, yes. > > every distributed system is self-driving > > I didn't know Google was in the bridge selling business. What I mean is that when your service runs 24/7 and downtime is reported in the New York Times, there is no room for manual action during normal operation. The system must have the capacity to maintain itself and self-recover.

jupp0r 4y ago

SREs don't normally write Kubernetes alternatives. They are the people who operate/write automation that interacts with/advise teams how to run their software on/ Kubernetes to solve business problems like ensuring availability.

jghn 4y ago

> DevOps is the idea that there shouldn't be separate "dev" and "ops" organizations, I agree with this definition of DevOps. However the vast, vast, vaaaast majority of real life uses of the term "DevOps" I've seen are just rebranded sysadmins. Sometimes it at least implies a more engineering approach to their coding. But in these institutions the Devs and Ops are very much separate groups of people, unfortunately.

thewileyone 4y ago
Agreed. The DevOps that I'm familiar with is two job descriptions in one job, one headcount, one pay.
0xBDB 4y ago
I agree. I think the grandparent is maybe describing an ideal state, but in practice most "DevOps" and "SRE" positions I see go by on job boards are for either sysadmins who can do some automation and infrastructure as code, or possibly devs who know how cloud infrastructure and networking work, depending on your perspective. If you're lucky the hiring manager might have at least read the Phoenix Project or the Google SRE books.