More on Cloud Broker 2.0

clip_image002Great email conversation with an old friend telling me I was wrong about Cloud Brokers. “The Market won’t support the broker you’ve outlined over the past three years.” Being the primary point. To a degree she was completely right. There is no argument that the market would support a more complex Broker model. It hasn’t to date why would that suddenly change?

Neil Young wrote a great song called Alabama. In that song he mentions that Alabama has “one wheel in the ditch and one wheel on the road”. That is the market for cloud brokerages right now. Lots of really cool technologies. Lots of really good ideas. But all of these are sitting in the far right slow line of DC Beltway traffic at 5 pm. Not likely to move into the fast lane, actually based on personal experience not likely to move at all for extended time periods. IE the market will change rapidly but only when the market is ready to change.

clip_image004Part of that is the confusion. Reality is that brokers have to be more than simply provisioning software. Today if you talk to most cloud providers they tell you “we supporting bursting.” Bursting is nirvana for most organizations. As long as cost can be managed bursting allows you to have a solution that runs at let’s say level 100. If needed it can immediately jump to level 200 for a time. If the application is written for and built in the cloud you can do this. Within reason of course. It requires modification of the application so that it supports this functionality. If your cloud provider is at capacity or doesn’t have the number of machines and processing you need you get diminished returns from bursting. So what I want to do is host the solution on premise in a secure private cloud. When I need more capacity I auto provision and burst into a cloud providers system. Then fall back out when I am done. Or I want to have my cloud solution burst across two cloud service providers. Like software CSPs are all specialists at some workloads but not at others.

Brokers have to be partners: Hey company A, you’ve burst into 200 new VM’s running in cloud X. First off, with our auto-migration toolset we can move you to Cloud Y, cloud Y is having a new customer special and those 200 machines will cost you 20% less. Part A of broker 2.0 is that the broker will provide its customers with the concept of secure portability. My stuff can be where it is most cost effective for my organization. Can you do this today? Yes, but the cost per move becomes impossible to manage financially. The tools that do the automated moving are separate and not included with the cloud broker software packages that are out there.

Brokers have to become security experts: Hey company A, we’ve noticed a number of phishing and DDOS attacks on your web sites. As part of the broker service we have set-up a fake redirection site to reduce the DDOS issue. I wrote an article about Cloud Brokers as the new DMZ. It is beyond that they, the broker has to be your security experts. Not you’re on premise security team that is something you have to have. These are the people you turn to for threat evaluation and protections from much larger threats. As part of the fees paid to the broker you get a CIRT. You also get access to the security folks that are running not across one CSP but across every CSP you and the brokers other customers are dealing with. Any one company gets 100 attacks. Any one CSP gets 1000 attacks. Brokers of the future see the attacks on their customers + all the CSP’s they works with. Not 1000, but perhaps more than 20,000 views on security breach attempts.

Brokers will also become identity brokers: Hey company A, we moved your application from CSP A to CSP B, but we also moved your directory pointer to this new provider. The value of portability is not that you can have your system moved from one CSP to the other on the fly. The value is you can have your system moved from one CSP to another at no cost and NO IMPACT on your users. The broker becomes your virtual directory provider for cloud services. Your broker could even provide abstraction services, want to have anonymous users created in a new cloud system to test it, without wanting you company name associated with it? Or need to obscure a part of your business? Using the cloud broker as a virtual directory service allows you to hide your users in the cloud without impacting their ability to log in. They still (your users) log into your on premise directory. That directory talks to the virtual directory in the broker system. When you provision a new cloud, the identity federation is done by the broker. You never have to know what CSP your solution is in if you don’t want to. You simply tell your broker I want this cost level.

clip_image006In the end the interesting thing is that each of the parts above for the new broker exist today. This is not a pipe dream, its why in the end I believe that the cloud broker of the future will be a systems integrator or SI. Now it is a race to see which one gets the message and delivers the Cloud Broker 2.0

.doc

Scott Andersen

IASA Fellow.