DevOps
DevOps is a completely loaded word in today’s technical discussion. What it means to one person or organization will not be what it means to another. As a solutions engineer, this is a conversation that I have on a daily basis with my customers and agreeing on what we’re trying to achieve is a foundational step in the customer journey.
What is it that we’re trying to accomplish when we talk about transformation or introducing “The DevOps” to our organization? The short answer is collaboration. How do delivery teams interact with each other to efficiently create applications, processes, and workflows that increase quality, security, and velocity?
I spent my 20s helping my Operational Detachment solve problems around the world. A mission would get sent down from our leadership teams and planning to complete that objective would begin.
A Special Forces Operational Detachment Alpha (ODA) has a base composition of team members that can solve a wide variety of problem sets. The ODA acts as the US Army’s swiss army knife for complex issues. The team operates independently and each member is a subject matter expert in their respective domain. Each team member is also cross-trained in at least one skill set outside of their main job (i.e. a medic might have really mature engineering skills).
When a mission requires skills that are not natively contained within the ODA, an extended organization is formed under the leadership of the mission commander. A detachment may need mechanics to service vehicles, translators, or any other functions not contained in the core detachment. The principal that is followed is that the team has all the necessary equipment, resources, and assets to complete the mission in their independent unit with minimal to no oversight.
A team will have equipment to solve all the obstacles that it will encounter. This will include individual equipment and team equipment. Anything that can be shared and used across the team will be standardized such as radios, medical equipment, and vehicle systems . Equipment that is for the individual alone is allowed to be customized to make sure that operator has what they need to perform to the best of their abilities to include clothing items and personal protective equipment.
As I help build DevOps teams, I use these experiences and learnings to help create efficient working processes and the underlying tool chains to support them. We standardize where it makes sense and where there are opportunities to reduce friction between functional teams. We customize where doing so allows delivery team members to perform at their best.
At Opsera, we encourage teams to use the tools that make them most comfortable. We encourage the use of languages that they are most familiar with and proficient in. This allows for the fastest delivery and creates a developer experience that puts a smile on their face every time they come to work. .
This is the key to any DevOps transformation and one of the biggest challenges to any organization. Standardizing key points of interaction between your product owners, developers, test engineers, infrastructure teams, security teams, and release teams is the enabler that will create the growth expected out of a digital transformation.
Containers allow your developers, release managers, tech leads, and infrastructure teams to collaborate seamlessly. They can use their own languages and manage their internal dependencies while creating a common, standardized artifact that can be passed to any functional team to be deployed, tested, and interacted with. This single source of truth can and is what many organizations rally on and the completed containerized artifact contains the “story of a build.” Combining the use of containers with a standardized versioning system will up level your delivery maturity and visibility.
Standardization on an orchestration layer is a key moment in any organization's transformation journey. Delivery teams have many different tools, processes to use those tools, and configurations to manage. The complexity is ever increasing. Creating a centralized orchestration platform within your organization allows teams to continue to use their customized processes while giving visibility and control to your centralized leadership and advisory teams.
Software delivery can consist of SaaS solutions, infrastructure as code, configuration as code, and traditional software applications (APIs and Web Apps). Reporting on how those teams deliver should look similar and standardize on KPIs that are consistent across your organization. At Opsera, we encourage teams to take advantage of our powerful insights module to view common DORA metrics across all delivery types. Giving leadership visibility into velocity, failure recovery, and quality across organizations allows for rapid decision making in the constantly changing environment that software teams work in today.
These challenges are difficult to solve. We at Opsera have all personally experienced these challenges and are passionate about solving them! If you’d like to learn more about partnering with experienced DevOps professionals to up level your delivery processes, please contact our team for a meeting.
