DevOps — Fallacy of cross training Ops to becoming a developer

Image source: https://blog.geekuni.com/2019/05/cross-training-to-grow-your-perl-teams.html

In the first place, is there a need to cross-train the operation people to be a developer and start checking in code for features that will drive business outcomes? In the beginning, there is a belief that in DevOps, we will have multiple skillset within the development team. An individual’s ability to combine skills will help balance the work between the group and expect fewer resources needed to deliver the same set of features. During crunch time, the OpsPeople is supposed to pick the slack from the development members to develop and contribute code. The perception builds from the notion that a waterfall delivery process follows the process of design, develop, deploy and deliver. Is the operation team thought to be only needed in the last? Is this true? Let’s take a deeper look at what happens in a project. Does it matter if the team follows an agile or waterfall methodology process?

People — Traits differences between a developer and an operation engineer?

1. Skillset — Developers, as the name of the role, focus on creating features and functions with their coding capabilities. What the operation engineers are generally interested in is looking at automation capabilities. Usually, creating these automation scripts are in languages and frameworks that are not common to the developers. YAML is a human-readable data-serialization language the operation engineers will be looking at optimizing daily. The lack of usage does not mean that an average developer is not capable of mastering the language. However, the developed application generally does not require them to create complex YAML code. The concept of objects in a Java or python is not the same as an object in YAML, which usually refers to a target of infrastructure components; name an example.
2. Mindset and Interest — Features and Functionality vs. Automation. Both Dev and Ops are concerned about performance, and hence they will put that as an essential element. In an operational context, performance is subjective as the work requires interaction with an out-of-band component and activities. Operational people are more concerned about accuracies and audibility. Hence, when building automated scripts, they need to ensure that the actions are accurate and repeatable. Generally, repeatable consistency is expected from the team’s output.
3. Deliverables and outcome — Operation engineers’ measurements are based on environment setup, completed deployment, or closed tickets. Results measure for a developer are features and functions delivered and tested. The results are counter-checked with the requirements from the business users.

Expectations — Peers and senior stakeholders to define their OKRs

1. Peers — Typical will seek to look for advisories. Hence, the kind of advisories for the operation team will focus on automation, compliance, and audit areas. The assistance might generally focus on coding for security, performance, and integration for developers.
2. Senior stakeholders — Expect the operation team to be on standby to get the system back online in an outage. Hence they are the benchmark against the system’s RPOs and RTOs metrics. On the other hand, the developers are measured by the velocity of converting ideas into products. Developers are deemed as resources of higher business value. They are expected to work with the business side of the organsiation as they need to develop skills to understand the business demands and context. This will ensure that the deliverables are business measurables. Operation team members are generally in charge of working with external vendors where the collaboration is technology.
3. Working hours — Operation engineers are required to rotate on shift. They need to be on standby whenever there are any issues with the applications and system. There are the first to be called upon when an outage is detected. Usually, they are considered as the L1 and L2 support. In contrast, typically, the developers are set up as L3 support. The arrangement is to shield the developers from providing BAU support, allowing the developer to divert focus on coding and delivering features. In recent years, with the rise of SRE practices that started from inside Google, the operation team also began to work in a broader scope where they are required to code. Usually, the code they build focuses on automation rather than building business functionality.

Therefore with the skills gap and the traits that one have developed their skill set during their career,