If you are embarking on building a software defined data center there are a few main ways you can go about it. Each of them has some merit, but all have trade-offs you’ll need to make too. Here’s our take on the four main choices laid out before you.
Option One – Going Proprietary
The first option to consider is to back the horse of one of the proprietary vendors building a software defined integrated hardware/software solution. This route is perhaps, at least on the face of it, the simplest to take. The vendor provides you with a “black box”, with all integration between hardware and software layers complete along with, you can expect, a hardware configuration designed and optimized to run their proprietary software – though they will likely still sell you an up front consulting engagement to best fit their solution to your environment. From a support point of view there is little wiggle room for the vendor to point a finger elsewhere. They designed, tested and delivered (either directly or through approved partners) the solution, so it’s fair to assume they are able to provide all the support required to design, deliver and maintain it.
But there’s a price to all of this, of course. Financially this is likely one of the most expensive routes in capital outlay. Plus, once you made your choice you are likely then locked into that vendor, their partners and their product roadmap, including any forklift upgrades they dictate, for a good number of years to come. Remember also that this is a relatively immature market with mergers and acquisitions common. You’ll want to ensure that you have confidence that the product family and architecture you choose will be both developed and supported for the time you’ll want to own it.
Option Two – “Roll Your Own”
Perhaps then you’ve decided to go the open source route, downloading a standard linux distro and, say Ceph (good choice, btw), as your SDS platform. You’ll probably have also gone the white label route, buying x86 servers from any number of vendors with the best spec. you can afford that meets or exceeds the recommended hardware requirements.
There are a couple of really good things about this approach. The initial capital outlay is almost certainly the lowest of any option. It also cuts the tie between your hardware and software strategy giving you the least vendor lock-in and widest variety of flexibility to seek out great deals and trial new configurations and software releases. But, of course, in that initial upfront saving lies a whole host of hidden costs. First it’s going to be down to you to do the integration, optimize at both the box and solution configuration (and it’s often at the solution level that things get most tricky). Your options for on-going management of the solution will be limited with no meaningful integration between the layers of hardware and software in the stack. Without careful control you may also end up with a real mix of hardware to manage – always tempted by the latest low cost offer. It’s this hidden complexity that will really start to hurt in the long term – especially if you have things like automation in mind. In fact, you may even end up having to bring in a “Ceph savvy” consulting firm to remediate issues that continue to elude you. And, assuming they are able to address the issues, will you then have to consider a support contract with them to give you the on-going support that will likely be needed?
If you have an endless supply of “command line warriors”, or are maybe in a test or experimental type environment, then maybe this option works for you – able to tinker and tweak the deployment to your heart’s content trying to coax better performance out of it. For many however, especially those looking for enterprise class type capability and resilience, this complexity overhead, lack of support or predictable performance will be a stretch too far.
Option Three – Supported SDS
Another option you might consider is to run a supported software defined stack on top of generic hardware. Here you might still choose to go open source, but use a supported stack from one of the “red, green or orange” vendors. You might choose to go the proprietary route and choose one of the SDS vendors relying on third party hardware for their platform to run. On the plus side you’ve still abstracted your hardware platform away from your software architecture. In this instance however, your hardware choice is still going to be limited to approved vendors and configurations from those vendors.
The on-going management and support of this kind of architecture is almost certainly better than “rolling your own”, but still that separation of the hardware and software layer will likely lead to instances where troubleshooting and support becomes fragmented between support teams and contracts. You may need to pay the vendor to, at best review, or at worst design and implement any config changes to ensure you do not void either support contract. And, even if you do all of that, if the finger pointing starts between them it’s likely you, the customer, that’s going to get caught in the middle.
From a cost point of view you have (at least) two vendor relationships, two contracts and two support teams. Depending on the badge on the hardware you decide to deploy those costs might well rack up to the same, or even more than a fully integrated proprietary solution. At a macro level, what have you really achieved?
Option Four – the SoftIron Approach
Of course we’re biased, but we think our approach that combines the best of open source based flexibility, with a dedicated, optimized, task specific platform and integrated support gives our customers the optimal blend of any of the other three options. And today, we believe, we’re the only company in the world to do this.
At the software defined layer, you’re running standard open source (Ceph for storage, SONiC for switching, ffMPEG for transcoding), but you’re combining that with a hardware optimized, designed from the ground up, platform on which it can run. A platform that’s predictable in its behavior, fine tuned to deliver blistering performance and efficiency, and is configured, managed and supported with (at least) the same simplicity that a totally proprietary solution might have achieved.
Because you’re running standard open source, you’ve still abstracted your hardware and software strategies, so if at some point SoftIron disappoints or becomes a poor fit (unlikely, but in theory possible), you’re free to do so – but crucially the software architecture remains untouched. In the meantime you enjoy the benefit of the simplicity and performance that come from integrated hardware and software consulting and support. You have known performance characteristics and integration points. You have access to what we consider to be the most finely tuned platforms to efficiently run open source at scale with Enterprise class management and performance available today.
Ultimately the choice is yours of course – and in your particular scenario maybe another option works better for you. If Option four sounds like a good fit though, why not get in touch and let’s talk.
