Make IT Portable: Give em OVAs!

It has been a busy few weeks.  A big part of that has been rebuilding my home lab to focus on doing real lab work not dabbling in whatever struck my fancy over the past few months.  In doing so I have been spinning up machines left and right.  Frustratingly I have had to spin up some of those servers 4 or 5 times in order to get to them to do what I need them to do.

Over and over and over we have been calling for the elimination of complexity when its not required.  But in the simple deployment of a lab it takes digging around the web, countless hours of reading and multiple failed attempts, it would seem that the industry is not eating its own dog food.  I would rather be be actively working with Openstack, OpenDaylight or ELK Stack opposed to troubleshooting why my install does not work after following directions to a tee.

We work hard on projects and products that we want people to adopt and buy.  Those people honestly usually have better things to do than dig through pages of documentation trying to figure out how to get those projects and products installed.  There a solutions for this.  Some people would say use the automation and configuration platforms like Ansible, SaltStack, Chef or Puppet.  I don’t really disagree.  But building out the configuration files for each of these takes time even if they can deal with a large set of operating systems.  There are also package management platform like apt and yum in the operating systems.  But again these take time to keep up to date and are often at least a rev behind shipping code.

So I would like to propose that we all do something different using something we already have.  Do something that many have been doing in some form for years.  Build your dreams in projects and products.  Then choose your preferred operating system and take the time to build a solid OVA and make it available to your clients. There are lots of options for keeping an OVA up to date with minimal effort.  Operating systems provide options for automated updates using package managers if for no other reason than keeping security updates current.  Once we have enabled our customers with rapid deployment of the projects and products we want them to use then we can lean on the automation and configuration platforms to keep them up to date and in compliance with organizational policies.

Along that line there is no reason that these same projects and products cannot be deployed just as they are now for clients who have more specialized requirements or preferences for platforms other than that of which the OVA was deployed on.  Flexibility will always be a critical aspect of what we do in IT.  However simplicity when possible should always be our goal.  I would love to get others input on this.  Please comment or join the fray on twitter you’ll find me there at @joshobrien77.

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.