Following our recent presentation showcasing Automation Logic’s collaboration with the Ministry of Justice, the first of our three part blog series explored Hybrid Cloud as a mixture of private and public cloud and framed this more as a predicament than a strategy. Now, in our second post, we’ll explore the other main type of Hybrid Cloud: the broker or abstraction layer, which we’ll refer to as ‘broker-based Hybrid Cloud’. We’ll expose this as an over-engineered fantasy that delivers perpetually reduced choice and introduce our simpler alternative: Multi-Cloud.
Broker-based Hybrid Clouds, attempt to give you the ability to dynamically choose between cloud providers, depending on certain criteria such as cost and performance.
A common (almost hackneyed now) example nearly always quoted is the checking of spot prices for compute resource between two cloud providers at the time of deployment and deploying to the least expensive.
In practical terms, the broker-based Hybrid Cloud has an engineer design a service for an abstraction layer or send a request for a service to a broker. The broker/abstraction layer then chooses which cloud provider to target and translates the request into language understood by the chosen cloud provider, before orchestrating the deployment.
Organisations who pursue this type of Hybrid Cloud strategy do so in hope of avoiding lock in to any one provider. Lock in is a measure for how difficult and expensive it would be to move from one supplier to another (for technical or commercial reasons).
Having delivered over 55 cloud and automation platforms to top-tier clients (including a couple of ill-fated broker-based Hybrid Clouds), our experience tell us that the theoretical benefits of Hybrid Cloud are just not realised in practice.
The main problem with a broker-based model is one of industry maturity. Today there is no single common denominator, standard or shared language for any cloud resource, no matter how simple (not even compute). Cloud providers call their components different things, they behave in subtly different ways and have differing capabilities.
So any organisation seeking to implement Hybrid Cloud not only has to build this common language (the abstraction layers, data models, interfaces, APIs, orchestration layers and decision logic that can gracefully handle differences in capabilities between cloud providers), they need to support and maintain it at the ever-accelerating pace dictated by cloud providers.
Builders of Hybrid Cloud are not just attempting to build a product, but to get ahead of and effectively corral an industry comprised of some of world’s largest tech companies who are all investing billions of dollars annually in moving as fast as they can, releasing as many new cloud services as is humanly possible and with no interest for building a standard way of consuming cloud resources.
The net effect of this intractable problem is that a broker-based Hybrid Cloud will deliver greatly reduced choice in terms of the cloud services it can offer to users.
It’s also worth reconsidering that one of the original goals of adopting Hybrid Cloud is the avoidance of lock in. But with their esoteric abstraction layers and languages, Hybrid Cloud actually make the lock in problem worse, locking you into an obscure abstraction layer rather than a well understood public cloud provider.
As the cloud industry moves away from building walled gardens and as organisations mature in their ability to understand and operate safely in the cloud, no doubt standards for ways of describing and consuming cloud resources will emerge, and at that time building Hybrid Clouds will start to make more sense. Until then, anyone considering a Hybrid Cloud approach should be prepared to wait a long time and spend a lot of money essentially funding R&D efforts in an attempt to realise benefits that can be attained far more simply and quickly in other ways.
We’ve now identified and explored the many problems and inconsistencies with Hybrid Cloud and in our next and final post in this series, we’ll introduce an alternative to Hybrid Cloud which we call simply Multi-Cloud. We’ll describe how this strategy is working very well within several AL customers and focus in on our ongoing collaboration with the Ministry of Justice.
Todays blog was written by Automation Logic Co-Founder, Kris Saxton.
To discover more about Multi-Cloud, get in touch.
Contact us today – Info@AutomationLogic.com
Automation Logic’s purpose is to deliver an automated world where people are free to realise their creative potential. We deliver technology-enabled transformation, helping our customers adopt emerging business practices and IT. Our portfolio of services span consulting, implementation and operational management solutions for DevOps, Cloud and Automation.
We work with our clients to de-risk and accelerate their business goals realisation. Our approach is based on tailoring our services to fit your needs leveraging our portfolio of strategy, execution, innovation and service delivery offerings to help you reach your objectives
We’re always on the lookout for exceptional talent and people who share our values. Even as we continue to grow, we maintain a family environment with respect and teamwork core to our culture.
Companies can start deploying containerised workloads to Kubernetes In days not months, by leveraging Automation Logic’s Kubernetes Platform Accelerator.
Largest Irish-Founded Tech Employer Surpasses 3000 Employees Signing 15th and 16th Acquisition Deals Version 1, a leading digital transformation partner, is to acquire Automation Logic – for an undisclosed sum as part of its ambitious growth strategy for 2023 and beyond. The Automation Logic deal is subject to clearance by the National Security and Investment […]
Automation Logic were recognised as one of the UK’s best Workplaces again for the 5th year running! We also placed 29th in best workplaces for women. This highlights the great work that we are doing as a business, including all the wonderful work being put in by the employee-led DE&I groups. This award means so […]
