Tag Archives: Amazon

Amazon Web Services Startup Challenge

The 2011 AWS Startup Challenge is now open. Every year Amazon stages a contest to promote up and coming startups that leverage the Amazon cloud. This is the 5th annual contest, and for the first time they’ve opened it to entrepreneurs world wide.

According to the contest FAQ, contestants are to be judged according to the following criteria:

(a) implementation and integration of AWS paid services as described in the Official Rules;

(b) originality and creativity;

(c) likelihood of long-term success and scalability;

(d) effectiveness in addressing a need in the marketplace.

The prizes are split evenly between cash and credits on AWS, acknowleding the new economics around bootstraping a modern tech company. Best of all—and unlike the more traditional sources of startup funding such as angels and VCs—the cash is non-dilutive. The free publicity of winning also doesn’t hurt.

New companies have always been the most aggressive adopters of cloud technology, and startups are obviously very important to Amazon. I’m a big fan of the free-tier pricing model they offer as a way to seed projects, but it doesn’t take too much success before you kick into higher-level tiers. It would be great to see Amazon create some kind of formal startup seeding program. It would be similar to what Sun once offered startups with its free servers back in the days when startups actually wanted physical boxes.

Advertisements

When Is The Cloud Not A Cloud?

Sometimes I joke that as my kids grow up they won’t see clouds, they’ll just see air—meaning of course that their use of cloud-based services will become so ubiquitous as to make the cloud moniker largely unnecessary. What we so enthusiastically label cloud will just be the way everyone builds and deploys their apps. “Nothing to see here folks; but look at my wonderful new application…”

We won’t arrive at this future until we strip the word cloud of its power. And to do this, we need to go after the things we thought made cloud unique and special in the first place. Today, Amazon took a vicious swipe at the canonical definition by introducing dedicated EC2 instances. Dedicating hardware to a single customer addresses the next logical layer in the hierarchy of security concerns after virtual isolation. Amazon’s VPC product, introduced back in August 2009, provided virtualized isolation in their multi-tenant environment. Essentially VPC is like a virtual zone housing only your instances. This zone is tied back to your on-premise network using a VPN. The only way in or out of a zone is through your corporate network. Other Amazon-resident applications can not access your apps directly—in fact, any external app, Amazon-resident or otherwise—must go through your conventional corporate security perimeter and route back to Amazon over the VPN to be able to gain access to a VPC app. The real value of VPC is that it puts instance access back into the hands of the corporate security group.

The problem that the highly security conscious organization has with VPC is that the “V” is for virtual. VPC may implement clever isolation tricks using dynamic VLANs and hypervisor magic known only to a gifted few, but when your critical application loads up you may actually reside on exactly the same hardware as your own worst enemy. In theory, neither of you can exploit this situation. But you need to believe the theory. Completely.

Today’s announcement means that Amazon’s customers can literally have exclusive use of hardware. This is good news for anyone with reservations about hypervisor isolation. However, the networking remains virtualized, and of course you can still ask the classic cloud security questions about where data resides, or the background of the staff running the infrastructure. So a mini-private cloud, it is not; but dedicated instances is an interesting offering, nonetheless.

What is more intriguing is that by providing dedicated hardware, Amazon is beginning to erode one of the basic foundations of the canonical cloud definition: multi-tenancy. Purists will argue—as they do so with unexpected vehemence with regard to private cloud—that what Amazon is offering is not a cloud at all, but in fact a retrograde step back to simple hosting or co-loc. I’m inclined to disagree, however, and think instead Amazon offers a logical next step (and certainly not the last) in the evolution of cloud services. By doing so, Amazon amplifies some of the other important aspects that define what the cloud really is. Things like self-service, a greatly changed division and scope of operational responsibility, the leverage of commodity of scale, elasticity, and the ability to pay for what you actually use.

I don’t think Amazon’s new offering will be wildly successful because it still leaves many security issues unresolved. But I do think it points the way to the future cloud, which will have many different attributes and characteristics that solve different problems. Some may conflict with traditional definitions and expectations. Some may fulfill them. What is important is to choose the service that meets your needs, and don’t worry what it’s called. That’s marketing’s problem.

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.

I Went for Coffee and RDS was Waiting for Me When I Returned

Here at Layer 7, we’ve been really excited about Amazon’s Relational Data Service (RDS) ever since they announced it last month. RDS is basically a managed mySQL v5.1 instance running in the Amazon infrastructure. The point of RDS to provide another basic service that we all need all of the time, managed within the AWS ecosystem. It offers some great scaling options (in terms of instance sizing), but best of all, it provides automatic snapshoting of  database instances. This revolutionizes EC2 because it solves the nagging persistence problem that we all face when we terminate instances. We’ve all come up with clever ways of dealing with this using S3 and EBS,  but now it’s gotten much easier.

Since RDS is really mySQL under the covers, I had been hearing that it’s pretty easy to port to. We’ve been itching to play with it here, using Layer 7’s SecureSpan Gateway AMI that’s runs in EC2. Unfortunately, this Fall has been really busy, so none of us have had an opportunity to play with it until now.

The inimitable Jay Thorne, who is a musician first but holds down a day job here as Director of Development for the Tactical group, finally cleared an afternoon to put RDS through it’s paces. I had to step out for coffee with another of our execs, which turned into a longer-than-expected discussion. But by the time I got back, Jay was done: SecureSpan using persistent Amazon RDS storage. Hello, cloud registry/repository…

Here’s Jay’s summary, which I think speaks for itself:

Total elapsed time: 1.25 hours
Number of pdf documents read: 1
Number of web pages read: 3
Number of command copy/pastes from doc: 6
Number of dbs created by mistake until I got the zoning right: 2
Number of mistyped credentials until I learned to use a creds file: 7
Number of dumpfiles created source side: 1
Number of times I had to import to get it right: 1
Number of characters in the hostname of the db: 50
Number of hosts I put in the db firewall allow list: 1
Number of sets of user credentials I created: 1
Number of lines in our internal wiki article I wrote about this: 35
Number of bangs on the keyboard in frustration: 0