DevOps Consultant vs DevOps Engineer

What is the difference between a DevOps Consultant and a DevOps Engineer? This question recently came up and I wanted to add my thoughts on the topic.

First, lets address the fact that consultants are almost always hired to work on a specific project or to address a specific issue the company is facing. As such, the role of a consultant will probably always be different than that of a regular employee. The regular employee has to deal with the mundane job of ensuring the lights are on, email, ongoing projects, operations, regular development tasks. The list goes on.

In a lot of ways, consultants are free from this type of scenario, and can focus on the one task or 5 tasks at hand. As such, sometimes consultants can get more done than a regular employee that has other responsibilities. Also, and because they are seen as experts in their areas, sometimes, the views of consultants are more highly valued or taken to heart by upper management.

With that out of the way. There is a difference. The article does stress the teaching, part. I am not sure that it really stresses the transformation part as much. A devops consultant, if they are good, will pair up with people at the company and help teach how devops works, and how to successfully transform a company and a group. They are brought in to look at a situation with fresh eyes, and potentially help shift the entire way that a group is doing things.

This does not mean that there is really a difference in skill sets between a devops engineer and a consultant. But if there is one, I would say it is around teaching and the ability to focus. There is also the other part, and that is the business acumen that consultants learn because they tend to have to deal with people from all levels of the company.

On the other hand, consultants, unless they are on a long assignment, may find that while they are making high level changes, do not always have the chance to get their hands dirty. This depends on the company they are working with, and what the job entails. So, a devops engineer, can end up having more time developing solution, whether it be configuring CICD, infrastructure as code, automating application deployments, automating error responses. Because of this, consultants sometimes have to dive deep on side projects to ensure that their skills are staying up to date with what is currently going on. Tongue in cheek, but sometimes it is just the opposite, and they are scrambling to learn the tool that the customer is using so they can help with that project.

The other reason people bring in consultants is because there could be a skills gap. Company A, realized that they are not moving fast enough and need to change. They go to the IT guys and that group says, “Not my job.” In that case, they bring in consultants because it is quicker to hire consultants than it is to hire full time people. And, unless you are just going to run your company with consultants, you should be bringing on full time people to learn from them or to be filling those roles as the consultants leave.

A bit long winded, but I hope it helps. Ping me if you have any other questions. I have been on both sides of the fence.

Oh. and travel. Consultants normally have to travel.

DevOps is more than just about developers

There. It has been said. Take a moment, and think about it.

There is a push in the community to talk about Continuous Integration / Continuous Deployment (CI/CD), and tying this all to the DevOps movement. About what practices are used to get code to market the fastest, and with minimal amount of code defects. And, I will admit, that I agree wholeheartedly, that CI/CD or some sort of pipeline is important to allow software development teams to move fast and innovate. Or, to just roll out code without doing it every 6 months. I would almost argue that CI/CD is more akin to Agile and Scrum methodologies than it is to DevOps.

When it comes to DevOps, there is a side to this equation that is not commonly being addressed, Infrastructure and Operations.

Infrastructure Ops

InfraOps, whatever you want to call it. This is the glue that holds together all the services that applications run on top of. It is the items that people take for granted when it works, but cry foul when things go down. When servers go down at 2 a.m. InfraOps is what keeps the lights on.

It is easy to dismiss this side of the DevOps house. But, lets quickly discuss all the items that we need to cover here.

Infrastructure Operations List

  • System Deployment
    • Operating systems
    • Patching
  • Virtualization (Docker, AWS, Azure)
  • CMDB
  • Monitoring
  • Software Deployment
    • 3rd Part
    • In house
  • Load Balancers
  • Hardware Failover
  • Disaster Recovery
  • Caching Servers
  • Database Systems
  • Development Environments
  • Backups

This is by no means an exhaustive list of all the items that must be handled for a solution to be properly deployed and supported. But, the idea is to bring to light the side of the DevOps world that is often overlooked. It does not matter how good your code is if you don’t have an infrastructure that will stay online and support your applications. Often this is an overlooked and under staffed area that needs more attention.

Automation is king

The only way to ensure that the Infrastructure is able to support ongoing systems, deployments, and updates is with automation. Every time that a machine is built by hand, a configuration file is manually changed, or updates are performed manually, you have introduced risk into your environment. Each of these interactions is potentially a slow down in the pipeline, or worse, a manual change that has never been documented.

There are a number of tools and processes wrapped around handling Infrastructure Automation: Chef, Ansible, cfEgine, Salt. The list goes on. In some places there people have rolled their own. It does not matter as much about the tool, as long as we are moving away from manual intervention to a more dynamic scalable infrastructure. These tools all require an in-depth knowledge of underlying systems as well as the ability to code. But the end goal is DevOps on the infrastructure as well as on the Development side of the house.

There are places where tools are lacking to help support of automation. While new SaaS Solutions are filling some of these gaps, if you need to run your monitoring system in house, many of the solutions that currently exist are not built around dynamic infrastructure and ephemeral machines. The tools need to catch up with the needs of the users. In the meantime, the back end DevOps guys write workarounds to handle situations like this.

Moving Forward

Moving forward, let us try and look at all aspects of DevOps, from development to application deployment, and from hardware to infrastructure and scaling design. There is still much work to be done, but we are moving in the correct direction.