The Trouble With Coding Across the Clouds: Part 1

CIO — Most cloud applications have development (or at least scripting) capabilities that allow for deep customization plus some level of database access and computational capabilities. But even the best of the cloud applications must put in limiters for their platform/development environments: an app isn't a general purpose run-time or generic object container. For example, the development language must be made safe for a multi-tenant deployment, and must be well-behaved so that user code can't take down the virtual machine, database, or overall application. Further, some kinds of language constructs must be limited to prevent resource hogging and deadlocks. (Indeed, if you think about the billion lines of user code that Salesforce.com has running in their cloud, keeping quick responsiveness and good uptime stats is a non-trivial task.)

Using Salesforce's APEX as an example, the language can handle most business logic without too many tricky work-arounds. But inevitably with a cloud-based development environment, there will be certain requirements that push against the platform's limits. For example, there might be a terrific library in J2EE that does just what you want, but J2EE is simply not available in the cloud platform where you need it. Even if you need just a couple of methods out of that library, it may turn out that some of its underlying functions cant be successfully ported over to the native language of your platform.

Let me take a real world example: license key generation. Software vendors like to use license keys to enforce their end-user contracts. The CRM system holds the license keys (as part of the customers' Assets), and it would be nice to generate the keys entirely within the CRM application. So the software organization asks to port the keygen system into the CRM app. The key generation uses encryption methods that are available as part of the CRM platform, but it also uses a nifty library that does arbitrary precision math. Arbitrary precision, as in: multiply two 400-digit numbers and take the square root modulo 7. That nifty library does this math entirely with strings, using recursions that are most lovely.

So even though you can port all the logic to the CRM system, the computational load of actually running the keygen will blow through the governor limits that must be enforced on the CPU, heap size, and number of queries. These run-time limits frequently hit analytics (think BI), optimization (think stock portfolios), really big lookups (think the Named Account Model or multi-channel distribution strategies) and other business applications touched by the CRM.

Continue Reading