35 ms·

DevOps, SRE, and Platform Engineering

173 points by limonod 5y ago

longcommonname 5y ago
What resources are there that go inepth into platform engineering? I currently see myself in a position where I'm responsible for direction of a platform. What best practices are there around common things like urn, config management, infra provisioning, and other common components. I have my best practices, which I could enforce on users. But how do I know what is most important to focus on.
- brujoand 5y ago
  I wrote down my experiences with building delivery platforms, which answers some of this. Might be interesting https://blog.brujordet.no/post/devops/building-a-delivery-platform/ https://blog.brujordet.no/post/devops/building-a-delivery-pl... But with regards to purely technical stuff like what tools to choose and how to use them you’ll need experience, either your own or someone elses. There’s really no replacement in my opinion. I had loads of experienced people around me previously, but now that I work more or less alone in the field I rely a lot on community slack channels for the various tools and debugging. It’s amazing to be stuck trying to figure out how to best use Loki for logging, jump on their slack and get advice from the Lead Engineer working on the tool. Or getting input on what tools to use from 50 different people in different companies through /r/devops on reddit.
Hnrobert42 5y ago
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!
- dilyevsky 5y ago
  DevOps is not a title. That’s like looking for “agile engineer”. What it sounds like you need is a systems eng / sysadmin
  - klohto 5y ago
    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. EDIT: Great explanation from one of the commenters https://link.medium.com/tC5p4nfYCib https://link.medium.com/tC5p4nfYCib
    - dilyevsky 5y ago
      Lol that is a ridiculous explanation. Most companies’ idea of “developer operations” is “someone needs to babysit that dinky old jenkins”, those that are serious about it certainly don’t call it devops in their job reqs
      - klohto 5y ago
        Again, you’re gatekeeping because of your personal believe. Check how the market looks like outside of your bubble. Industry has moved on and if you need somebody to manage direction of your infrastructure (yes, be it just Jenkins or whole AWS) you will search for DevOps Engineer. There is no serious tier.
        dilyevsky 5y ago
        > Industry has moved on and if you need somebody to manage direction of your infrastructure If you needed dedicated people so dev teams can just throw it over the fence to them that already existed and was just called sysadmins/ops. No need to invent a new term for that. More like some companies didn’t get the memo that devops != sysadmin, not even a title at all. > There is no serious tier. Well who’s in a bubble really?
      - 5y ago
damagednoob 5y ago
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) [1]: https://en.wikipedia.org/wiki/Waterfall_model#History https://en.wikipedia.org/wiki/Waterfall_model#History [2]: https://scaledagile.com/safe-50/ https://scaledagile.com/safe-50/
- Zababa 5y ago
  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.
  - damagednoob 5y ago
    > 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.
dijit 5y ago
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. http://blog.dijit.sh/devops-confusion-and-frustration http://blog.dijit.sh/devops-confusion-and-frustration
- nhumrich 5y ago
  I also recently wrote a blog post about this, trying to sum up why different definitions exist. https://link.medium.com/tC5p4nfYCib https://link.medium.com/tC5p4nfYCib
  - dijit 5y ago
    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.
    - bigiain 5y ago
      > "Infrastructure Engineer" being the kind of person who makes bridges and roads and so on. Reminds me of an old old joke. There are two kinds of Engineers. Mechanical Engineers who build weapons, and Civil Engineers who build targets.
Jumziey 5y ago
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.
- Jumziey 5y ago
  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.
- nhumrich 5y ago
  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. https://link.medium.com/tC5p4nfYCib https://link.medium.com/tC5p4nfYCib
  - Jumziey 5y ago
    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.
WinDoctor 5y ago
Usually a bunch of wildly different teams are called "DevOps" But I found a nice resource to reference where we have 7 "DevOps" team anti-patterns and 9 valid team patterns that people call "DevOps": https://web.devopstopologies.com/ https://web.devopstopologies.com/
fenk85 5y ago
"So, if after pushing the changes to the repository, you got unlucky enough to notice a bug only on the live version of your service, you'd need to beg for an extra rollout. It most definitely sucked" Been there, had the CEO tell whole company to write code without bugs, sigh...
CSDude 5y ago
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.
- royjacobs 5y ago
  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.
  - CSDude 5y ago
    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.
  - pydry 5y ago
    That's a wonderful idea in theory but I've never seen it work out that way in practice. 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.
  - 5y ago
trhoad 5y ago
DevOps is a culture, where there is a mindset of "build it, run it, own it". SRE is a job title. A new job title for what used to called System Administrators, except Google called them SRE's so everyone else joined in.
- deleted 5y ago
  [deleted]
