What can be more collaborative than the principle of DevOps? The very word suggests a collaborative relationship between Operations and Developers. It is, in reality, much more than that but for the sake of this two-part article, we will treat the term as “the collaborative nature between developers and operations (system admins/ITPros).”
First, let’s start with a glossary of terms from the definitive source (ThoughtWorks):
Continuous Integration – “Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.”
Continuous Deployment – “Continuous deployment is about automating the release of a good build to the production environment.”
Infrastructure as Code – “Infrastructure as Code (IaC) entails defining environments, including networks, servers, and other compute resources, as a text file (script or definition) that is checked into version control and used as the base source for creating or updating those environments.”
Configuration as Code – “In this approach, you define the configuration of your servers, code, and other resources as a text file (script or definition) that is checked into version control and used as the base source for creating or updating those configurations.”
OK, now that we have our terms defined, let’s go into the typical dysfunctional relationship between Operations/System Admins and Developers. I’ve been in that relationship many times as many of you may have as well. Sometimes it’s good and other times, not so good. Why is that? I will speak from the perspective of the Sys Admin/Operations person in this article
First of all, Operations like to have stable environments. Making changes is looked at negatively. Patching/updating is a labor most love to hate, but understand that it is necessary to maintain a stable environment. To have to make configuration changes to the environments so that developers’ applications function as desired introduces the specter of instability and Operations resist this. Second of all, the very nature of software development requires change and ultimately an inevitable change to the environment to accommodate functionality or new features. Sys Admins/Ops generally don’t understand developers (I suspect the Developers who read this article will smile and nod their heads in agreement. 😊); they don’t understand their needs (just like in a dysfunctional relationship) but need to figure it out for the business to run smoothly. What this article seeks to be is a counsel for the dysfunctional relationship between Sys Admins/Ops and Developers—targeted to Sys Admin/Ops.
Too many ITPros/Sys Admins/Ops (IPSOs) are still updating infrastructure manually. Too few are using Infrastructure as Code (IaC) (and to a greater extent Configuration as Code (CaC)) to its fullest potential
Most IPSOs have lots of scripts that they use to create, update, and configure infrastructure. Lots of them. Everywhere. Some of the scripts may need to be updated every so often to reflect changes in configuration. Some of the scripts are well documented, others not so well. When changes happen, the previous versions are often lost. In some cases, a current version of the script may be in use while there is a need to run a previous version for some reason. This can often lead to configuration drift.
For years admins have been performing repetitive tasks – even with the advent of PowerShell, they still repeat many tasks over and over. Their collective reluctance to employ code in their everyday routine creates a greater rift between them and developers. This, in turn, makes it more difficult to employ the principles of DevOps.
When IPSOs begin employing IaC/CaC, the relationship (think:DevOps) becomes a thing of beauty.
This article outlines some principles and tasks that IPSOs can use to help develop a proficiency in IaC and CaC. The Development world is not remarkably different than the typical IPSOs world, but they speak different dialects of the same language. One concept that will help the relationship is that of source control, continuous integration (CI), and continuous deployment (CD).
We will start with the concepts of source control, then on to CI (build) and CD (release), then demonstrate how IaC/CaC fits into the process.
What is source control? It is the practice of tracking and managing changes to code. For IPSOs, this is a challenge with their scripts. Since they typically have no sort of version control for their scripts, they will store multiple copies of code maybe on our laptops or on the network. Developers have learned that by keeping track of where their code lives and what version is current, they have better control over what to deploy, where to deploy, and even when to deploy. Typically, in software development, many developers work on a project and on a code base. This is not the experience of IPSOs. The scripts they use were typically written by one person. If updates were made, no one knows. Using source control, forces the concept of “source of truth”. Using version control, this encourages collaboration and enables automation. I recommend that IPSOs use Git to manage their code versioning. Github is a good place to have a repository for code as well.
Continuous Integration (CI) is automating the build and testing process of code. Every time an IPSO changes the code in their script and puts it into version control, the changes are automatically tested to ensure that it works. I recommend using Azure DevOps for the CI process (otherwise known as the BUILD process).
So how does this work? Here is an overview of how the Build process (CI) works:
Go to the source repository where the code is stored. Check the code out and work on it locally. When finished, check it back in with comments as to what changes were made and why.
Run tests locally in a development environment.
If the tests pass, commits to the code to the source repository.
The previous step will cause the CI server to checks out the changes and perform the “build and test” process, which consists of the CI server running the code and testing it. The testing will produce a Successful/Failed build, and a Successful/Failed test result.
If everything passes, the code now moves to the CD (Release) phase. If not, the code needs to be fixed and retested.
OK, so how does this work in the real world (for an IPSO)? Let’s say you have a PowerShell script that builds out an entire environment in Azure. You use an Automation runbook to build it out and then tear it down when you are finished. What if you had to make a change to a VM or web app? You would use the above process to ensure everything worked and ran *before* you committed it to the runbook.
Continuous Deployment (CD), like Continuous Integration (CI) is about releasing code that has passed through automated testing. The difference in this case is that the code from the CD process (otherwise known as the RELEASE process) goes into production.
OK, now that we know that we (IPSOs) need to a) keep our code in source control b) version our code and c) test it before release – all that remains is to deal with the elephant in the room…”What is this “code” you speak of? Certainly, all of this is overkill for my disjointed PowerShell scripts?” This point brings us to the crux of how to fix the relationship. When IPSOs start performing their duties as developers, the relationship starts to mend. Why? Because the behaviors will start to standardize, goals will begin to align, and a culture of collaboration will begin to form. To get there, we need to understand a major principle. Infrastructure as Code (IaC).
Infrastructure as Code and Configuration as Code
Infrastructure as Code is a principle that falls under the greater practice of Configuration Management. Configuration management is the practice of taking the configuration of all environments and treating it as a discreet entity. Both Infrastructure as Code (IaC) and configuration as code (CaC) fall under configuration management, and both relate to defining or scripting for environments.
As an IPSO myself, I find that I perform many tasks over and over again. I have learned to use tools to automate these tasks on different levels and it has served me well. The key word being *automate*. The mantra for a successful IPSO is “if it *can* be automated; it *must* be automated. So, I began looking for ways I could automate processes and tasks. I started with the environments I build.
The first step is to take inventory of your assets; every VM, every web app, every database, every service, et al. If any of the assets have configuration files, get those, too. Next, document the steps it takes to rebuild every one of the assets (which you should have done anyway, right?) and write a script to build each asset (which you might have done, already), and then write another that combines it all together. Put all of those into a private repository on Github.
The next step is to clone the repository to Azure DevOps. Invoke the CI (build process) server to build the environment, then create a release. Now, every time you need to make a change to a script or configuration file, you will check it out, version it, test it, and then commit it. Rinse and repeat.
Truth be told, the infrastructure shouldn’t change much (excepting scaling); certainly not as much as perhaps the configuration. Treat the configuration as code in the same manner as IaC and use it to ensure that configuration drift does not occur.
Now that I have outlined what is wrong with the relationship and how to fix it, the second part will walk you through some example scenarios.
Did you like this article? Are you interested in this topic? Would you like to share your knowledge and experience with the authors and other readers? Our #communityrocks group on Facebook is bringing everyone involved together: authors, editors and readers. Join us in sharing knowledge, asking questions and making suggestions. We would like to hear from you!
Join us on Facebook
This article shows how the use of rotating certificates with Azure Key Vault and Azure App Services works. As soon as the SSL certificates are uploaded in Key Vault and set up in the App Services, they can be used automatically in all App Services by renewing them at a single point.
Cloud is very secure. But there is always a ‘but’. There are a few things we need to understand and consider when moving our data to the cloud.