For this article, we’re speaking to Jordan Atkinson, an experienced Senior DevOps Consultant and AWS Certified Cloud Professional based here in Teesside that has previously worked at the likes of DuPont and Accenture.
Let’s jump right in: what is a DevOps Engineer?
Jordan: a DevOps Engineer is a professional role that encompasses the combination of Software Development (Dev) and Operations (Ops). The role focuses on reducing technical barriers between Software Development Teams, and the Business Operations of an organisation so that they can work homogeneously. This is primarily done through the use of a range of tools/technologies that focus on automation, deployment, and monitoring, however, the broad spectrum of tools is quite vast.
How does it differ from web development and software engineering roles?
Software engineering and web development roles primarily focus on the functional aspect of a product or service. They develop, test, and maintain software applications or websites that provide a rich suite of functionality to the user and may not necessarily be involved in the operational deployment or scaling of the solution or target architecture.
A DevOps Engineer is more focused on the processes, tools, and methodologies that enable an organisation to deliver software applications and services at high velocity and efficiency.
Do you need to be a “traditional” developer first to move into a DevOps position?
The simple answer to this is no!
Having development experience will certainly help, however, I find that those who excel in a DevOps role tend to come from a more SysAdmin background, or have great investigatory, trouble-shooting abilities.
Due to the role of DevOps spanning the whole deployment pipeline, you are often exposed to a wide range of issues (application, data, storage, monitoring, patching, automation) so having the ability to switch and be aware of these things is useful.
I see it more as a good DevOps Engineer is someone who has ‘been around the block’, had some time in the seat, and has seen a range of problems. Knowing where to look, and being able to start from the top of the stack and work down to where the likely root cause is, through the use of familiarity (seen this before), pattern recognition (this doesn’t seem right, or when X happens, we see Y as a result), that general awareness and ability to walk through a problem I feel is what stands out.
Now as a web developer, application developer, and data engineer, all of these require that level of thought process but just on a smaller, or different domain area. So no, you don’t have to be a web developer, it’s about how you think, rather than what your background is that makes a good DevOps Engineer.
At what stage would you usually become involved in the projects and what would your main responsibilities be?
Usually, you are involved in a project from the start when it comes to creating automated deployment pipelines or infrastructure. The reason for this is that you need to understand the nature of the applications, the technology stack, and how they are used and deployed. You also need to know things such as usage patterns, scaling needs, and what the main drivers of the platform are – is it stability, high availability, or cost optimisation?
From there, you can start building the platform and automation pipelines ready to accommodate the application stack. The main responsibilities are to assess the needs and requirements of the pipelines/automations/platform, and then iteratively build up each of the environments. Remember, a key benefit of DevOps is the consistency of environments and predictable deployments, therefore you are generally responsible for automating the creation of predictable environments and application deployments so that the developers can focus on building the functional aspects of the application without worrying about the target architecture or platform.
Is there a key inflection point where a business or project would see the most benefit from DevOps roles?
You see an increased benefit for SMEs and growing businesses who are moving into a more modern application stack or want to move towards a more modern approach. It is a great point to instil good DevOps practices regarding predictability, consistency, and resiliency for application deployments.
When there is an established platform that is poorly designed, there is a lot of up-front effort trying to not only update the platform and application but also push through a culture and mindset change on how modern applications should be deployed following a more iterative deployment. A lot of businesses whereby they have had breaking changes, outages, etc are very risk averse, and fear deployments, but it is important to explain and realise that frequent deployments are a good thing as it reenforces platform stability, reduces drift and stale environments, and treats applications and platforms as mutable, we can tear them down and spin them up with new code at pace. You see the greatest benefit in helping businesses move into that mindset and bring the business and the development team along that journey collectively.
Do you find there’s a typical duration for you to be involved in a project?
I find this to be vastly varying. I feel if you are part of a more mature organisation, you will often have a defined scope of work to complete and this is usually 3-6 months in nature depending on size. If there is a platform/organisation re-design or a culture shift whereby you’re changing an entire organisation in the way they run their environments, and deploy their code, these projects can last 12-36 months.
You tend to find as you deliver automations and operational efficiencies, you’re often trusted and encouraged to help the development teams, solve wider issues, or get involved in more strategic decision-making at the SLT level. It does entirely depend on the project and team – I do find that in comparison to Web Development or Software Engineering where they work in sprints, for DevOps, given the scope of impact of their changes, the sprints are longer, and you can spend time waiting for the development team, or wider decisions. Your changes tend to be higher risk in terms of you’re changing the deployment and hosting as opposed to a feature change which can be rolled back easily or rolled out via batch/phased deployment.
What are the common tools that you use in your role?
There are a range of tools used due to the nature and breadth of the role, here are a few of them listed in their domains:
Infrastructure as Code
The ability to deploy consistent infrastructure for your applications to run on.
Tools: Terraform (now Open Tofu), AWS Cloud Formation, AWS CDK, Azure Resource Manager (ARM), Bicep
Automation Pipelines CI/CD
The ability to take your committed code, pull it down, build the artifacts and deploy them on the target architecture and run the service.
Tools: Github Actions, Azure DevOps, Jenkins, Octopus Deploy, GitLab CI/CD, Team City
Configuration Management
The ability to define the configuration of your applications on the target architecture and are often run as part of your CI/CD pipelines. This decouples the infrastructure deployment, with the application deployment, and the application configuration.
Tools: Ansible, Chef, Puppet, Desired State Configuration (DSC), Terraform Provisioners,
Monitoring and Observability
The ability to observe, monitor, and troubleshoot your applications/deployment pipelines/infrastructure for issues
Tools – Datadog, ElasticSearch (OpenSearch), NewRelic, Splunk, Prometheus & Grafana, Zabbix, CloudWatch Dashboards, Azure Monitor.
Thank you to Jordan for his insight on the role of a DevOps Engineer and how they add value to businesses of all sizes with large technology plans.
At Embeddable, we support ambitious businesses to help them explore ideas, understand requirements and deliver meaningful solutions and products. If you have an idea, we’re here to help you start, scale and succeed through consultancy, development and fractional leadership services.
