What is DevOps
I often get asked what is “DevOps” when talking to others about my career. My response has changed over the years as I’ve expanded my skills and experiences within a “DevOps” role. The goal of devops is to bridge the divide between what are usually two different departments in organizations and to reduce toil. Most career paths to DevOps start out either on the Operations side as a traditional sysadmin who learns some of the Development side, or as a Developer who learns some of the operations side. My definition of DevOps will continue to change in the future as this is only a snapshot definition that I am using as of today. To start defining DevOps let’s separate DevOps into Development and Operations.
Ops
Traditionally operations handles the infrastructure hosting applications. This can be physical servers in a DataCenter or infrastructure hosted in the cloud. For DevOps engineers the operations side can be broken into three different areas, provisioning, configuration, and monitoring.
Provision
Provisioning consists of spinning up new infrastructure. For DevOps engineers this means using Infrastructure as Code (IaC). IaC allows the infrastructure to be defined in code and can be stored in a version control system. This allows for a versioned history of all changes made to the infrastructure and if done correctly allows for new environments to be spun up quickly by reusing code. All major cloud providers provide some sort of IaC. AWS has cloudformation, Azure has azure resource manager; but, one of the most common tools used for provisioning is Hashicorp’s Terraform. Terraform allows provisioning of infrastructure in cloud environments along with many other services commonly used such as DataDog, PagerDuty and VMWare.
Configure
Configuration management is another large aspect of a DevOps engineer role. Like with provisioning there are many tools such as puppet, chef and ansible. Managing configuration using templates allows for slightly different changes in different environments while reusing most of the same code. Automating this configuration reduces human error and allows for faster provisioning of entire systems.
Monitor
For DevOps engineers the monitoring should be focused on the infrastructure. Uptime, network latency, CPU and memory usage are just some of the things to be monitoring. Infrastructure logs should also be shipped and monitored including OS level logs. Application logs should not be monitored by DevOps engineers and should be the responsibility of the development team who wrote or owns the application. The two should work closely together since some errors will cause alarms for the different teams. Aggregating metrics to a single source allows for easy monitoring and alerting.
Dev
To be a successful DevOps Engineer one need to understand code and be able to write code. On the development side understanding how code is built and how it is deployed allows for the entire organization to speed up as this is normally where a hand off is done between departments.
Design
Knowing application architecture is important, as DevOps engineers should be included early on in the planning of new applications to be advocates of resources that may not be known to the developers. AWS even has a “Solutions Architect” certification that can show proficiency in this area. A good place to start is to learn the 12 Factor App.
Build
When it comes to building of applications there is a lot to write here and will need to be split across many posts. Commonly there will be CI/CD pipelines. The build aspect will focus on the CI. Developing a good pipeline to build code that is immutable and versioned (Docker is great for this). During the build process it is important to get fast feedback to the developers. To accomplish this tasks such as Unit Tests, and compiling should be early in the pipeline as they take less time to run. Later on in the pipeline Integration Tests and Acceptance tests should be ran. A decision should also be made about trunk based development. Should all stages of a pipeline run for a branch of code or only for a pull request to the projects main branch?
Deploy
Finally a successful DevOps engineer will automate deployments to be repeatable across all environments. This is where the CD part of the CI/CD pipeline comes in. It does not mean code has to be automatically pushed to production after a merge to the main branch but that the code that deploys is repeatable. If the deploy was successful in lower environments, the same code should be used to deploy the same artifact to production.
Final Thoughts
I’m sure most of what I have written above will need to be changed as DevOps roles continues to evolve. There are other aspects of the role that include security (DevSecOps) which raise interesting problems that can get solved using DevOps principals. Also is there a difference between a Site Reliability Engineer (SRE) and a DevOps Engineer? That may be a topic to explore at a later date.