Welcome!

IT Is Power. Try Living Without A Single Breadboard For A Day.

Don MacVittie

Subscribe to Don MacVittie: eMailAlertsEmail Alerts
Get Don MacVittie via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Cloud Computing, OpenStack Journal

Blog Feed Post

The Language of Provisioning By @DMacVittie | @CloudExpo #Cloud

The path to automation is not a straight one at most organizations

If you think of automated provisioning as a formal written language definition, it does have some value in illuminating issues with partial automation or portions of the overall data center that are not automated.

The path to automation is not a straight one at most organizations. It takes time, it takes resources, and even though there is a definable ROI, the press of business needs wins every time there is a conflict – because meeting business needs is pretty much the purpose of IT.

But taking the staggered approach has costs too, and it’s good on occasion to look at them. I’ve admittedly created this view, but it is a way to consider your automation efforts and how well they’re working with regard to the end goal.

We cover bare metal provisioning, application provisioning, multi-system provisioning, and cluster provisioning here. There is a relationship between these things, we’ll go over it as it develops. Afterward, we’ll peek at network and storage provisioning – because the datacenter is the automation goal, if attainable.

The basic building block of any language is the letter. In our case, letters represent the bits of hardware in a server…

Letters

Bare metal provisioning should be able to handle all of them, and if it is bare (virtual) metal provisioning, it should be able to handle virtualized versions of them also.

These are the basic building blocks. You cannot automate an entire datacenter without having automation in place for these bits. Sitting and booting into the RAID card BIOS to set up arrays, or hand partitioning your disk, or hand loading drivers is time-consuming and not in line with automation goals.

These, when taken together, form words, which for our comparison are servers.

Words

Now words represent the smallest thing that can convey meaning. This might ultimately be destined to be a Linux server, or a Windows server, but the point is, it is a container that can hold applications. It could be physical, virtual, or cloud.

Again, this is the bailiwick of Bare Metal Provisioning, if physical or virtual bare metal, and the bailiwick of the cloud management software if in the cloud. Either way, full automation to bring this server up with all of the hardware configured and the OS installed and configured will speed all IT deployments.

On top of server, there are of course phrases and sentences, represented by us as the application. This is the point where the business starts getting interested in what IT is doing…

Sentence

These are important because they include application provisioning, and allow for the application to be deployed, expanded, upgraded, and recycled automatically. A few lines of script and your favorite application provisioning tool, and you’re spinning up tons of whatever is needed – provided the bare metal provisioning tool has done it’s job, and you have targets that are already pre-configured with the OS.

These sentences are normally tied to other sentences – you need an AAA system for any public facing app, for example, but they are stand-alone in that they have a specific function that they completely provide. Unlike the step below them “words”, these systems have applications that are deployed and configured on-demand.

Adding a little bit of complexity offers us the next element in our language – paragraphs. These are high-availability clustered servers. Think of OpenStack and Hadoop as two good examples. A single server with the application on it won’t generally work (outside of dev anyway), you need multiple systems running. Here’s our paragraph:

Paragraph

These systems are highly useful when needed, but highly complex. An automation tool at this level offers an immense time saver if it is adequately implemented. While these systems are very useful, they rely upon the underlying infrastructure to be installed and configured correctly, along with the portions of the app that a given server needs to fulfill its role within the cluster.

These tools tend to be more than application provisioning tools, and they tend to be specialized just like the clustered software they support. The requirements of OpenStack are vastly different than the requirements of Hadoop, even though both require multiple servers running a subset of the overall system and in constant communication.

And yet, they require fully functional OS installs on servers, application configuration, support for whatever hardware is provided… They have much in common with generalized application provisioning.

You Need the Entire Language

Language

When letters are left out of a language, it quickly becomes gibberish. While native-speakers of the language can generally make out the meaning, it takes them longer to do so.

The same is true with datacenter provisioning. The more parts that are not automated, the more time is wasted providing the missing parts. We need solutions or solution sets that can handle the entire language.

We Have the Tools, So the Answer Is Easy
Well, relatively easy at least.

  • Build a full language (stack) solution
  • Automate configuration from the parts of a server through app configuration.
  • Tie the systems together, so that there is a single automation flow.
  • Have the parts able to operate independently, so that changing out a NIC doesn’t require a ton of overhead.

And Remember the Parts of a Full Datacenter Solution:

  • Bare Metal Provisioning
    • Hardware (and VM) elements and OS
    • Everything required (including config!) to spin up a server
  • Application Provisioning
    • Application install on top of the OS
    • Everything required (including config!) to spin up the app on a running server.
  • Cluster Provisioning
    • Cluster install and distribution
    • Everything required to make complex multi-system software like internal cloud or big data systems run on servers with installed OS’s.

The Other Provisioning(s)
There are two more areas where provisioning is moving forward. They contribute to the language by adding nuance, so I saved them to keep my precious theme alive, but many organizations are looking at them:

  • Cloud instance provisioning. Where Bare Metal Provisioning often falls short is with cloud instances. Much of this is because cloud systems have their own dedicated way of spinning up instances with the OS pre-installed (AMIs, etc). Application Provisioning tends to be the same as post-bare-metal, so the only extra bit is using cloud vendor APIs to initially configure a server instead of bare metal provisioning.
  • Network Provisioning. Increasingly, those who are automating the datacenter want to automate the networking along with servers. This market is moving fast, but as of this writing there just aren’t truly solid products out there that meet this desire. SDN, NSX, and ACI all offer promise that this capability is just around the corner though, so it is a good area to watch.
  • Storage Provisioning. This is arguably the most stable of all provisioning, and has been in use since I was Storage and Servers Technical Editor for Network Computing around the turn of the century. Probably you’ve got this down, and need only tweak for new technologies.

It’s safe to say that when one or more of these technologies is ready for prime time, we will have reached the Software Defined Data Center in more than marketing literature.

FasterBetterSmarter
Check out the options available in these markets, choose the ones that best suit your needs, and automate the mundane so that you can focus on business differentiation.

As always, remember to worry more about your organizations’ needs than what someone is screaming that you must do today… Because you have to actually live with what you’re implementing, perhaps for years.

Read the original blog entry...

More Stories By Don MacVittie

Don MacVittie is founder of Ingrained Technology, A technical advocacy and software development consultancy. He has experience in application development, architecture, infrastructure, technical writing,DevOps, and IT management. MacVittie holds a B.S. in Computer Science from Northern Michigan University, and an M.S. in Computer Science from Nova Southeastern University.