First try with CloudFoundry
The cloud is here to stay. When Google made Java available for its App Engine PaaS platform (before there was only Python), I was there and I tried it. Last week, VMWare launched its competitor, the CloudFoundry platform, and I wanted to try it the same way.
Since then, I’ve played a little with it and it’s full of good surprises compared to GAE. That is not to say that GAE was bad, in fact, it’s the first PaaS that is free under a certain trafic limit (and this limit is quite high) but it has some limitations that are really a burden for developers:
- First, if you need to persist your data (a likely event), you’re forced to use either JPA 1.0 or JDO with the DataNucleus datastore underneath. This means you can forget about NoSQL or MySQL or you preferred RDBMS. Moreover, you’ve to learn all about DataNucleus in order to configure the datastore. Since it’s not a widespread product (like Hibernate or EclipseLink), this can be quite a burden.
- Second, at every request, the entire session is serialized. This means a little overhead each time and possible NotSerializableException. I think (hope) this behavior has been corrected since I last used it, in order to only serialize when needed (that is when the user is directed to another server).
- Then, the term cloud is to be taken at face value: you see nothing of the infrastructure. No logs (although an interface let you see them, you can say goodbye to all your nicely log configuration), no configuration, no temp files, no nothing!
- Finally, you have only access to a subset of the Java API: no threads, no files, etc. The white list is available there: don’t be suprised by the high number, it’s quite few in fact. There are 1498 items, whereas the Java 6 API has 3793, meaning you have only 39% of all the features!
All these mean you cannot take an existing application, upload it to GAE and expect it to run like it ran on your local server. In fact, migrating an application to GAE is a lenghty process, depending on the gap between what you use and what you are permitted to use. The worst is that once migrated, either you cannot run on a standard server anymore (or only in the GAE sandbox, which is provided) or it takes a very (very!) long time to configure both a GAE and a standard configuration.
The good news with CloudFoundry is that these limits don’t exist. I tried with two different applications:
- Twaattin, a custom application for my Learning Vaadin book based on Vaadin and HSQLDB. It also makes use of threads and files and heavily relies on the Twitter API.
- The Vaadin demo application available on their site, which I took and uploaded “as-is”.
Both deployed seamlessly on CloudFoundry from Spring Tools Suite. Moreover, the logs appear in the STS log tab, just like with any other local server. For example, I forgot to include SLF4J and was pleasantly surprised to see the stack informing me of that.
As for running the applications, it’s the same: they just run in the expected way out-of-the-box. In my STS, I can even see remote files! It’s a Tomcat instance, and I can read both its config files and the HSQL database files.
The whole thing is not even tied to Spring. Well, it sure helps. More specifically, it’s not trivial to connect to the offered database services without the Spring configuration but it’s possible (look here if you’re stuck). Until now, it’s the only negative point I’ve found.
Understand this: these are not production applications, I didn’t perform any performance testing (it’s forbidden by the terms of service anyway), beta doesn’t provide any billing information for the future and there’re no metrics displayed. Thus, my point of view is only from an developer perspective, who tried GAE 2 years ago. In this light, and until proven the contraty, CloudFoundry is a developer’s dream come true.
People interested in testing CloudFoundry for themselves and not taking my word for granted are welcome to do so (I would also like feedbacks). Requests for the service can be sent here. Alternatively, you can also get the source code on GitHub and deploy the CloudFoundry application on your own infrastructure.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)