The Cranky Admin

A Step-By-Step Guide to DIY Cloud

Trevor Pott takes the first step toward rolling his own.

• By Trevor Pott
• 03/22/2017

Learning about clouds has nothing to do with tech, and everything to do with business and economics: subjects virtual admins are going to need to master to survive in tomorrow's world. The tech is, comparatively speaking, the easy part. You can buy cloud-in-a-can today. Retraining ourselves to grok cloud is what will be hard.

For the individual who wishes to dive into the public cloud, the first thing they'll discover is just how staggeringly expensive it is. As individuals we wail and moan about the cost of a mobile subscription, or the fees our ISP charge us for home internet connectivity. Try lighting up one of each service that Amazon offers for a month and you'll start to truly understand the deceptive simplicity of the opex economic model.

You Must Unlearn What You Have Learned
What's important about clouds is unlearning all the marketing lies we've been told over the years and learning the truth: when using a cloud you do not pay for what you use, you pay for what you provision. In a cloudy world, allocation is key. How you slice up hosts into virtual CPUs, RAM, storage, networking and so forth is the be-all and end-all of how the cloud provider gets paid.

Virtualization administrators are under increasing pressure to cloudify things. Embedded customer administrators are asked to consider the public cloud as well as on-premises clouds. The channel are scrambling to build their own clouds. And yes, there are risks.

Even organizations that 10 years ago would never have thought about providing IT services to their customers are today approaching me to help them build clouds they can re-sell to their customers. They are doing this because their customers are SMBs that are bad at IT. If those SMBs go under due to IT failures, the supplier organizations do too, so they are intent on providing IT services to those SMBs that directly integrate with the supplier IT chains.

Self-service multi-tenant IT systems are no longer novelty, they're becoming the default. So how do we set about unlearning everything we need to learn?

Face First Into the Breach
Personally, I'm terrible at book learning. I learn by breaking things, so the best way to unlearn might be to give it all a go and see what breaks. There are many providers who help me make this happen. Fortunately, I have a test lab and thus the opportunity to try multiple options simultaneously. Naturally, I intend to document the journey.

The first step along the path is to do a needs assessment.  What is it that I am trying to accomplish by building my cloud? Who will be my target market? What resources do I have to bring to bear? In other words, knowing what I need and what I have.

Part two is to pick and master my cloud software. As much as we would all like to be able to beat software into the shape of our expectations and business processes, the reality is often more give and take. I will have to select a happy medium between how developers envision the world and how I operate in practice so that I can transition to cloudthink as painlessly as possible.

Part three is going to be realizing how woefully unprepared I am. It's one thing to cheer and say that I have a great test lab, but after a proper needs assessment, and learning how the software works, I'm bound to discover that there's a whole bunch of stuff I'm missing if I want to roll my own cloud. I'm going to have to come up with a plan to bridge the gaps.

Part four will be struggle and strife; getting the production environment built, the software installed and the first demo virtual environments set up. How to I create templates for end-users to consume, and how do I keep those templates up to date?

Part five will have to focus on monitoring. How much of the administrative burden can be automated before I even begin? How do I achieve the lowest possible mean time to innocence in any outage and what does my supply chain look like for repairs of any given component? How do I achieve the lowest possible mean time to innocence in any outage? (Essentially, how I can prove that this is not some configuration error on my part. Also: what does my supply chain look like for repairs of any given component? Do I replace components or whole nodes, and do I have spares on hand or must I wait hours or days for replacements to be shipped in?)

Part six will be an exercise in reality. How do I determine what my ongoing costs are for hardware, software, datacenter space, and administrative time? Can I teach my customers how to use this software? Do I need to create tutorials and training material? Is this cloud I propose to build viable in the long term?

Learn From My Mistakes
As I stumble from mistake to mistake and document for all to enjoy, reader feedback will be welcomed. At the end of it all, if there's enough feedback to warrant it, I'd like to write a blog about what it was like to design and implement my own cloud piece by piece in the public eye.

These sorts of articles tend to get the eye of the vendors involved. With luck, I will be in a position to forward reader questions, comments and concerns to the vendors directly. It's bound to be wild fun, building some clouds for own nefarious purposes. I hope you'll help me make sure the vendors build products that work for Virtualization & Cloud Review's readers too. Email me here and let's get the conversation going.