In part 1, we explored the definition of DevOps and touched on some of the challenges that exist when in implementing DevOps into IT organisations. In part 2 we’ll look the benefits of using the DevOps model within your teams.
Coming back to the DevOps definition from Part 1 – DevOps can be defined simply as – the people who build the app, run the app. So then why DevOps? Why take this approach? How is it any better than the traditional Build / Run dedicated function model commonly deployed in IT organisations? What problems does it solve? Let’s review some of the key failings of the traditional Build / Run approach. These shortcomings will give an idea of how DevOps can be more beneficial for organisations.
In the traditional Build / Run dedicated function model, each function has effectively competing priorities. “Build” wants to move as fast as possible, deploying features to Production in the shortest possible cycle. “Run” wants stability above all else. If you’ve ever been the responsible technician during a P1, you know how intense this situation is. And you’ll do everything in your power to avoid this occurring. Often, this will mean minimising the rate of change to the Production system. IT Pros are aware of the fragile nature of many IT solutions. The adage “If it ain’t broke, don’t fix it” is modified for IT Pros to be “don’t touch it so it won’t break”. Therefore, “Run” often wants to slow down the Change cycle as much as possible. The desired Rate of Change is one conflicting priority in this model, but there are other conflicts and impacts.
The functional model generates externalities in the way they work – fancy speak for their work pushes problems they create onto others. As “Build” is often executed under project delivery (Waterfall, Agile or something in between – it doesn’t matter), most are established using the common business case model that effectively states “If we invest X, then we will get Y”. Once approved, project success is often a measure of the “Invest X” part of the business case – i.e. on-time/ on-budget/ milestone-focused success measures. And making sure the “Invest X” appears successful can often come at the expense of the “then we will get Y” side of the equation – which is the more important part of the equation, it’s the return. For a project to claim success by meeting it’s on-time/ on-budget/ milestone-focused success measures, known problems in a Build project are often left unresolved. They are “thrown over the fence” for “Run” to deal with after the project has wound down.
Every Developer on every project has written a function that has a reasonable chance of causing significant problems once deployed. So why does this occur and why don’t they correct it? Are they bad at their jobs? Lazy coders? If you ask this question, you’re probably a non-coder. You can always tell coders from non-coders, i.e. people who have written even basic applications vs those that never have written a line of code. Non-coders can’t comprehend bugs are 100% certain in IT solutions. In their own experience, a “bug” is misspellings in an email or Word document, with your mistake clearly highlighted (even corrected) by the application itself before it is sent off to its recipient. their bugs are clear and easy to fix and they imagine it must be the same when writing software. Ironically, bugs even exist in this context, as content creators don’t bother with the basic proofread and issue content with spelling mistakes! But this point escapes non-coders. Bugs are certain in IT and most commonly occur in exception cases, which are difficult to foresee by the developers.
“It works on my machine…?” It’s often given as a combined defence, factual statement, and question when an IT Pro raises a Production bug back to the Developer. The probably flabbergasted IT Pro will mumble back “well it’s not running on your machine…”. The issue is that, as the Developers machine is a closed loop environment. Exception cases will generally not be experienced in this environment. Even attempts to mimic Production environments on an Individual Developer Environment fall significantly short as they are, wait for it, not Production environments. Thus, even when the Developer has an inkling that a function is poorly written, it can meet its functional objective, pass testing rounds and be released. This creates a ticking timebomb bug, waiting for that exception case to occur, generated by a distributed Production environment with real Production workloads.
It seems like it the Developers, right? Wrong. Here’s the thing – Developers are the top of the IT food chain. It’s the dirty little secret of IT. Devs can do literally every other function in IT – Tester, IT Pro, Network Admin – but it does not work the other way. Testers, IT Pros, Network Admins CANNOT code like Developers, even though they often act with the attitude like they can. Your script is not application code. So, don’t get it wrong, Devs are the rockstars – they are trying to build the future for their customers.
On the Run side of the fence, “Run” teams generate their own externalities. This is often a by-product of the circumstance in which they operate. The funding of the “Run” of IT is often viewed as a pure Cost in the business case, not an investment. Instead of on-time/ on-budget objectives, Run team goals are often an unrealistic vision of constantly “doing more with less”. In practice, this generally becomes “doing less with less.” Important activities are discarded as resources are spread thin. Indeed, these can be the exact activities that would have avoided an exception case occurring, like helping Developers establishing a like-for-like development environment or enabling tools that minimise the risk of Production changes, such as Blue/Green alternation. Just like Developers, it is wrong to think that IT Pros are bad at their jobs. They simply align themselves to their incentives which are often to maximise uptime, avoid Production Changes being marked as failed deployments and avoid P1s at all costs.
Conflicting priorities. Externalities created. Slow and low-quality output. There’s more – separate tools and processes. Production Timebombs. Siloed approach. These are only SOME of the issues with the traditional Build / Run functional model.
So, what’s the better approach? DevOps of course! DevOps aims to ensure that the right balance is struck between application feature progress (the traditional “Build”) and application stability (the traditional “Run”), as DevOps ownership exists on BOTH the code itself (where new features will be built) AND the Productionised application (the traditional “Run”).
The Benefits of DevOps
When viewing how DevOps performs in the context of the problems described, it becomes easy to see why DevOps works and, in most cases, is a superior operating model:
- “Conflicting priorities” becomes “One set of team goals” – First and foremost, there is no conflict of outcomes between Dev and Ops as the goals are the same. Instead of the Build Project team being tasked with delivering new features as quickly as possible, the DevOps team is responsible for achieving a rapid rate of change. Instead of the Ops team being solely responsible for delivering application availability, the DevOps Team is responsible for maximising uptime. The team work cohesively to achieve these outcomes – even under the circumstances where you have defined roles within your DevOps teams. Thus, the perfect balance is struck between progress and stability. Importantly, this is not a trade-off scenario. In DevOps, both rate of change AND stability generally see improvements. The balance is that, in DevOps, the goals are set on equal footing. You don’t compromise one for the other.
- “Externalities created” becomes “Quality Boomerangs” – In DevOps, problems created are boomerangs – your failures come back to bite and the team needs to work together to resolve. As a Developer, this means that poorly written code that causes a high priority incident will find its way back to you to fix. A more rigorous approach to Quality Assurance needs to be deployed in practice by the team, generating higher quality outcomes. On the Ops side, you need to know the application context – for application availability and performance, there is now no separation of the application layer and the abstracted layers below like OS, VM and Network. End-to-end ownership is required and a providing a platform and environment that supports the rapid achievement of customer outcomes is relied on by the team and customers. Ops are not able to push away issues like “Developer machines are not like Production” as it is within the domain of your roles and the team to address.
- “Production Timebombs” become “Production speed bumps “– DevOps won’t ensure that you never have a Production outage or a significant Production issue. However, the framework will minimise these issues and will be more effective in early detection. Teamwork and tooling combine to increase quality output, which minimises the timebombs going in. DevOps application telemetry can detect application performance or behaviours that deviate from the baseline – the canary in the coal mine for early detection of significant Production problems. These combine to improve application reliability, which help maximise return on investment.
- “Separate tools and processes” become “Tools and processes that span the outcome” – DevOps is fundamentally a people problem. However, the tools and processes are important. DevOps fosters a singular set of tools that span the end-to-end solution capability – not a set of tools for Devs and a set of Tools for Ops. This singular toolset (and supporting processes) is critical to delivering on the team outcomes. CICD, Testing Automation, Source Control, Monitoring and Application Telemetry, IAC, Blue/Green Deployments – these become essential to the team delivering on the outcomes in shorter timeframes while producing higher quality output. We will be covering the topic of Tools and processes in a later post.
- “Siloed approach becomes” “Teamwork to deliver” – What is often not apparent is how little actual teamwork is required for an IT project implementation. People are assigned roles, take inputs and produce outputs. Collaboration is generally limited to architectural problem solving. It feels like teamwork, but it is not. It’s something closer to a multi-lane relay in sporting analogies, where people take the baton for their leg. Even for Agile projects, this is how they are commonly executed. In the case of DevOps there is no end date with no finish line to reach. DevOps is more like basketball. You might have positions defined (point guard, shooting guard equals Dev, Tester etc) and you might have primary responsibilities aligned to individuals, but everyone works together to not only score on one end (feature release!) but defend the opposition on the other (maximise uptime!). This implementation of teamwork yields better results and higher satisfaction from the team doing the work.
In summary, what makes DevOps a preferred model over the traditional Build / Run dedicated function model is that, when deployed correctly, DevOps is a superior operating model for IT Build AND IT Run. It is the best of both worlds.
Coming back to our MuleSoft DevOps Managed Service, our service is built and delivered with these objectives in mind. The team that builds your MuleSoft solutions, runs the solutions – so we have one set of team goals that we strive to achieve. Higher quality output is consistently produced, and application uptime is maximised. We establish the tools and processes that support the end-to-end objectives of the service.
“But what if we didn’t build the app? Are you saying we can’t run DevOps?”
“We run projects and they need to have a finish date. Are you saying we can’t run DevOps?”
“How does Agile fit in with DevOps? If we run Agile are you saying we can’t run DevOps?”
These are great questions that I’ll address in another blog post.
Jeff Nowland is Director of MuleSoft Managed Services at Capgemini and has 10 years’ experience in Managed Services