James Thew - Fotolia

Manage Learn to apply best practices and optimize your operations.

A CTO's vetting process for hyper-converged architectures

Hyper-converged architectures: CTO and SearchCIO columnist Niel Nickolaisen lays out the five critical questions he asked before taking the plunge.

It was only a few years ago that I concluded all the interesting technology innovations were happening at the application layer. The focus was on mobile apps, compelling user experiences through intuitive design, data analytics tools and predictive analytics, digital marketing and segmentation. It seemed as if we had taken the infrastructure layer as far as it could go.

Boy was I ever wrong. With the advent of software-defined everything, solid state storage and hyper-converged infrastructures, the world of infrastructure is a hotbed of innovation with lots of interesting opportunities, choices and decisions -- starting with hyper-converged architectures.

Hyper-converged architectures consolidate compute, storage, networking and virtualization onto a single device. Why do this? It simplifies management (all management happens through a common console), can be less expensive than separate or converged alternatives and delivers the flexibility of cloud services but on our own hardware -- it scales simply and allows us to expand in smaller chunks. This eliminates the need to make a large, upfront investment in services (compute power, storage and networking) that get cheaper each and every day.

We recently took the hyper-converged plunge and I thought it might be worthwhile to explain our rationale and approach.

Five questions for the hyper-convergence vendor

There are also some things that are expensive to run on hyper-converged infrastructures -- for example, your database or application provider might require you to license every device.

The primary driver for our choice was to create our own high-performance cloud-like services that we could use for failover and replication and incremental expansion. For regulatory reasons, this had to be on our own hardware -- hence, hyper-converged architectures. We looked at the numerous options but based our decision on the following:

  • What hypervisor does the product support? This is critical because we still need to license the virtualization product that runs on the device -- unless we use an open source option.
  • Does the design and architecture create real clusters? We needed to make sure that the various nodes would replicate and failover to each other -- some do this better than others (and some not well at all).
  • Can you vary the ratio of compute power and storage? We needed to match compute/storage power to different use cases and so needed the ability to switch from compute intensive to storage intensive.
  • How simple and easy is it to deploy in remote locations? We would be deploying the devices in different geographies and, sometimes, using local technical resources. We wanted the process to be nearly error-proof.
  • Finally, would our hyper-converged infrastructure be a way to replace our legacy, converged infrastructure but at a lower cost? Over time, we want to shift our spending from our "plumbing" to innovation and hope that this would help us make that shift.

Hyper-converged architectures: Lessons learned

We are now quite a ways along on our hyper-converged infrastructure path and have learned quite a bit.

  1. First, some of our decision criteria have changed. Solid state storage costs continue to drop and are approaching the cost of spinning disk -- but at much higher levels of performance. This changes the hyper-converged value equation unless the hyper-converged infrastructure allows the use of solid state storage.
  2. Second, there are also some things that are expensive to run on hyper-converged infrastructures -- for example, your database or application provider might require you to license every device. (From their perspective, you "could" run their products on the processors of the clustered hyper-converged infrastructures.)
  3. Third, it could be that a combination of separate compute, storage and networking is actually less expensive than an equally-powerful hyper-converged infrastructure.

Looking back, we made the right decision when we took the plunge and it turns out that our decision was right because of the flexibility hyper-converged infrastructures provide us -- all in a nice, single piece of equipment.

Next Steps

Previous columns by Nickolaisen:

My campaign to the business for adopting a platform business model

Learn to test and scale emerging technologies with 3D printing

Don't pay a fortune for advanced analytics

Dig Deeper on Enterprise systems management