IT As Developer: One Of The Keys To Relevance
This blog is the third installment in a series focused on the question of what IT teams need to do to retain or regain relevance (depending on their circumstance) with line-of-business. For the full list check out my first blog on this subject. In addition to this list I also covered self-service in blog #1. The second blog looked at the need for IT to effectively market their services to their internal customers. This blog is focused on two of items on the list. What is “Infrastructure as Code” (IaC) and how does this relate to the concept of IT as Developer. It is also about the need for IT to embrace DevOps principles along with Continuous Integration / Continuous Delivery practices for IT Code in order to help accelerate application development initiatives at their companies.
The Forrester Research papers below provide some great additional background on many of the key concepts that will be covered in this blog. The first paper is all about IaC. The second paper by Forrester focuses on the need for System Admins (term used broadly here) to transition to IT Developers. You should also check out a blog by my colleague Colby Heiner which looks at the topic of the Software-Defined Data Center (SDDC) as Code.
- How A Sysadmin Becomes A Developer; Chris Gardner and Robert Stroud; Forrester Research; March 2017
- Lead The I&O Software Revolution With Infrastructure-As-Code; Chris Gardner and Richard Fichera; Forrester Research; September 2017
DevOps, Continuous Integration, Continuous Delivery
It’s hard to appreciate the idea of IT as Developer without first considering how application development has changed since the advent of the DevOps movement. For many years now App Dev teams have been pushing hard on the idea of becoming more agile. A big part of becoming more agile is the adoption of DevOps principles.
From my standpoint, the goal of DevOps is to empower teams that include developers and operations professionals to create together a new operating model that can produce higher quality code and more frequent releases. DevOps is first and foremost about people and process. Technology comes later and is something that supports people and process.
Continuous Integration and Continuous Delivery (CI/CD) is a practice that supports making this idea a reality. CI/CD is about integrating the developer tool chain and automating the development pipeline so that every step of the development process is integrated and movement across steps in the development pipeline are fully automated. Through this approach, code moves from development, to test and then to production in a rapid but controlled fashion. The adoption of CI/CD practices allows organizations to push code to production rapidly but with a very high confidence that the code will function as expected.
Infrastructure as Code and the SDDC
The core idea behind a software-defined data center (SDDC) is that all the physical resources that make up the data center can be abstracted through software. “Infrastructure as Code” (IaC) is another way that people talk about the same idea. Turning a physical data center into software makes it infinitely easier to quickly compose and then roll out environments based on software defined building blocks of compute, storage, and network.
IaC came into vogue with the ascension of AWS . With IaC developers could request infrastructure in a declarative fashion, using a building block approach that allowed them to completely specify what kind of environment they needed for a particular project. IaC not only supported self-service but it was also programmable. This meant that other technologies could orchestrate the creation of resources using the API of the automation platform that was responsible for building out the requested environment. Being able to compose infrastructure by calling it through an API meant that IaC could easily be leveraged as part of CI/CD initiatives.
But the implications of IaC extend well beyond being able to easily request resources programmatically. One of the Forrester Research papers cited at the beginning (Lead The I&O Software Revolution…) summarized these implications well: “An SDDC treats infrastructure in the same manner that an application developer treats the application – it’s all code.” So, while IaC supports the ability of organizations to implement CI/CD for application code, it also presents an opportunity for IT to manage the SDDC as if it were an application itself.
DevOps Principles and CI/CD Applied to the SDDC
Since the data center is just code, IT can now apply the principles of CI/CD to the development of code that represents infrastructure. IT can also apply the same principles to software that does not represent physical hardware but instead represents processes associated with managing that infrastructure (or the application that rides on that infrastructure). An example of something beyond infrastructure could be a monitoring solution that helps ensure performance and availability of a specific environment or application.
Closely linked to the idea of creating a development pipeline for the code that represents the data center is the notion of “immutable infrastructure”. The core idea behind immutable infrastructure is that infrastructure changes should always be done as part of a development pipeline process. Just like with application level code, IT needs to make sure that any changes that are introduced are fully tested before being put into production. So rather than changing configurations of already provisioned environments, adopting DevOps principles would mean that IT instead a) makes changes to the source code that represents an environment; b) thoroughly test changes to that source code in an appropriate test environment; and then c) rerolls the environment with the changes implemented.
This approach is consistent with how an application developer would push out application level code changes if they were using DevOps principles supported by CI/CD practices. The developer would a) create new code that extends or changes the functionality of an existing application; b) then they would fully test the change as part of the entire application (not just test the code change in isolation) and finally c) they would reroll the entire application. The comprehensiveness of this kind of process along with the need to do it relatively frequently dictates the need for some sort of automated development pipeline to ensure that things happen exactly as expected and that the process can easily be rerun as often as necessary to push new code to production.
With so much of the data center now software defined there is no shortage of targets where IT could begin to apply DevOps principles and CI/CD practices to IT Code. Configuration files, free form scripts written in Perl, Python or any number of languages; scripts associated with Configuration Management solutions like Puppet, Chef, Ansible, Salt; workflows associated with any number of orchestration solutions. All of these are examples of IT Code where CI/CD practices could be extremely useful.
Files that are created or edited as part of an IT solution in the data center are also IT Code. An example in this category would be files associated with an application monitoring solutions. The files involved represent artifacts like custom dashboards; custom reports; or perhaps user created scripts that drive alerts for specific scenarios that are not supported out-of-the-box. If the files change frequently or if the results of a misapplied change would generate considerable re-work, then they also would be good candidates for use with CI/CD practices.
Getting Started
As mentioned at the start of this blog, app dev teams are well down the path of embracing DevOps principles and CI/CD practices. It’s the best way to produce high quality code rapidly. IaC is now a natural part of that process and ensuring that the environments that get wrapped into these CI/CD processes perform well is a key part of what it means for IT to be a more effective partner to the lines of business. However, with the velocity of application delivery dramatically increasing due to the adoption of DevOps principles it is becoming increasingly difficult for IT teams to keep up without adopting the same approach. But where to start?
If you are a vRealize user there is a very easy on ramp. The vRealize Code Stream Management Pack for IT DevOps is solution that makes it easy to embrace the use of CI/CD practices for vRealize and other VMware artifacts. The solution combines vRealize Code Stream along with a management pack that delivers pre-created pipelines designed to manage vRealize artifacts. Covered artifacts include the following:
- vRealize Automation: Blueprints, software build profiles, property definitions, groups and actions
- vRealize Orchestrator: Workflows, actions, configuration elements, and packages
- vRealize Operations: Custom dashboards, reports and alerts
- vSphere: Template and custom specifications
- vRealize Code Stream: Pipelines
My colleague Greg Kullberg did a couple of great YouTube videos that show the management pack in action. The first video shows the management pack being used to manage vRealize Automation artifacts. The second video video shows the management pack being used to manage vRealize Operations artifacts.
The management pack along with vRealize Code Stream are part of the entitlement associated with vRealize Suite and vRealize Automation Advanced and Enterprise editions. The use of Code Stream included as part of that entitlement is limited to the management of IT artifacts associated with the VMware products mentioned above but it is possible to purchase additional licenses to manage code beyond VMware artifacts.
Other Blogs In This Series
- IT Teams Need To Finally Implement Self-Service Automation
- Marketing Internal IT to Line-of-Business
Learn More
- Visit VMware vRealize product page
- Visit VMware Integrated OpenStack product page
- Try our Automate IT Hands-on Labs
- Try our Intelligent Operations Hands-on Labs
