Hands on: 4 Java clouds face off

At the movies, almost every thriller seems to include a moment when a character says, "That was easy ... a bit too easy." Then everything falls apart.

When I set out to test some of the top Java clouds on the marketplace, I found myself repeating this script. The bottom never dropped out on me. Nothing ever stopped working. Nothing fell apart. But time and time again, I kept fretting about how easy it was -- too easy. When the whole thing exploded, where would my Web app be?

Enterprise developers need to be a bit more paranoid about these possibilities than others. The average computer user is thrilled when a new package in the cloud makes life easier. They can embrace cloud-based email, and if the email gets lost, they can just shrug because email always gets lost and can sometimes be a blessing.

[ Also on InfoWorld: Java 7: What's in it for developers | Bossie Awards 2011: The best open source application development software | Top Java programming tools | For more on Java, subscribe to InfoWorld's Enterprise Java newsletter. ]

Enterprise developers can't be so sanguine. All of the fancy tools take as well as give. Every slick configuration option that's activated with one push of a button locks us in forever with the same push of the button -- or so it feels to those who worry. If we adapt to the cloud too readily and let it do too much for us, it may not be possible to go anywhere else.

The danger of lock-in seems to lurk around every corner, and that's not necessarily the worst part. What if we're happy with everything about our cloud except we need one missing feature that the cloud's masters either can't or don't want to deliver? The cloud can be a one-size-fits-all world.

If it's any consolation, cloud developers also appear flummoxed by the trade-off. They know customers want one-touch solutions and plenty of automation to make life easier. But it means delivering interfaces that won't be as standard or as flexible as customers would like. The cloud builders must figure out whether the marketplace wants everything done by the cloud or whether customers want to do enough for themselves to avoid lock-in.

To see where things stand, I set up some accounts on four leading Java clouds, built a few toy Java applications and watched the gauges turn. Even among the four I tried -- Google App Engine, Cloud Foundry, CloudBees and Red Hat OpenShift -- there is a wide variety of approaches. Some of the clouds rely upon standard tools that take standard WAR files and deliver their information to the world. Others have so many proprietary twists that you might as well tattoo the code on your arm -- it's going to be with you for the rest of your life.

The cloud experiment: Java version

The Java cloud offerings are steadily growing better and more sophisticated, but they're far from a finished set of products. Several of the tools here are perfectly open about their half-baked state. The sign-up forms often insist that we understand the cloud is just a beta application, for development only and not for production work. In fact, it might be more accurate to call the clouds post-alpha or pre-beta.

Even the more established clouds are constantly shifting because this is all something of an experiment. No one really knows how the loads and the costs will add up, so the prices seem to be changing, sometimes in dramatic ways. The cloud sellers don't really know how their costs will shake out, so they're guessing when they say it costs X dollars for Y million transactions. As the old joke goes, they're losing money on every click but hoping to make it up in volume.

Pricing may be the most difficult and challenging issue for both buyers and sellers for years to come. People are already cheesed off at the way Google stopped subsidizing its App Engine. Some users are complaining that their costs doubled or tripled with, irony of ironies, one click of a button. But who can blame Google? While the company has excellent financial engineers, I'm not sure if they can know the fair price for a round trip to the Big Table data store. It probably fluctuates with the rainfall in the northwest, where the hydropower is the cheapest power source for some of Google's newest data centers.

Perhaps I'm overthinking it. Things can go wrong anywhere. Prices will fluctuate. The cloud can be more flexible and automated, thus saving us money on people who will minister to the racks and make sure the data is flowing smoothly. If that Web 3.0 application turns out to be a big hit but the cloud is too expensive, it will still bring in enough revenue to pay for all of the reprogramming required to move the app to a set of in-house servers. If it's one of those Web things where the revenues never scale with the costs, well, the price of experimentation couldn't be lower. That's what clouds are ultimately about: They simplify experimentation and change.

Just choosing a cloud can involve plenty of experimentation. The simplest option is to turn up a raw machine from the Amazon or Rackspace cloud, but these don't offer much of what the cloud marketeers promise. Sure, I pushed the button and started up a new machine in just a few seconds, but then I spent more than a few hours logged in as root installing the JVM and the rest of the stack. Once I finally got a machine configuration I liked, I was so proud of it that I wanted to put a picture of it on the fridge. I made sure to store it away so I could start it up as many times as I like.

If you've got the time and the inclination to build up a machine image with the software you like, raw cloud machines can offer you most of what you want from the cloud with few problems of lock-in. Both Amazon and Rackspace make it easy to store an image and hit the replication button again and again. You choose the software and you decide how many machines you want. In theory, there are more machines there whenever you need them. I experimented with spinning up new machines for the daily housekeeping work, and it was nice to spend only 1.5 cents per hour for them. After the work is done, they're gone.

Of course, you've got to do all of the thinking yourself. Do you want 100 machines or 102? Yes, you control your costs but you don't have time to react unless you build more intelligence on top of it.

Java clouds: Google App Engine

There's something warm and comfortable about using Google's App Engine. What began as a fairly radical tool has slowly matured into an asset that's easier to understand and use, if only because the world has adopted many of the ideas.

