Thinking Out Cloud

Cloud Computing. Literally.

Last week we made a very exciting announcement about Miwok Airways selecting GigaSpaces as the application server for running their reservation and pricing engine which will run on EC2. This is a great case study for cloud computing.

For one thing, you have to love the fact that it is cloud computing used for a business that literally runs in the clouds (the actual meteorological kind). Second, it is an on-demand compute infrastructure for a business that has an on-demand business model in the real world. A perfect fit.

There is a great piece in the LA Times that describes Miwok, but let me give you a brief description from the software application angle. 

The idea is that for so-called ultra-short flights (typically, less than 250 miles), as a traveler you have a terrible dilemma: use commercial airlines or drive your car. I don't need to tell you the hassle and costs involved in both options these days.

Miwok overcomes the hassles of these options by providing you with an on-demand "air taxi" service. You book your flight when you need it. So, say, you want to fly from Santa Monica to Orange County or Palm Springs. You go to the Miwok web site and say when and where, you get pricing and you can book the flight on the spot. The flight you are booking is for a private Cirrus SR22. You can park 100 feet from the airplane itself (at a local airport, not just the major ones) and you don't need to go through security (imagine that!). All of this at the same cost of a commercial flight.

But here's the part I really like:You can connect to other people via Miwok's own social network, or through a Facebook app (and others to come). As the Cirrus can seat 3 passengers, you can split the costs with other passengers who need to make the same trip. So the flight could end up significantly cheaper than a commercial airline.

Think about it: This is the exact opposite pricing model of big airliners, where the more people go on a flight, the price goes up. From a marketing point of view, this has tremendous viral potential.

One of the biggest technology (technology as in software, not aviation) challenges Miwok was facing was developing an extremely sophisticated real-time pricing engine. It needs to take many parameters into account to offer you a price on the spot, including location, path, season, date, time of booking, number of passengers and several other criteria. It needs to be able to grow and shrink on-demand, especially because of the social networking and viral effect.

The architecture Miwok selected uses MySQL and Hibernate for the persistence layer, but the database is not used as the system of record for calculation and reservations. Instead they use GigaSpaces' in-memory data grid, which gives you in-memory speeds and can also grow and shrink dynamically in the EC2 environment. The benefit for Miwok is that having very little advance knowledge on the traffic they will get, and expecting extreme peaks and troughs in activity, they don't need to pre-plan and invest upfront in the infrastructure. They use GigaSpaces and EC2 and will only pay for hardware and software on a per-use basis -- when and if they actually need it.

They also use GigaSpaces XAP (which includes the in-memory data grid) as the container for the business logic, written in Java, and as a bus for integrating the various underlying services involved in generating pricing and booking reservations.

In short, on-demand application scalability for an on-demand air travel service.

Check out Miwok's web site.

Sign up for the GigaSpaces pay-per-use license for Amazon EC2.

The Law of Unintended Consequences

Service-oriented architecture is becoming one of the latest examples of the Law of Unintended Consequences. In a recent InformationWeek survey, 24% of respondents from large corporations said their SOA projects “fell short of expectations.” Of these, 55% said the reason for failure was that the SOA initiative “introduced more complexity into their IT environment” -- ironic , given that one of the benefits touted by SOA proponents is that it reduces complexity.

There are several reasons for this complexity, and one of them has to do with capacity planning. Eric Roch and Jason Bloomberg have both written thoughtful pieces that discuss this issue, but generally it did not receive much attention.

Capacity planning challenges are not unique to service-oriented environments. They exist with many applications. The typical approach to address these challenges has been over-provisioning. In other words, estimating peak loads expected (usually, for the next few years), and providing enough hardware resources to be able to handle those loads. That works well, if you like throwing away money on idle hardware, electricity, cooling and data center real-estate costs. So the industry has ended up with a pathetic 5% to 15% utilization figure (the lower number typically occuring when you count people's idle desktop computers).

With SOAs, the problem is exacerbated. Services are publicly available (either within the organization or externally). This means that the designer of the service has even less visibility into the potential demand for the service down the line.

Q: So what's the best way to do service capacity planning?

A: Don't.

Eliminate the need to plan by creating a service infrastructure that dynamically grows and shrinks on demand. This is the notion of the Service Grid we introduced in GigaSpaces Enterprise Edition 5.0.

The Service Grid creates a self-managed, dynamic “cloud” of services. Requests are sent to the cloud, and it determines, based on demand and Service Level Agreements, if services need to grow or shrink their capacity (i.e., dynamically deploy on additional resources) The Service Grid is also self-healing, meaning it will dynamically maintain the high-availability policies you define.

The approach is to assume the Law of Unintended Consequences, not to ignore it.

You can learn more about the Service Grid here. There's lots more to it than I described above. As an acknowledgment: The Service Grid was originally developed by Dennis Reedy, the "father of Rio," who essentially enhanced the open source Rio Project he originally developed at Sun Microsystems, and tightly integrated it with GigaSpaces.

Larry Mitchell and Kevin Hartig are even blogging about Rio.