How To Adopt DevOps Framework For Executives

So you were tasked as the new DevOps czar in your organization. The first thing to do was getting fancier Title of members and call them "DevOps" with same skill sets, build a SWAT team, make process changes without understanding the IT Value Chain, nominate an app for pipeline, and claim L1 and L2 support DevOps/DevSecOps/SRE. Then make an endless plan for DevOps that never starts. Mistakes happen in production as you starts implementing DevOps, but pretend mask it in a jargon called "Fail Fast". There you have it, a DevOps. Wrong!!! That’s called ChaOps, aka Chaotic Operation.

Becoming a DevOps Champion is difficult. The success rate is low. Based on experience, I’ve seen countless executives attempt to do so yet fail to deliver. Their biggest mistake was simply changing the title of people to DevOps / DevSecOps / SRE. Those that stand a chance follow a simple recipe called the DevOps Adoption Framework. The one described in this article is my variation, just one among many, and is not a sure way to success but a guide to increase the chances of winning. This variation of the DevOps Adoption Framework may not be unique, as there may be others with the same thought process and experience as me. Note that culture and discipline will eat the best DevOps Adoption Framework and Strategy.

Below is the high-level illustration of How To Adopt DevOps Framework For Executives. We will discuss this one by one in the succeeding section of this post. For the time being, go over it and try to visualize.

Step 1: Discovery

During this phase, it is crucial for the DevOps Champion to evaluate the current and upcoming infrastructure, application inventory, architecture, IT Value Chain, and development process. The key takeaway here is to understand how the organization works, particularly in relation to the IT Value Chain. The IT value chain is defined as how a feature is conceptualized, developed, and delivered to the customers to add value.

Inputs:

• List of Applications

• Deployment Process

• Current Infrastructure Architecture

• Application Design

• Current Team Structure

Expected Outputs:

• Application Classifications

• Deployment Pain Points

• Infrastructure Limitations

• Technology Stack

Things to watch out:

Expect people to hide information during discovery. Win their trust to get what is necessary.

Step 2: Planning

The proposed team structure for DevOps will be presented. Identify competent existing talent to fulfill the DevOps vision. The identification must be based on skills and experience. Avoid onboarding yes-men or friends without talent. Discover new people who have potential, not just filling roles for favorites.

Provide an overview of the planned application design and categorization for transitioning to Kubernetes and implementing DevOps. Outline the infrastructure design required to back the project, ensuring scalability and adaptability. Establish a refined release process through enhancements identified during the Discovery session.

Inputs:

• All the output of step 1

Expected Outputs:

• Vision and Mission and KPI for DevOps

• DevOps Program Roadmap

• Project Timeline and Roadmap

• Costing and Funding

• DevOps Executive Committee

• Approved DevOps Team Structure

• Formal DevOps Champion

• Apps Prioritizations and Pilot Nominations

• Solution Design

• Build and Release Process

• Infrastructure Architecture in Cloud

• Pipeline Implementation and Deployment Playbook

• Approved DevOps Team Structure

• Map at least 3 KPI's for each stage of IT Supply Value Chain

Things to watch out:

Avoid Over planning. Do something simple and credible. Just enough to get started but not too much where everyone has something to say. There will be people who will try to figure out everything on the onset. Others will suddenly become a DevOps guru that knows the chemical composition of horse shoe nebula. Planning must be engineering, and process centric.

Step 3: Build

It's time to create a cloud infrastructure in AWS with a landing zone of at least 3 zones, using the CloudFormation Template in Control Tower. Once the landing zone is configured, it must adhere to best practices such as monitoring and governance, which are beyond the scope of this article. The primary objective is to build 3 Kubernetes clusters.

• Development Environment Kubernetes Cluster

• QA Environment Kubernetes Cluster

• Production Environment Kubernetes Cluster

To reduce costs, both Dev and QA can be combined under one cluster and have them isolated via Node Group and Namespaces. Once the Kubernetes environment is set up, onboard and containerize the identified apps using the Kubernetes migration playbook from Step 2.

The apps for onboarding need to be refactored into cloud-native applications, purpose-built for the cloud. Avoid containerizing monolithic or stateful apps that cannot run in a distributed environment and defeat the purpose of Kubernetes.

Inputs:

• All output of step 2

Expected Outputs:

• Cloud Infrastructure

• Kubernetes Environment

• Containerized Apps

• Apps Running in Kubernetes

• By batch migration to Kubernetes

• Application Fixes

• Infrastructure Tuning

• Some or all apps cutover to Production

Things to watch out for:

Your old IT Supply Value Chain is becoming outdated as the app release process has evolved. Focus on improvements for your pathway to Cloud/Kubernetes. Document and validate these improvements against your Build and Release process from step 2, which will serve as the blueprint for your CI/CD in future steps. Remember to use the Migration Playbook from previous step.

Step 4: Operationalize

A competent leader should resist the temptation to implement automation or CI/CD immediately. It's crucial to observe how new apps perform in production first, allowing for a stabilization period. The DevOps champion must train Operational Support staff to support the new technology, especially if they come from a VM background.

