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.
What are the steps one should take to really leverage the cloud for development and QA tasks? This week’s post sets out how to improve dev/test through the cloud.
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.
Scrub any sensitive data: Don’t let the fact that this is a development effort obscure the fact that you’re putting data into a different environment. Make sure that any data put into an application in a development cycle is treated with the security and privacy it deserves. It can be tempting to just take a data dump from the production system and load it into the development application; in a purely internal development environment that may be appropriate. However, when data is put into a more publicly accessible environment, it’s important that it be analyzed for privacy/security concerns and sanitized as needed.
Make sure your software licenses are in order: Cloud environments may not align with application component licenses, so caution is a byword. Many software licenses assume a permanent host and may be locked to a particular MAC address. Licensed software sometimes requires that the component “phone home” for approval to run. And most software is licensed on a perpetual basis, not on a pay-as-you-go arrangement. It’s important that you examine all licensed software that is part of the application under development to ascertain that it may be run in a cloud environment, where variable numbers of copies of the software may be running at any given time, with each of the copies executing on a sporadic basis. If the application under consideration for cloud development has software components for which their licenses are incompatible with cloud operational characteristics, it is probably not a good candidate for this effort.
Plan for the complete application life cycle: applications iterate through a number of phases, so plan for this upfront. An application repeatedly moves through the development, QA, and production cycle; in fact, with today’s emphasis on agile development there are likely to be a high number of iterations through this cycle. The system cloning that is a characteristic of the virtualization that underlies clouds makes it so seductively easy to reproduce application versions that one can end up with application sprawl in a situation not unlike Mickey Mouse as the Sorcerer’s Apprentice, with similar outcomes. Therefore, it makes sense to consider using a cloud management tool to enable version control and release. There are tools like Skytap, Surgient, and VMLogix specifically focused on the dev/test use case; companies also use general purpose cloud management tools like enStratus or RightScale for dev/test purposes (disclosure: my firm has a partnership with RightScale).
Using the cloud for dev/test is an excellent first step in cloud computing. It obviates many of the concerns enterprises have about moving production systems into a cloud environment, while ameliorating many of the issues dev/test confronts in building applications within a production environment. As an added benefit, the pay-as-you-go cost structure of cloud computing helps stretch limited development budgets. Of course, any new environment poses challenges in terms of adapting existing tools, practices, and processes to an unfamiliar situation-but don’t let that stop you from experimenting with moving some dev/test efforts into the cloud.
Bernard Golden is CEO of consulting firm HyperStratus, which specializes in virtualization, cloud computing and related issues. He is also the author of “Virtualization for Dummies,” the best-selling book on virtualization to date.
Follow Bernard Golden on Twitter @bernardgolden.
