A few bumps on the road to HTTP/2

I had recently blogged about making concurrent REST calls at scale using HTTP. I had observed that, thanks to async I/O and/or virtual threads, it's feasible to make large numbers of requests in parallel. But while threads are cheap, there is typically another limiting factor: the HTTP connection pool. This pool serves as a semaphore: if the pool is empty you'll have to wait. I've seen default pool configurations that have even tighter limits on connections to the same host, which is problematic for internal service-to-service calls.

On the other hand, the HTTP/2 protocol offers an end run around the pool: requests are multiplexed onto a single connection, and you get responses back in any order. HTTP/2 seems to promise some serious performance benefits. We could send numerous requests without the overhead of setting up and tearing down a new connection every time, and the protocol is more compact and requests can processed in parallel. Unfortunately, I found some gotchas while experimenting with HTTP/2 requests which I'm going to note here for future reference.

AppFog: the GMail of PaaS

AppFog sent out an email announcement a couple of days ago that made my jaw drop. AppFog is one of the commercial implementations of the open source CloudFoundry PaaS (Platform as a Service). I blogged briefly before about CloudFoundry: it's one of the new generation of PaaS that do not lock you in with vendor-specific APIs. You can provision a standard DB service, upload a war and watch your application go live.

So AppFog is a commercial offering of an open source PaaS over generic public infrastructure: sounds about as generic as it gets, right? The difference is in their business model: calling themselves the "GMail of PaaS", they intend to shake up the market in the same way. Remember GMail? It arrived as a free email service with virtually unlimited storage. Suddenly, the idea of a paid email service seemed ridiculous. AppFog's announcement is comparable. The part of the announcement that made my jaw drop is the price: free for an application with 2GB of RAM, 1GB of DB storage and a 50GB transfer limit. By contrast, Jelastic's prices at ServInt work out to $14.40 per 128MB per month. The next step up is a $100/month plan, but the free plan alone is so generous many users won't need anything more. AppFog could kill the VPS market altogether.

There are details I'm still not clear about. For example, the default infrastructure is Amazon's AWS: is the disk storage the EC2 ephemeral storage that disappears when an instance shuts down or is that EBS or S3? Of course, you also have other infrastructure options: HP's OpenStack, Microsoft's Azure (no Java) or Rackspace. Moreover, I'm still skeptical about how AppFog intends to make money. They made vague noises enterprise customers, but the fact is their free product will be very popular. And while AppFog will not charge you money, AppFog itself still has to pay Amazon for the infrastructure. Still, why look a gift horse in the mouth? One thing is for sure: the PaaS market will not be the same again.

Revealed: my top secret Grails project

I have mentioned in previous postings that I had been working on a Grails project, but neglected to actually say what that project was. Jelastic not only hosts this project on their PAAS cloud, but Judah Johns of Jelastic was kind enough to interview yours truly on their blog:

The Jelastic Spotlight: My Hometown Video

Now that My Hometown Video (HTV) is out there, it seems unnecessarily bashful to avoid blogging about this project. HTV is the brainchild of my client, Rob Roddenberry, who wanted a way for communities to form around towns of interest. Perhaps you might be nostalgic about a town you grew up in, or would like to tour attractions (parks, beaches). That's where HTV comes in: to provide location-centric videos and discussions. A longer explanation and more screenshots are in the Jelastic spotlight link above, but the best way to check it out is to visit the HTV site.

This has been a fun project. While I have a day job building enterprise Java applications, this is one site that I could sort of call my own. It really belongs to Rob, of course, and is entirely his idea. But it is satisfying to be get to do "everything" at the technical level including UI, server, DB, provisioning, deployment and operations. Grails has been fun to work with, and I find it interesting that every single Jelastic Spotlight application up to HTV has been a Grails app. The presence of public APIs like Facebook's and easy-to-use PAAS offerings like Jelastic has made such applications so easy to turn into reality.

No more cookies for you, says Facebook

The Facebook platform offers a great deal of functionality, and I have been using it recently for user authentication and management for a web application. Last December, Facebook implemented their mandatory migration to OAuth 2.0, causing breaking changes for those of us naïve enough not to monitor their blog. As part of this migration, they changed both their cookie format and policy, which will make life more difficult for server-side developers.

Reconsidering Java cloud hosting with PaaS

I have been looking into Java cloud hosting for my Groovy on Grails application, and I am quite pleased at what has been happening in this space. I last explored cloud hosting a couple of years ago. By contrast, today's PaaS (Platform as a Service) options look quite promising, particularly Cloud Foundry and Jelastic.

The cloudy future of relational databases

Cloud computing is the big new thing. The fate of the formerly ubiquitous relational database, on the other hand, is uncertain. There are many ways for a developer to deploy his application to the "cloud", whatever that might mean. On the other hand, the various cloud vendors do not necessarily have a database story to tell, or if they do that story isn't necessarily a good one. As a result, deploying a traditional database-backed application to the cloud may be difficult.

One story I have heard is to simply opt out of using a relational database. You would use some "NoSQL" persistence technology, such as SimpleDB on Amazon or Google's datastore. Such solutions have their advantages in terms of performance, scalability and ease of mapping to objects. If you just want to store dumb data objects, that may be all you need. But there are situations where the traditional RDBMS is more appropriate. If you have a data-centric view of your problem domain, where the data is ontologically independent of the application and can outlive the application, where you want the database to guarantee certain transactional and integrity rules, where you want to do lots of ad-hoc querying ... you might just want an RDBMS. My worry is that for many cloud platforms, you may not have that option.

For the platform as a service (PaaS) sort of cloud, where you may not even have filesystem access, setting up your own database server will not be an option. Even where the vendor provides a database service, your choice remains limited to that one service. For example, if you use Azure you can only use SQL Server. The infrastructure as a service (IaaS) sort of cloud will generally give you that freedom, but it may have limitations. Generally, IaaS vendors like Amazon offer:

• a compute service: a virtual machine with local filesystem storage. Small, fast storage.
• a storage service: an API to read/write data on the cloud. Big, slow storage. 

So you have a choice of small, fast storage (EC2) or big, slow storage (S3). Trouble is, a database server really wants big and fast storage.

At this point, I think the reader of this blog may want to slap me on the head and point out that yes, Amazon tells a perfectly good database story. In fact, it must have at least half a dozen stories to tell. You can use their MySQL service, put up an Oracle AMI or stand up your own database server: there are lots of choices both from Amazon and third parties. There are choices partly because Amazon's EC2 can use elastic block storage (EBS). This is a filesystem which is both big and fast, especially if you set up several EBS volumes in a RAID configuration. I noticed that my former colleague Chip recently blogged about his success deploying database-backed applications to Amazon's cloud.

OK, so you have lots of database choices if you go with the Amazon cloud. But only Amazon. I have been talking to another cloud IaaS vendor without a database story, being stuck with the fast/small vs slow/big dichotomy. With other vendors, it seems, you either have just one choice of RDBMS or you simply cannot get a production-ready RDBMS in the cloud. Did I miss an another option or two? You tell me.