Sand Castles and DevOps at Scale
by Niall Crawford & Carlos “Kami” Maldonado.
Modified by Eric Goebelbecker.
DevOps at scale is what we call the process of implementing DevOps culture at big, structured companies. Although the DevOps term was back in 2009, most organizations still haven’t completely implemented the practice.
DevOps used to be most popular at start-ups. After all, it’s easy to introduce processes that break the rules when you had no rules to begin with. But this has left large corporations and bureaucratic organizations to watch DevOps from the sidelines.
Now, things have finally changed. If we check the numbers from the 2021 edition of Accelerate: State of DevOps Report, it’s evident that big players in the industry are actively implementing DevOps practices. Could you do this at your organization? When applying DevOps at scale, you’ll face a collection of hurdles. Let’s look at how to overcome some of them.
A Bit of History
DevOps first appeared back in 2008 at an agile conference in Toronto. In a nutshell (and with the help of Wikipedia), we can define it as a software engineering culture and practice that aims at unifying software development (Dev) and software operation (Ops). DevOps intends to reduce the time between committing a change to a system and the change being placed into normal production while ensuring high quality.
That’s the theory, but your mileage may vary. The success of DevOps depends on the quality of individuals and how well the team works together. The biggest challenge is that few changes touch only one system. It’s usually the opposite; a change impacts many systems, processes & services.
In today’s complex IT environments, few systems or components are islands. And that’s where the issue with DevOps lies; it encourages a culture of “System” or “Team Thinking.” However, effective DevOps at scale requires us to think at a broader “Enterprise” level.
An Analogy: DevOps & DevOps at Scale
It’s a little bit like comparing the building of Sand Castles on a Beach to Town Planning. Yes, it’s fun, and you might build a damn good sandcastle, but, unfortunately, some of your sister teams will fall short of the mark, and ultimately the whole task of integrating is going to slow down, and the so-called “Release Train” will grind to a halt.
Delivering DevOps at Scale
Organizations cannot expect DevOps teams that are naturally focused on discrete systems or atomic tasks to manage and deliver a solution at scale. Not unless there’s some form of enterprise harness that ensures all the moving parts are effectively orchestrated. DevOps is more than simple Code, Build, Test, Package, Release, Configure & Monitor. DevOps at Scale is about resolving the classical cross-system orchestration challenges experienced today and providing an approach, preferably a complimentary & non-obtrusive approach, that overarches existing DevOps methods and ensure the release train wheels are greased and your delivery is streamlined.
As a way of preparing for a DevOps at scale capability, here are five practices to promote.
- Understand what your End-to-End Environments look like.
Look beyond your systems & model the End to End IT & Test Environments they live in. Understand them intrinsically i.e. map your components, dependencies, interfaces, business relationships, processes, and supporting operations.
- Shift your release / operational planning & coordination left
Avoid the ongoing issues around System not being fit for purpose and/or contention. Capture project & portfolio demand as early as possible and establish effective notification & transparency methods to ensure readiness and awareness.
- Don’t neglect the data
How often do you see the CICD solutions fail as nobody bothered about the data? In addition to streamlining Application & Infrastructure tasks, invest in data. Automate key data tasks like ETL (Extract, Transform & Load) and/or Fabrication and ensure the automation methods are “cross system aware”, thus ensuring E2E integrity.
- Orchestrate enterprise release activity
Avoid common “release issues”, “deployment delays” and “rollbacks” by adopting an “Enterprise Release Management” (ERM) strategy. A strategy that promotes prioritization of change, alignment of cross-system release activities, and promotes consistent and repeatable operations.
- Promote higher levels of “Enterprise Intelligence”
System metrics are fine although off little use to executive decision makers or your CIO. Start capturing & reporting on “Enterprise Metrics” i.e. metrics that allow the senior executives to see the “forest from the trees”. Examples may include Team Performance, Compliance, Automation & Innovation
Enov8 provides a complete platform for addressing organizations’ DevOps at scale requirements. Providing advanced “out of the box” IT & Test Environment Management and Release Management capabilities, the enov8 platform uplifts enterprise transparency, command, and ultimately control.
Innovate With Enov8
If you are interested in learning more about IT & Test Environment Management and IT Release Management, contact us about EcoSystem.
EcoSystem is a fully configurable and easily integratable solution that comes with out of the box “enterprise management” functions that support IT & Test Environment Management, Release Management, Data Management, IT Operations Management, Configuration Management & Service Management.
This post was originally written by Niall Crawford & Carlos “Kami” Maldonado. Modified for re-publication by Eric Goebelbecker.
Niall Crawford Niall is the Co-Founder and CIO of Enov8. He has 25 years of experience working across the IT industry from Software Engineering, Architecture, IT & Test Environment Management and Executive Leadership. Niall has worked with, and advised, many global organizations covering verticals like Banking, Defence, Telecom and Information Technology Services.
Carlos “Kami” Maldonado Kami is an engineer helping his company transition to DevOps. He specializes in Linux automation, and he’s experienced in all layers of infrastructure, from the application layer down to the cable. He’s part of a team migrating a monolithic app from static VMs to on-premises Kubernetes deployments.
Eric Goebelbecker Eric has worked in the financial markets in New York City for 25 years, developing infrastructure for market data and financial information exchange (FIX) protocol networks. He loves to talk about what makes teams effective (or not so effective!).
Test Environment Management Explained3JUNE, 2022 by Erik Dietrich, Ukpai Ugochi, and Jane Temov. Modified by Eric GoebelbeckerMost companies spend between 45%-55% of their IT budget on non-production activities like Training, Development & Testing and lose 20-40%...
3JUNE, 2022 by Eric GoebelbeckerWhat Is Serverless Computing? Serverless computing is a cloud architecture where you don’t have to worry about buying, building, provisioning, or maintaining servers. In return for structuring your code around their APIs, your cloud...
25MAY, 2022 by Niall Crawford & Justin Reynolds. Modified by Eric Goebelbecker.So, you’ve decided to implement a Scaled Agile Framework (SAFe) and promote a continuous delivery pipeline by implementing “Agile Release Trains” (ART)*. Definition: An Agile Release...
24MAY, 2022 by Michiel Mulders. Modified by Eric Goebelbecker.With the cost of data breaches increasing every year, there’s a need for higher security standards. According to IBM’s 2021 security report, the average total cost of a data breach has risen to $4.24...
24MAY, 2022 by Keshav MalikWith the rise of agile development methodologies, the need to quickly test new features is more critical than ever. This is especially true for websites and applications that rely on real-time data and interaction. The only way to ensure...
20MAY, 2022 by Jane TemovMost organizations employ strong security measures to keep production data secure while being made available for day-to-day business activity. However, Data may be utilized for less secure activities like testing and training, or by third...