Our latest podcast discussion centers on using cloud computing technologies and models to improve the test and development stages of applications' creation and refinement. One area of cloud computing that has really taken off and generated a lot of interest is the development test and performance proofing of applications -- all from an elastic cloud services fabric.

The build and test basis of development have traditionally proven complex, expensive, and inefficient. Periodic bursts of demand on runtime and build resources are the norm. By using a cloud approach, the demand burst can be accommodated better through dynamic resources, pooling, and provisioning.

We've seen this done internally for development projects and now we're starting to see it applied increasingly to external cloud resource providers like Amazon Web Services. And Microsoft is getting into the act too.

To help explain the benefits of cloud models for development services and how to begin experimenting and leveraging external and internal clouds -- perhaps in combination -- for test resource demand and efficiency, I recently interviewed Martin Van Ryswyk, vice president of engineering at Electric Cloud, and Mike Maciag, CEO at Electric Cloud.

Here are some excerpts:

Van Ryswyk: Folks have always wanted their builds to be fast and organized and to be done with as little hardware as possible. We've always struggled to get enough resources applied to the build process.

One of the big changes is that folks like Amazon have come along and really made this accessible to a much wider set of build teams. The dev and test problem really lends itself to what's been provided by these new cloud players.

Maciag: The traditional approaches of the overnight build, or even to the point of what people refer to as continuous integration, have fallen short, because they find problems too late. The best world is where engineers or developers find problems before they even check in their code and go to a preflight model, where they can run builds and tests on production class systems before checking in code in the source code control system.

Van Ryswyk: At a certain point, you just want it to happen like a factory. You want to be able to have builds run automatically. That's what ElectricCommander does. It orchestrates that whole process, tying in all the different tools, the software configuration management (SCM) tools, defect tracking tools, reporting tools, and artifact management -- all of that -- to make it happen automatically.

And that's really where the cloud part comes in. ... Then, you're bringing it all back together for a cohesive end report, which says, "Yes, the build worked." ElectricCommander was already allowing customers to manage the heterogeneity on physical machines and virtual machines (VMs). With some integrations we've added you can now extend that into the cloud.

There will be times when you need a physical machine, there will be times when your virtual environment is right, and there will be times when the cloud environment is right. ... We may not want to put our source code out in the cloud but we can use 500 machines for few hours to do some load, performance, or user interface testing. That's a perfect model for us.

... When you have these short duration storms of activity that sometimes require hundreds and hundreds of computers to do the kind of testing you want to do, you can rent it, and just use what you need. Then, as soon as you're done with your test storm, it goes away and you're back to the baseline of what you use on average.

• Cloud Computing as a Euphemism
• Cloud Computing One-Day Event in Toronto Cancelled
• Cloud Computing as a Euphemism

• More on ElectricCommander