I've been each of them over 5 years and been involved in a huge enterprise. In my experience:
- DevOps: Hired to do everything not involved in the feature development of main business. Range varies from Terraform to maintaining Jira, GSuite, Jenkins, ETL, BizOps. Maintains scripts and hacks everywhere.
- SRE: Orders teams to define SLOs, focuses only after incident procedures, not before. Insists on creating dashboards and putting them on TVs (when we had offices). Most eventually become vendor fans.
- Platform: We made this, we know better than you, you cannot use anything else. If you need new thing/improvement, create a ticket we will get back to you in 6 months to say we cannot do it due to other company wide very important initatives.
I love not being a regular developer and work on platform side, but its a very irregular space and very hard to hire.
I have seen organisation where platform teams build tools, frameworks and nobody uses them. Few places where it makes sense is when an organisation is large and has corporate and regulatory policies that applications and people have to adhere to.
As platform team member, you really have to know what to build, doing interviews, figuring out what developers and SREs really want, filter through what they are asking for, control through not-invented here syndrome, make build-vs-buy decision, create the community around the product you build within the organisation etc. You cannot just start building a PaaS (most common thing I have seen them build). It is actually quite complex if done right. Having said that, lot of organisation the definition is quite vague, political too and sometimes the boundaries are not clear.
Our systems team is veering into the first sentence hard. Tried to make a whole "one size fits all" CI/CD CLI tool that is inflexible and obfuscates the process.
Nobody asked for it and everyone is content rolling their own pipelines by hand, yet they've sunk a ton of time into it.
I do a lot of this kind of work on the consulting side, and the interview process is critical to establishing buy-in from the essential stakeholders. You have to understand the pain points because without that, you won’t build the right thing for the way the company operates.
The most common hurdle is simply that most developers buried in enterprise software dev have no familiarity with the cloud or foundational DevOps tech like infra as code. So we typically end up building some form of deployment mechanism cobbled together with packer and terraform, but the real value in bringing in outside help is that we handle training and change management necessary to actually drive adoption.
“Build it and they will come” is a terrible design philosophy. You can’t just stand up a platform team and expect it to go well: a more transformational mindset inclusive of org design and strategic outlook is required, and this type of DevOps / SRE transformation is no less of a radical change than HR or finance transformation programs.
As a platform engineer, that's quite a cynical take you have there. What I've found works best is to write tools that take away complexity so that teams don't all need to reinvent the wheel. Then make it so well-documented and easy to use that teams don't need to be _forced_ to use the platform tooling, they'll just use it because it's the most convenient thing to do.
> What I've found works best is to write tools that take away complexity so that teams don't all need to reinvent the wheel.
The problem is complexity is variable. For developers who never really learn how their code actually executes, or haven't had to be responsible for tuning and such, this is great, but for those of us who want to know where the rubber meets the road, these tools are kid-gloves. How can we fully optimize and support our code if we can't see the compute on which it runs? What other "benefits" will the system bring that we have to account for?
> Then make it so well-documented and easy to use that teams don't need to be _forced_ to use the platform tooling, they'll just use it because it's the most convenient thing to do.
Very optimistic. In my experience with this kind of thing with homegrown platforms, documentation was a distant last, because it always is, and we weren't left with other choices anyway. I would love to pick the best tool because it is convenient, but that, too, is variable. Maybe I know Kubernetes inside and out - that's plenty convenient for me, then, and will be better documented and discussed than any homegrown platform because the world can contribute to it.
I think one way of reading the comment above is that it's the effect of business incentives / Conway's law on various approaches to staffing the non-developer parts of your organization:
- DevOps is incentivized to be an extension of the dev team and get stuff into production, i.e., in the average company hiring "DevOps," the engineers operating production report up into existing dev management. Therefore you get "scripts and hacks" because you're never given the mandate to do anything better, and you're evaluated on how much you can manage to ship things to prod without building separate specialties, not how well you ship it to prod.
- SRE is incentivized to demonstrate good SRE practices and their value to the business. Incident response is a lot more visible than incident prevention. Picking an observabiity vendor who can get you nice graphs is a lot more visible than spending months making the right graphs. You're evaluated on how much you improve "reliability," which means you need to figure out how to measure it (and display it) in the first place, but it's not clear your measurement is what the broader business would measure.
- Platform engineering is incentivized to build up a well-defined platform and have their own products/services that are used internally. They are a development team of their own. So their value is most visible when those products exist and are widely used, and a little more cynically, when those products aren't unmodified vendor or OSS products. You're evaluated on the number of people using your product and how infrequently the rest of the company says "I'm just going to run this myself, give me an AWS account."
Any of these disciplines can be done well with strong management support, by which I mean when management actually cares about the long-term problem of running production well and can make informed decisions about how to staff that problem. (For myself, for what it's worth, I'm in a platform engineering organization but my current role is 80% to make it easier for people to use OSS and to reduce our deltas and 20% incident prevention.) But when incentives get disconnected from the business and the inertia is to keep delivering what people thought you should have delivered in the past, the disciplines break down in different ways.
I mostly agree with you, an average dev does not know and do not care how things are done. But if platform team or any tooling is blocking you from delivering your features frequently, it becomes an issue. They are either under-staffed, or generalizing in favor of greater good comes at a cost of dropping your specific requirements.
In my experience, the end result is having a team of kubernetes fanatics reinventing the wheels themselves and forcing everyone to use their custom ego filling tools instead of paying $100 per month to an already existing solution.
Most developers just need something like heroku, tsuru, appengine, or openstack. But because kubefans want to have fun too and try to be as cool as Google or Facebook we end up having to deal with tons of custom Golang tooling with fancy names, half assed documentation and grumpy looks when you ask for help because you don't understand the 38 steps guide to deploy a service.
> - Platform: We made this, we know better than you, you cannot use anything else. If you need new thing/improvement, create a ticket we will get back to you in 6 months to say we cannot do it due to other company wide very important initatives.
I think it is due to cynical takes like this that the industry is evolving towards “Use whatever you want, so long as you are open to being on-call for it yourself. Or you can use this Platform maintained by other people.”
Nothing sucks as much as being woken up by pages because some new, shiny, and untested piece of technology was used in production and broke in an unknown way.
What's cynical about it? If the platform team is on the way it becomes a problem. And going to be on-call is way to go if you want to have actual ownership, or it becomes to same dev and ops people split.
There is not an exact line. Platform team can easily abstract (i.e) Kubernetes deployment infrastructure, but not everything else that you might be needing.
Then the team who made their own platform hire DevOps and SRE to janitor what they created because it's spiraling out of control, and now you have another platform! It's the circle of IT life.
How did SRE become such a non-skilled job almost like a CISSP auditor is for security?
Originally it was supposed to be a SWE who could also do operations, but there seems to have been a quick race to the bottom to remove all the SWE tasks and turn them into pure operations policy wonks.
SRE is a highly skilled job. It is actually difficult. Doing a root cause analysis or investigating an infrastructure blackhole is a very rare skill. You have to be aware of the end-to-end landscape, or atleast communicate well with the stakeholders who own the domain and resolve issues, manage expectations, huge pressure dealing with time critical issues.
Having seen all of roles, being SRE was the only time when a slack message sounds would trigger anxiety in me.
It was always like that outside of select few like Google. Most companies’ infra is not complex enough to warrant anything beyond sysadmin skills. Fwiw google sres also had two distinct subroles within sre one of which is not software focused
You are mistaking your personal experience with various companies and positions to the actual industry standard. I've worked on the same roles as you did and my experience is completely different and very positive.
Are good ideas just destined to be corrupted? Some examples:
Royce: "These are the flaws in the 'Waterfall model'" -> everybody looks at his diagram and uses it [1]
Agile: "Individuals and interactions over processes and tools" -> SAFe [2]
DevOps: "Assign development and operations the same business goals so they work together, rather than against each other" -> "DevOps was a cultural shift giving development teams more control over shipping code to production" (this article)
Are these really good ideas if they can't survive the collision with the real world? While I don't doubt that there are lots of smart people behind them, knowing what you should ideally do and knowing what would be the best compromise, in reality, are two very different sets of skills.
For example, agile was never going to work according to the rules, because "individuals and interactions over processes and tools" are not how most companies work.
There's probably a parallel to draw with programming languages. A few people will use Haskell or Lisp or Idris and be at the bleeding edge, but most people are satisfied with Java that sometimes cherrypicks good features.
Both of those seem to be rooted in aversion to risk, or (inclusive) managers making most of the decisions. I'd say that's because developers tend to have different values from other people, often valuing stability a bit less and "the right solution" a bit more.
> I'd say that's because developers tend to have different values from other people, often valuing stability a bit less and "the right solution" a bit more.
You're hinting at what the original DevOps idea was trying to solve. The traditional view is that Developers value shipping features while Ops engineers value stability/uptime. It should be easy to see why these differing values cause friction between these two groups.
The way DevOps was trying to solve this was getting _management_ to assign incentives/values/goals that would apply to _ both_ groups. An example might be increasing user engagement.
Aligning these two groups should be the main takeaway. The reason why The Phoenix Project book was so successful was it perfectly described this adversarial relationship. I'd certainly seen the same thing playing out at several companies I'd worked for.
Yeah, pretty much. But don't despair, this is how the industry progresses.
First, elite practitioners identify flaws in the standard practices of some corner of the industry and figure out a way to ameliorate them. They give it a name so they can talk about it, write about it, organize conferences etc. They're mainly interested in disseminating this good idea.
The idea becomes popular, and a cottage industry springs up. Some of the original proponents become consultants, but there are others who were early adopters, and many more who are jumping on the trend. You also get an ecosystem of open source and commercial tools. This starts to warp the original ideas, as they stop being about purely about improving results and incorporate a bias for generating more consulting or tool revenue.
This drives wider adoption. Companies start looking for people with experience in the new thing, and people start putting it on their resume. It gets applied in situations it wasn't meant for, sometimes on purpose and sometimes by accident. You start to see "no true Scotsman" discussions where detractors claim they tried the thing and it didn't work and proponents claim they weren't doing it right. There's also cargo culting, where people who don't really understand the ideas try to implement the practices with varying degrees of success.
Eventually things get watered down to the point where the terminology starts to just mean "good" or "cool". The actual practitioners stop using it because it's no longer useful for communication and it falls out of favour.
But. All is not lost! The original ideas were good, and they've been widely disseminated. They get taught to young people joining the industry, and they start to be part of "how we do things." They don't need special names to distinguish them from "mainstream" practices because they are the mainstream. In fact, young people sneer at them because duh, without knowing what they were a reaction to.
You can see this with Agile, Lean and DevOps. On the business side, "disruption". The cycles are slower and maybe less intense in more CS and pure coding domains, but you find it there too with scripting languages, object oriented languages, TDD. Functional programming is leaving the consulting phase and seeing wider adoption.
This is probably not how we'd like to think things work. But they do work.
I see DevOps as a culture shift that is working towards a culture where developers can easily build, deploy, monitor and alert on their code in production. It is a direct counter-attack to the pattern of developers throwing their code over the wall and hoping that a sys admin will deploy it. You need expertise in tooling and processes in order to achieve the culture shift, that is where these 3 positions come in.
I see each role as an evolution where you go from DevOps -> SRE -> Platform Engineer. Automating the infrastructure and tooling is the catalyst. You can have any of these roles in your company based on how far along the path your company is, how on board management is and how interested your development teams are in growing/learning these practices.
DevOps writes scripts/code to automate CI/CD pipelines, creation of infrastructure, deployments. Once automated you move onto..
SRE writes scripts/code monitoring, alerting, SLOs/SLAs, incident processes. Once automated you move onto..
Platform Engineering where you write the tooling to make all of the above codified. Tooling could be anything from cli tools to kubernetes operators.
I say this as someone that has spent the last 3 years automating my way towards platform engineering.
I've been listening to the "DevOps is a culture, not a role" mantras on HN and elsewhere for years now. Meanwhile, I've been working precisely as a DevOps Engineer/SRE and doubling my income every year or two.
The job is what you and your colleagues make it out to be. You are there to fill a certain need and a knowledge gap within the team. Figure out what that is and you are golden.
Totally agree. In my experience it seems engineering titles and the associated role/duty are wildly inconsistent between companies. The company size and industry have a huge impact.
For some reason "DevOps Engineer" is much more polarizing than "FullStack Engineer" or "Senior Developer"
Heh I may have exaggerated a bit to make a point ;) realistically its more like every 2 years or so, and partially because I started from a junior role in an enterprise environment and worked my way up to independent consulting.
Generally in my experience, a company that's looking for a DevOps engineer does not know what DevOps is.
DevOps is great, but it's not a title. It's beautifully summarized in "The DevOps Handbook" and it's fictional counterpart "The Pheonix Project". It's about culture.
Some people might feel different and want to re-evaluate due to so many company adapting it in a similar vein many companies want to adapt agile. But make no mistake, you can't define it then, since then the context of the company defines the word. Thus sadly the word is slowly loosing its meaning.
This is likely due to lots of management people wanting to adapt the buzzword without understanding it. This since it has have had such a great success in many companies that actually know what it is, have taken the DevOps culture to heart and implemented processes in line with it.
Whoever gets too hung up on this must've never had to hire people to do what the DevOps culture they so want to implement needs.
If your plan is to just hire software engineers, you're going to have confused applicants, if your plan is to hire sysadmins, they probably will have a different skillset than you need. Most real companies hire DevOps engineers because that's the way to get the people with the skillsets you need.
Being so purist about this sounds to me like useless debate, but maybe you have better suggestions.
At my current place we stopped hiring DevOps and started hiring SREs + software engineers for specific internal teams, but for a few years there between 2010-2020, good luck getting people with DevOps skills without actually advertising DevOps roles.
Generally, in my experience, an individual who says, "DevOps is a culture, not a title", does not know what DevOps is. It can be both, and exclusive, at the same time.
I think there's a point to the blog article itself, but i think you miss a vital point in the conclusion. The way a DevOps position that is described in the blog post is a valid position that could have DevOps in the title. But that's not usually how the DevOps role is used. This can be easily seen in many listings of the job title.
The analogy with agile is pretty good here. Sure you could have an Agile Engineer, that works primarily with making sure the agile process is actually used and help facilitating that. Normally that would not be a position itself though, especially not an engineering one.
If you are out there interviewing for a DevOps job and you hear things like this: run. Every meeting you have with this person will be a living hell. Endless debates on semantics and definitions while your project is due today.
So you think the issue is semantics and not understanding? Being due today and having 5 developers thinking the end goal is different and working against each other is way worse then spending some time building consensus and work toward the same goal
In many way the adoption of DevOps has many similarities with the larger adoption of agile development. It just looses it original meaning in a world of little reflection and just surface level knowledge.
Those who can manage to surpass that though can get great productivity from it though.
I wrote a blog post about this relatively recently.
I was incredibly frustrated with everyone I spoke to having a different definition of DevOps. For many it’s just sysadmins rebadged. For others they think they sysadmins couldn’t code so it’s an evolution. For yet more they think it’s feature developers who manage ops.
Nobody has a formal definition that fits, the term only exists to obfuscate responsibility.
The term "DevOps" was originally coined to mean organizing teams so that development and operations were merged. That is, development teams were responsible for writing, deploying and operating services. It was a reaction to the then-common system where development and ops were separate.
But it was quickly coopted to be "ops, but cooler" because these sysadmins write code too. And then even that definition started to get coopted by people using it for other things. These days it can mean anything. Frankly, I see it as a small red flag. Anyone who uses it is basically jumping on yesterday's trendy jargon, and that's not a good sign.
I think it's good that you took the time to write such a detailed post, certainly better than mine in a lot of ways.
I agree that Development should be mostly self-service and that the goal of any "Ops" person is to get out of the way. "Automate yourself out of a job" is a common sysadmin mantra.
However I don't agree with your other points, there's some over exaggeration when you say "if devops doesn't exist then thats a red flag", if devops can mean anything then it's a useless term and absence of it shouldn't be seen as a red flag.
>Shoud DevOps engineer be a role? Yes. Absolutely.
Small typo here, and of course I disagree with the statement and preceding paragraph.
I think "Platform Engineer" is closer to what your definition of DevOps is.
The point of my post is that everyone has their own definition, which is why I'm frustrated at the term.
> Infrastructure Engineer
Regarding this... This is actually my job title right now, but it exists outside of computing: "Infrastructure Engineer" being the kind of person who makes bridges and roads and so on.
This is a very timely post for me. I was just writing a DevOps job listing, but it felt wrong. We don’t have a lot of code, but we do have a lot of AWS infrastructure. It sounds like we should be looking for a Platform Engineer more than a DevOps Engineer. Of course the titles are less important than the work, but I think a different title will help focus the search better. So, thanks for posting!
You make a good point about cloud cost optimization. That is not a core DevOps function, but it is something we need. Yet another reason to refocus our search.
I see more and more "platform engineer" in job listing, for what require the same skills as infrastructure/hosting/system engineer (regarding SaaS, at least).
Maybe the next buzzword will be "platform engineer".
Sort of off-topic, though I'm looking for a role similar to what you described. If you're open to chatting about it, please do shoot me an email: notsure_12 at protonmail.com
DevOps Engineer is absolutely a title nowadays. Refusing it because you personally don’t agree with it doesn’t change anything; it’s what searched by both candidates as well as companies.
Well, thought I’d share my personal experience and the focus areas of our platform engineering team, since the DevOps/SRE definitions are more-or-less correct.
I’ve seen Platform Engineering take various different forms, but it’s current incarnation is split into 2 teams:
1. Developer Productivity. Ownership of quality, efficiency, and developer tools. A recent example project was improving the quality of our test data capabilities to make manual testing easier/more consistent.
2. Unified Client Platform. This team owns our design system and is the primary owner of our effort to unify on React.js/React Native, though a lot of the heavy lifting is distributed around the team.
(I mostly wanted to weigh in since at a mid-sized company at least, we’re not interested in building our own PaaS… k8s or Lambda is fine for that. Instead, we want to ensure developer onboarding is painless and anything specific to us is easily understood - the bulk of the surface area should be best-in-class 3rd party tools or ideally popular OSS frameworks.)
Readit News
- DevOps: Hired to do everything not involved in the feature development of main business. Range varies from Terraform to maintaining Jira, GSuite, Jenkins, ETL, BizOps. Maintains scripts and hacks everywhere.
- SRE: Orders teams to define SLOs, focuses only after incident procedures, not before. Insists on creating dashboards and putting them on TVs (when we had offices). Most eventually become vendor fans.
- Platform: We made this, we know better than you, you cannot use anything else. If you need new thing/improvement, create a ticket we will get back to you in 6 months to say we cannot do it due to other company wide very important initatives.
I love not being a regular developer and work on platform side, but its a very irregular space and very hard to hire.
As platform team member, you really have to know what to build, doing interviews, figuring out what developers and SREs really want, filter through what they are asking for, control through not-invented here syndrome, make build-vs-buy decision, create the community around the product you build within the organisation etc. You cannot just start building a PaaS (most common thing I have seen them build). It is actually quite complex if done right. Having said that, lot of organisation the definition is quite vague, political too and sometimes the boundaries are not clear.
Nobody asked for it and everyone is content rolling their own pipelines by hand, yet they've sunk a ton of time into it.
The most common hurdle is simply that most developers buried in enterprise software dev have no familiarity with the cloud or foundational DevOps tech like infra as code. So we typically end up building some form of deployment mechanism cobbled together with packer and terraform, but the real value in bringing in outside help is that we handle training and change management necessary to actually drive adoption.
“Build it and they will come” is a terrible design philosophy. You can’t just stand up a platform team and expect it to go well: a more transformational mindset inclusive of org design and strategic outlook is required, and this type of DevOps / SRE transformation is no less of a radical change than HR or finance transformation programs.
The problem is complexity is variable. For developers who never really learn how their code actually executes, or haven't had to be responsible for tuning and such, this is great, but for those of us who want to know where the rubber meets the road, these tools are kid-gloves. How can we fully optimize and support our code if we can't see the compute on which it runs? What other "benefits" will the system bring that we have to account for?
> Then make it so well-documented and easy to use that teams don't need to be _forced_ to use the platform tooling, they'll just use it because it's the most convenient thing to do.
Very optimistic. In my experience with this kind of thing with homegrown platforms, documentation was a distant last, because it always is, and we weren't left with other choices anyway. I would love to pick the best tool because it is convenient, but that, too, is variable. Maybe I know Kubernetes inside and out - that's plenty convenient for me, then, and will be better documented and discussed than any homegrown platform because the world can contribute to it.
I think one way of reading the comment above is that it's the effect of business incentives / Conway's law on various approaches to staffing the non-developer parts of your organization:
- DevOps is incentivized to be an extension of the dev team and get stuff into production, i.e., in the average company hiring "DevOps," the engineers operating production report up into existing dev management. Therefore you get "scripts and hacks" because you're never given the mandate to do anything better, and you're evaluated on how much you can manage to ship things to prod without building separate specialties, not how well you ship it to prod.
- SRE is incentivized to demonstrate good SRE practices and their value to the business. Incident response is a lot more visible than incident prevention. Picking an observabiity vendor who can get you nice graphs is a lot more visible than spending months making the right graphs. You're evaluated on how much you improve "reliability," which means you need to figure out how to measure it (and display it) in the first place, but it's not clear your measurement is what the broader business would measure.
- Platform engineering is incentivized to build up a well-defined platform and have their own products/services that are used internally. They are a development team of their own. So their value is most visible when those products exist and are widely used, and a little more cynically, when those products aren't unmodified vendor or OSS products. You're evaluated on the number of people using your product and how infrequently the rest of the company says "I'm just going to run this myself, give me an AWS account."
Any of these disciplines can be done well with strong management support, by which I mean when management actually cares about the long-term problem of running production well and can make informed decisions about how to staff that problem. (For myself, for what it's worth, I'm in a platform engineering organization but my current role is 80% to make it easier for people to use OSS and to reduce our deltas and 20% incident prevention.) But when incentives get disconnected from the business and the inertia is to keep delivering what people thought you should have delivered in the past, the disciplines break down in different ways.
I think it's just genuinely too difficult for most companies to do well and it's too easy to fall into the same old well trodden traps.
Documentation is something everybody professes to keep up to date, clear and complete, for instance, but IME it never truly is.
Most developers just need something like heroku, tsuru, appengine, or openstack. But because kubefans want to have fun too and try to be as cool as Google or Facebook we end up having to deal with tons of custom Golang tooling with fancy names, half assed documentation and grumpy looks when you ask for help because you don't understand the 38 steps guide to deploy a service.
I think it is due to cynical takes like this that the industry is evolving towards “Use whatever you want, so long as you are open to being on-call for it yourself. Or you can use this Platform maintained by other people.”
Nothing sucks as much as being woken up by pages because some new, shiny, and untested piece of technology was used in production and broke in an unknown way.
There is not an exact line. Platform team can easily abstract (i.e) Kubernetes deployment infrastructure, but not everything else that you might be needing.
Originally it was supposed to be a SWE who could also do operations, but there seems to have been a quick race to the bottom to remove all the SWE tasks and turn them into pure operations policy wonks.
Having seen all of roles, being SRE was the only time when a slack message sounds would trigger anxiety in me.
You didn't have to call me out like that.
My personal experience agrees 100% with what he has said :)
Royce: "These are the flaws in the 'Waterfall model'" -> everybody looks at his diagram and uses it [1]
Agile: "Individuals and interactions over processes and tools" -> SAFe [2]
DevOps: "Assign development and operations the same business goals so they work together, rather than against each other" -> "DevOps was a cultural shift giving development teams more control over shipping code to production" (this article)
[1]: https://en.wikipedia.org/wiki/Waterfall_model#History
[2]: https://scaledagile.com/safe-50/
For example, agile was never going to work according to the rules, because "individuals and interactions over processes and tools" are not how most companies work.
There's probably a parallel to draw with programming languages. A few people will use Haskell or Lisp or Idris and be at the bleeding edge, but most people are satisfied with Java that sometimes cherrypicks good features.
Both of those seem to be rooted in aversion to risk, or (inclusive) managers making most of the decisions. I'd say that's because developers tend to have different values from other people, often valuing stability a bit less and "the right solution" a bit more.
You're hinting at what the original DevOps idea was trying to solve. The traditional view is that Developers value shipping features while Ops engineers value stability/uptime. It should be easy to see why these differing values cause friction between these two groups.
The way DevOps was trying to solve this was getting _management_ to assign incentives/values/goals that would apply to _ both_ groups. An example might be increasing user engagement.
Aligning these two groups should be the main takeaway. The reason why The Phoenix Project book was so successful was it perfectly described this adversarial relationship. I'd certainly seen the same thing playing out at several companies I'd worked for.
First, elite practitioners identify flaws in the standard practices of some corner of the industry and figure out a way to ameliorate them. They give it a name so they can talk about it, write about it, organize conferences etc. They're mainly interested in disseminating this good idea.
The idea becomes popular, and a cottage industry springs up. Some of the original proponents become consultants, but there are others who were early adopters, and many more who are jumping on the trend. You also get an ecosystem of open source and commercial tools. This starts to warp the original ideas, as they stop being about purely about improving results and incorporate a bias for generating more consulting or tool revenue.
This drives wider adoption. Companies start looking for people with experience in the new thing, and people start putting it on their resume. It gets applied in situations it wasn't meant for, sometimes on purpose and sometimes by accident. You start to see "no true Scotsman" discussions where detractors claim they tried the thing and it didn't work and proponents claim they weren't doing it right. There's also cargo culting, where people who don't really understand the ideas try to implement the practices with varying degrees of success.
Eventually things get watered down to the point where the terminology starts to just mean "good" or "cool". The actual practitioners stop using it because it's no longer useful for communication and it falls out of favour.
But. All is not lost! The original ideas were good, and they've been widely disseminated. They get taught to young people joining the industry, and they start to be part of "how we do things." They don't need special names to distinguish them from "mainstream" practices because they are the mainstream. In fact, young people sneer at them because duh, without knowing what they were a reaction to.
You can see this with Agile, Lean and DevOps. On the business side, "disruption". The cycles are slower and maybe less intense in more CS and pure coding domains, but you find it there too with scripting languages, object oriented languages, TDD. Functional programming is leaving the consulting phase and seeing wider adoption.
This is probably not how we'd like to think things work. But they do work.
Dead Comment
I see each role as an evolution where you go from DevOps -> SRE -> Platform Engineer. Automating the infrastructure and tooling is the catalyst. You can have any of these roles in your company based on how far along the path your company is, how on board management is and how interested your development teams are in growing/learning these practices.
DevOps writes scripts/code to automate CI/CD pipelines, creation of infrastructure, deployments. Once automated you move onto..
SRE writes scripts/code monitoring, alerting, SLOs/SLAs, incident processes. Once automated you move onto..
Platform Engineering where you write the tooling to make all of the above codified. Tooling could be anything from cli tools to kubernetes operators.
I say this as someone that has spent the last 3 years automating my way towards platform engineering.
The job is what you and your colleagues make it out to be. You are there to fill a certain need and a knowledge gap within the team. Figure out what that is and you are golden.
I do agree though that the most important part of a professional life is to fill the gap within your team. But that's another discussion.
For some reason "DevOps Engineer" is much more polarizing than "FullStack Engineer" or "Senior Developer"
15k -> 30k -> 60k -> 120k
Also if you have stock at a successful company in the past couple of years things have gone vertical.
DevOps is great, but it's not a title. It's beautifully summarized in "The DevOps Handbook" and it's fictional counterpart "The Pheonix Project". It's about culture.
Some people might feel different and want to re-evaluate due to so many company adapting it in a similar vein many companies want to adapt agile. But make no mistake, you can't define it then, since then the context of the company defines the word. Thus sadly the word is slowly loosing its meaning.
This is likely due to lots of management people wanting to adapt the buzzword without understanding it. This since it has have had such a great success in many companies that actually know what it is, have taken the DevOps culture to heart and implemented processes in line with it.
If your plan is to just hire software engineers, you're going to have confused applicants, if your plan is to hire sysadmins, they probably will have a different skillset than you need. Most real companies hire DevOps engineers because that's the way to get the people with the skillsets you need.
Being so purist about this sounds to me like useless debate, but maybe you have better suggestions.
At my current place we stopped hiring DevOps and started hiring SREs + software engineers for specific internal teams, but for a few years there between 2010-2020, good luck getting people with DevOps skills without actually advertising DevOps roles.
What's DevOps skills in your opinion?
https://link.medium.com/tC5p4nfYCib
The analogy with agile is pretty good here. Sure you could have an Agile Engineer, that works primarily with making sure the agile process is actually used and help facilitating that. Normally that would not be a position itself though, especially not an engineering one.
If you are out there interviewing for a DevOps job and you hear things like this: run. Every meeting you have with this person will be a living hell. Endless debates on semantics and definitions while your project is due today.
Those who can manage to surpass that though can get great productivity from it though.
I was incredibly frustrated with everyone I spoke to having a different definition of DevOps. For many it’s just sysadmins rebadged. For others they think they sysadmins couldn’t code so it’s an evolution. For yet more they think it’s feature developers who manage ops.
Nobody has a formal definition that fits, the term only exists to obfuscate responsibility.
http://blog.dijit.sh/devops-confusion-and-frustration
But it was quickly coopted to be "ops, but cooler" because these sysadmins write code too. And then even that definition started to get coopted by people using it for other things. These days it can mean anything. Frankly, I see it as a small red flag. Anyone who uses it is basically jumping on yesterday's trendy jargon, and that's not a good sign.
I agree that Development should be mostly self-service and that the goal of any "Ops" person is to get out of the way. "Automate yourself out of a job" is a common sysadmin mantra.
However I don't agree with your other points, there's some over exaggeration when you say "if devops doesn't exist then thats a red flag", if devops can mean anything then it's a useless term and absence of it shouldn't be seen as a red flag.
>Shoud DevOps engineer be a role? Yes. Absolutely.
Small typo here, and of course I disagree with the statement and preceding paragraph.
I think "Platform Engineer" is closer to what your definition of DevOps is.
The point of my post is that everyone has their own definition, which is why I'm frustrated at the term.
> Infrastructure Engineer
Regarding this... This is actually my job title right now, but it exists outside of computing: "Infrastructure Engineer" being the kind of person who makes bridges and roads and so on.
I've held multiple titles doing this. Titles doesn't matter, because nobody respects what the titles implies.
Look for CloudOps, we often also have multiple certificates from Azure/AWS/DigitalOcean/Alibaba etc.
We not only keep infrastructure in code, but also make sure you are not ripped off by cloud provider and your architecture makes sense..
Maybe the next buzzword will be "platform engineer".
EDIT: Great explanation from one of the commenters https://link.medium.com/tC5p4nfYCib
I’ve seen Platform Engineering take various different forms, but it’s current incarnation is split into 2 teams:
1. Developer Productivity. Ownership of quality, efficiency, and developer tools. A recent example project was improving the quality of our test data capabilities to make manual testing easier/more consistent.
2. Unified Client Platform. This team owns our design system and is the primary owner of our effort to unify on React.js/React Native, though a lot of the heavy lifting is distributed around the team.
(I mostly wanted to weigh in since at a mid-sized company at least, we’re not interested in building our own PaaS… k8s or Lambda is fine for that. Instead, we want to ensure developer onboarding is painless and anything specific to us is easily understood - the bulk of the surface area should be best-in-class 3rd party tools or ideally popular OSS frameworks.)