Monthly Archives: February 2011

Layer 7 Technologies Joins the Cloud Security Alliance (CSA)

I’m pleased to announce that Layer 7 has joined the Cloud Security Alliance (CSA) as a full corporate member. For the past several years, the CSA has assumed the leadership role in defining the best practices to secure cloud applications, data, and infrastructure.

I believe that when you join a community organization, you are obliged to make a real contribution. Being a member means a lot more than just having your company logo on the sponsor list. I’ve been involved previously with the CSA, as a co-author of version 2 of its Security Guidance for Critical Areas of Focus in Cloud Computing, and as a co-author of the organization’s Top Threats in Cloud Computing document. Now that we are corporate members, Layer 7 will help to drive two important events within the CSA.

First, Layer 7 is a sponsor the CSA summit at this year’s RSA conference in San Francisco, running Feb 14-18, 2011. I was a participant at the CSA summit last year. This one-day event sold out instantly, and most attendees agree it was one of the highlights of the RSA conference. If you are in San Francisco for the 2011 RSA show, you should try to get into Monday’s CSA event. The CSA has some very special guests lined up to speak—including Vivek Kundra, US Chief CIO—and I can assure you that once again the summit will be the talk of the RSA.

I am also fortunate to be co-presenting a CSA-sponsored webinar about Managing API Security in SaaS and Cloud with Liam Lynch, eBay’s Head of Security. The rapidly growing API management space has a number of unique challenges with segmentation of roles, access to usage information, developer on-boarding, user management, and community building. Liam and I will talk about our own experiences in this space, and I will explore several case studies that illustrate each issue and its solution. I hope you can join us on Feb 23, 2011 for this talk.

Advertisements

REST is Simple, But Simple is not REST

Last December, William Vambenepe posted a provocative blog entry about RESTful APIs in the cloud. In it, he states that Amazon proves that REST doesn’t matter for Cloud APIs. Writing over at InfoQ, Mark Little re-ignited the controversy in his recent post asking Is REST important for Cloud? And Vambenepe responded to the re-invigorated commentary in Cloud APIs are like Military Parades. All of these posts are very much worth reviewing, and be sure to read the comments left by members of the community.

Amazon’s query APIs are certainly not textbook examples of the RESTful architectural style, a point the Restafarians are quick to make. But they are simple, understandable, and very easy to implement, which is largely the set of characteristics that attracted developers to REST in the first place. REST does have a satisfying elegance and undeniable philosophical appeal, but accessibility probably counts for more in the popularity stakes. If there is one theme that repeats throughout the history of computing, surely it is the story of simple and good enough winning the day.

Amazon’s APIs are not the reason that AWS is such a resounding success; it is the service offering that was responsible for that. However, the APIs were good enough that they didn’t hinder Amazon’s success, and this is the relevant point. Dig a little deeper, though, and Amazon’s API story offers some interesting insights.

Amazon, it turns out, is a good case study illustrating the evolution of Internet APIs. When AWS first appeared, Amazon engineers faced what at the time was an unresolved question of style: should a cloud publish SOAP services, or RESTful APIs? I’ve heard that question led to some pretty heated internal debates, and I don’t doubt this is true. Amazon lies in Microsoft’s backyard, and .NET in those days was very firmly in the SOAP camp. REST, however, was rapidly gaining mind share, especially due to the growing popularity of AJAX in Web 2.0 apps.

The engineer’s solution was to hedge, producing a mix of SOAP, a “REST-like” query (HTTP with query params as NVPs), and REST APIs somewhat in parallel. Developers gravitated toward the later two options so much more than SOAP that AWS left the orbit of WS-* for good. Amazon gave the market choice, and the market spoke decisively. This was an interesting experiment, and in performing it Amazon actually led the way—as they have in so many ways—for future cloud providers. Each new provider had the luxury of an answer to the question of API style: REST won (even if this wasn’t really REST). Now all an emerging cloud provider needed to do was to design their API according to current best practices, and this is something for which experience counts. Roy Fielding’s thesis may have come out in 2000, but the appreciation of what constitutes good RESTful design among developers is a much more recent phenomena, one that has benefited greatly from the growing popularity of this style.

APIs are of course simply an interface between components of a distributed application. Like any interface, properly versioned, they can evolve. One thing I’ve noticed lately is that our customers are increasingly using Layer 7 technology to refine their APIs as they come to better understand their own needs.

For example, we have a customer in the publishing industry that is actually adapting existing SOAP-based APIs to RESTful design principles. They use our SecureSpan Gateways to present a true REST facade, and adapt this to existing SOAP messages on-the-fly. This transformation is fairly mechanical; what is more important is that the exercise also gave their developers the opportunity to refine their API suite to better meet their needs. Many of their new RESTful APIs leverage SecureSpan’s orchestration capabilities to consolidate multiple SOAP calls behind a single REST call. The resulting API 2.0 is a better match to their current business—and best of all, they were able to do all of this without writing a line of new code.

The lesson here is that while we like to think that APIs are perfectly static and never change, the truth is that we rarely get interfaces right the first time. Requirements change, business moves, and our understanding advances. What is important is that your APIs can respond with agility to changing needs, because change, we all know, is inevitable.

A Clear View of Virtualization

I spoke recently with Robyn Weisman from Processor Magazine about the basics of virtualization. This is one of those terms that everyone in the computing industry uses, but very often with different meanings. Her article is now available in the Jan 28, 2011 print issue. It is also accessible online: A Clear View of Virtualization.