Monthly Archives: April 2011

VMware’s Cloud Foundry Ushers In The Era Of Open PaaS

Mention VMware to anyone in IT and their immediate thought is virtualization. So dominant is the company in this space that the very word VM has a sense of ambiguity about it: does it refer specifically to a vmdk, or another hypervisor image like Xen? As with Kool-Aid and Band-Aid, there is nothing better for a company than to contribute a word to the English lexicon, and while VMware may not completely own virtual machine, they command enough association to get passed the doorman of that enviable club.

Strong associations however, may not translate directly into revenue. From open source Xen to Microsoft’s Hyper-V, virtualization technology is rapidly commoditizing, a threat not lost on VMware. Hypervisors are now largely free, and much of the company’s continued success derives from the sophisticated management products that make mass virtualization a tractable challenge in the enterprise. But for every OpenView, there is ultimately a Nagios to content with, so the successful company is always innovating. VMware, a very successful company, is innovating by continuing its push up the stack.

Last week VMware introduced Cloud Foundry, an open Platform-as-a-Service product that represents an important step to transform the company into a dominant PaaS player. You don’t have to read any tea leaves to see this has been their focused strategy for some time; you just have to look at their acquisitions. SpringSource for Java frameworks; RabbitMQ for queuing; Gemstone for scalable, distributed persistence; and Hyperic to manage it all—it’s basically the modern developer’s shopping list of necessary application infrastructure. The only thing they are still missing is security.

Cloud Foundry assembles some components of this technology in a package that enables developers to skip the once-necessary evil of infrastructure integration and to instead concentrate fully on the business problems they’ve been tasked to solve. It is a carefully curated stack of cloud-centric frameworks and infrastructure made available by a cloud provider as a service. Right now, you can use Cloud Foundry in VMware-managed cloud; but the basic offering is available for any cloud, public or private. Applications should be easily portable between any instance of Cloud Foundry. VMware even promises a forthcoming micro-cloud VM, which makes any developer’s laptop into a cloud development environment.

All of this reduces friction in application development. Computing is full of barriers, and we often fall into the psychological trap of perceiving these to be bigger than they actually are. Barriers are the enemy of agile, and basic infrastructure is a barrier that too often saps the energy out of a new idea before it has a chance to grow. Make the plumbing available, make it simple to use, and half the battle for new apps is over. What’s left is just fun.

Cloud Foundry is important because it’s like a more open Azure. Microsoft deserves credit for keeping the PaaS dream alive with their own offering, but Azure suffers from a sense of lock-in, and it really only speaks to the Microsoft community. Plus the Microsoft ad campaign for cloud is so nauseating it might as well be bottled as a developer repellant for people who hate geeks.

Cloud Foundry, in contrast, goes far to establish its claim to openness. It references the recently announced Cloud Developer’s Bill of Rights, another initiative spearheaded by VMware. Despite being a Java-head myself, I was encouraged to learn that Cloud Foundry offered not just Spring, but Ruby on Rails, Sinatra for Ruby and Node.js. They also support Grails, as well as other frameworks based on the JVM. Persistence is handled by MySQL, MongoDB, or the Redis database, which is a decent range of options. So while VMware has’t quite opened up all their acquisition portfolio to the cloud community, they have assembled the critical pieces and seem genuine in their goal of erasing the stigma of lock-in that has tarnished previous commercial PaaS offerings.

I’m a fan of PaaS; I’m even a member of the club that believes that of the big three *-as-a-Services, PaaS is destined to be the dominant pattern. Managing and configuring infrastructure is, in my mind, pretty much on par with actually managing systems—a task I consider even less rewarding than shoveling manure. And I’m not alone in this opinion either. Once PaaS becomes open and trustworthy, it will be an automatic choice for most development. PaaS is the future of cloud, and VMware knows this.

Why Cloud Brokers Are The Foundation For The Resilient API Network

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.

Space Exploration and the Trough of Disillusionment

Hype cycles may be a largely a marketing construct, but it’s easy to forget that a lot of important engineering work gets done in the heady days of an emerging technology. I was reminded of this today when I noticed these two news items side-by-side on CNET this morning:

Rocket science just isn’t what it use to be. Must have been an amazing 20 years…

No More Iron in the Cloud

Iron Mountain, the well known information management company, is exiting the cloud storage business. The company announced yesterday that they will be phasing out their basic cloud storage services by 2013. Iron Mountain isn’t the first provider to turn its back on the cloud just as the space is getting off of the ground; but it is probably the most high profile company to exit this business.

I’ve always liked Iron Mountain because the name makes me think of the Hobbit (remember Dain of the Iron Hills?) In fact I think that Iron Mountain is one of the all time great company names, and their marketing group deserves credit for leveraging this to build a very strong brand around what is arguably a pretty dull and conventional service—that of records management. The extension of this brand into the cloud seemed obvious and fitting, so at first blush its disappointing that they’ve made a decision to reverse course.

In reality though, it seems that Iron Mountain is performing more of a realignment of its cloud strategy. Simple cloud-based storage is just not very hard to do, and so the field is rapidly becoming as crowded as the battle of five armies. Differentiation is the key to great brands, and its hard to standout from S3 or Carbonite or Mozy or any of the dozens of providers peddling mass storage services in the cloud. Iron Mountain seemed to recognize that their brand could be better served—that is, both leveraged and protected—by ducking out of the commodity bazaar and moving up the street to provide a more specialized and business-aligned service.

This is all very interesting because over the next few years we will see that brand—that most mysterious response in the consumer’s mind—is going to be the deciding factor that makes or breaks a cloud provider’s success. And as Amazon has demonstrated, cloud branding can come out of the most unlikely places.

Blowing Holes in the Web of Trust

The Register today published an excellent summary of the latest issues with SSL. In the typically blunt and mordant style for which the publication is so famous, Dan Goodin illustrates how the gossamer-thin SSL web of trust is built on a superstructure of astonishingly dubious merit. It’s a wonder the whole thing works at all.

Have a careful read of How is SSL hopelessly broken? Let us count the ways and then re-examine the cartel certs that anchor your own web browsing experience. As you roll out your API strategy, make sure you deploy your SSL endpoints with certificates that were subject to organizational or (much better) extended validation. Encourage—or if you can, demand—that your API clients limit their trust stores to a small subset containing only the most legitimate CAs.

The opportunity is largely over in the browser world; affecting massive change there will only happen when individuals personally lose money on a grand scale. But APIs still have a chance to regain some level of trust through rigorous application of SSL best practices, and API providers and developers can take the initiative here.