What you should know about a “Cloud Broker”

A Cloud Broker is typically a form of CMP (Cloud Management Platform) which touts the ability to deploy and move a service (a set of cloud resources and an application) across multiple providers such as Azure, AWS etc. This is the brokering bit; broker a service to the cloud.

The Promise

This can be very attractive to certain IT decision makers since it builds on the “single pane of glass” concept to present a single portal for provision of services in a very ITIL-friendly manner. Furthermore, it’s seen as a method to provision such a service in a common manner no matter what the underlying platform whether it’s AWS or an on-premise VMware cloud. The consumer just chooses the service and the destination and boom! All of this is then tied together and labelled as Hybrid Cloud; deploy the same service across multiple providers! move the workload to another cheaper provider! avoid lock-in! choose the most cost-effective provider! etc. Examples of such products include CliQr, Scalr, Accenture Cloud Platform, HPE Cloud Service Automation.

Problems

Sooooo…… there are a number of problems in such a tool which are often overlooked by decision makers and sometimes by the very vendors themselves.

Building to the Lowest Common Denominator

In order to be able to deploy the same service across multiple providers, the platform needs to work against a common set of capabilities which are interchangeable, otherwise things become complex and the promise of being able to easily choose and move between multiple providers disappears or ends up broken (i.e. separate service entries for each provider). Can I use RDS MySQL in AWS and Azure? No, so now I need either Azure to offer MySQL-compatible DB or to deploy my own DB and manage it myself. Often these brokering tools assume cloud = compute, network and storage and nothing else. For basic VM vending the concept can work but for anything more it’s flawed.

Chasing Features

Can such a platform look to keep up with integrations on the backend for new features introduced by providers? AWS, Microsoft and Google will keep releasing new features that must be constantly added to the broker even within the lowest common denominator, ideally with some sort of equivalent in place across multiple providers to keep the universal deployment dream alive. This just isn’t likely to be a reality.

The Audience

This is really most fundamental. In a prior post I briefly mentioned the shift towards consumerisation of IT and what this means for consumption of services from cloud platforms. In short, developers are wanting to consume directly whatever they want from the cloud platform, not from IT. These tools tend to assume the audience is (and will always be) someone who doesn’t care about access to capabilities of the underlying platform. How can these tools be used by a developer who needs access to Kinesis for IoT workloads? So clearly such a tool is working towards a different demographic, typically the internal IT department itself. This doesn’t align with the market direction but reinforces more of the traditional way of working with traditional workloads. It ultimately puts barriers in front of the consumer and forcing all users through a centralised CMP will be seen as a hindrance not a help.

The No Lock-in Fallacy

There is no such thing as “no vendor lock-in”. Even if you could restrict yourself enough to be able to deploy across multiple providers using a lowest common denominator, you would still be locking yourself into doing so via the CMP’s unique method, whether that is the underlying automation technology or the interface for building and provisioning services.

Conclusion

As you can probably tell, I’m not a fan of brokers. My feeling on these types of product are that they have a limited lifetime in the market. I don’t think these sorts of tools are completely redundant but I do think that the current incarnation of a broker has a limited lifespan and that this is tied to legacy applications, operations and consumption models. Brokers should not be seen as the end-game for organisations adopting cloud services but rather as a stepping stone to help move traditional applications with no refactoring plans into the public cloud.

If I were a product manager for CMP software, I would have been putting my efforts into some sort of compliance scanning and cost analysis component rather than focusing on provisioning and consumption. Build a product to help IT manage the non-centralised consumption.

Ultimately consumers of public cloud will want to provision on their terms, not IT’s. They’ll want to bring their own tools to provision and manage deployments; one team will want Terraform, another wants Ansible, you name it they’ll use it. Why should we care? IT’s efforts to benefit the business could be better spent elsewhere. My argument has and will continue to be that IT’s focus should not be on provisioning and centralised service consumption in the traditional model but rather issues like best practice, integration, security and compliance; the stewardship of cloud consumption.

So, my advice to IT decision makers:

  • Think hard about how the users will consume cloud and map this out before making any product purchases. What do the users want to be able to use public cloud for? How do they want to interact with the platform? Do you see traditional versus modern users?
  • CMP’s and cloud brokers may be a good fit for legacy workloads if you need to move an existing service into the cloud. CMP’s are not a silver bullet to suddenly turn the IT organisation into some sort of cloud native entity.
  • CMP’s and brokers won’t suddenly make you more relevant and attractive to consumers and developers.
  • Focus elsewhere on your cloud practice and public cloud adoption efforts (best practice, internal consulting, managed svcs etc.).
  • Consider using public cloud vendor solutions if you need a service catalog in the traditional sense.
  • Consider that application teams will often have a preference on cloud vendor already or will arrive at one, usually driven by features and capabilities.
One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.