Java is finally available on Google App Engine. The initial developer preview release that Google announced yesterday provides the basic infrastructure needed to build web applications using Java and deploy / run it on the Google infrastructure (their cloud computing infrastructure).
The process is fairly simple - write Java code, bundle it up as a WAR (web archive) and deploy it to Google infrastructure. That is all. They will scale it as needed. The best part is that Google is providing access to their Data store (based on Big Table) via JDO (Java Data Objects).
JDO provides persistence to Java objects, and the retrieval of data is via a set of SQL like queries. The current generation JDO is pretty mature -- it handles all of the standard one-to-one, one-to-many relationships, inheritance etc. The actual persistence is itself configured via simple annotations. Google data store is highly optimised for web application needs -- i.e. reads and queries are super quick and easy to do. Writes are a little bit slower. They have transactions and all of the standard features one would expect to see in any data store.
---
This is fairly ground-breaking in my opinion. There are a large number of people that already know Java -- and given how simple it is now to create and deploy basic applications, we are likely to see Java regain its lost shine. Unless Microsoft starts providing quick access to something like this with .NET (they have it in development but not sure of its current status), many of the newer start-ups will start to closely look at companies like Google for hosting their applications.
In a nut shell developers no longer have to worry about:
1. Server operating system (and patching it)
2. Database server (esp. load balancing, writing code to scale up to multiple database servers)
3. Mail servers (installing it, configuring it, providing it with sufficient space for persistance)
4. Web server (securing it, bandwidth)
5. DoS attacks, network configuation
6. Memory cache (Google App Engine provides access to their own memcache for temporary persistance)
7. Messaging (Google is proving access to their underlying messaging infrastructure)
All this is infrastructure -- do not need to install, deploy, maintain or think about it.
Why is hosting a big deal? Because, most developers know very little about managing networks and infrastructure. The U/G courses in CS and Software development focus heavily on building solutions -- the deployment and management aspects if covered are presented at minimal depth (since this is not the core focus of the course). Most developers do pick this up over time on real projects, but never really enjoy it or care much for it. Most developers I know enjoy building new things, not pouring over log files and worrying about peak loads, upgrading and patching servers, DoS attacks, monitoring email traffic etc.
From the business perspective, it is a lot cheaper to have someone else provide the reliable and scalable computing infrastructure (this is a skill set that very few companies can afford to build and maintain). Not to mention the start-up costs that one needs if they roll out their own infrastructure. Cloud computing infrastructure is cheaper than LAMP, esp. since it takes 10 minutes to sign-up and have the entire infrastructure up and running.
With the emerging cloud computing infrastructure, developers can go back to focusing on solving user domain problems and letting the machines / experts worry about the installation, configuration and administration.
Limitations? As exciting as this all is, we are still in early days -- some applications will still need custom infrastructure (for instance, net banking). But, in another 3-5 years these infrastructures will get better, and compete for developer mind share (Amazon has EC2, Microsoft will have their platform soon enough, IBM has one in the works). Sadly, the only company that has .NET cloud infrastructure for now is Microsoft.
Interestingly -- this is how computing used to be in the hey-day of mainframes. I guess, history does repeat. We are back to just paying for CPU, Disk and Bandwidth while someone else worries about the underlying infrastructure.
-- rv
