Companies embracing their digital enterprise present — and future — are organizing their DevOps initiatives around four key pillars:
- People/Teams: reflected in new types of functions, such as Site Reliability Engineers, full stack teams, autonomous “two pizza” teams, feature teams and more.
- Technology: embracing open source platforms as well as Agile-focused tools such as ChatOps, to enable fast time to market.
- Systematic Processes: reflected in an approach that uses continuous delivery, a complete embrace of automated build, test and deploy, Fail Forward and Canary Rollouts where everything is instrumented, tested and monitored.
- Culture: that puts a premium on collaboration and trust, centered on an engineering, rather than ‘traditional IT’ culture.
At Daitan, we have real-world experience with the challenges, and rewards of DevOps. We live and breath Agile Application Lifecycle Management within a DevOps culture. With many of our customers, we have seen the reality of operations and engineering teams working together to embrace the new ‘culture,’ and we understand the many challenges this kind of ‘change’ creates across the organization.
The new ‘Digital’ reality expects increased deployment speed, reduced failure rate, less bugs, and improved team motivation and productivity. And DevOps is well documented as being able to deliver on those demands.
It’s complex, but really all part of the Digital Transformation many companies are making to move their business initiatives forward.
From a technical perspective, it’s often about breaking down their monolithic apps into services designed for speed and better customer experience.
If you are getting started with DevOps, we suggest to always start with the end in mind. Embracing DevOps can be a long and complex journey, full of change and uncertainty. But the rewards are great.
Starting with a Self Assessment is the Smart Move
How to begin? We start with a 3-question self assessment that will give you clarity, and ensure you have the right organizational and technology alignment to succeed. These questions are relevant whether we are renovating and upgrading existing systems to be DevOps feasible, or initiating brand new systems.
Question #1: What current Agile practices and tools do you already have in place?
It is important to start by understanding what exactly is in place already, and how much needs to change in order to meet the software release goals. That estimate should be as accurate as possible, with an inventory of all the tools currently being used — that inventory will help with the selection of the group’s DevOps “Toolchain” — the combination of tools that enable the development, delivery and deployment of applications throughout the software development lifecycle.
Question #2: What are your release goals and how fit is your architecture for DevOps?
The infrastructure and software architecture influences how far an enterprise can “go” with DevOps. In discussing this topic with clients, we review:
- The impact of a modular, if possible microservices-oriented architecture to allow more frequent delivery and deployment; this is often a better approach than employing a monolithic architecture.
- The comparison of physical versus virtualized machines. Physical (bare metal) machines make it harder for teams to provision and configure environments.
Where possible, we recommend virtualization and containers, unless there are very specialized and specific hardware performance requirements that make this impossible.
Of course, we are also faced with special requirements that mean different approaches are needed. For example, there may be special code review requirements or manual testing procedures that have to be complied with — which means that systems have to be less automated. But generally, we try to approach software architecture recommendations that include a modularized and virtualized approach.
Question #3: Are you building a new team, or evolving an existing team’s practices?
Our experience has shown over and again that there is frequently a ‘resistance to change’ mindset when moving even experienced Agile teams to embrace DevOps methods. This issue cannot be overlooked. Our advice generally includes:
- Anticipate pain — especially the pain that will be experienced by the Ops teams — clear and understood by everyone. Pain will occur. Expecting and planning for it helps.
- Make developers accountable — everyone should understand the enterprise impact of service downtime, and should be on the same side of the table in helping the Ops teams address and recover from issues.
- Educate and evangelize — resistance can come simply from fear of the unknown. Embrace education. Evangelize new tools. Help every member of the team ‘step up’ and raise their level of coding skills. Share and model good programming and architecture patterns and practices, particularly when those patterns and habits impact Ops teams.
The Next Step Digs Deep into Technology, Process, People and Culture
Once the self-assessment is complete, we move onto reviewing technology, process requirements, people and culture. It’s another blog’s worth of discussion and too much to include here. If you need the information now, just click to download the whitepaper: DevOps and the Engineering-Led World of the Digital Enterprise. No email required, no form to fill out. Easy. The paper covers: Enterprise Adoption of DevOps, the Five Core Principles of DevOps, Getting Started with DevOps, and; DevOps in Practice: Lessons Learned at Daitan Group.