Layer 7 and Cloud Redundancy Through Brokerage

After the recent AWS outage – much attention has been given to the need for cloud users to create redundancies across zones, data centers, regions and even providers. All of which sounds fine in theory, but gets a little tricky in practice. Skip a few days and, coincidentally, I was talking with Scott Morrison from Layer7, a company I’ve written about before but in relation to cloud gateways. Well Layer7 are making a push into cloud broking – essentially being the orchestration layer that sits – agnostically – above multiple cloud providers.

In essence Layer7 handles the authentication, authorization and orchestration of different cloud services and does so based on a series of rules so, to use a relevant case, if part of a particular region’s cloud service goes down, Layer7 can automate the moving of data to another provider, another region or another zone.

But why use a third party? I put it to Morrison that perhaps by doing so, customers would be introducing another point of failure and level of complexity. Understandably Morrison disagreed, saying that Layer7 can handle all the complex integrations and thus adds value by being the “Swiss Army Knife” of the cloud management layer.

Morrison used the example of VMWare which, despite having it’s own effective orchestration layer, is making use of Layer7 both internally and externally. Layer7 is also seeing uptake when customers want to use different specialist cloud services and has built integrations with Savvis, Terremark etc.

It makes sense, as Klint Finley wrote in his post AWS outage roundup;

…many customers will move away from using EBS and RDS. In the medium term, infrastructure-as-a-service providers need to come up with a standard system for sharing instances across clouds, whether that’s OpenStack, Cloud Foundry, Eucalyptus or something else. Customers shouldn’t have to choose between trusting only one provider or committing to a complex and potentially unreliable multi-vendor solution. The days of vendor lock-in must come to end.

slide1_thumb3

 

It’s worth reading the post that Morrison wrote as a post-mortem after the AWS issue. While it very much justifies his own service, Morrison’s contentions ring true.

…we design cloud brokers from the beginning to interpret application layer protocols and to use this insight to optimize API traffic management between clouds. A well-designed cloud broker abstracts existing APIs that may differ between hosts, offering a common view to clients decoupled from local dependencies. Furthermore, Cloud Brokers implement sophisticated orchestration capabilities so they can interact with cloud infrastructure through a provider’s APIs. This allows the broker to take command of applications the provider hosts. Leveraging these APIs, the broker can automatically spin up a new application instance on demand, or release under-utilized capacity. Automation of processes is one of the more important value propositions of cloud, and Cloud Brokers are means to realize this goal

I’d be thinking some smart VCs will be looing hard at the startups in the orchestration space this week…

1 Comment
  • the interoperability has its own issues. it seems transparent to customer, however it causes IP and Copyright issues. Swiss Army knife needs to be with informed consent otherwise it will have legal issues and also loose trsut of the customer.

Leave a Reply