Moving to a DevOps state of mind

There are different definitions for DevOps – “Not a tool”, “You can’t buy it”, “It is a culture” on and on. But every one agrees on benefits and certain principles that enables those benefits. So I wanted to list the top 5 principles that I have been sprinkling in conversations over the years in my cloud transformation journeys at various organizations.

Principles:

1. Minimize Handoffs
2. Shift Left
3. Automate almost everything
4. Bake in Governance
5. Experiment, Learn and Refine

I will address each of these principles and give a commentary on each one to set context –

Minimize Handoffs – For our software development life cycle(SDLC) to move at a faster pace, we need to decrease dependencies on multiple people in the critical path of projects. When I look at a typical Resource Modeling spreadsheet, we see 10-15 roles needed to accomplish the project. This does not mean we need to make a single person play 5 roles, but instead let each role automate their part, set appropriate access permissions and let few people execute those tasks in a “self-service” mode at their pace and not have to be waiting on a shared resource. The parts that cannot be automated/self-served will still need “handoffs” but use standard project management techniques to schedule and minimize wait times.

Shift Left - The idea here is to place and enforce governance rules for example - security policies, vulnerability checks, testing etc as early as possible in our SDLC, rather than checking for these in pre-production environment. This is a big paradigm shift for cybersecurity and Infrastructure teams as they can get uncomfortable with Development teams now defining these policies in code as they can feel they will lose control. We can alleviate the fear by clarifying “Shift Left” does not mean developers are defining these policies, but instead the cybersecurity/infrastructure team can define these policies, standardize them and ensure that all applications implement these policies.

Automate almost everything– The idea here is all the provisioning/deprovisioning of infrastructure that the application will be running on should be automated. To be pragmatic, each organization can define their exception conditions where it might not be practical to automate everything (e.g: Create only once, Technical Limitations, Complexity Tradeoff), but set a high bar to not automate.

Bake in Governance – The idea here is to create the CI/CD pipeline which has governance steps baked in and done in an automated fashion with tools instead of sitting in a Review meeting going through a checklist. Another complementary mechanism to bake in governance is to provide a “Starter Application” to the development teams which already has the code structure, libraries, standards built in which set the guardrails for the applications.

Experiment, Learn and Refine – The idea here is the cloud space is evolving very rapidly and the standards for the organization also have to evolve. Each organization has to define the pace that is right for them as this has multiple dimensions like - Tech debt, consistency, having to support multiple standards, personnel, skillsets etc.

I would like to close out with the final thought of – every role as we move from On-Prem Siloed organization to a DevOps centric Cloud first organization, we need to learn new skillsets and adapt as our position on when we will be called to bat in the SDLC lifecycle might change.

Are there other principles that I should add to my list or did any of these principles not resonate with you ?