These are often referred to as the primary vendors in cloud computing today. Yet, the differences between these cloud offerings are broad. For instance, with Force.com, the learning curve of a proprietary language to develop with their Platform as a Service (Paas) is minor for a Java developer as it is very similar to Java. The real issue is the lack of re-usable libraries. In the Java community, there is a lot of open source, such as XML libraries from Apache (e.g., digester). Without this, you have to reinvent the wheel instead of rapidly producing the business logic you need. This, IMHO, is a very large hidden cost of their PaaS and one reason their development community isn't taking off like a rocket.
The real appeal of Force.com is high productivity for creating data entry, reporting and analysis apps, much of which can be accomplished without programming. They also have decent licensing options for organizations that need an enterprise capable application infrastructure without the data center or software maintenance costs.
Google Apps Engine (GAE) is attractive to Java developers. If you look at the Java Google Group (2765) count, they far outnumber Python users (802).
One advantage of their Java platform is portability. That is, an app created for GAE can be hosted on any Java EE server, as they provide a subset of Java EE standards, open standards within the Java community. The catch is you have to avoid their hooks; or at least consider how to minimize your rip-and-replace costs. One potential hook can be in the use of Google Accounts for authentication. They are also producing APIs into their infrastructure for things like task queues that might not be so portable to a non-GAE Java EE environment.
The key here is to push to ensure that all their APIs follow open standards within the Java community. If such standards don't exist, then now may be the time to create them via the Java Community Process (JCP.org). One example of Google doing this right, in addition to supporting a subset of Java EE standards, is JCache (JSR-107). Although they implement it with their memcache, the open standards interface protects your code from this, allowing you to swap to an open source implementation if you move your app to another Java hosting environment. It is clear that Google went far to support Java Community Process standards. However, Google is also creating APIs for their services that don't have JCP interfaces. As long as Google proprietary APIs are coupled with a drive to create new JCP standards to complete these gaps, then one could settle for near-term limited rip-and-replace risk with an overall and long-term benefit of open standards.
Amazon's "you can do anything in your VM" approach sounds good; but can be a lot more costly if you don't need Infrastructure as a Service (IaaS). Even with cloud computing, your minimum costs can really add up on a monthly basis when you do the math, particularly if you consume a lot of bandwidth. Your IT costs can be higher for this freedom as well as you'll have to support software configuration and maintenance. It is, in a nut shell, a different cost model for hosting with the added benefit of elasticity for those with high growth rates or dynamic demand and a need for application hosting, security or SLA requirements not met via current PaaS providers. Your platform options are more flexible. Yet, this equation includes a lot more than just platform, and may be more flexible than you need, translating to unnecessary cost. On the other hand, if you are moving exiting apps to it, have requirements that PaaS providers aren't providing, or need data center disaster recovery, then this can be your preferred choice.
In the end, Force.com, GAE and Amazon are apples and oranges today. One isn't better than the other because they are very different; so different, it could make sense to combine them all.
Erik Sliman
OpenStandards.net
Wednesday, August 12, 2009
Subscribe to:
Posts (Atom)
