By Tony Lock, Freeform Dynamics Ltd.
Cloud might represent a new mindset for users, but – unfashionable though it might be to say it! – buying solutions and systems to support internal clouds should be no different from the way you buy any other IT tech. That’s especially true given that cloud likes to present itself as being always available, and ready to scale whenever you need.
For example, while your data center probably has a mix of equipment of various ages, acquired from multiple manufacturers, each and every piece of it is there for a reason. It was most likely selected to meet clear technical requirements, especially in terms of performance, reliability, security and scalability. And then you probably looked at the best way to finance it – perhaps most importantly of all – at how you and the supplier would support it in operational use for several years.
Conversely, one thing most organizations cannot do is build their private cloud in the same way that public clouds are built. For a start, public clouds are typically built so that if one hardware element fails, there will be plenty of others ready to take up the slack, but enterprises rarely have the ability to replicate such large resource pools. And it is quite possible that some of the applications your organization wants to develop may not be tolerant of the public cloud’s “fail/restart” approach, and will instead require more resilience.
So if you are putting together an RFP or PoC to create an internal cloud platform, what are the key factors you need to look for in the equipment you’re going to be using?
Take the example of the Microsoft Azure Stack, which is one of the platforms that enterprises and service providers are looking at to build internal cloud-like capabilities. This is designed to bring Azure into your data center, and to do so it is built as a hyper-converged infrastructure (HCI) solution. So first, you will want the underlying hardware to be enterprise-grade rather than “cheap and cheerful”.
However, while that will help to ensure that hardware problems occur less often, it cannot eliminate them. Thus, you will also need to look for kit that is built to be fault-tolerant, with management software capable of identifying hardware failures, isolating them and automatically keeping the software going. The software should then report the failures to the hardware service provider for remediation, again without system administrators having to get involved.
The same applies to routine maintenance activities such as updates to firmware and the underlying Azure Stack software elements. Plus we must not overlook the cloud attribute of scalability. To do this the hardware platform must be designed to accept additional physical resources (compute, storage and network) and add them to its resource pools without impacting service.
Next, cloud may be cloud but it’s very unlikely your Azure Stack HCI systems will function as a stand-alone silo. So you will want to make sure that it and its management software integrate with your existing systems monitoring, management, and reporting tools. You may also want to check whether the system gives you sufficient reporting of resource consumption to let you cross-charge your Azure Stack users.
Another area to consider is that while Microsoft Azure Stack appliances may be designed as complete platforms, it is highly likely that you are going to need to protect the data and applications they hold. Thus, the HCI system you select should fit seamlessly into your existing data protection regime, even if you must allocate specific resources to meet the additional demands. To an experienced enterprise IT professional, none of this will be new.
Lastly, there is the supplier angle. While Microsoft Azure Stack is still in its early days, there are vendors such as Fujitsu who have already acquired significant experience building HCI systems that address key enterprise requirements for performance, availability, scalability and resilience. They also tend to have the support skills and financial flexibility that enterprises look for. I will look more deeply at the importance of suppliers in my next blog in this series.