What Exactly Does A DevOps Engineer Do?

What Exactly Does A DevOps Engineer Do?

It’s currently one of the most in-demand and well-paid roles in software development, but what does a DevOps engineer do, and what skills are needed to become one?

As an approach to software development variously referred to as a mindset, culture, methodology, and set of practices and tools, DevOps has become one of the strongest trends in IT in recent years. Whole software development teams and even organizations can be defined as DevOps. But there is also a dedicated role most associated with the term – DevOps Engineer. 

Here we’ll look at what exactly a DevOps engineer does within a software development team within the wider context of a DevOps approach or culture. Why has the role become so crucial to so many teams and organizations, and what are the responsibilities and tasks of a DevOps engineer? 

DevOps As An Extension Of Agile

DevOps As An Extension Of Agile

As already mentioned, DevOps can be seen as a culture or mindset and is widely considered an extension of the Agile approach to software development. An agile software development team builds software in short iterations adding features and functionalities to a software system based on user feedback and data. 

There is no highly detailed, fixed plan for the software system from the outset, as in traditional Waterfall development. Instead, an agile approach starts with the broad goal of solving a particular problem for users and then works towards achieving that iteratively. 

First, an MVP or stripped-down version of the software is built. It is then added to in a series of further iterations that take into consideration learnings from the already working software system. Further iterations then either smooth out issues or reverse wrong directions (discovered through user feedback and behavior data) taken in the path towards achieving the broad goal or add new features and functionalities that will help it be better achieved. 

Each iteration, built intensively over a fixed period that is usually somewhere between a few days and a couple of months, depending on the size of the project, is reviewed at its completion and the next sprint planned. 

The strength of the Agile approach is that it significantly reduces the risk of a project sponsor allocating significant time and resources to building a complex software system that turns out to not adequately solve the user problem it was designed to. 

As software systems became more complex over the years and competition between commercial products increased, it became clear the Waterfall approach of first creating a detailed spec, executing it and then launching it as a ‘complete’ software was no longer working. 

It’s almost always the case that some presumptions made at the start of a software development project turn out to be inaccurate. Sometimes these mistaken presumptions can be significant enough to undermine the value of the entire software system. And if they are baked deep into a large, complex piece of software with multiple dependencies, rectifying these mistakes can be hugely time-consuming and expensive to fix. 

It can even mean having to rip up the entire project and start again. Or it is simply being abandoned as a white elephant if so much cost has already been sunk that it’s impractical to invest further. 

In an iterative agile approach, rectifying a wrong turn or adding a feature that user behavior or feedback suggests will improve the software should be easy. At worst, the most recent iteration might need to be rolled back and reworked. 

Most software systems we regularly use, either in our personal lives or for work, are the product of agile development. When the version of an application we use is updated to the latest release, like Windows updating regularly, that’s an example of agile development. We’re already using the software, and it’s doing its job. But is still continuously being improved through regular new iterations that add new features and functionalities, remove bugs or improve security.

The Problem With Agile Development DevOps Solves

The problem with releasing new iterations of software systems with active users is that it has to be done in a way that doesn’t, or minimally, interrupt that activity. But updating software systems, especially complex systems with multiple dependencies, can introduce bugs and other errors. 

Such errors will either be detrimental to the user experience or render an application unusable in the worst-case scenario. Pre-DevOps, the most common source of such errors were differences between how a new iteration of the software ran in the development environment compared to the production environment. 

A software development team would hand over a new iteration to the production team, whose job was then to launch it into production. Unfortunately, the software doesn’t always run the same way in the production environment. And when the development team is not responsible for dealing with the consequences of bugs and other issues in production, human nature means there can be a tendency for them not to do everything in their power to ensure the next team in the process, the operations team, has no issues to deal with. The attitude can often be, “it worked perfectly in development; you’ll have to sort out any issues in production; that’s not our responsibility”.

DevOps was introduced as the solution to this disconnect between siloed development and operations teams. The approach brings the two distinct teams, one responsible for the development, the other for the software’s smooth running in the production environment, together as one with a single goal – creating and delivering high-quality software that offers the best possible user experience. 

The software development team becoming a DevOps team by including also operations roles means the role of developers no longer ends with the software running smoothly in the development environment. They have to work together with colleagues responsible for its running in production to make sure it does so in the same way. If it doesn’t, they are equally responsible. There is no passing of the baton, it is carried to the finishing line together. 

The unification of development and operations into a single DevOps team with a single goal and joint responsibility not only led to breaking down organizational silos between specialists. It also led to unifying development and production environments because the best way to ensure a software system runs the same way in both is for them to be exactly the same. 

If they are, in theory, there should be no risk of errors being introduced when a new iteration is moved from development into production. That doesn’t mean divergences never creep in, but they are very much minimized, leading to more reliably performant software that retains the advantages of Agile’s iterative approach and a team all pulling in the same direction rather than passing the buck. 

The Role Of A DevOps Engineer In A DevOps Team

The specialist role of a DevOps engineer is to facilitate the DevOps approach to software development by ensuring the reliably smooth transition of new iterations from the development to production environments. That’s termed CI/CD or continuous integration/continuous development, which is achieved through automated pipelines for which the DevOps engineer is responsible. 

IT outsourcing company K&C describes the role of a DevOps engineer as:

“…typically responsible for the release engineering, provisioning and maintenance of infrastructure, system administration and security. The role usually emphasizes automation with DevOps engineers managing the CI/CD tooling or developing and maintaining automated test suites.”

The thorough description of the role goes on to describe a DevOps engineer’s responsibilities as including:

  • The selection, set-up, and maintenance of CI/CD tooling or writing and maintaining bespoke build/deploy scripts.
  • Server deployment and maintenance, storage, and provisioning of network resources. 
  • In an on-premise environment, a DevOps engineer’s responsibilities typically involve provisioning and maintaining physical servers, storage facilities, and data center-based virtualization software.
  • In a cloud or hybrid environment that combines on-premise and cloud platform-hosted infrastructure, a DevOps engineer will also usually provision and manage virtual instances of components.
  • A senior DevOps engineer also often involves DevOps advocacy and promoting and maintaining a DevOps culture across the software development team and lifecycle and sometimes even at an organizational level.

The role of DevOps engineer generally requires expertise and experience with popular tools used for:

  • Version control
  • Continuous integration (CI) servers
  • Configuration management
  • Deployment automation
  • Containers and container orchestration
  • Infrastructure Orchestration
  • Monitoring and analytics
  • Testing and Cloud Quality tools

Demand For DevOps Engineers Will Continue To Grow

In its annual report on the most in-demand software development roles, CodinGame put DevOps engineers in first place for 2021, ahead of the front, back, and full stack developers with expertise in popular web development technologies like JavaScript and its various frameworks, including React and Node.js. The jobs portal Seek.com estimates 30% growth in demand for DevOps engineers over the next 5 years.

What looks certain is that an iterative DevOps approach to Agile software development is here to stay and is becoming the industry standard because the market and users demand it. Or rather, they demand the reliable, secure, high-quality software and user experience it leads to. And that means there will continue to be an increasing demand for qualified, experienced DevOps engineers that provide the automation and CI/CD pipelines and environment provisioning DevOps entails. 

Leave a Reply

Your email address will not be published. Required fields are marked *