DevOps was not "coined" until 2009, but it has been around for a very long time. It was discussed in 2006, but before that it didn't have a name. What was DevOps supposed to be or why was it coined in the first place?

There are many ideas around what DevOps is supposed to be in 2020. There were also many ideas on what it was supposed to be in 2019, 2018, 2017,2016, 2015, etc etc.

What was DevOps supposed to be? (In my humble opinion)

First and foremost, DevOps was never supposed to be a title. We weren't supposed to have DevOps Engineers or DevOps Architects. The biggest reason why it started was because Devs and Operations did not work together. There were hundreds of old-school change management meetings, people throwing work over the fence, throwing their hands up, and saying "not my problem". It was a way to bring everyone together. Not just "Devs" or "Ops" either. This included security practitioners, storage admins, compliance officers, etc. It was a way to make everyone work closely together to get to the end goal. The end goal, as I hope it still is now, is delivering quality to whoever is using our software or systems.

It was simple really: Get people in the same room working together so everyone can get to the end goal TOGETHER.

Lean Manufacturing

So, "DevOps".. is it a technical term? Or was it built from people in tech? No, it actually wasn't. DevOps originated from Lean Manufacturing. Lean Manufacturing gained popularity from Toyota.. Yes, the car. LEAN practices were already well established prior to anyone in IT caring what the other team thought. This was a way for the automobile industry to keep inventory low, minimize orders in the queue, and maximize efficiency. Deliver quality to the customer in a timely fashion... sound familiar?

What is DevOps now?

Again, in my humble opinion: I don't think anyone really knows what it is now. There are companies that truly practice DevOps (Netflix, Etsy, etc.) but not everyone is Netflix. If you line up 10 org leaders in a row and ask them what DevOps is, I guarantee you'll always get a different answer. DevOps has turned into a buzz-word. You'll see multiple pieces of software saying that their software is "DevOps", but you CANNOT buy DevOps. DevOps is a cultural change first and the technology change comes with it. What you CAN do is buy technology to help your organization deliver quality. You can change technology practices to help deliver quality as well. What you can't do is buy some CICD software and say "We're DevOps now". It doesn't work like that.

Specializing in DevOps?

What I said above is my opinion, however, it does not mean that my opinion will become reality. No matter what I say, the way we're seeing the DevOps path go is what we should be expecting. With that being said, should you specialize in DevOps? Absolutely, I do. There are a ton of different tools and pieces of software that I use to help me get there, but I focus on delivering value and shipping quality software with those tools. Before we had Systems Administrators, Network Admins, or Desktop Support, we just had "Engineers". It doesn't mean that because Systems Administrator is now a title they are doing any less work compared to an "Engineer". It just means times change, titles change, and responsibilities change.

What do you need to be successful in DevOps from a cultural perspective in 2020

You need to be ambitious and excited. In 2020, DevOps is very much the harder IT space to get into. It's definitely not impossible, but it's not easy. You need to have dedication and a customer first mindset. Your number 1 priority should be "how do I ship quality software to my users". Whether you work at a software company, do consulting, work internal IT, or do training. Your number 1 goal should be to provide quality.

From a company culture perspective, this is what makes or breaks DevOps in an organization. Everyone needs to;

  • Work together
  • Have the same end goal
  • Work closely to help everyone in every team
  • Not point fingers or blame. This creates a toxic environment and an uncomfortable workspace. It's time and energy wasted when that time and energy could be put towards solutions.
  • Be innovative: No, this doesn't mean use the latest buzz word technology. This means always be thinking how shipping the software can get better. This isn't a change that has to be immediate. What I'm trying to say is don't let your software delivery become stagnant.
  • Don't be a "cowboy". There's no need to change things on the fly or move a production configuration to "put out a fire" right away. Sometimes you need to put out fires and do things manually, sure, that's the reality. You can however take a few minutes to think about it and ensure what you're doing won't perhaps make the situation worse.
  • Communication, communication, and communication. Communication is the biggest factor.

What do you need to be successful in DevOps from a tooling/software perspective in 2020

Let's not think about the tooling from a "Is it DevOps?" perspective. Let's think about it from a "making your life easier and giving quality to the people that paid for your software" perspective.

Documentation