crypt1d 5y ago
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.
- Jumziey 5y ago
  You having a successful career is not really relevant to the discussion. 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.
  - crypt1d 5y ago
    Its relevant in the context of showing just how little weight the 'devops is not a role' view has in the real world :)
    - dijit 5y ago
      if it were to be called "Release Engineering" and the pay was the same, would it matter?
- moondev 5y ago
  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"
- hacker_newz 5y ago
  How do you double your income yearly?
  - poooogles 5y ago
lazyweb 5y ago
Started out 10 years ago as IT Administrator. Transitioning from platform (Company A) to DevOps (Company B) soon. I'm convinced that DevOps, for better or worse, is where the money is / will be. Platform is still quite close to the classic Sysadmin from 10-20 years ago. Sure, there's some IaC and pipelines and automation, but depending on the company, it might as well be 2007 and you're wrangling bash scripts on individual hosts.
g051051 5y ago
DevOps and Agile: The two worst things ever to happen to software development (and developers).
- moondev 5y ago
  What else is in your top 10 worst things list? Version control? Stack Overflow? The Internet?
  - g051051 5y ago
    The Internet, obviously. But that's the worst thing to happen to everybody, not just Software Developers.
    - moondev 5y ago
      heh you've got a point - I don't think anything else comes close
midrus 5y ago
As a developer, I love the idea of operating, maintaning, deploying and monitoring the services I work on, as long as I'm using s proven platform such as appengine, tsuru, openstack, heroku, etc. I don't want to waste my life understanding your custom reinvented wheel Golang tooling around kubernetes and 50 steps guides to do anything.
bpicolo 5y ago
Platform teams have become my bread and butter. They come with an interesting set of challenges. One of the biggest of those, and the reason it can be a challenging position to be in, is that the person managing the team, coming up with the vision and roadmap, and even the architecture direction are often the same person. Few people around you are experts in building a good vision, strategy, or roadmap for a platform organization. It’s a skill set heavily overlapping with product strategy but also completely divergent. If you’re in this position, you’ll be doing several of these things poorly at any given point in time. (My current employer sits on the opposite side and has made sure we have a fully engaged product partner to do this well, which is a breath of fresh air. It's a much different working relationship than with a product partner in user-facing teams) It’s a high leverage position and can provide a center of excellence for the rest of the organization to emulate. You tend to be very visible among developers in the org if you’re doing it well, and you drive a lot of cross-cutting architectural goals. On the team building side, hiring people that thrive doing platform work can also be tough! It’s lower visibility, but provides a unique set of technical challenges and an opportunity for building technical breadth you find in few other roles. Early on in your career can be a great time to explore this sort of work. Repetition is low, and you build a lot of tech chops through the work. Try to be somewhere where it seems like a first class citizen in the organization ecosystem with engagement from product, too. And for what it's worth, I don't think your general goal should be to attempt to build over buy. Helping teams adopt and successfully use paid-for tools is a big part of the gig.
rickspencer3 5y ago
I work on a Platform team, but I'm wondering whether we should rename it. We do provide CI/CD to the rest of the company, and we provide an internal development platform. Our biggest focus, though, is providing the platform upon which our customers build their apps. We are a Multi-Tenant SaaS development platform. So we offer the APIs and run "The Platform" in production, which includes a database, a task system, a programming language, etc...
cbushko 5y ago
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.
philipkimmey 5y ago
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.)
throwaway984393 5y ago
"Theory" DevOps: Make the developers work with infrastructure better, deploy faster, have less errors! SRE: Make the products more reliable, get failures down to the minimum, have less toil! Platform: Be more efficient by standardizing technology across a large organization! "Reality" DevOps: A sysadmin that writes Terraform SRE: A sysadmin that writes Terraform and knows when the site goes down and if it's important Platform: A couple of sysadmins forcing everyone to use one set of technology in one way without ever talking to anyone about what to build or how to use it
badmadrad 5y ago
Yeah tech is definitely a semantics and buzz word race, but at the end of the day if you see SRE, DevOps, or Platform Engineering in your title understand you are moving into an organization that has the expectation that running production workloads/systems should require minimal human interaction, scale horizontally, and be resilient to failure/disaster. Sometimes you are siloed to SRE work. Sometimes to Platform or DevOps work as defined by your leaders. Or Sometimes you wear all three hats. Its completely situational but more than likely you will have a role in automating away problems that improve stability, increase visibility, and reduce manual interventions on the production systems. The same sore of redundant and interchangeable titles exists for software engineers. Senior Software Engineer or Lead Software Engineer or Staff Software Engineer or Principal Software Engineer Try to explain those differences.

