IT As Developer Of Infrastructure As Code

IT As Developer Of Infrastructure As Code

This post was originally published on this site ---

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 the concept of IT as Developer and is 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.

Infrastructure As Code

Infrastructure As Code

 

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 the topic of “Infrastructure as Code”  (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.

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 Pearl, 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?

Code Stream Pipeline for vRealize Automation Blueprints

Code Stream Pipeline for vRealize Automation Blueprints

 

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.

Blog Series Recap

  1. IT Teams Need To Finally Implement Self-Service Automation
  2. Marketing Internal IT to Line-of-Business

Learn More

The post IT As Developer Of Infrastructure As Code appeared first on VMware Cloud Management.

Leave a Reply

Your email address will not be published. Required fields are marked *