The Development Team might encounter bugs in the newly refactored code. Rather than focusing on automation, the project team must focus on fixing issues. Likewise, the Cloud Infrastructure Team may have to make some infrastructure enhancements. Monitoring tools in Kubernetes must also be introduced. There are 3 types of monitoring tools needed here:

• Runtime Security Monitoring Tool for Container like SysDig

• Kubernetes Management Tool like Rancher

• Application Observability like AWS XRay

There are countless tools needed, but these are the basics at this moment. Please note that we assume all existing and foundational IT tools are available from the past and are still operational.

Lastly, on the Ops side of things, a maintenance, deployment, and update procedure must be created for these newly deployed apps. The DevOps Engineering Team will not remain forever to manage these apps. Their job is to transition them to the Operation Team so that the DevOps Engineering Team can focus on Step 5 and 6, the Automation and Improvement stage.

Inputs:

• All output from Step 3

Expected Outputs:

• Revised / improved release process

• Optimized Infrastructure

• Cleaner Codes

• Stable Apps

• Operation Manual for Apps

• Handover Document for Apps

• Monitoring Tools

  • Container Runtime Security

  • Kubernetes Management Tool

  • Code Observability

Things to watch out for:

Avoid the temptation of automating or doing CI/CD at this moment. Focus on fine-tuning whatever you have currently. Keep a simple track of your IT Value Chain KPIs from Step 2 to serve as your baseline to measure success later.

Step 5: CICD Automation

As of this moment, the DevOps Team has mastered the IT Supply Value Chain process. Infrastructure is optimized, code has been stabilized. Change process are also aligned to the new DevOps paradigm. Ownership and accountability has been solidified. Trust among the working group has been put in placed.

With all of these foundations in placed. The organization is now ready for CICD automation. Using the IT Supply Value Chain and the final release process, automate each stages of release. By minimum the CICD automation must have the following core components:

• Code Repository

• Automated Code Security Scanning

• Automated Code Bug Detection like Sonarqube

• Automated Code Build

• Automated Image Scanning

• Automated Deployment

• Blue-Green Deployment or Rolling Update

• Automated Approval

• Automated Rollback

Those are the key component of CICD. We will not be able to describe them here one by one but the name it self are self explanatory. The goal of automation is not to automate, but to do the process right so that we do not end up automating the problems in the past.

Inputs:

• All outputs from step 4

Expected Outputs:

• CICD Pipeline for All Apps

• Automation

• Proper Security in each and final stage

• Audit trail of releases

• Governance of releases

• A clean build and release process

Things to watch out for:

Fitting Security protocols and measures based on tools or vendor recommendation yet wont integrate in CICD as it was not designed to be cloud native. This is called on-premise security approach carried to Cloud Native. Asking everyone's opinion on the CICD process. Nobody knows CICD better that the DevOps Champion and that is you. Therefore the DevOps champion should be able to call the right shots.

Inputs:

• All outputs from step 5

Expected Outputs:

• New ways of doing things for good

• A DevOps Template

• Become a thought leader

Step 6: Iteration

Also known as continuous improvement. At this point, each component of DevOps already has the ability to shift left, right, and improve feedback loop. Discussing those will be in a different post. This is where each member of the DevOps Team gains mastery of the process, where they are now capable of introducing future technology, breaking the norm, or challenging the process in an objective way that improves the delivery.

A good example of technology enhancement for development is that they've reached the maturity to introduce a new paradigm such as No Code Development. The developer learns automated testing alongside with the QA, where it is integrated in CI/CD pipeline. Old apps are refactored to new programming languages as they have already reached the end of life for the old. New development streams were created in order to experiment with new features that are later merged into the final release. All of this is done without chaos.

For the Infrastructure Team, AI can then be introduced. By feeding infrastructure logs to a Machine Learning platform like AWS Bedrock, they can build a Chatbot that has the intelligence to respond to infrastructure queries about the status of the Kubernetes platform. Edge Technology can then be applied to improve the customer experience by localizing the compute capability, having Kubernetes near your main source of traffic. Lastly, Disaster Recovery inter-regional can be introduced. Depending on your Recovery Point and Recovery Time Objective, a DR strategy is chosen, like active-active or active-passive.

Concluding DevOps Adoption Framework

This is just a brief summary on the DevOps Adoption Framework. No adoption framework will ever work if you choose the wrong DevOps Champion or having a poor Executive Champion. On the future article. I will be writing on how to choose the right DevOps Champion. The key takeaway here is being decisive in your DevOps Execution and having a champion that seats in every stages of the supply chain. DevOps is not fire and forget.

Leaders must also differentiate between action and motion. Initiative without a plan is motion, which leads to chaotic operations. Initiative with clear direction, a plan, and follow-through is the real action. Just get started with DevOps, no matter how small the plan and progress are; it is a snowball that builds momentum.

I am Teodoro Rico the author. An informal DevOps leader less the title but able to co-deliver and co-contribute on the following and I hope you do too:

• AI Chatbot in Infra

• Edge Computing

• Disaster Recovery

• CICD Automated Pipeline

• Automated Testing

• Automated Approval

• Automated Release

• Automated Rollback

• Release Strategy e.g. AB Testing, Blue Green, and Canary Deploy

• Migration of 50 containerized apps in 6 weeks