DevOps, build it or buy it and what is it anyhow?

What is DevOps? Everyone has an answer. Yet they’re almost all different.

CI/CD is often the answer given. Continuous Integration and Continuous Deployment should be part of DevOps, but it is just a tool and a process to help achieve an outcome, not the definition of DevOps itself. But wait – is CI/CD an acronym for “Continuous Integration and Continuous Deployment”? Or is it “Continuous Integration and Continuous Delivery”? Or is it both? And what is the difference anyway? Even within CI/CD, you don’t find a consistency of definition. 

IAC or Infrastructure-as-Code is another common answer. IAC allows consistent and repeatable deployment and expansion of underlying platforms. The platform definition is maintained as a set of “structured templates” that are “code-like” in nature. Yes, IAC can be an essential part of DevOps, but turning IT Pros into Devs isn’t the intention of DevOps, so IAC isn’t the answer. 

What about Testing Automation? Testing Automation is vital in reducing the time required to deploy a change into Production. The more manual testing you have, the longer each deployment cycle will be. While Testing Automation is another part of the DevOps puzzle, it’s not the answer alone. 

SRE or Site-Reliability Engineering? Well, SRE and DevOps can be considered as different sides of the same coin – one developed and defined by Google (SRE) and the other developed and defined more organically within the broader IT community (DevOps). So SRE is more an acronym (another one) for DevOps, rather than a definition. 

So what is DevOps? Simply stated, DevOps means ‘the people who build the app, run the app’. 

Again, the people who build the app, run the app. Now “app” here can mean “code” literally, or an abstracted “app” or “solution”, made up of multiple technology layers. Surprisingly (or unsurprisingly) the definition is right there in the title – “Dev” and “Ops”, joined together. And it is singular – i.e. a single team with a single set of outcomes.  

DevOps presents real challenges for IT teams to implement for many organisations coming from a traditional structure. IT teams are often structured in a Design – Build – Run, siloed, functional model. This model has been deployed regardless of whether IT teams are internal or outsourced – as outsourcing was along these functional lines. In this model, IT Projects (Agile or waterfall – it doesn’t matter) build or extend solutions, that are handed over to support, with much knowledge lost along the way. Ops teams often call this the ticking time-bomb, thrown over the fence where they wait for the inevitable. Against this model, the “Dev” from DevOps is aligned to “Build” project implementation and the “Ops” to “Run”, with Level 1, 2 3 Support functions. 

So how do you realistically achieve DevOps in your organisation? Do you have to change your entire IT functional model to DevOps? Do you need to re-align your entire IT team or start with one team? Do you need to buy all new tech or use what you have?  

Like achieving anything of worth in business, a successful DevOps implementation occurs with the alignment of the right People, Process and Tools in an organisation. However, with IT teams being IT teams, there is usually a heavy emphasis on the Tooling (and Technology) part of the solution, rather than the part that matters most. Technology choices – CICD, IAC and Testing Automation etc – typically lead the implementation – “we need Azure DevOps”. This is how DevOps often devolves into “we have CI/CD, so we have DevOps” or “we have testing automation, so we have DevOps”. Hence, the definitions from above exist and persist. 

Going back to the definition – the people who build the app, run the app. It is the people that make the difference. DevOps is fundamentally a people problem. Yes, process and tools are important, and essential, to success. But aligning People to the model needs to be the first and foremost objective. 

People problems can be hard to solve. “Developers hate support work” and “IT Pros don’t know how to code” are common barriers (or complaints) to DevOps success. And there will be many more problems faced. However, the problems and reasons for failure are not “we can’t agree on a release process” or “we can’t afford Azure DevOps”. These may be true but can be overcome in any number of ways. People problems are harder to solve. 

So how do you do it? Knowing that it begins with People, how do you establish a successful DevOps function? Well, there’s 2 solutions – Build it or Buy it. 

In the “Build it” option, there is truth to DevOps being cultural. Organisational “Culture” itself has many broad definitions, but for simplicity, we’ll say it means that team members approach work in a similar way, with the belief that it is the right way. For an organisation to achieve cultural alignment to a DevOps model, the team needs to believe that the DevOps way is the right way. On this, there is a good chance of difficult days ahead.  Organisational Culture is defined in both a top-down and bottom-up manner. Leadership can set the expectation of what the culture should be and do their best to align the organisation achieve to these cultural principles. But it is in the actual “doing” of work and the common ways in which it is done that is the culture. And obtaining acceptance of a new paradigm from everyone can be difficult. Some hard choices will be required. 