173 points by limonod 5y ago

What resources are there that go inepth into platform engineering? I currently see myself in a position where I'm responsible for direction of a platform. What best practices are there around common things like urn, config management, infra provisioning, and other common components. I have my best practices, which I could enforce on users. But how do I know what is most important to focus on.

brujoand 5y ago
I wrote down my experiences with building delivery platforms, which answers some of this. Might be interesting https://blog.brujordet.no/post/devops/building-a-delivery-platform/ https://blog.brujordet.no/post/devops/building-a-delivery-pl... But with regards to purely technical stuff like what tools to choose and how to use them you’ll need experience, either your own or someone elses. There’s really no replacement in my opinion. I had loads of experienced people around me previously, but now that I work more or less alone in the field I rely a lot on community slack channels for the various tools and debugging. It’s amazing to be stuck trying to figure out how to best use Loki for logging, jump on their slack and get advice from the Lead Engineer working on the tool. Or getting input on what tools to use from 50 different people in different companies through /r/devops on reddit.

Hnrobert42 5y ago

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!

dilyevsky 5y ago
DevOps is not a title. That’s like looking for “agile engineer”. What it sounds like you need is a systems eng / sysadmin
- klohto 5y ago
  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. EDIT: Great explanation from one of the commenters https://link.medium.com/tC5p4nfYCib https://link.medium.com/tC5p4nfYCib
  - dilyevsky 5y ago
    Lol that is a ridiculous explanation. Most companies’ idea of “developer operations” is “someone needs to babysit that dinky old jenkins”, those that are serious about it certainly don’t call it devops in their job reqs
    - klohto 5y ago
      Again, you’re gatekeeping because of your personal believe. Check how the market looks like outside of your bubble. Industry has moved on and if you need somebody to manage direction of your infrastructure (yes, be it just Jenkins or whole AWS) you will search for DevOps Engineer. There is no serious tier.
      - dilyevsky 5y ago
        > Industry has moved on and if you need somebody to manage direction of your infrastructure If you needed dedicated people so dev teams can just throw it over the fence to them that already existed and was just called sysadmins/ops. No need to invent a new term for that. More like some companies didn’t get the memo that devops != sysadmin, not even a title at all. > There is no serious tier. Well who’s in a bubble really?
    - 5y ago

damagednoob 5y ago

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) [1]: https://en.wikipedia.org/wiki/Waterfall_model#History https://en.wikipedia.org/wiki/Waterfall_model#History [2]: https://scaledagile.com/safe-50/ https://scaledagile.com/safe-50/

Zababa 5y ago
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.
- damagednoob 5y ago
  > 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.

dijit 5y ago

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. http://blog.dijit.sh/devops-confusion-and-frustration http://blog.dijit.sh/devops-confusion-and-frustration

nhumrich 5y ago
I also recently wrote a blog post about this, trying to sum up why different definitions exist. https://link.medium.com/tC5p4nfYCib https://link.medium.com/tC5p4nfYCib
- dijit 5y ago
  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.
  - bigiain 5y ago
    > "Infrastructure Engineer" being the kind of person who makes bridges and roads and so on. Reminds me of an old old joke. There are two kinds of Engineers. Mechanical Engineers who build weapons, and Civil Engineers who build targets.

Jumziey 5y ago

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.

Jumziey 5y ago
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.
nhumrich 5y ago
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. https://link.medium.com/tC5p4nfYCib https://link.medium.com/tC5p4nfYCib
- Jumziey 5y ago
  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.

WinDoctor 5y ago

Usually a bunch of wildly different teams are called "DevOps" But I found a nice resource to reference where we have 7 "DevOps" team anti-patterns and 9 valid team patterns that people call "DevOps": https://web.devopstopologies.com/ https://web.devopstopologies.com/

fenk85 5y ago

"So, if after pushing the changes to the repository, you got unlucky enough to notice a bug only on the live version of your service, you'd need to beg for an extra rollout. It most definitely sucked" Been there, had the CEO tell whole company to write code without bugs, sigh...

CSDude 5y ago

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.

royjacobs 5y ago
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.
- CSDude 5y ago
  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.
- pydry 5y ago
  That's a wonderful idea in theory but I've never seen it work out that way in practice. 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.
- 5y ago

trhoad 5y ago

DevOps is a culture, where there is a mindset of "build it, run it, own it". SRE is a job title. A new job title for what used to called System Administrators, except Google called them SRE's so everyone else joined in.

deleted 5y ago
[deleted]

