Find us on social media
Blog

Part 2: DevOps from Developer Empowerment to a Separate Role

  • WP_Term Object ( [term_id] => 45 [name] => AWS [slug] => aws [term_group] => 0 [term_taxonomy_id] => 45 [taxonomy] => post_tag [description] => [parent] => 0 [count] => 63 [filter] => raw ) AWS
  • WP_Term Object ( [term_id] => 104 [name] => CTO Corner [slug] => cto-corner [term_group] => 0 [term_taxonomy_id] => 104 [taxonomy] => post_tag [description] => [parent] => 0 [count] => 11 [filter] => raw ) CTO Corner
  • WP_Term Object ( [term_id] => 9 [name] => DevOps Automation [slug] => devops-automation [term_group] => 0 [term_taxonomy_id] => 9 [taxonomy] => post_tag [description] => [parent] => 0 [count] => 56 [filter] => raw ) DevOps Automation
  • WP_Term Object ( [term_id] => 40 [name] => Infrastructure-as-Code [slug] => infrastructure-as-code [term_group] => 0 [term_taxonomy_id] => 40 [taxonomy] => post_tag [description] => [parent] => 0 [count] => 30 [filter] => raw ) Infrastructure-as-Code
Part 2: DevOps from Developer Empowerment to a Separate Role
Author: DuploCloud | Monday, July 25 2022
Share
Content

Previously we described how adoption of Service Oriented Architecture (SOA) at AWS gave birth to a DevOps culture where Developers would own the E2E lifecycle of an application from coding, running deployments to maintaining uptime of the app. Today’s DevOps is not about Developers owning operations but is about operators learning to Develop automation code. 

DevOps today is a skill and a discipline that could not be farther from developers. It is basically a new job profile, it is IT version 2.

At the time of this writing there were 55,000 DevOps openings in Linkedin. We rarely come across organizations where developers operate their own infrastructure. The resulting impact on productivity and the original goals of SOA is glaring. While at AWS a single engineer scales to operating thousands of workloads with lightning release cycles. In mainstream IT for every 50 Virtual Machines there are one or even 2 DevOps engineers. Getting an infrastructure to conform to a basic compliance standard like SOC 2 takes 6 months.

So what went wrong? When the concepts of SOA made their way from AWS to mainstream IT why didn’t the same happen with the DevOps culture? The short answer is the technology that enabled SOA came to the mainstream software industry, but the corresponding operations and infrastructure automation technology never did. SOA was propelled by the advent of Docker and scores of public cloud PaaS services. No such transformation came about in IT tools that empowered developers to take on operations. 

There are two reasons for this: (a) the technology that enabled DevOps at AWS was custom built for in-house use targeting Highly Skilled AWS Developers and not mainstream developers, (b) developer empowerment in IT operations was not enthusiastically welcomed by large swaths of IT in mainstream enterprises. 

Instead of giving control to Developers, IT teams advocated for the upliftment of the existing IT workforce with Infrastructure-as-Code.

The original focus of AWS was to enable Infrastructure-as-a-Service, eliminating on-premise IT infrastructure. As IaaS picked up, from originally appealing to SMB developers, cloud became very appealing to enterprises. A lot of original AWS adoption was for extension of on-premise datacenter and workload migrations; all projects owned by IT. AWS operations was becoming a highly sought after skill within enterprise IT and IT controlled major decisions pertaining to AWS projects. 

“While the term DevOps started becoming associated with this upliftment of legacy IT, there was a problem. “Dev” was missing in DevOps. Along came Hashicorp with Infrastructure-as-Code (Terraform).“ 

Infrastructure-as-Code brought the development element into operations. Many operators were already familiar with scripting via bash, powershell, chef and puppet. IAC seemed achievable. IAC never abstracted any of the operational or security nuances from the user, who is required to be a subject matter expert in the same. Developers who had programming skills lacked this SME and today we rarely see an organization where developers run operations at scale by self authoring IaC.

Operating at AWS scale was never a goal for mainstream IT anyways. Also within mainstream IT many cloud native organizations were able to hire highly skilled engineers who were very good at IaC and could operate a highly efficient cloud infrastructure compared to their peers. A few examples are companies in Silicon Valley like AirBnb, Facebook, Intuit, LinkedIn and so on. The success of the new “DevOps'' along with the advent of more and more application centric PaaS in cloud like Kubernetes, SQSS, SNS, Managed Databases, Kafka, etc. put a lot of pressure on IT teams across the board to get these highly sought after DevOps engineers who knew how to build and enable these services. 

While developers still did not get down to operations, all IT teams wanted to become “DevOps” i.e. write code to automate operations. 

The IT tooling industry jumped in to assist this transformation of IT to DevOps and built many tools targeting this new DevOps audience. Empowering developers with operations was no one’s goal. The original meaning of DevOps, the culture of developers operating their own application in the cloud is now long lost. The term DevOps is now permanently sealed to mean a new skill and a job profile of an operations engineer in a culture where developers and operators are largely still as far apart as they were in the age of enterprise IT pre-cloud. Infrastructure is more sophisticated and DevOps is catching up, but in terms of productivity and scale of operations the industry is nowhere close to what the original DevOps culture set out to achieve.

Platform engineering is the future. In our survey of 500 IT professionals, we found that more than 90% of respondents have adopted or plan to adopt an IDP within the next five years. Learn more with your free copy:

New call-to-action
Author: DuploCloud | Monday, July 25 2022
Share