For individuals, in DevOps, Senior “Dev” team members will need to participate in an on-call on a rotational roster for Level 3 support if Ops is 24×7. This can be challenging for individuals and the organisation to accept and manage – work/life balance needs to be achieved to avoid burnout, hence, it needs a team commitment to the process. The “Ops” Run needs to be as necessary as the “Dev” function of the team? Why? Because “Ops” is where Return on Investment exists. It’s where the money is made. “Dev” is where value is created. “Ops” is where value is delivered.  

Further, in DevOps, defects are first-class citizens in the backlog. This means that “Dev” team members split time between Feature development and Defect resolution. Many Devs would say that this was always the case, which is true. But Feature delivery deadlines always took priority over Defects. And, for most Devs, Features are just more fun to work on. It is just not as interesting to fix something you created. Now, with a single set of outcomes for the team that span both Build and Run, there is equality applied to both. This can be a challenging mindset to adopt. 

For those in the traditional “Ops” space, there becomes a higher requirement to understand challenges that exist in the “Dev” world. As DevOps teams have a single set of outcomes spanning all activities, those in Ops become just as responsible for the achievement of Dev goals as everyone else. It can often be challenging for Ops team members to consider solutions that suit the end-to-end application lifecycle, rather than just the end. For “Ops” team members, the scale challenge that comes from the inclusion of the Developer world can be challenging. For their role, it means the list of requirements to further streamline delivery will only expand over time. 

These are just some of the numerous “People” challenges that will exist in the “build it” version of establishing effective DevOps in your organisation. There will be many more. From decisions on the cross-functional skillset of people in teams, to broader organisational alignment for delivery, changes in reporting lines etc. From decisions on a centralised DevOps model, to Product aligned DevOps – aligning the People to the mindset needed will be the critical challenge. And we haven’t even touched on the Process, Tooling and structural funding changes needed to support DevOps – all bringing their own diverse challenges along the way. 

For those that do go down the “Build it” path, approaching it in the same way as Agile Software Development would be advised. MVP it – find an area within IT where it can be implemented, implement something like an MVP model, then fail, learn, and iterate until it defines the standard. Once you’ve got something that works, then roll out more broadly.  

The alternative to ground-up build? Simple – Buy it. Select a partner that provides a ready-made DevOps service. And, again, a KISS approach would still be recommended. Engage a partner to prove a DevOps capability for one area of IT that can initially be an incubator/accelerator. Engage, ensure it works for your organisation, then work with the partner to roll it out more broadly.  

As an example of the buy it option, our MuleSoft DevOps Managed Service is just that – explicitly designed to deliver a DevOps outcome for your MuleSoft eco-system.  

• CI/CD – Many customers have CI/CD solutions in place so, for those that do, we’ll ensure it aligns to our best practice implementation, from source code management through to pipeline deployment procedures. If you don’t have anything in place, we’ll progressively transition whatever you currently have (even manual management) into CI/CD tooling and establish release processes. 
• Testing Automation – We’ll ensure an appropriate level of automated testing for MuleSoft solutions is in place. Does no automation exist? We can even progressively establish automated testing for existing solutions, ensuring deployment cycles are minimised. 
• MuleSoft Monitoring – The right monitoring solution is critical to “Ops”. To effectively monitor MuleSoft, you need to consider the multiple layers of abstraction involved to deliver the application to users (users in this context can be human or other systems). And within each layer, you need to consider the types of problems that can occur, how can they be detected and how they should be managed when they occur. Our MuleSoft-specific DevOps Managed Service specialises in establishing this monitoring for your MuleSoft solutions.  

And, most importantly, People. Our Managed Services Team comprises 100% certified MuleSoft Engineers, already culturally aligned to delivering DevOps. Our DevOps Teams understand that Features and Bugs are first-class citizens on the backlog and that BOTH need to be balanced to guarantee that your investment derives the required return for your business. 

I’ll have more to say on that point in Part 2 of the series, discussing why DevOps is an important consideration for organisations today.  

Learn more about our MuleSoft DevOps Managed Service or contact us for an in-depth discussion. 

Jeff Nowland is Director of MuleSoft Managed Services at Capgemini and has 10 years’ experience in Managed Services