crypt1d 5y ago

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.

Jumziey 5y ago
You having a successful career is not really relevant to the discussion. 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.
- crypt1d 5y ago
  Its relevant in the context of showing just how little weight the 'devops is not a role' view has in the real world :)
  - dijit 5y ago
    if it were to be called "Release Engineering" and the pay was the same, would it matter?
moondev 5y ago
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"
hacker_newz 5y ago
How do you double your income yearly?
- poooogles 5y ago

lazyweb 5y ago

Started out 10 years ago as IT Administrator. Transitioning from platform (Company A) to DevOps (Company B) soon. I'm convinced that DevOps, for better or worse, is where the money is / will be. Platform is still quite close to the classic Sysadmin from 10-20 years ago. Sure, there's some IaC and pipelines and automation, but depending on the company, it might as well be 2007 and you're wrangling bash scripts on individual hosts.

g051051 5y ago

DevOps and Agile: The two worst things ever to happen to software development (and developers).

moondev 5y ago
What else is in your top 10 worst things list? Version control? Stack Overflow? The Internet?
- g051051 5y ago
  The Internet, obviously. But that's the worst thing to happen to everybody, not just Software Developers.
  - moondev 5y ago
    heh you've got a point - I don't think anything else comes close

midrus 5y ago

As a developer, I love the idea of operating, maintaning, deploying and monitoring the services I work on, as long as I'm using s proven platform such as appengine, tsuru, openstack, heroku, etc. I don't want to waste my life understanding your custom reinvented wheel Golang tooling around kubernetes and 50 steps guides to do anything.

bpicolo 5y ago

Platform teams have become my bread and butter. They come with an interesting set of challenges. One of the biggest of those, and the reason it can be a challenging position to be in, is that the person managing the team, coming up with the vision and roadmap, and even the architecture direction are often the same person. Few people around you are experts in building a good vision, strategy, or roadmap for a platform organization. It’s a skill set heavily overlapping with product strategy but also completely divergent. If you’re in this position, you’ll be doing several of these things poorly at any given point in time. (My current employer sits on the opposite side and has made sure we have a fully engaged product partner to do this well, which is a breath of fresh air. It's a much different working relationship than with a product partner in user-facing teams) It’s a high leverage position and can provide a center of excellence for the rest of the organization to emulate. You tend to be very visible among developers in the org if you’re doing it well, and you drive a lot of cross-cutting architectural goals. On the team building side, hiring people that thrive doing platform work can also be tough! It’s lower visibility, but provides a unique set of technical challenges and an opportunity for building technical breadth you find in few other roles. Early on in your career can be a great time to explore this sort of work. Repetition is low, and you build a lot of tech chops through the work. Try to be somewhere where it seems like a first class citizen in the organization ecosystem with engagement from product, too. And for what it's worth, I don't think your general goal should be to attempt to build over buy. Helping teams adopt and successfully use paid-for tools is a big part of the gig.

rickspencer3 5y ago

I work on a Platform team, but I'm wondering whether we should rename it. We do provide CI/CD to the rest of the company, and we provide an internal development platform. Our biggest focus, though, is providing the platform upon which our customers build their apps. We are a Multi-Tenant SaaS development platform. So we offer the APIs and run "The Platform" in production, which includes a database, a task system, a programming language, etc...

cbushko 5y ago

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.

philipkimmey 5y ago

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.)

throwaway984393 5y ago

"Theory" DevOps: Make the developers work with infrastructure better, deploy faster, have less errors! SRE: Make the products more reliable, get failures down to the minimum, have less toil! Platform: Be more efficient by standardizing technology across a large organization! "Reality" DevOps: A sysadmin that writes Terraform SRE: A sysadmin that writes Terraform and knows when the site goes down and if it's important Platform: A couple of sysadmins forcing everyone to use one set of technology in one way without ever talking to anyone about what to build or how to use it

badmadrad 5y ago

Yeah tech is definitely a semantics and buzz word race, but at the end of the day if you see SRE, DevOps, or Platform Engineering in your title understand you are moving into an organization that has the expectation that running production workloads/systems should require minimal human interaction, scale horizontally, and be resilient to failure/disaster. Sometimes you are siloed to SRE work. Sometimes to Platform or DevOps work as defined by your leaders. Or Sometimes you wear all three hats. Its completely situational but more than likely you will have a role in automating away problems that improve stability, increase visibility, and reduce manual interventions on the production systems. The same sore of redundant and interchangeable titles exists for software engineers. Senior Software Engineer or Lead Software Engineer or Staff Software Engineer or Principal Software Engineer Try to explain those differences.