What is DevOps?

What is DevOps?

DevOps is just a made up word, a combination of Development and Operations that have been smashed together in an abuse of the English language. Of course I don’t feel that strongly about mashing up words like that, so what does it mean?

DevOps is supposed to be the integration of the Software Development efforts and the IT Operations teams. If we think back a few short years, it was common, and is still common in many places, for a development team to work in complete isolation, adding, fixing, or breaking…, things and then pushing them out to production.

In some cases, the dev team might well be able to push direct to production and in some cases, the finished product is thrown over the wall to the IT Operations teams, these folks are then left to deploy or even worse, they may be left to support changes they knew nothing about until they went live.

So DevOps is a methodology that breaks down silos, it should ensure that all invested partes are aware of the changes before they happen.

Collaboration

DevOps leads to a more collaborative environment. The structure of a DevOps team varies from one organisation to another, in some cases the DevOps teams are made up of resources from Development, Testing, Infrastructure, Customer Support. In other organisations, it may be that the teams are still distinct, but pipe-lines and project planning is built to look a bit like a conveyor belt, so that the Testing Team are ready to receive the Developed product as soon as Dev have finished with it. When ready for production, the Infrastructure team is ready to deploy when Testing have finished with their stage, there should be no situations where a product has been finished but it is sat there waiting for the Testing teams availability or for the Infrastructure team to go away and setup new resources etc.

SRE / Platform / DevOps

I’ve worked in companies where DevOps is just passing the product to the Infrastructure team, a team that were primed ready for that work to arrive, they’ve already provisioned hardware and software where required, but they’re just waiting for the new code to be released to them. Then during deployment a Developer is either embedded into the Infra team, or available for support during provision.

I’ve also worked in companies where DevOps is just another name for the Infrastructure team(s), again, a few short years ago, and perhaps still the situation in some organisations, the Infrastructure teams (Networking, Servers, Storage, Voice (or Collaboration), etc) are all independent, when a problem arrives, the first focus is on proving the problem doesn’t sit in your team, it’s like throwing a live grenade around, trying to pass a problem on as quick as possible rather than actually working together to find the cause and fix it. DevOps in this world just means that those barriers within the Infrastructure teams have been broken down, you might find that you end up with a bunch of generalists with everyone knowing a bit about everything but with some individuals being the Subject Matter Expert(s), such as I may know a little about Linux and Databases, a little about Windows and how to setup Virtual Machines, but my main focus is on the Networking, I can help with many things but in most projects, the Networking bits sit with me. If I am busy, then my colleagues that know more about Linux or Windows, Backup Solutions or Virtual Machines also know enough networking knowledge that a project doesn’t need to sit and wait for me.

Then you have terms like the Platform team, or Site Reliability Engineering (SRE), some companies seem to have relised that Development work and Deployment work remain independent, again, whilst I might be a good Infrastructure Generalist that can provide cover for some of my other colleagues, I don’t actually know enough about Java to be able to deal with an application breaking down when we’ve taken it from Testing to Deployment.

Platform and SRE teams are used in place of calling a mixed Infrastructure team a DevOps team. Further to this, you will often find that Platform and SRE terms are commonly used in orgnaisations that are in the cloud, where most of what they are working on doesn’t really fit into the old silos of Systems, Networking, Collaboration, etc.

So a DevOps role can mean many things, the job description could be wildly different from what you do now or what you think the role might entail. It may also be that the role you applied for evolves into something that you never imagined it to be at the time you joined the company.

Where did the term (DevOps) come from?

We can thank something called the Waterfall Model for the introduction of DevOps. The Waterfall Model of software development was where we start with this massive piece of work at the start that captures and documents the end products requirements. You then flow down the waterfall, you build what was captured, you then pass to testing, hopefully it passes as this is a waterfall, everything is supposed to flow down, it shouldn’t really flow back, then we go to User Acceptance, Training, Handover, etc.

Of course, this was a silly model for something like software (though it worked for some pretty major projects, like building software that allowed us to land on the moon for example), however, if you can imagine that delivering a product might take many weeks, perhaps months or even years. The liklihood that the requirements captured at the start of the project are still correct at the end of the project is remote. The larger the product, the less likely what was captured at the start is what is required at the end.

In addition to capturing those requirements potentially a long-time before you deliver any software, you don’t want to keep your Test team sitting around waiting for software to be tested in 3 weeks, 3 months, or 3 years time. Those people are drawing a salary, they need to be doing something in the meantime, so you allocate them to another project/product that needs testing, and then another one, and another one, and then by the time that the major product is ready for testing, well now the testing team are busy, so a product that took many weeks or months to get to the testing team may now sit for weeks or months waiting to be tested. The Developers can’t just sit around waiting for test output, they’re allocated to a new project and so when Testing is finally ready to test the product, they find some issues and pass it back to Development, who are now too busy to work on that. Before you know it, we’ve added weeks, months or years of delay into a project (just think about pretty much every major IT project that any government has ever tried to deliver and how few of those projects arrive on time and/or on budget…). When it does finally make it to market or to the internal users, it may not be what they wanted, or perhaps more to the point, what they wanted 3 years ago isn’t what they need today.

So DevOps is one of those things that helps make an organisation more Agile, Product Owners can quickly help a team understand what elements of a product can add most value to a customer in the shortest amount of time, the Product Onwer also knows how busy the DevOps team is and perhaps even what the skill-sets are, they can help manage a customers expectations when a customer asks for new features. All of these things reduce the size of the product delivery challenge and therefore the speed of delivery. We can focus on delivering high-value features in the shortest timeframe possible, hopefully what the customer gets is somewhat aligned to what they want because the ‘ask-build-test-deliver’ loop is smaller.

What does it look like today?

Of course the main focus is to break down silo’s. Beyond that, much of the work is around automation, reducing the time the teams take to deliver things that are well known, such as a Linux installation, most companies have a typical build, once you understand that build, you can automate the process so that a few commands in a terminal delivers a platform that can be used for build, test and production for example.

CI/CD

Continuous Integration / Continuous Development

Ensuring that what we push to production is generally small, perhaps limited to a feature, this reduces development time, testing time and time to market (time to production), enables rapid feedback (user acceptance) and continuous feedback.

Infrastructure as Code

Moving to production, or rapidly scaling your production environment should be a few lines of code, we use things like Docker, Kubernetes, etc to rapidly scale up an environment as required with just a few commands in the terminal.

Where do we think it will go tomorrow?

DevOps is likely to continue down the automation route allowing improvments to reach the end users faster than ever as a result of collaboration and communication. New tools are surely just around the corner. Automating an organisations security posture is likely to be a major focus going forward, allowing a cyber defence team to stay ahead of, or at least keep up with, the ever growing number of bad actors out there.