November 11th, 2011

FROM THE VAULT: Webinar – Extending Enterprise Security into the Cloud presented with The 451 Group

CA World - CSA CongressNext week, Layer 7 will be exhibiting at a couple of events, both of which have a strong Cloud security focus. Between November 13 and 16, we’ll be in Las Vegas for CA World, where we’ll be setting up shop in the Cloud Section and the Security Section. On November 16 and 17, we’ll be at the Cloud Security Alliance Congress in Orlando.

With these Cloud security-focused events just around the corner, it seems like a good time to mention our archived webinar Extending Enterprise Security into the Cloud. Presented with The 451 Group, this webinar explored ways for enterprises to extend existing security investments into the Cloud without incurring significant costs or creating additional IT complexity.

Presentations from Layer 7 CTO Scott Morrison and 451 Group Security Analyst Steve Coplan, delved into how enterprises can leverage the identity, privacy and threat-protection technologies they already own to facilitate the secure adoption of SaaS, IaaS and other Cloud-based technologies.

You can read more about the webinar in our Resource Library or simply watch the recording in the player below, courtesy of the Layer 7 YouTube Channel.

And if you happen to be attending either CA World or the CSA Congress, stop by and say “hi”. CA World attendees can find us at Partner Pedestal 261A in the Cloud Section and Partner Pedestal 338B in the Security Section. For the CSA conference we’ll be at table 10. Hope to see you there!

May 16th, 2011

Amazon’s Mensis Horribilis

Written by
 

Hot on the heels of Amazon Web Service’s prolonged outage late last month, Bloomberg has revealed that hackers used AWS as a launch pad for their high profile attack against Sony. In a thousand blogs and a million tweets, the Internets have been set abuzz with attention-seeking speculation about reliability and trust in the cloud. It’s a shame, because while these events are noteworthy, in the greater scheme of things they don’t mean much.

Few technologies are spared a difficult birth. But over time, with continuous refinement, they can become tremendously safe and reliable, something I’m reminded of every time I step on an airplane. It never ceases to amaze me how well the global aviation system operates. Yes, this has it’s failures—and these can be devastating; but overall the system works and we can place our trust in it. This is governance and management and engineering working at the highest levels.

Amazon has been remarkably candid about what happened during their service disruption, and it’s clear they have learned much from the incident. They are changing process, refining technology, and being uncharacteristically transparent about the event. This is the right thing to do, and it should actually give us confidence. The Amazon disruption won’t be the last service failure in the cloud, and I still believe that any enterprise with reliability concerns should deploy Cloud Service Broker (CSB) technologies. But the cloud needs failure to get better—and it is getting better.

In a similar vein, overreacting over the Sony incident is to miss what actually took place. The only cloud attribute the hackers leveraged on Amazon was convenience. This attack could have been launched from anywhere; Amazon simply provided barrier-free access to a compute platform, which is the point of cloud computing. It would be unfortunate if organizations began to blacklist general connections originating from the Amazon AWS IP range, as they already do for email originating in this domain because of an historical association with spam.  In truth this is another example of refinement by cloud providers, as effective policy control in Amazon’s data centers have now largely brought spam under control.

Negative impressions come easy in technology, and these are hard to reverse. Let’s hope that these incidents are recognized for what they are, rather than indicators of a fundamental flaw in cloud computing.


May 13th, 2011

NIST Seeks Public Input On New Cloud Computing Guide

Written by
 

What is the cloud, really? Never before have we had a technology that suffers so greatly from such a completely ambiguous name. Gartner Research VP Paolo Malinverno has observed that most organizations define cloud as any application operating outside their own data centre. This is probably as lucid a definition as any I’ve heard.

More formalized attempts to describe cloud rapidly turn into essays that attempt to bridge the abstract with the very specific, and in doing seem to miss the cloud for the clouds. Certainly the most effective comprehensive definition has come from the National Institute of Standards and Technology (NIST), and most of us in the cloud community have fallen back to this most authoritative reference when clarity is important.

