These days there are many new catch phrases and buzz words being thrown around when talking about refreshing storage and compute. Hopefully this blog can help decrypt some of the media speak and categorize these three approaches into a quick cheat sheet that you can use when speaking with your storage, compute, or network vendor.
I’d like to start by using a high level Classification of Architecture that we can use to compare the three different categories. I’ll call it EMMSS!
- Is this an Engineered Solution?
- Is it Manufactured as a single Solution?
- Is it Managed as a single Solution?
- How is the solution Supported?
- What is the solution’s Sustainability?
Let’s review the categories and my EMMSS classifications for each.
What is a Reference Architecture? I would classify a RA as a vendor built/written whitepaper. Vendors typically take a storage array, throw in a couple of servers, and install a high end database or application on that infrastructure. They will then put it through a series of tests to see how well the solution scales and alleviate any major compatibility issues. This will lead to a whitepaper detailing how to duplicate what they built. As long as the customer follows the directions with little deviation, they can reasonably expect the solution to work as described. Of course we all know that we can rarely recreate lab conditions perfectly in the real world. There will always be something different in your environment that was not thought of in the test lab. This is not always an issue, but who helps you deal with the integration challenges and documents the changes required so that you can reproduce the result in the future?
As hinted at above, in a RA, the customer takes on the responsibility for actually doing the integration work to get the solution into production. The customer can choose to work with a partner to handle this piece, like they have done in the past, but it still becomes a custom job for their particular environment. Once you have the solution in production, you must patch it and perform other maintenance tasks. With a RA, you are dealing individually with the different manufacturers who supplied the different pieces and parts for the solution. You the customer must figure out what versions work with what other versions. This information is generally available, but you have to obtain it and perform the work of testing the upgrades yourself, working with each individual vendor if something goes wrong.
Now, let’s match this up to our EMMSS model. I would consider RAs to be an engineered solution. You typically procure all of the pieces independently, so it’s not manufactured as a single solution. The pieces are also managed independently, similar to how you likely operate today. Generally speaking, these are also not supported as a single solution. There may be “joint support agreements”, but these are nothing new, and just mean that each vendor will “try” to work with the other if there is another issue. With the lack of post-sales documentation, support, etc., it’s tough to consider this as the most optimal solution from a sustainability perspective. Again, it doesn’t mean that this option will fail or is impossible. You’re likely doing it this same way already (minus the instruction manual!). If you need the flexibility to customize like crazy, this is the way to go. Just remember that flexibility typically equates to complexity when trying to manage the solution and repeat the results in other environments.
Let’s talk about Hyper-Converged Infrastructure. These HCIs are becoming the talk of the town lately. Many different companies are trying to gain momentum and capture some of the market share against the big companies by offering a single product that has compute, storage, sometimes networking, and sometimes licensing all bundled together.
These products are usually very quick to deploy and have a low entry point from a cost perspective. The big exception is when the solution does not include all of the components, like networking or virtualization licenses. HCIs essentially give you the ability to pool together resources from multiple servers as if they were one, including from a management aspect. This means they are about as easy to deploy as a general purpose server. You can scale this solution by adding more “nodes”, which gives you more compute, storage, networking, etc. The more you scale the more resources you have to manage. There is also a point where this solution breaks down from a cost perspective as you continue to buy each resource as you scale whether you need that resource or not. If your company expects massive growth, you may find yourself with a bunch of independent HCI clusters to manage.
Most of the Hyper-Converged manufacturers say they are engineered, manufactured, managed, supported and sustained as one product. Depending on the manufacturer, this story does not always hold true. If they are not truly providing all of the elements (i.e. networking, virtulization, etc.), you end up still being on the hook for at least part of the patch management and integration work. These HC’Is can add simplicity and they can speed up deployment time, however many of these companies are relatively small/midsized startup companies, and that should be taken into consideration.
If your environment is on the smaller side, or you have a need in a remote office, this could be the solution for you. However, if your environment requires massive growth or ultimate flexibility, this is unlikely the best choice.
Fully Converged Infrastructure is the solution that best covers all of the EMMSS classifications above in my opinion. These products are engineered, manufactured, managed, serviced, and supported as a single product. There is one clear leader in this space, and that is VCE. That’s not just from a market share perspective. VCE has the most mature offering available and uses best of breed technology, not just what’s in their own product portfolio.
VCE’s Vblock Converged Infrastructure means that within 45 days of purchase, you can have a fully configured environment ready to serve applications! That doesn’t mean it ships in 45 days or arrives and you have to spend another 2-3 weeks racking & stacking, getting VMware loaded, integrating into your network, etc. When VCE hands you the keys, it’s literally ready to put production application workloads on the system.
The Vblock is an engineered solution with thousands of man hours spent in testing and development. VCE provides a standardized way to deploy infrastructure in your environment using processes that they use for thousands of other customers. While some look at a Vblock as too rigid, this is exactly one of the major benefits of these systems! The more variance you introduce into your environment, the more risk you create. This standardization is why VCE solutions end up being so reliable. Add to it that VCE has a mature patching & upgrade process (that they will perform for you) and single support resources, and you not only just increased your environment’s reliability, you just freed up your resources to focus on higher-level tasks that provide more value to your business.
With the best of breed storage from EMC, best of breed compute and networking from Cisco, and best of breed virtualization from VMware, a Vblock clearly meets all of the EMMSS criteria and is a powerful platform to support our customers in an ever changing IT landscape.
To wrap up, all 3 of these options have their benefits and draw backs. Like anything in our world, you have to pick the right tool for the right job. I hope this helped you see some of the difference between the different approaches vendors are taking in the market. If you have questions on how best to approach your next project, please contact us! We would love to hear from you!