Problem solving in the IT Industry is generally classified into multiple skill-sets depending on the subset of the Engineering area being addressed — Backend, Frontend, Operations, Devops etc. With the advent of Cloud Computing and scale with which MNC’s/startups are periodically opting for Public Cloud Offerings(AWS, Azure, GCP), the Devops domain has picked up as a hot area of expertise in both the Job Market and also a major backbone of platform teams. Having had the opportunity to work on areas of Cloud and Devops for the last decade, writing this blog to elaborate on the key ingredients behind the “Devops Mindset”- a fundamental mindset which when shared independent of the actual engineering domain helps achieve Engineering and Product Excellence.
What is Devops MindSet?
As the syllables in the word, Devops is an intersection of Engineering activities from both Developer and Operations Domain with a sole purpose of improving the overall team productivity through measurable tools, processes and guidelines. Often misunderstood, Devops Mindset doesn’t come from the Tsarist school of Operational autocracy focused on regulating/standardising activities through centralised teams acting as an additional guardrail , hence slowing down the overall time to production.
The essence of Devops teams should be solving the recurring tedious manual problems through a Developer first thought process enabled by tools which give Development Teams enough domain agnostic flexibility over the baseline automation. The end customers of these tools and processes are Developers; hence creating a parallel rigid system is often the biggest pitfall of monolithic Devops teams. The key goal is the ability to measure the time saved for either Developer and Operational Impact, anything which doesn’t fall in the given bracket is a recipe for long time diminishing of productivity.
Devops Tasks- Evaluating the Quadrants
The entire lifecycle of tasks in the Devops Domain consists of 8 steps starting from the Deployment Plan to Monitor Production Systems. These tasks generally vary based on the choice of tools, programming languages and underlying systems and have readily available Copy and Paste Manuals on the Internet.
Through a simple X-Y quadrant of measuring the 2 key productivity metrics stated above, we will evaluate the regular Devops Tasks and the long term impact on Doing vs Not Doing them for team benefits.
- Task 3 — This is the quadrant of the least impact and is often done in the illusion of short term gains. Any Standardisation efforts done which makes it more cumbersome for tools to be used by developers/operations, degrading the overall time to onboard these tools. In some extreme cases The Efforts to Build > Time to Onboard+Use and hence adaptation of these frameworks are often limited. Some examples of these are — Standardising Repo Paths, Centralising Access Controls etc.
- Task 2 — Tasks in this quadrant often are done to improve the Time to production and reduce manual deficiency in pipelines. These are good to have when the ratio of Devops: Developers < Support: Developers and Dev teams are crunched on bandwidth on a shorter release cycle . As the product matures, these tools can be optimised for the Operational Benefits. Some examples are — Tenant Dependent CI/CD Pipelines etc.
- Task 4 — In cases where legacy products are transitioned with limited scope to change existing build/deploy and infrastructure pipelines, solving to improve Operational Productivity is a good starting point. Solving for Common Patterns based on existing production monitoring issues is the fulcrum for tasks in this quadrant. Some examples are — Automated Recovery Pipelines , Self Learning operational play-books, Replaying Production Issues etc.
- Task 1 — Quadrant of the highest impact, this contains building domain configurable tools for enhancing the efficiency on both the quadrants. These often take more time to build and bake before making it available to the end-users. However the long term benefits of these tools run across tenants and years of usage. Some example are Multi-Tenant CI/CD Systems, Unified Production Operational Dashboards
The above quadrant model is often difficult to keep at bay when picking up the daily Tracks often a differentiator between productive vs non-productive Devops Teams.
Also, ramble in about 140/280 letters at every nth hour at Amit Raj, in case any of you would like to build a sharing relationship.
