Today’s IT environment is somewhat reminiscent of the days of the Linux Revolution. We see the established vendor base under pressure for the cloud, both as an alternative way of doing business and as a new method of deploying inexpensive COTS hardware and open-source code to drastically reduce the cost of IT.
Nowhere is this more evident than in the thought processes behind the private cloud. Seen as a natural successor to virtual server clusters, the idea of extending automated control to cover everything from orchestration to billing is now within reach, thanks to OpenStack, while the same COTS vendors that deliver in huge quantities to the mega-cloud providers are now reaching out into distribution and end–user sales.
COTS is in many ways shorthand for a simplification process that, derived from templates provided by the CPU makers, embodies consistent operation and interfaces into the servers and storage products, making integration relatively risk-free. In fact, any attempt to limit configurations to pre-approved and usually expensive systems is frowned upon mightily by the industry.
There are three ways to build a private cloud. First, using OpenStack and COTS systems, a cloud can be built from basic building blocks. Second, a system vendor can integrate all the pieces for you and deliver a turnkey solution. The third option is relatively new and that’s to rent a fixed space on someone else’s cloud setup. All of these approaches have value, but they play differently and it’s worth looking at the implications and opportunities they each deliver.
Building a private cloud from scratch isn’t a huge challenge today. Now not everyone agrees, but ask if they are trying to sell proprietary hardware or software before listening! Even so, this approach does mean that IT has to get involved with hardware selection and integration. One answer to integration issues is to add in a software management scheme for the cluster infrastructure, such as StrataCloud. This type of tool manages hardware integration into the cluster for you.
In configuring a bare-bones COTS server, try to avoid pushing to the limits of the particular server or storage box you select. Sure, you can add a bunch of NVMe SSDs and flash cards, but that can create cabling nightmare, use a lot of power and make for an out-of-balance system. Usually, your systems vendor will guide those choices.
Speaking of drives, it’s time to talk “enterprise drive”. It used to be de rigeur that servers needed these much more expensive hard drives if they were to maintain data integrity and uptime, but the rules of system building have shifted to an appliance-level integrity model, where dual-ported drives no longer make any sense.
This brings the second major savings opportunity. After the base box and motherboard or drive controller, the drives are usually the biggest cost item. Looking at internet pricing, we’ll find that SSD pricing has dropped well below that of Enterprise hard drives, though not yet to the level of bulk storage.
Avoiding enterprise drives can save a lot of hard cash, especially when even relatively slow SSDs outperform those drives by big factors. Usually, this speed translates into fewer servers being needed for any particular workload, and the savings there may pay for the SSD drives. This too may be moot by the end of 2017, since 3D NAND is helping to drop SSD prices at a pretty fast pace.
The next major saving lies in software. I’m an ardent fan of containers as a way to reduce the footprint of a virtual machine. Not only do containers increase VM count by factors of 3 to 5 times, the reduction in image loading favorably impacts network loading and storage data rates. This should obviate a good portion of the next few planned server buys.
Also crucial in planning is the choice of a fast network. We are moving to an era where 25/100 GbE is the way to connect, with RDMA over Ethernet fast on its heels. Fast networks make servers run better and 3000 VMs running in containers on a server deserve something better than a single 10GbE port!
For a premium, you can get the integration task done for you. The traditional vendors all provide pre-integrated OpenStack and startup support services, but the price isn’t small and vendor lock-in is a big issue. Try putting a drive from distribution into one of these systems.
The biggest integration task is OpenStack itself. It’s complicated and still not well understood across the admin population. A good experience in installing a cluster requires at least a couple of seasoned staff and they are hard to find. Enter Red Hat (and others) offering startup expertise. It costs some extra cash, but the bootstrap effect is often worth it. Overall, using an integrator is part way between do-it-yourself and a turnkey cloud solution.
The third alternative, using a managed cloud provider, puts the onus of starting up completely on a third party. Whether the physical gear is co-hosted by the cloud manager or on-premise, this is a good way to nullify start-up risk, but is likely to prove expensive in the long haul. The approach has variants, with AWS having dedicated cloud spaces and Rackspace offering a broader management approach, for example.
I’ve not mentioned Azure much. Microsoft has a “Stack-in-the-Box” approach in the pipeline for 2017 general availability. Recent announcements point to this being restricted to limited configurations on an OEM basis. The implications are higher acquisition and support costs and many are asking why this isn’t like Windows and fully open.
It is possible that over the life-cycle of a private cloud, all of these approaches might be used at some point. The arbiter will be a TCO analysis and a risk-benefit assessment. With management software evolving rapidly, the risk side is bound to decrease over time, leaning solutions more to the DIY approach and overall a much lower cost of computing. Couple the evolution to software-defined infrastructure and automated approaches should ease admin tasks and lead to even further cost reductions downstream.