In last week's post, I discussed why dev/test can be a good first use of cloud computing. Without rehashing the entire post, it's clear that dev/test is often hampered in its activities by the difficulty of getting enough computing resources to its job.
It's important that hardware dependencies that cannot be accommodated in a cloud environment be avoided.
It's always tempting for bloggers/consultants/vendors to turn a list like this into a set of "beware" items, which is always frustrating to read, because the lists say what not to do, not what to do, with an implication that, unless you're really, really careful, things could go wrong.
Rather than repeat that tiresome approach, in this post, I'll state the positive things to implement to make dev/test better via the cloud.
The most important fact to keep in mind is that you're integrating cloud computing into the dev/test process, so it's an and situation, not an or situation; that is, the resulting environment will have both existing practices and artifacts and cloud artifacts, so it's vital that your approach meld the two.
Your task is to blend internal and cloud environments:
Integrate with code management systems:
Treat the cloud as an extension, not a separation. It can be tempting to upload fully deployed applications from a developers box (or even a staging box), but a better arrangement is to have a cloud VM pull the code from the on-premise code management system and install it into the VM.
This ensures that version control issues are avoided; nothing is worse than bugs being fixed in the latest version, but reported because they were present in an older version which was uploaded to the cloud.
There's a reason development shops use code management systems as the "one version of the truth," and using the cloud should align with that practice.
Ensure easy integrations to internal systems are available:
If the application makes calls to other applications, make sure the interfaces are clean. This implies that service oriented-type interfaces are available that avoid direct interaction between applications.
Certainly any integration that relies on direct database calls or on hard-coded IP addresses or internal DNS names should be avoided. If such integration mechanisms are in place, either encapsulate them in a service interface or do not attempt to use the cloud as part of this application's development lifecycle.
Ensure the application can operate on commodity hardware: Cloud environments have standardized hardware environments, so be sure your application aligns with that fact. It's important that hardware dependencies that cannot be accommodated in a cloud environment be avoided.
This means applications that require specialized cards, are architected for particular processors or unsupported operating systems, or that assume high performance infrastructure are not good candidates for cloud dev/test.
Consider architecting for cloud environments:
Make the application scalable in both directions. Admittedly, this recommendation can be a bit controversial. The cloud can certainly host non-elastic apps just fine, and if the target environment production environment does not support bi-directional scalability, architecting for it may be unnecessary.
In fact, if one is sure the application will not experience large variability of load and therefore never need to scale, architecting for bi-directional scalability may impose application complexity where it's not needed.
On the other hand, many, many applications find they bump into a performance ceiling because their architecture is unable to grow gracefully, so it might make sense to implement a flexible architecture where it seems unneeded- today.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.