During the last decade, I did quite a bit of launching IT and product operations for products as a ‘sidelight’ of my main product development work. Build the product, launch it operationally, and grow/maintain it going forward. This pretty well matches the responsibility of a DevOps role as people are now using the term, so I seem to be among the earlier ‘DevOps’ people. At first I had a Data Center (racks in Hurricane Electric), later VMWare ESX on the Data Center, later servers running in other people’s Data Centers (e.g. RackSpace), and then servers running in true clouds (e.g. AWS, GCE, etc.)

A number of tools have appeared to help automate operations, and each seems to have a fair number of acolytes. One of the issues with software is that there is a lot of it, and it takes quite a bit of time to become familiar with all of (a) software design, (b) software languages and (c) the problem domain itself.

Although it was not really my ‘direct intent’, over a decade I put in thousands of hours into DevOps. We needed a running product and I was more and more concerned that the operations itself needed to be capable and software deployment seamless. Part of this may have kicked in when I lost all Thanksgiving vacation in a data center fixing someones very bad IT.

Comparison

You really shouldn’t talk about something you don’t know, and ideally you know quite a few different things so you can compare them to each other. Or you can try to leverage someone else’s work and evaluation to help yourself go in the right direction.

The ‘Taste Of’ series is meant to help people compare different programming languages solving a similar problem. The ‘Architecture’ series is meant to help people see similarities and differences of architectures solving various problems.

This comparison describes a number of plausible ways to provision and deploy software systems. Depending on your goals and background, they are all viable. Some are clearly better for most teams because they deal with critical needs very effectively, where others handle needs some teams might have and other would never have.

A list of approaches is below.

• Copy-Paste Provision – Have a script designed to provision a machine, and copy-paste into the console to make it happen
• Machine Image – Have a virtual machine image that you can clone and launch
• SSH-Provision – Have a script that executes on any number of machines
• Jenkins (Pipeline) Deploy – Have the automated pipeline automatically deploy/provision
• Bash-Up – Have a script that a machine can automatically execute when baseline provisioned
• Git-Deploy – Have one or more repositories with changing contents and machines watching (PushMePullYou)
• Provisioning DSLs:
  • Chef
  • Puppet
  • Ansible
  • Salt
• BOSH
• Docker
• RightScale

Goals

Software operations is software running. Development operations is within the development team, and production operations is for the benefit of users outside the development team. DevOp Goals can be either for development or production. Some of them include:

• DOG-1: Running the software successfully with the intended amount of usage
• DOG-2: Handling spikes of usage successfully/gracefully
• DOG-3: Being easy to diagnose and repair issues
• DOG-4: Knowing what version (of each/all components) is running in a given environment
• DOG-5: Easily deploying new versions
• DOG-6: Automatedly deploying new versions
• DOG-7: Being able to tune system components to behave optimally
• DOG-8: Being able to understand what the working environment looks like and how it works
• DOG-9: Not having a single-point-of-failure (SPOF)
• DOG-10: Having development and production mirror each other as much as possible
• DOG-11: Being able to deploy to a new data center easily