What is DevOps?

I realize this topic has probably been beaten to death, but I had to put together a presentation for a group of my peers and I thought it might work as a blog post.  Plus, adding it here helps me internalize my thoughts about a topic.  I hope some of it is a useful distillation of the information out there on this huge topic.  If you find it interesting, I highly recommend checking out one of the books I list below.

A Definition:

DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support.  It’s also characterized by operations using many of the same techniques as developers.

Think automated infrastructure provisioning.  You’ll frequently hear the phrase “infrastructure as code.”  What that means is that provisioning activities are driven by a recipe that can be treated like a program.  For example, the application Puppet has a concept called “manifests” which are used to create an application and also to determine if the running machines comply to that specification.

The Three Ways:

In “The Phoenix Project,” Gene Kim talks about the Three Ways, methods used to continuously improve IT operations.  These have been taken from manufacturing theories used in many organizations today.  (credit for the images goes to Gene Kim on his https://itrevolution.com/ website)

The First Way


The First Way emphasizes the performance of the entire system.  It also encourages IT to look at Operations as a Customer of Development.  It consists of Dev creating services which are transitioned to Operations and then consumed by the Business.

The Second Way


The Second Way is all about feedback loops.  There should be continuous feedback about the results of the product delivered to Operations by Development.  This enables continuous improvement to be built-in.

The Third Way


The Third Way is about the culture of the organization.  It’s about creating a culture that fosters two things: continual experimentation,  and understanding that repetition and practice is the prerequisite to mastery.  IT can be very resistant to change.  Also failures can result in finger pointing and this can create an “us versus them” environment.  I think this way is probably the hardest to implement, because it can require a real mind shift in the people of the organization.

Common DevOps Practices

Let’s talk about some of the more common practices organizations use to implement a DevOps culture.

Version Control

This is key to the concept I mentioned above around “infrastructure as code.”  You need to have some way to control the configuration of your systems and the best way to do this is some type of version control system.  Many companies are using Git and Github for this, although you might also see systems like svn and cvs.  This is also where products like Puppet and Chef come in, as they provide a way to consume these “recipes” when building and maintaining systems.

Automated Testing

Instrumental in implementing the Second Way, some type of automated testing should be built into an environment so that continual improvements can be realized.  Also, this will help minimize issues creeping into Production.  Some examples of testing frameworks include Pester and Cucumber.  These are both examples of software that is designed to provide BDD, or Behavior-Driven Development.  A good read about what BDD is and why it can help improve your processes and app development is here.  You can also find a good intro into testing methodologies here.


This is almost an obvious one, but the advent of virtualization enabled the implementation of DevOps throughout organizations.  It made it much simpler to deploy systems automatically and based on a configuration described by code.  Systems like containers and Docker have taken this to the next level by abstracting even further from the underlying hardware.  New tools like NSX and network virtualization extend this promise of “infrastructure as code” by allowing Ops to control not only the systems, but also the networks that connect them.

More Reading

Here are some good resources if you want to delve more into the world of DevOps and help improve your environment.

Ravello Systems Review

Recently, I was given access to an account at Ravello Systems (full disclosure: this is a free account given to vExperts) and I thought I’d write about my experience. For those of you that don’t know, it’s a front end for deploying workloads in AWS and was bought by Oracle in 2015.

I’ve had an account with them for a while, but really never needed to utilize it due to having some pretty sweet home lab gear provided by my previous job. However, with me going over to Rubrik in March, I obviously had to return that stuff and I’m not sure if I’m going to purchase new gear on my own. It’s just getting so you don’t need a homelab for a lot of things anymore, and tools like Ravello make that possible.

Well, on to the review. The interface is really nice in that it looks like a standard blueprint and has a lot in common with a Visio or Lucidchart drawing. You add components to the design and on the right pane you can configure their settings.


The account comes with various pre-configured VMs, like the one shown above which can be used to install ESXi.  I’m building a vSphere farm in that example.  You do have to provide your own software images and licenses, but they can be uploaded easily.  Once that’s done, you simply connect the ISO to the VM and install ESXi normally.  You can also do some cool things with their import tool, like pulling in running VM images from your existing vSphere environments,  sort of like a V2V converter.

The networking options are fairly robust, as well.  You can configure DHCP or static addresses, as well as control which NICs have external access.

Finally, the entire platform has a REST API available, if you want to automate the provisioning or management of your environments here.  This could be really powerful, as it extends the functionality to any scripts or automation tools you might have.


For a potential homelab / SMB lab use, I think this could be really powerful.  It reduces or eliminates the need to buy gear that will eventually become obsolete (or get taken back by your previous employer!).

Learning Python

So, I’ve decided to start working on my Python skills.  I’ve always been a code borrrower, using others’ scripts and modifying them to fit my own needs. I imagine this describes a lot of you out there.   It’s always easier to edit other work than create something on your own.  Like anything in the Linux world, there are a lot of resources out there, both free and paid.  I found a good subreddit about it here: https://www.reddit.com/r/learnpython/

Based on that, I’ve decided to go through the course at Learn Python the Hard Way.  I like his approach of repetitive lessons.  Also, he stresses using the command line, rather than an IDE.  The initial exercises are really basic, but I’ve been slogging through them and I’ll update here with my progress.