DevOps. The ultra buzzword in the industry. Marketing loves it, and managers use it to apply to pretty much everything. Just sprinkle some DevOps on it and everything will be okay. Let's try to break it down by going back into time.
The world before DevOps
Let's for a moment, imagine the world of 2007. A world of disparate IT projects, a world devoid of DevOps. When working on a software project, developers would be adding features, making bug fixes and other changes. But nobody would ever check to see if those changes work together with the other components.
After months of working on a project and with bated breath, the projects were tested, not knowing if they would succeed or fail. When there was a failure, there would be a series of error messages and those error messages would sometimes not appear until weeks later in which someone would essentially copy the error messages and scramble to try to fix it. They would try and run the program again, and they would get another set of error messages. And this process would repeat over and over and over again.
The lack of insight into dependencies and hidden connections could mean changes were extremely expensive and often never happened. This is insane, right. Project costs would often blow out, and issues would not be known until the users were reporting them. If something did go wrong, the downtime could be significant until the fault was found and rectified.
Now, fast-forward to the present, we have a process now called DevOps that allows us to go through this process of running the program testing and fixing bugs much faster. This result in features getting released faster and fixes getting out to our customers without any downtime. There's a famous graphic of an infinity symbol.
There it is, which alludes to that process of build, test, deploy, monitor, plan, code, and repeat indefinitely. And a lot of times, multiple times a day, this is what DevOps introduced to the world.
A day as a DevOps Engineer
Feels good to be back in 2020. Right? So let's jump into what exactly a DevOps Engineer does apart from writing code, working in teams and wearing pretty cool T-shirts. You could be designing and implementing a continuous integration and continuous deployment pipeline also called CI/CD. This is when the code, the developers have written is automatically tested, built, confirmed and pushed to the production environment. Fully automated, without any human input whatsoever. If something goes wrong, you know, straight away, and you can do this tens or even hundreds of times a day, you could be defining dependency management between various parts of the system to monitor and recommend tools to do that management.
Other tasks include security inspections to ensure code doesn't contain common vulnerabilities and exposures also called CDEs managing code quality to ensure bugs are worked out and the program behaves as expected analyzing where applications are hosted in order to optimize performance, building infrastructure for new applications in a way that's building infrastructure as code and improving the communication between project managers, project stakeholders, and the rest of the company.
The challenges of DevOps
Of course, being a DevOps Engineer, isn't all sunshine and rainbows. First of all, you'll often get stuck between wearing your developer hat and your operations hat, two hats. The role is still relatively new and many places will dump both developer tasks and operations issues on your desk.
Second, if you walk into a company that already has a more established system and ways of doing things, introducing new DevOps practices may not be met with open arms or not open. There can be significant cultural challenges, as DevOps tends to introduce a pace and working method that can be foreign and hard to adapt to.
Also trying to apply DevOps practices to legacy or monolith applications can be difficult being that even the slightest change affects each and every part of the application. So yeah, moving from a monolith to a microservices application, allowing for a more fast moving release, cadence takes some major shifts and cultural changes.
The path to DevOps
Taking all of this into consideration, how do you end up in a role like a DevOps engineer? Well, you've got to have skills. The following are the five major skills you need on a path to DevOpsiness.
Configuration
So learning how to configure computing systems using modern tooling.
Versioning
Understanding how versioning of code applications and templates ensures minimal downtime and maximum release cadence.
Packaging
Getting a handle on how applications are packaged. That means how you make sure all the various dependencies of the are included in that package.
Deployment
Understand the way that software is deployed. Where will the application run? What are the hosting options? Such as Kubernetes. Which cloud platform? And many, many more.
Monitoring
Appreciate that you need to monitor solutions already in production and learn which tools can help you do that.
When you have those five parts well understood and feel comfortable with their complexities and connections between them, you can start looking at DevOps roles.
DevOps as a role is possibly the least well-defined. And one of the most complex within cloud computing and IT infrastructure. Bridging a gap between two distinct roles and two distinct cultures can be a huge ask.
No comments yet