The tech world is filled with buzz words, from cloud to synergy, serverless and of course DevOps. If you look at job postings or company guidelines, DevOps is probably the most common term you can find. The problem is that this term has many different definitions, which leads to people not really understanding what it means, or what is involved in actually practicing DevOps on a day to day basis. So here is my definition, based on many years practicing the various concepts embedded in DevOps.
The word itself gives you the most important clue as to what DevOps means: Developers and Operations. DevOps is a mix of the development and operations worlds, which is a massive shift of how technology used to work. Back in the 90s, there was two very clear paths that you could follow in order to work in tech. There was IT, which focused on operations (maintaining servers, configuring software, looking over logs, etc) and there was software development, which focused on creating and building code. The divide between these two worlds was great, and over the years even became greater in many organizations. This leads to all sorts of inefficiencies. When a development team created a new version of their software, they needed to send a request to the operations team in order to deploy it. Then, testing could be done, and once ready, once again a request had to be done to move it to production. If there wasn’t enough computing resources, servers had to be built and configured by hand. This took time, effort and money.
DevOps is an attempt to streamline the process. Many people think the way to do this is by transforming developers into IT administrators, however that typically always ends in failure. This is how you end up with shadow IT where various departments have servers running under their desks that nobody monitors, or various cloud servers running in separate environments. There’s a reason administrators exist, and that’s because deploying and maintaining IT environments is a very complex task.
Instead, it should be a mix of the two professions, typically using automation tools called Continuous Integration / Continuous Deployment (CI/CD). The automation is the glue that mixes the two worlds together, and a DevOps consultant should be someone who understands these tools, can deploy and then maintain them. CI is the development part, where code is no longer something that one person maintains locally on their desktop, but instead gets constantly merged into a central git repository. It’s then built centrally based on triggers using tools like Jenkins or CodeBuild. The CD part handles operations, and makes sure that any new release gets deployed to a test environment, automated tests are run, feedback is sent to the developers, and once ready everything is deployed to production. This can be done using tools like Ansible or CodeDeploy.
This is an example of the entire process using AWS CodePipeline:
Not every part of the process has to be automated all at once, but many parts can be. Here are a few examples:
- Code repository (git)
- Build process (Jenkins, CodeBuild)
- Environments creation (Ansible, CloudFormation)
- Build deployment (CodeDeploy)
- Testing process (Robot framework)
- Log gathering and monitoring (ELK, CloudWatch)
- Alerts and notifications (PagerDuty, SNS)
By using these tools, the entire process from development to production is greatly sped up, especially if you take advantage of things like Docker containers and the cloud, because you eliminate a lot of the manual steps like deploying servers or installing operating systems. A good DevOps consultant would know which tools are the best to a specific implementation, how to deploy the tools, automate existing processes, and address any hiccups.