I just got done with my afternoon shift of manning the Force.com booth at Cloudstock. Other than some tired legs, Cloudstock has been an amazing experience. I got to learn about technologies that I had been itching to find out more about and met some really smart developers who challenged, and yes even humbled me. Since I was manning the Force.com booth during the afternoon, I only got to attend 3 morning sessions, but that was plenty. For those of you watching at home, I thought I'd do a quick recap of the salient nuggets from my admittedly limited memory cache.
1) Introduction to MongoDB: A Document-oriented Data Store
This was a great introductory session to one of the more popular NoSQL databases – MongoDB. Highlights included
- Contrary to my initial understanding, NoSQL technically means ‘Not Only SQL’, and not ‘No SQL’
- The session started with a quick recap of the history of databases and RDBMS systems in particular. It then went on to discuss BI oriented OLAP systems that evolved to address use cases that weren’t well suited for RDBMS data stores (ability to analyze vast sets of historical data etc). NoSQL was similarly developed to address specific use cases that aren't well suited for a traditional RDBMS – namely the ability to deal efficiently with vast data sets.
- NoSQL databases like MongoDB have no defined schema – no predefined ‘tables’, DDL scripts etc. This makes MongoDB especially well suited for Agile development where you need to iterate the data model often and quickly.
- MongoDB is highly scalable (think billions, not millions) and performance scales with these large data sets. As with other NoSQL databases, MongoDB is ‘document-oriented’.
- The downside of that agility is that MongoDB does not support joins or transactions. However, that’s not as big of a drawback as one (like myself) might initially think. The applications that MongoDB is well suited for don’t need to do complex queries that require joins (though you can join MongoDB data in your own code) and can live with weak transaction support. It does however support indexes and partitions (called shards in MongoDB)
- A MongoDB data model is not as normalized as a traditional RDBMS (since there are no joins to support).
2) Introduction to Heroku and Platform-as-a-Service
Next up was Adam Wiggins session on Heroku. Highlights included
- Heroku provides a PAAS platform for Ruby/Rails development.
- Adam started with a general overview of some of the key characteristics of any PAAS platform. This part of the session resonated with me particularly well since it echoed many of the advantages of the Force.com platform. Some of the PAAS characteristics that he listed included
- No Capital Expenditure (aka 'CapEx') to get started
- Egalitarian infrastructure – the smallest app has the same SLA as the biggest fish in the pond
- Built to scale from the start
- Quick to get started with. That, combined with rapid development leads to faster time-to-market for PAAS applications
- Heroku features include DB import/export, cron jobs, memcache, release management etc.
- Heroku also supports an ‘add-on’ framework whereby other providers can provide complimentary services. Some popular add-ons include PostgresSQL & RabbitMQ
- Adam ended by listing some of Heroku’s guilding principles – again ones that should sound very familiar to Force.com developers
- YOYODA principle – You Own Your Own Data, Always
- Simple is beautiful
- Form and function are joined at the hip. You can’t have one without the other.
3) The Cloud and Mobile Space: Living in Harmony
Jeremy Glassenberg presented a session on how to design good API’s for accessing cloud services from a mobile device. With my recent interest in Android development, this session was very timely and pertinent for me. Highlights included
- In addition to releasing native mobile apps, companies have also started releasing API’s for the various mobile platforms. Examples of this include Facebook, Foursquare and even Salesforce.
- Jeremy had some great tips on designing a mobile centric API. It was especially gratifying to see how well Salesforce aligns with these points.
- Use REST (instead of the more chatty SOAP). Force.com – check.
- Use JSON (instead of the more chatty XML). Force.com – check.
- Use OAuth (instead of username/password). Force.com – check.
- Develop native toolkits/libraries for the various mobile platforms like Android and iOS. Force.com – check and check.
- Some other points that Jeremy made included focusing the API on methods that are relevant in a mobile context (i.e. no need to support everything), making any Java library/toolkit Android specific and setting a position on branding (e.g. should 3rd party developers using the API always disclose/acknowledge your company)
Now it’s on to getting ready for the big show. Dreamforce, here we go…