5 ms·

This article touches on a couple of the problems with SRE-ism as its currently understood/practiced at a lot of organizations: > SREs aren’t necessarily organi

by chazu 5y ago

This article touches on a couple of the problems with SRE-ism as its currently understood/practiced at a lot of organizations: > SREs aren’t necessarily organized as part of development or IT ops teams. SRE teams should be comprised of software engineers. Who do software engineering - specifically to tackle the thus-far intractable problem of managing operational complexity for the SDLC. It says as much in the first chapters of the SRE book. The idea that SREs are not engineers, or developers, is nuts to me. Of course, most SREs _arent_ developers, they haven't ever been in that role. Thats fine, but organizations need to understand that transposing Sysadmin into SRE doesn't magically change anything. > No role in CI/CD for reliability engineering Phew boy - this really underscores the weakness of the SRE meme, in my opinion; and highlights the usefulness of the Platform Engineering meme. CI/CD is the fulcrum where effective SREs/Platform Engineers can insert a _ton_ of value into the business, and if they're not allowed to have a leading role in its care and feeding then they are basically being kept from doing their jobs. I've seen this many times over. Another pathology is an organization where CI/CD is neglected in favor of shinier, more whiz-bang toys - this is just as unfortunate. Just my two cents - but as I always say, everthing in moderation except moderation. t. SRE/Platform Engineer/DevOps for 6ish years

loevborg 5y ago
Great comment, really resonates with me. What's a good place to learn about Platform Engineering?
- emptysongglass 5y ago
  I'd also like to hear about a reading list the commenter suggests for erroneously-named-but-that's-our-job-title DevOps Engineers who really want to spearhead manifest SRE changes at their workplace
  - chazu 5y ago
    I suggest Accelerate, Balancing Agility and Discipline, The Phoenix Project and the OG Continuous Delivery book by Jez Humble and David Farley.
- chazu 5y ago
  Personally, I would recommend listening to Thoughtworks' Techonology Podcast. Their approach in general to running in the cloud is a pretty good one, which I'd characterize as platform engineering-centric. Anything Will Larsen writes is bound to be worth looking at and thinking about in the context of scaling cloud operations and operational complexity. His concept of the 'pierceable abstraction' is _absolutely key_ in my opinion. Additionally, the following blog posts are fairly good introductions: https://charity.wtf/2018/10/24/ten-platform-commandments/ https://charity.wtf/2018/10/24/ten-platform-commandments/ https://martinfowler.com/articles/talk-about-platforms.html https://martinfowler.com/articles/talk-about-platforms.html https://lethain.com/pierceable-abstractions/ https://lethain.com/pierceable-abstractions/ https://srvaroa.github.io/paas/infrastructure/platform/kubernetes/cloud/2020/01/02/talk-how-to-build-a-paas-for-1500-engineers.html https://srvaroa.github.io/paas/infrastructure/platform/kuber... Hope that helps - had to dash this off fairly quickly.
lovemenot 5y ago
Not specifically about the article, but this applies to any X where you get a conclusion like: "Everyone owns X" For those who currently care about X and they don't get enough support in their organisation, it makes perfect sense. For the rest, nothing needs to change. After all those other guys should have it. The article issues hypothetical directives "Include all teams in testing", without any consideration as to what kind of activity might make this feasible. All teams simply reply "no thank you". And it's back to square one. To be clear, I am not saying these suggestions are wrong. Just naive.
- WJW 5y ago
  Years ago I saw a talk by someone leading the "innovation department" of a large national police organization in the EU. Her main point: the quickest way to kill innovation (or reliability, or performance, etc) is to make a special team that "owns" that area. This is because it signals to the rest of the teams that it is not their problem anymore, because "after all SRE is responsible for reliability". On the other side of the spectrum, the main problem with "Everyone owns X" type initiatives is that often nobody gets measured on X but they do get measured on their other responsibilities. The predictable result is that all those smart and driven people you hired will realize that spending time on X will not get them promoted but neglecting it does not cost anything.

by chazu 5y ago

loevborg 5y ago

Great comment, really resonates with me. What's a good place to learn about Platform Engineering?

emptysongglass 5y ago
I'd also like to hear about a reading list the commenter suggests for erroneously-named-but-that's-our-job-title DevOps Engineers who really want to spearhead manifest SRE changes at their workplace
- chazu 5y ago
  I suggest Accelerate, Balancing Agility and Discipline, The Phoenix Project and the OG Continuous Delivery book by Jez Humble and David Farley.
chazu 5y ago
Personally, I would recommend listening to Thoughtworks' Techonology Podcast. Their approach in general to running in the cloud is a pretty good one, which I'd characterize as platform engineering-centric. Anything Will Larsen writes is bound to be worth looking at and thinking about in the context of scaling cloud operations and operational complexity. His concept of the 'pierceable abstraction' is _absolutely key_ in my opinion. Additionally, the following blog posts are fairly good introductions: https://charity.wtf/2018/10/24/ten-platform-commandments/ https://charity.wtf/2018/10/24/ten-platform-commandments/ https://martinfowler.com/articles/talk-about-platforms.html https://martinfowler.com/articles/talk-about-platforms.html https://lethain.com/pierceable-abstractions/ https://lethain.com/pierceable-abstractions/ https://srvaroa.github.io/paas/infrastructure/platform/kubernetes/cloud/2020/01/02/talk-how-to-build-a-paas-for-1500-engineers.html https://srvaroa.github.io/paas/infrastructure/platform/kuber... Hope that helps - had to dash this off fairly quickly.

lovemenot 5y ago

Not specifically about the article, but this applies to any X where you get a conclusion like: "Everyone owns X" For those who currently care about X and they don't get enough support in their organisation, it makes perfect sense. For the rest, nothing needs to change. After all those other guys should have it. The article issues hypothetical directives "Include all teams in testing", without any consideration as to what kind of activity might make this feasible. All teams simply reply "no thank you". And it's back to square one. To be clear, I am not saying these suggestions are wrong. Just naive.

WJW 5y ago
Years ago I saw a talk by someone leading the "innovation department" of a large national police organization in the EU. Her main point: the quickest way to kill innovation (or reliability, or performance, etc) is to make a special team that "owns" that area. This is because it signals to the rest of the teams that it is not their problem anymore, because "after all SRE is responsible for reliability". On the other side of the spectrum, the main problem with "Everyone owns X" type initiatives is that often nobody gets measured on X but they do get measured on their other responsibilities. The predictable result is that all those smart and driven people you hired will realize that spending time on X will not get them promoted but neglecting it does not cost anything.