I wrote my first article about what DevOps is and how to start with it in October 2015. Back then, there were not much information about DevOps, but Agile was peaking up, and some processes like Application Lifecycle Management and SDLC were very well known. Likewise with “DevOps” tools, there were some, but not to the degree of sophistication we can expect from tools we have nowadays.

Then on January of this year (2018), I wrote down another article about a DevOps journey that I took part in during Christmas time, and I thought, “Great! I just added my little grain of sand to the DevOps community” which I hoped was already very well known, and I assumed (bad from me) that by now mostly everyone knew about DevOps and what it’s about.

But, I’m finding myself in many situations where people still have the wrong concept or idea about what DevOps is.

Here are a few examples:

• “Yes, we have a new project that needs a database developer for 3 weeks to create some views on an Oracle DataBase, let’s bring a DevOps consultant for this work.”
• “I need a Web Frontend Developer for this Mobile Application, we should hire a DevOps engineer.”
• “Yes, if it is a DevOps person has to be an expert on Java, C#, JavaScript, Python and Perl, and be able to deploy them into production.”

I could go on but you get my point…

I have a view of what DevOps means and what a DevOps “Consultant/Engineer” should be capable of. I’m not saying it’s the right view, but as always, we can open a constructive debate about it.

Let’s start with the official definition of DevOps by Mr. Wikipedia:

DevOps (a clipped compound of “development” and “operations“) is a software engineering culture and practice that aims at unifying software development (Dev) and software operation (Ops). The main characteristic of the DevOps movement is to strongly advocate automation and monitoring at all steps of software construction, from integration, testing, releasing to deployment and infrastructure management. DevOps aims at shorter development cycles, increased deployment frequency, and more dependable releases, in close alignment with business objectives

My favourite sentence is: “The main characteristic of the DevOps movement is to strongly advocate automation and monitoring at all steps of software construction, from integration, testing, releasing to deployment and infrastructure management”

So, if you ask me again what a good DevOps consultant should be aware of, I would suggest the following:Code – Code development for Automation, Source Code Management, Code Reviews, Branching Strategy, Code Analysis tools

Build – Build Strategy, Continuous integration, build status

Test – Continuous testing tools, Automation for Functional and Non Functional testing

Packaging – Artefacts generation, quality labelling and packages readiness

Release – Change management, release approvals, release automation, environments generation, automatic deployment

Configure – Infrastructure configuration and management, Infrastructure as Code tools

Monitor – Applications performance monitoring, alerts, reports, end–user experience

On top of that you can include the technologies which are crossing through these areas. Technologies like, Jenkins, Terraform, Ansible, Grafana, Chef, VSTS, Splunk, ELK, Python, Nuget, TeamCity, Cloudwatch, Lambdas, OMS, etc. They are just tools for a purpose, and they are meant to be used for the categories previously mentioned.

There is a common misconception that a DevOps consultant needs to be a Cloud Expert. This is not true at all, Cloud Services are just another set of servers, services and tools that are used for the same purpose.

A good place to check out what tools are trendy at the moment and how they can be used in each of the above areas is https://xebialabs.com/periodic-table-of-devops-tools/. This for me, so far, is one of the best representations of what an engineer specialised in DevOps should know about.

When someone asks me what a DevOps consultant is, I answer that it’s a mixture of all these things, with strengths in 1 or 2 specific areas and an overall average/good knowledge of the other areas. They are also capable of working with any of these with ease. This doesn’t mean a DevOps person is exclusive to being a pure developer, a pure test automation dev, or even a pure operations person. It’s the knowledge about of these areas of DevOps which makes the difference.

Saying that, I will be interested to know what your understanding of DevOps is and what everybody now (maybe incorrectly) calls, a DevOps engineer.