The basic architectural themes have remained the same. You upload a small kernel of code with your business logic, and App Engine deploys enough instances to satisfy the demand. If you want to store data or synchronize your work between sessions, you have to use Google's proprietary data stores and caching, but everything else feels fairly standard. The first versions of App Engine used Python, but now you can push up Java WAR files filled with JSPs, servlets and server-side logic. The administration is handled through a separate Web interface. Command-line issues are pretty much relegated to the past.

While the architecture and data store haven't changed, the tools are more sophisticated and richer, with more features and buttons to juggle quotas and tune performance. I used the complete set of Eclipse plug-ins to build applications, but there are similar offerings for NetBeans and IntelliJ. These tools also integrate the Google Web Toolkit with the App Engine, making it possible to do all of your programming in Java. If you can't stand JavaScript or just want to use the same code on the server and the client, the Google Web Toolkit will translate your Java for the browser.

I think the biggest challenges for programmers will be adjusting to Google's nonrelational data stores. When App Engine first appeared, there weren't so many NoSQL projects around, and the idea of storing collections of name-value pairs was more of a novelty. Anyone approaching App Engine with a bit of experience with NoSQL won't be shocked at all by the simple solution that App Engine forces upon everyone who wants to keep data around. But anyone who still thinks of JOINs and normalized data will need to break from the table-oriented, relational past and adjust to a new way of doing things.

App Engine offers two classes of the data store, so the architect must decide whether to pay for additional power. The basic model makes one data center the master and all others a slave. If the data center fails or starts up a scheduled maintenance, your data can't be stored. You must be ready to live with a "planned read-only period." Many modern Web applications (think Facebook) can easily survive these kind of glitches, but applications requiring banklike levels of availability and consistency will need to look elsewhere.

The low-rent, master-slave configuration is supposed to be about one-third the cost of the "high replication" version, with each low-rent write costing about five-eighths of the high-rent equivalent. The low-rent version may be twice as slow on writes as the high replication cloud; then again, it might not. You have to be careful with some of these numbers because the mechanism includes lots of hidden overhead. Each name-value pair, for instance, includes all the names as overhead because there's no schema. That's the price you pay for the flexibility to store any old thing in any old row.

For some reason, I found myself fretting about the lack of access to the file system. I realize that the idea is to store the bits as blobs so that App Engine can optimize everything, but I still like the ability to write to the file system for some projects.

One of the biggest changes in App Engine is the appearance of economic reality. While Google heavily subsidized the first crop of applications by offering so much for free, it has slowly been squeezing the free apps and pushing people to pay for what they get. Free apps can now access the data store 50,000 times a day -- which adds up quickly if you keep more than a few items in the data store.

The new price list includes a long set of quotas and rates. All seem tiny and reasonable, but I have no easy way to compare them. Is 1 cent per 10,000 reads from the data store a good price? Should I hold out for 1 cent per 12,000 reads? Somehow it seems easier to go to the boss and ask for a box with two quad-core processors, a ton of RAM, and some fast disks, then cross our fingers. It's not very scientific, but it's so much easier than thinking through all of the details.

One interesting detail is that the App Engine sort of strips away your ability to tune your application's performance to handle peaks: 100 emails will always cost one penny. You can't save money with a cheaper processor and a queue that delays the email.

Java clouds: Cloud Foundry

Spring has always been one of the cleanest frameworks in the Java enterprise world. It makes sense that someone would use it as the foundation for a Java cloud. That someone in this case is SpringSource, one of the Cloud Foundry project leaders and a division of VMware. It should come as no surprise that this cloud is built on top of VMware virtual machines.

(The VMware-hosted Cloud Foundry is a bit of a departure from past offers. The first version deployed Spring apps to the Amazon EC2 cloud. It's still available from classic.cloudfoundry.com if that's what you want.)

The easiest way to use Cloud Foundry is to create a Spring project from a template with SpringSource's customized version of Eclipse called the SpringSource Tool Suite. I tried installing some of SpringSource's tools into my own version of Eclipse, but the right collection of libraries was not easy to find. The SpringSource Tool Suite is simpler.

The Cloud Foundry is not limited to Spring. There's support for Rails, Sinatra, Scala, Grails and Node.js. It's all running on the JVM even if you don't write any Java. Cloud Foundry just announced PHP and Python/Django support as well. The VM image that you get also comes ready with MySQL, MongoDB and Redis databases waiting to suck up your information.

VMware has kept mum about the pricing. The product is still in beta and VMware has been kind enough not to charge for it. Will the rates be too high? How can you plan? You can't, but the Cloud Foundry virtual machine is fairly open. You can download the Micro Cloud Foundry -- a portable virtual machine image of the Cloud Foundry environment -- and run it on your own system with VMware Player. The core code is open sourced at cloudfoundry.org and largely covered by the Apache license.

Java clouds: CloudBees

One joke floating around the Net is a list of lies that companies tell potential hires to seem more with it. Running a continuous integration server is near the top. Everyone likes the idea of constantly checking the code to make sure it works, but no one wants to do all of the work required to both maintain the code and keep the continuous integration server up and running.

CloudBees would like to change this. Not only does the company offer a cloud for deploying your applications, but it provides a cloud to build them too. Your account is more than just a way to serve your data to the masses. There's a code repository (Git or Subversion) and a Jenkins server watching every piece of code you check in.