There has been much talk recently about multi-zone and multi-region cloud infrastructures – indeed this is often the defacto definition of a cloud infrastructure. But does it have to be ‘the’ definition for cloud service platforms? I suggest no, there is a whole tranche of use cases for cloud infrastructure that can happily reside on single-zone or single-region infrastructure.
Designing resilience into any infrastructure is the primary responsibility of and systems designer or virtual sysadmin, so the problem resides not in the technical nature of the infrastructure, but the mindset of the consumer and applying the correct use case. If these are in-line with the requirements, then a single-zone cloud is both acceptable and indeed desirable given economies of cost and risk.
Firstly, the mindset of the customer has traditionally been one of ‘backup’, ‘DR’ and ‘recovery’. All entirely valid concerns about virtualisation platforms and service delivery. But relevant? Not necessarily – especially given the fact that true cloud applications should be designed to sustain local failures (i.e. compute, network and software outages). Regional failure is a consideration of service delivery, and not always relevant to use case. Consider this – some major cloud providers actively promote local random outages to DC infrastructure to ensure that the hosted services can suffer local failure.
Secondly, there are several (indeed the majority) of consumers using virtualisation who will have made significant investment in local compute provision (local DCs, servers, network infrastructure, training and personnel) which make migration to a full cloud service model impractical. Cost and resources from those deployments need to be realised before being decommissioned, so this fact alone can often make the case for a single-zone cloud deployment.
So, why a single-zone cloud? There are several use cases where this can be relevant:
- DR. In the majority of models where services are provided in the ‘traditional’ sense of backup and DR provision. Many consumers with local DCs want to provide an off-side presence for hosting DR provision in case of business continuity or DR scenarios. This is the use case specifically targeted at those with services particularly unsuited to single-zone clouds for service provision. With a cloud as a second DC, the deployment of dedicated hardware (along with the associated capital expenditure), plus operational expenditure of configuration of networking and testing etc. is all avoided.
- Mobility. Those with local DCs may want to host some production and some DR services in the same DC, due to topology or unbalanced provision across sites. With this use case, DR is provided on a per-service and not per-platform basis with workloads or services migrating between DCs – so in the case of site outage only some services are affected. This is a valid architecture design for many, especially those with diverse network topology with customers requiring transit on particular landing WAN links.
- Politics. Like it or not, policies and politics are all part of service definition. This isn’t always a bad thing, as risk management can sometimes dictate that multi-site service deployments are undesirable on several levels: cost, complexity, cost/benefit.
- Burst. Not all resources in a virtual environment are needed all the time. So, why provision multiple tiered compute nodes (be it ESXi, Zen, Citrix or OpenStack) for that one day of the year when your website or service hits double during a seasonal peak? Connecting cloud instances to local traditional virtual infrastructures (a public / private hybrid) allows workload migration and elastic service provisioning to grow and contract without the capital and operation expense of over-provisioning hardware for peak instances.
- HPC. Stateless compute requirements are often the need of consumers with large chunks of data that require ‘chewing’ or processing. In these requirements, backup and DR are not required – just the ability to rent processor cycles on a host to process data and download the results. Combine this with the allocation or pay-as-you-go model makes perfect sense…..
- Multi-Vendor Provisioning. Again apolitical consideration, but some CTOs are cautious about putting all the service eggs in a single DC basket. In this scenario, a single-zone DC becomes part of a multi-zone service provisioned platform.
Jeremy loves all things technology! Has been in IT for years, loves Macs (but doesn't preach to others about their virtues), loves virtualization (and does shout about it's virtues), and sometimes skis, bikes and directs amateur plays!