Now is our chance to give back to NIST. To define cloud is to accept a task that will likely never end, and the standards boffins have been working hard to continually refine their work. They’ve asked for public comment, and I would encourage everyone to review their latest draft of the Cloud Computing Synopsis and Recommendations. This new publication builds on the basic definitions offered by NIST in the past, and at around 84 pages, it dives deep into the opportunities and issues surrounding SaaS, IaaS, and PaaS. There is good material here, and with community input it can become even better.

You have until June 13, 2011 to respond.


May 11th, 2011

Layer 7 to Demonstrate Cloud Network Elasticity at TMForum Management World in Dublin

I’ll be at the TMForum Management World show this May 23-26, 2011 in Dublin, Ireland to participate in the catalyst demonstrating cloud network elasticity, which is sponsored by Deutsche Telekom and the Commonwealth Bank of Australia. For those of you not yet familiar with TMForum, it is (from their web site) “the world’s leading industry association focused on enabling best-in-class IT for service providers in the communications, media, defense and cloud service markets.” We’ve been involved with the TMForum for a couple of years, and this show in Dublin is going to showcase some major breakthroughs in practical cloud computing. TMForum offers catalysts as solution proof-of-concepts. A catalyst involves a number of vendors which partner together to demonstrate an end-to-end solution to a real problem faced by telco providers or the defense industry. This year, we’re working closely with Infonova, Zimory, and Ciena to showcase a cloud-in-a-box environment that features elastic scaling of compute resources and network bandwidth on-demand, all of which is fully integrated with an automated billing system.We think this solution will be a significant game-changer in the cloud infrastructure marketplace, and Layer 7′s CloudControl product is a part of this solution. CloudControl plays a crucial role in managing the RESTful APIs that tie together each vendor’s components. What excites me about this catalyst is that it assembles best-of-breed vendors from the telco sector to create a truly practical elastic cloud. Zimoury contributes the management layer that transforms simple virtualized environments into clouds. We couple this with Ciena’s on-demand network bandwidth solutions, allowing users to acquire guaranteed communications capacity when they need it. Too often clouds elasticity starts and stops with CPU. Ciena’s technology ensures that the network resource factors into the elastic value proposition. The front end is driven by Zimory’s BSS system, ensuring that all user actions are managed under a provider-grade billing framework. And finally, Layer 7′s CloudControl operates as the glue in the middle to add security and auditing, integrate disparate APIs, and provide application-layer visibility into all of the communications between different infrastructure components.

Layer 7's CloudControl acts as API glue between cloud infrastructure components.

I hope you can join me at TMForum Management World this month. We will be giving live demonstrations of the elastic cloud under real world scenarios given to us by Deutsche Telekom and Commonwealth Bank. This promises to be a very interesting show.
April 23rd, 2011

Why Cloud Brokers Are The Foundation For The Resilient API Network

Written by
 
Amazon Web Services crashed spectacularly, and with it the illusion that cloud is reliable-by-design and ready for mission-critical applications. Now everyone knows that cloud SLAs fade like the phosphor glow in a monitor when someone pulls the plug from the wall. Amazon’s failure is an unfortunate event, and the cloud will never be the same. So what is the enterprise to do if it can’t trust its provider? The answer is to take a page from good web architecture and double up. Nobody would deploy an important web site without at least two identical web servers and a load balancer to spray traffic between them. If one server dies, its partner handles the full load until operators can restore the failed system. Sometimes the simplest patterns are the most effective. Now take a step back and expand this model to the macro-level. Instead of pair of web servers, imagine two different cloud providers, ideally residing on separate power grids and different Internet backbones. Rather than a web server, imagine a replicated enterprise application hosting important APIs. Now replace the load balancer with a Cloud Broker—essentially an intelligent API switch that can distribute traffic between the providers based  both on provider performance and a deep understanding of the nature of each API. It is this API-centricity that makes a Cloud Broker more than just a new deployment pattern for a conventional load balancer. Engineers design load balancers to direct traffic to Web sites, and their designs excel at this task. But while load balancers do provide rudimentary access to API parameters in a message stream, the rules languages used to articulate distribution policy are just not designed to make effective decisions about application protocols. In a pinch, you might be able to implement simple HTTP fail over between clouds, but this isn’t a very satisfactory solution. In contrast, 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. For more information about Cloud Brokers, have a look at the Cloud Broker product page at Layer 7 Technologies.