How to Evaluate Cloud Code, Part 1

Many cloud applications focus on declarative programming, but let's face it -- code happens. How should you evaluate the code that runs in the cloud?

By David Taber
Thu, October 13, 2011

CIO — Cloud-based applications tend to focus the users' creative impulses on what the vendors are calling "declarative programming:" point-and-click specification of behavior, plus configurations, settings, rules, and formulas. These are good choices for ease of use, containing multi-tenant workloads, and testability. But if your cloud app has large user counts or sophisticated use cases, declarative development will take you only so far: soon enough, you'll be merrily coding in both the presentation layer (view) and the business logic (controller). In some cloud environments, you'll even be working directly with metadata and the transaction layer (model).

Of course, if you're using a cloud-based development or deployment environment, you'll be working with all three of the MVC layers from day one. For IT pros, that's nothing new.

But the world of cloud development does present some new challenges, because it's still very much in the early stages. For example:

There's no center: Not only are the users decentralized, the developers can be anywhere and the services are in several locations. There's no central repository for the application model, code, test databases, or application artifacts unless you create one with your favorite version control system and wiki. So...go do that.

You'll typically be working in several languages at once: Even when working within just one application, you'll be using plenty of cross-language references. For example, your code might call java libraries, internal application functions, and scripts. Your UI may call jquery, JavaScript, JavaScript frameworks, native file-system utilities, AJAX, Flex, and other languages. This is very powerful and efficient, but it can lead to code that is very tough to troubleshoot and debug. Try to keep the total number of languages in use to less than 5. Go ahead...try.

Different developer tools will affect the code structure: This is true from analysis and design through to test and deployment: some tools allow (even encourage) much more elaborate and extensible coding structures than others. Some of the fancier tools are available only on windows, so you're Mac and Linux-based developers will have a different experience of your system, both at development and deployment time. This goes double for debugging. And double again for UI.

Cloud Code Evaluation Criteria

Assuming that the cloud code functions and meets the user requirements, how else should code be evaluated? Let's look at some basics:

Performance: In a cloud application, this is typically measured by "screen refresh time," as that's what the users will perceive as "time to complete." Do this evaluation on a typical user machine (say, 3-year old laptop), not a 3 GHz quad-core behemoth with 16 GB of RAM. Two elements typically dominate perceived performance: the length of time before the cloud's servers respond to requests, and the screen-paint time. The three killer things to look for when evaluating cloud code: silly queries, excessive network chattiness (particularly when several Web services have to be called), and overblown page length or view state.

Continue Reading

Our Commenting Policies