Chauffeur service, kit-car or a clunker with a bodykit

Imagine your ideal car. What do you prioritise? Are you someone who values ease of use over form factor? Do you enjoy getting under the hood, or do you want to do as little maintenance work as possible? Do you even want to drive, or would you rather be driven by someone else?

Choosing a type of car or car service is a lot like choosing a private cloud. Private clouds come in many flavours and offer many different features but one decision has persisted since the early days. Do you build, or do you buy?

Gung-ho - scratch built

Maybe you have a team of senior engineers just itching to build something. It happens. In this case you are taking the kit-car route. You can have anything you want, as long as the team includes someone who knows how.

OpenStack and VMware systems are both candidates for scratch building, with many experienced engineers leaning towards OpenStack for flexibility and features. With great reward comes great risk - there is no-one to pick up the phone if anything goes wrong. Staffing is a concern, you cannot afford to have the one person who knows a crucial part of the system walk out of the door. Of course such project might never be ready for production.

Photo by <a href="https://unsplash.com/@craigcpcb?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash">Craig Cameron</a> on <a href="https://unsplash.com/photos/brown-cardboard-box-on-gray-car-RHz8amxNmvg?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash">Unsplash</a>

Support is another challenge: as the buck stops with the customer, they must run their own support team for every part of the system. If you are lucky enough to work in an industry where such teams already exist then it can work out, otherwise hiring and retaining the perfect mix of staff is a huge challenge.

Reference architectures - a slightly easier self-build

Deploying groups of servers to perform common functions has historically been tackled in two ways. The vendor either produced a whitepaper or instruction manual and let the customer get on with it - a reference architecture - or the vendor sold fully built systems - termed rack scale solutions.

Reference architectures represented the minimum possible a vendor could realistically do whilst naming the result as part of their product portfolio. A slightly easier kit-car with a friendly vendor who might pick up the phone and make sure you use the correct tools.

Photo by <a href="https://unsplash.com/@ppovoroznuk?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash">Paul Povoroznuk</a> on <a href="https://unsplash.com/photos/man-standing-beside-boxes-bJkynpjVRBQ?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash">Unsplash</a>

The customer takes on a lot of responsibility, including:

  • checking bills of materials,
  • constructing the system,
  • operating the system within specific derived parameters, and
  • expanding the system according to strict rules.

The joke ran that the only reference architecture system the customer could see was the one taken to trade shows; every customer system was a unique snowflake as soon as it was built and the customer was on their own in terms of support. Upgrades represented a huge risk to such a system, but a steady professional services revenue stream to the vendor. This includes systems like the NetApp FlexPod and VMware Validated Designs.

Staffing and support remain challenging but ironically flexibility is greatly reduced, likely due to management expressing a wish to align with a specific vendor.

Rack scale solutions - customised production car

Rack scale solutions were sold as a risk mitigation compared to reference architectures, combining complex server blade chassis, rack mount servers, storage arrays, fiber-channel storage area networking and an Ethernet fabric in one or more racks which would be shipped to the customer in vast shipping containers, pre-installed and ready to go. A typical ordered-to-spec production car with the paint job, seats, trim and wheels of your choice.

Photo by <a href="https://unsplash.com/@sooprun?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash">Alex Suprun</a> on <a href="https://unsplash.com/photos/several-vehicles-parked-beside-wall-AHnhdjyTNGM?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash">Unsplash</a>

Of course the reality of this was still complex, with labyrinthine specialist ordering systems exchanging huge spreadsheets of customer data to include customer uplink networking, lists of customer VLANs and routers and a slew of credential and password data. Doorways needed to be measured to fit the fully-loaded rack and every step of the building entryway needed to carry up to 750Kg+ of pre-built hardware when the system arrived. Customers were largely happy as they had avoided lengthy planning and engineering cycles and were able to use the system, that is until the first upgrade cycle. Upgrades of such a system are notoriously difficult and typically require on-site assistance from the vendor. Horror stories would circulate of customers attempting to upgrade themselves and all but destroying their systems. Examples include the VxBlock and VxRack systems.

Staffing and support are less onerous but card-carrying vendor employees are often present full-time at customer sites.

Hyper or actually hypo converged - most of a car

Ironically when we take a rack scale converged infrastructure system with rack-mount servers and remove the network switches we create a hyper converged system instead of a hypo converged systems. So-called hyper converged infrastructure was a marketing term created to sell systems offering Software Defined Storage instead of a storage array. Fiber channel storage arrays had a reputation for high costs and as much as 10 years ago the SAN equipment was being eclipsed by Ethernet. Today FC SAN is limited to 64Gb whilst Ethernet is 400Gb and up. Moving away from fiber channel, many customers were also increasingly aware that the storage array was little more than a regular server with custom NICs and a fancy face-plate. Shame then that the storage software costs replicate those of the dedicated hardware they replaced. HCI targets smaller sites and teams with lower budgets, and does so by foregoing the network part of CI. Teams must plan, build and maintain the network infrastructure outside of the scope of the HCI, adding risk and making performance guarantees for the storage hard to manage. HCI is like buying a car then finding out you have to bring your own wheels.

Photo by <a target="_blank" rel="noopener noreferrer" href="https://commons.wikimedia.org/w/index.php?curid=52568432">Podol, Kiev. Old car without wheel. - panoramio</a>&quot; by <a target="_blank" rel="noopener noreferrer" href="http://web.archive.org/web/20161028024918/http://www.panoramio.com/user/1039651?with_photo_id=23717278">Viktor Ugrin</a> is licensed under <a target="_blank" rel="noopener noreferrer" href="https://creativecommons.org/licenses/by-sa/3.0/?ref=openverse">CC BY-SA 3.0.

True “Buy” value - chauffeur driven comfort

SoftIron’s HyperCloud steps past CI, HCI and prior solutions, offering a new premise. Ready to run without a huge initial investment. Ready to scale without customer engineering risk or a huge professional services fee. Ready to upgrade without reading compatibility matrices and 100s of pages of instructions. Integrated and simple to run, whilst still including networking and everything to run.

Customers are no longer responsible for building cars, they can enjoy using them instead!

Photo by <a href="https://unsplash.com/@michaelbenz?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash">Michael Benz</a> on <a href="https://unsplash.com/photos/person-holding-clear-wine-glass-eiJfBem7cPw?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash">Unsplash</a>

You can marvel at how it all works if you like. But it doesn’t have to keep you up at night.

Related articles