DevOps Explained to the Layman

Related articles:

Containers: plug-and-play code in DevOps world - part 1
Containers: plug-and-play code in DevOps world - part 2

Quick Intro

My goal here is to allow the big picture of DevOps to sink in so when you read a more detailed explanation you can take the big picture for granted, and focus only on the details, to solidify even further your DevOps knowledge.

Does it make sense?

How do we understand what DevOps is?  

After discussing the subject with loads of different people and thinking of it myself I found that one framework to understand DevOps at a very high level could be the following:

• Know how software was traditionally delivered in the past
• Know what was the problem with above traditional methodology
• Know how DevOps solves above problem - YES, here's where you understand what DevOps is at a high level
• Define what DevOps is yourself! - That's right, knowing what it does gives you the power to conceptualise it yourself.

Know how software was delivered in the past

It was pretty simple strategy. We gather all requirements with customer then design, code it all, hand it off to Q&A team for testing and lastly to Ops team to deploy it.

Beautiful, isn't it? Until it is not...

Know what is the problem with traditional (waterfall) methodology

Let's imagine a situation where 2 teams of developers are contributing in parallel. That's quite common.

After they finished coding their components (or even the whole application!) they found the components are incompatible and don't integrate well.

What a waste of time, eh? Waiting for both teams to finish everything and only then merge their code.

Now, say we finished integration but when we hand off our app to Q&A to test it a bug is found?

Or even worse, what if apart from correcting our bug we also coded many days or weeks on top of it?

 

Pretty bad, eh?

Up to now that's all on the Dev ↔ Q&A side of things.

Let me give you an example where IT Ops can also be a bottleneck here:

 

If we take into account that Dev spent all this time coding on top of the above code then that's 8 days wasted.

In reality, wasted time could easily go over 2 weeks as in larger organisations there might be other processes involved.

For example, if IT Ops needs help from Database Administrator (DBA) or another key person to finish setting up test environment.

How do we solve these problems? That takes us to DevOps.

 

Know how DevOps solves above problems

Some people say a picture is worth 1,000 words:

 

 

Continuous Integration

In DevOps approach, we use an Agile methodology where typically functional smaller chunks of code just enough to be meaningful (e.g. a new feature) from all Dev teams are regularly integrated so integration errors are spotted and corrected more quickly. This is called Continuous Integration (CI)

The smaller chunks of code are usually plug-and-play components with an API to communicate with other components which makes it much more organised when compared to a single large component. This is called Microservices.

Continuous Delivery

Following CI, integrated code is automatically tested through a couple of environments all the way to pre-production environment where it is "deployable" or ready to be deployed.

This is called Continuous Delivery (CD) and as it follows CI we call it CI/CD.

In CD, every change is proven to be deployable but not yet deployed to production.

Some companies do not automate further than that and prefer to do manual deployment.

Continuous Deployment

Following CI/CD, when even deployment is automated we call it Continuous Integration followed by Continuous Delivery and Continuous Deployment (CI/CD²).

This is the goal of DevOps.

Infrastructure as Code

For Dev team to be able to automatically deploy code quickly in different test environments all the way to production environment we need a heavily automated infrastructure.

This is called Infrastructure as Code. Notice that this is the antidote for the Dev ↔ Ops bottleneck in our previous example.

 

I'm including here both infrastructure provisioning tools, the one that you actually build/deploy your infrastructure with a click of a button (e.g. using cloud services) as well as configuration management tools, the ones that you configure your infrastructure (e.g. how to upgrade 10,000 boxes with a single command?).

Culture of Collaboration

None of the above is possible without proper collaboration between customers, developers and IT operations.

Collaboration is the trigger of continuous feedback and  continuous improvement.

Developers focus on coding, IT operations on managing automated infrastructure and both on innovation and improvement.

Other key practices

CI/CD, Infrastructure as Code and a culture of collaboration are key DevOps practice.

Regularly updating code according to user feedback, developing smaller functional detached pieces of code that communicate with each other via API (microservices), standardising systems and tools, and continuous monitoring are also best DevOps practice.

Cloud is also popular in DevOps community because it natively supports DevOps tools and has the necessary degree of automation and speed required for DevOps practice.

Define what DevOps is yourself

Now you might have a 10,000 feet idea of what DevOps does so you should be able to conceptualise what DevOps is yourself, but here's one definition I came up with:

DevOps is a practice that eliminates sources of waste from application delivery pipeline, making it efficient by means of optimising processes, removing silos, using automation tools, standardising platforms and establishing a strong culture of collaboration.

I will create other articles to incrementally add more details about DevOps practice.