You need a public cloud-based relational database to support a new application. You submit a request, not directly to a specific cloud provider, but to an internal cloud broker. This is a system that looks at your submitted requirements and picks the best relational database fit for the lowest cost and the highest SLAs (service-level agreement).
What’s more, these brokering systems can operate at an API level, allowing applications to provision coarse-grained or fine-grained resources, through the broker, with the simple invocation of an API. This can be done on the fly from within the application.
In short, the internal broker culled through several public cloud providers to find the best cloud service at the best price with the best track record. How could this be any better?
The reality is that although internal cloud brokers are the next logical step if you’re moving to a multicloud model, the best practices, tools, and acceptance by IT in general have been a bit hit and miss. I’m finding a few reasons for this:
- The desire to go directly to the cloud-native systems and bypass some of the restrictions that internal brokering systems put on you. This includes having access to subsystems that are not made available when using the internal cloud brokers.
- The brokers focus on price and not performance. Many using internal brokers have complained that although they get a good price, they believe that performance and reliability are often not considered.
- Many have claimed that the brokers are not up to date and often have old or outdated services listed. As described to me, it’s almost like ordering from an online store and getting a notice a few days later that the item is out of stock.
My take on this is that cloud brokers themselves might be working per function, but they are not being maintained properly by cloudops. Indeed, many are set up by ad-hoc teams that move on, tossing the keys to cloudops, which is not up to the task of managing brokers that require a great deal of maintenance and updating.
There are a few choices.
First, mandate that everyone go through the broker to access cloud, not direct to the native cloud. I suspect that this approach won’t work considering that people using public cloud services at times are going to need access to the native cloud interfaces.
Second, encourage the use of a broker only to provision long-term resources, such as storage and databases that are bound to a specific application. This means that application owners and developers can leverage the native clouds for all the small stuff.
Third, get rid of the broker.
There is a role for internal cloud brokers, but it seems to cause more frustration than productivity, at least for now. I suspect that we’re going to have to figure something out quickly or else move on.