2 November 2024, Sat |
8:31 PM
By Rob Tribe, VP, System Engineering EMEA at Nutanix
Throughout the rapid evolution of cloud computing from its earliest stages, we have witnessed the development and extension of many different cloud service specialisms, applications and optimisations. But however diverse and complex the cloud becomes, we can classify its core DNA into two strands i.e. public and private.
With public cloud services coming from datacentres and offering maximum flexibility, breadth and scope, private or on-premises cloud sits alongside the public cloud in a sort of yin-yang balance to provide control, privacy and compliance where needed. Businesses quickly realised that a hybrid combination of the two strands was the most prudent workable approach.
When these same businesses also saw that they could cover a wider multiplicity of use cases and deployment requirements by extending hybrid across multiple Cloud Services Providers (CSPs), we reached the point of hybrid multi-cloud epiphany that characterises the most progressive cloud implementations today.
But what else do we need to know about how hybrid multi-cloud happened and how this technology should be most productively implemented today?
Among the core validation points that exist for hybrid multi-cloud are the need to locate certain workloads in specific geographic locations.
This can be due to latency requirements if a particular application’s functionality depends upon it working to a precise number of microseconds, or it can be in order to fulfill upon regulatory compliance rulings and legislation. Potentially, it can be as a result of both.
While these requirements can theoretically be delivered from the public cloud, in the vast majority of scenarios these reasons are core justifications for the workloads concerned being located on-premises in private cloud deployments.
For applications that use a lot of compute resources but on a highly variable basis and only for a short burst of time, on-premises private cloud represents a disproportionate Capital Expenditure (CapEx) outlay with the risk of purchased resources lying idle and unused.
A good example here might be quarterly or annual tax processing; the workload is high and heavy, but essentially intermittent on a comparatively date-specific basis. Running this type of workload in the public cloud enables us to shoulder a cost that specifically tracks the consumption of resources, which is logically an Operational Expenditure (OpEx) weighted use case best suited to the public cloud.
Looking at the middle ground and looking for the deployment sweet spot, we need to think about what happens if we start a new business from scratch with modest capital investment and limited physical equipment or resources.
In this scenario, it of course makes sense to use as many suitable public cloud services as possible in the first instance; they require little or no pre-procurement expenditure and offer the maximum breadth to scale if and when the business flourishes and grows.
On that growth path, there will logically come a point at which workloads are predictable enough (and potentially privacy-related enough) to determine the use of some colocated resources. This is the straddling intersection point between public cloud and private on-premises cloud – this is hybrid cloud. Further up that growth path, the business can define an increasing number of workloads where on-premises costs can be justified. This is hybrid cloud at a more fully blown scale.
If a company has progressed to this point but then opens a new office in a new territory or country, it may very reasonably look to adopt a greater weight of public cloud in its new location.
If a business runs its New York operation with an 80% on-premises deployment and a mere 20% of resources located in public cloud to define its 80:20 hybrid split, it is entirely feasible that its new Cape Town office might be 100% public cloud.
This again is hybrid cloud. But if the business finds that it gets a better deal (commercially, or support-related, or platform-related) in one country from one particular CSP, then it may switch some workloads to Microsoft Azure, push some workloads to Google Cloud Platform, others to AWS and still others to any of the smaller tier players in this market. This is hybrid multi-cloud reality.
Many organisations now using hybrid multi-cloud may be comparatively oblivious as to why their mixed usage model has evolved. This disconnect is amplified if the gulf and the communication channel between the C-suite management function and the IT department is wide.
Understanding how, why, when and where hybrid multi-cloud deployments have resulted, what the layers and tiers within the deployed matrix of services are tasked with doing inside any given working day… and knowing which way business requirements might be developing next, will enable an organisation to manage its hybrid multi-cloud engine room with highest levels of efficiency.
If we have learned anything at this point, it is perhaps just how far hybrid multi-cloud has become a kind of de facto industry standard for prudent, strategically tactical cloud implementations. It offers the greatest scope for deployment flexibility, functional dexterity and cost optimisation.
Where we go from here is interesting. We will continue to see all of the ancillary competencies that flow alongside the wider development of cloud now more directly reflect the infrastructure resiliency that organisations can achieve with this model. Skillsets will need to be tuned, bolstered, augmented and extended in line with the specific actions of cloud architects, Site Reliability Engineers (SREs) and the now cloud-native DevOps developer+operations teams that will exist in this space.
As hybrid multi-cloud usage patterns crystallise, so will the most logical migration paths for organisations looking to complete the more advanced stages of their digital transformation initiatives.
On the road ahead, businesses will look to unify their infrastructure control mechanisms in order to straddle the full breadth of the hybrid multi-cloud IT stack that they themselves will now build, manage and operate across an increasingly connected pool of API-centric applications.
Where once we had cloud, we now have cloud multiplicity, connectivity and an occasional instance of exclusivity. It’s a small but hybrid multi-cloud world after all.
