Force.com vs GAE + GWT
Salesforce could be regarded as the cloud computing leader but history tells us that many-a-giant has fallen before. Apple has; Microsoft has; IBM has. I think Salesforce is still on the up ‘n up, but there are contenders out there and some of them are noteworthy; probably the most obvious of these is Google. Over the past few months I’ve dug into the Google cloud platform and I thought it was time to attempt a side-by-side comparison of my two favourite PaaS providers.
Some quick definitions are probably in order:
Force.com is a cloud computing platform as a service offering from Salesforce, the first of its kind allowing developers to build multi tenant applications that are hosted on their servers as a service.
Google App Engine is a platform for developing and hosting web applications in Google-managed data centers.
A developer could use Google App Engine alone to build out cloud-based web applications, but I sincerely feel that by itself it is not a contender for Grand Poobah Of Cloud Computing. Semantically it’s closer to Apex without Visualforce, and that’s why I’ve included GWT in this discussion. This analogy is not precise but in order to compare two entities it’s necessary that they share some vague commonalities.
It’s probably worth mentioning that when I discuss Google’s technologies I’ll be talking exclusively about the Java-based implementations.
Documentation and Support
The platform offers extensive documentation, although not in the form that any Java developer expects. There are number of resources, from free books that thoroughly document sample applications that cover most needs, to integration documents for most other popular languages, a developer wiki and language references aimed at developers of all levels. A lot of this information is in online PDFs but there seems to be a movement to serve HTML versions too.
Support is offered through a number of channels including their developer forums, blogs, and official support channels. My experience with the support channels have typically been excellent, and I very much enjoy the developer community.
GAE + GWT
The documentation for GAE and GWT is very good. Their code samples and sample applications are delivered flawlessly. Beyond these though it can be tough to find exactly what you need. This may be down to the fact that these technologies are young-ish, but so is Force.com.
Support can be found across the internet, typically in StackOverflow or Google Groups. Google’s official support is virtually non-existent, even for paying customers. Of course if you’re using non-Google libraries in your application then you’ll need to look for support with that individual/organisation/community giving you a decentralised support system.
Force.com. Google’s documentation for the beginner is excellent, but beyond this you’re going to have to don a wooden pipe and employ a chap called Watson to wade through the internet with you. And I’m not sure if it’s Giant Corporate Arrogance, but Google’s support channel stinks.
The Learning Curve
Comparisons in this category are difficult as it depends on your background and what you’ve experience up until the point of being introduced to either platform. That said I found GWT quite unusual for begin with, but that learning curve tapers off quite quickly. Let’s call this one a tie.
The Force.com platform is quite flexible in that it allows you to build applications entirely within the browser or through Eclipse with the help of the Force.com IDE.
Given that the Force.com IDE is relatively young it is very good at what it does, but if you’re a Java developer moving onto the platform you’ll be disappointed by the lack of ‘small’ features such as fully fledged code completion, tricks to navigate around your project, tools for formatting, the ability to organise your code neatly (by packages etc.), a mature unit testing suite, build managers, performance & standards managers and some other tidbits. You will also spend about 10% of your time between saving source-code files and then waiting for them to deploy to the Salesforce servers, where you can check the result of your coding efforts.
The in-browser IDE is superb for beginners and is stable as well as almost problem free. It nudges you in the right direction when you’re still getting the gist of the development paradigm, but you’ll find as you become more familiar with the platform that it slows you down, and it makes working in teams very difficult as all developers working in one environment would share the same code (disastrous!).
Application configuration of the platform is managed through a large, but well throughout set of point-and-click interfaces. This is one area where the platform shines. Don’t get me wrong, there are a lot of options, but it’s still logically laid out and simple for anyone willing to read the context-sensitive help.
Database connectivity and management on the platform is simple and reminiscent of Hibernate/JPA. At the same time SOQL, whilst growing, still lacks many of the features offered by other products and platforms. Despite this I’d argue that no one has created a simpler way to use data persistence than Force.com
Debugging on the platform is possible but needs a large amount of tweaking. Issues here range from a lack of debugging-level control – it’s there but it seems to lack the options that most developers require, to the fact that you have virtually no control over how long the logger can run for (overnight for example is impossible) – making complex, new deployments tricky to debug.
GAE + GWT
GAE and GWT also have Eclipse plugins to facilitate development (although I’m sure you could use a host of other IDEs too).
This development environment benefits from the solid 15 years or so that Java has had to mature. The IDE is superb for coding, and for GWT development you have a ‘Hosted’ mode wherein you have a local server (automatically setup) that your code is deployed to on each save. This means that developers don’t need an internet connection, and there’s little or no latency between ‘save’ and viewing the results. You also have the freedom to employ the wealth of libraries that Java has to offer, and all the development tools you might require.
Application configuration can be complex; you have the usual suspects here in the form of configuration XML files and needing to know which files go where, as well as the required syntax for each. Of course all of this information is on the interwebs, but sometimes you’ll not be aware you need a configuration tweak purely because the option isn’t in front of you. Once familiar with the environment though you’ll have granular control over nearly every aspect of your application.
Database connectivity and management with Google’s platform is flexible and most often is employed using JDO or JPA which sit on top of Google’s DataStore. These technologies work very well server-side, although there is quite a learning curve involved for any developer new to the paradigm. There are some issues when GWT is brought into the picture as it seems the flexibility offered by Google has caused segmentation amongst developers – concerning which way is the correct way to implement persistence – and as far as I’ve seen there is no ideal implementation.
Debugging is a breeze, you have several tools at hand including good ol’ log4j. Log files of any size, break points, watch variables, thrown exceptions and their handling and more are all there.
GAE + GWT. Or rather Java, since Google have chosen to build on this technology they’ve hop-skipped-jumped the growing pains that Salesforce will have to endure for at least a few more years. The tool set is more stable, has more of major and minor features that developers love and is beyond flexible.
Applications built on the Force.com platform scale well (as long as you’ve architected your code to suit the Governor Limits), and application responsiveness is adequate. There are some areas that are slow though. For example AJAX functionality is easy to implement, but you’ll find that most times the page responsiveness is very poor, even when no database round-trips are required.
GAE + GWT
Anything you created on this platforms will also scale easily, and the interface served by GWT – which attempts to be entirely AJAXy – is faster than any web platform I’ve seen before.
GAE + GWT. GWT is geared towards responsive user interfaces and it shows. The architecture of the toolkit allows many modern features that one might expect when creating and AJAX-driven web site.
Application Resources & Quotas
In any multitenant architecture limitations on resources will have to be imposed, but the manner in which Salesforce has imposed these often draws a large amount of criticism. In part I agree with the Governor Limits* that have been imposed, it forces developers to be efficient in their application development, but in some ways it is so restrictive that you’ll need to violate development best practices to overcome them. In reality this has only been an issue when integration with off-platform services come into play, and I am aware that Salesforce endeavours to increase these with each new release.
*At times I wonder why Salesforce doesn’t allow a payment model in which certain Governor Limits can be removed or raised at least, although I suspect the answer has something to do with PR.
Google restricts resources by either their Free or Billing-Enabled Quotas, a model which I feel offers the flexibility that an integrated platform requires, as well as creating another revenue stream for the company itself. The Quotas are partitioned in a similar manner to Force.com Governor Limits but you’ll notice that even the Free Quotas are massive in comparison to those that Salesforce offers.
GAE + GWT. I think their position as an internet giant has put them leaps-and-bounds ahead in this area, there is no comparison.
As a developer I’m peripherally aware of the cost of developing and maintaining a Force.com application. The pricing model for Force.com is quite different from that of App Engine, with Salesforce using more or less a ‘Per Seat’ pricing model and Google using a ‘Per Resource’ pricing model. Pricing is available on their site, but the ‘Per Seat’ model can be very expensive for smaller companies (and large ones!).
The pricing model they employ is also bound by the license types they offer, and it’s come to my attention more than once that many common application architectures aren’t well supported by the license types on offer i.e. you’ll might have to re-architect to get around license limitations, or have to pay for a license more extensive than you require.
You’ll also need developers to create and maintain your application, and from current market prices (in London) they’ll cost you a pretty penny.
GWT + GAE
The pricing model from the big G is similar to what you might expect from a mobile or hosting contract, and in this sense is more a consumer type model. It is also cheaper.
Developers experienced in GWT + GAE are hard to come by currently so you might need to have some extra dosh in your mattress if you’re looking to employ some. The advantage here though is that any Java developer could quickly familiarise themselves with the platform, and won’t feel they’re losing anything because they’re not working with a Domain Specific Language.
GAE + GWT. Of course I’m looking at this from a developer and potential startup POV, but for me it just makes sense.
Time To Market
There are a number of assumptions here including:
- An application of similar magnitude.
- Developers and other resource of similar ability and quantity.
- Resources have similar levels of experience.
Application development on the platform is very fast, as long as it falls within the general confines of a forms-based, data-centric application you should hit very few speed bumps. Configuration and infrastructure have been abstracted away in a thought-out way, and this let’s you get down to the job at hand, software development. Not only this but the manner in which the Model, View and Controller are wired together makes life very easy for developers.
Creating an application on GAE + GWT is also quick, but it’s going to take you a bit longer. Configuration isn’t as simple, and although the MVC bit is easy to understand, in most instances it’s going to take more time to create the components of the architecture and get them speaking to each other.
Force.com. You’d be hard pressed to find any development environment that offers the speed-of-development that this platform offers. This is despite the youth and short-comings of development environment and might even offset the cost.
This depends on your role, the application you’d like to develop and the amount of money you have. Why not let me know what you think?