Is documentation a tool that makes you successful? Yep. In fact, it's the tool that makes you most successful. There's no way you can remember everything nor can anyone on your team. If you can't remember it, how can you fix a production level issue or help out in application support? How about if QA is having an issue regression testing a specific component or they need your help automating some testing? Writing documentation to understand all pieces of your application are crucial

Understanding your application

The last sentence of the Documentation section brought me to my next point - understanding your application. Let's say you want to help QA, or do some application support, or write some new and shiny code to automate a piece of your delivery process. How could you do that if you're unsure how the application works? This doesn't mean you need to memorize every single line of code in the application from frontend and backend, but you need an understanding of how your application moves packets around. If you have a database, some sort of account server, and a place for your users to log in, you need to understand how that all works. How does the frontend talk to the backend account server? Is it a container? A virtual machine? What secrets does it use to communicate? Where are those secrets stored? Do I have access to those secrets? Where is the database? Does the frontend need the connection string from the database or does the account server need the connection string from the database?

Questions like that can make or break what you're doing. Understanding what you're working on in-depth is key.

Development

You don't have to be a hard-core backend or frontend developer, but you definitely need to know how to script and how to write quality code. I prefer Python and PowerShell for this purpose. There are a ton of great books and courses out there.

For PowerShell I recommend Adam Bertram's new book PowerShell For Sysadmins

For Python I recommend this Udemy course

Understanding source control is crucial as well. The most popular at the moment is Git. There are also different types of branching strategies and the way your organization writes code. One that comes to mind is Git Flow, but there are many others. You can also create your own within your organization. This is a HUGE cultural change and everyone must be on the same page.

Another aspect of this that's very popular in DevOps at the moment is Infrastructure-As-Code. Infrastructure-as-code allows you to define your cloud or on-prem infrastructure as code. Creating virtual machines, networks, storage, etc. I personally love Terraform, but there are many other popular tools out there;

  • Terraform
  • ARM Templates
  • Cloudformation
  • Ansible

Cloud Platforms

Azure and AWS are the most popular. If you're going to start somewhere, I'd recommend looking into one of these. You can look into both, but don't overwhelm yourself. A lot of the core components you'll learn in one will carry over to the other.

You can sign up for a free 30 day trial of Azure here

You can sign up for a free 12 month trial of AWS here

Continuous Integration and Continuous Deployment (CICD)

CICD is a very popular and common topic in DevOps.

Continuous Integration allows you to continuously integrate your code in with the rest of the developer code. This means you can have all of the code in the same place verses pieces of code all over the place. It allows you to get an understanding of how all of the work will work together and where it will be stored. Integrating that code in several times a day is key so you can understand the quality of the code and any conflicts that may occur.

You can also create an "artifact" or a "binary" of your code and use it elsewhere. An artifact is your code produced in the software development process. You can then use this artifact to deploy your piece of the application. You could for example write some Terraform code that creates a virtual machine. That Terraform code could be packaged into an Artifact and deployed via Continuous Deployment to Azure.

Continuous Deployment allows you to deploy your code over and over again in any environment to understand what the code is doing. There was a time that developers would write code and not see it in action for months. Then once it was deployed, components would break. This isn't ideal because not only is it a huge time sink, but it's negatively impacting anyone that is using your application. With Continuous Deployment, you can deploy your code 1, 4, or 100 times a day if you wanted to. That way the developer can get constant feedback and fix any bugs that may arise.

Automation

Automation is important because delivering quality is one thing, but delivering that quality fast and efficiently is also a very big piece of the puzzle. If you deliver quality but it takes 4 months to do so, that's a problem. The other big problem with doing things manually is humans make mistakes. Code doesn't lie, so it's much easier to not break the process if you write code to do it for you verse clicking the buttons yourself. It's also a huge time saver and allows you to use your skills in other parts of the organization that need them more.

Automation can be done with tools, programming languages, or even QA. Automated regression testing is a huge part of the puzzle that allows you to get results about your code or environment at any time.

Closing Thoughts

I believe that DevOps will continue to change like everything else in IT. DevOps is definitely not what it was originally anticipated to be, but it's an extremely fun and emerging field to be in. If you enjoy tech and learning, you will never be bored in the DevOps space.