Leverage Cloud Computing to Accelerate Development and Test

Editor's Notes

• #4: Cloud Computing is often described as new and emerging technology. Truth be told, Cloud Computing is not about technology at all. It is first and foremost a business model and a user experience. Cloud computing user experience delivers self-service that lightens the load on the IT personnel while providing line of business users with capabilities they need. It delivers IT resources as a service rather than a collection of hardware components.
• #7: While the analysts are unanimous in their predictions of the bright future for cloud computing, it is always best to gauge this enthusiasm against real life experiences. This graph depicts real usage growth as reported by our partner RightScale.com. They saw a 1000% increase in usage. We also observed similar accelerated usage of DB2 on the Amazon EC2 cloud. During the period of July 2009 to July 2010 we observed 800% increase in the paid usage of DB2 on the Amazon EC2 cloud.
• #10: Here are some specific dev and test challenges we’ve heard from our prospects and customers – and they were surprisingly consistent across industry and co size. Rarely are there enough resources available for experimentation and testing, and equipment is shared and must be configured and re-configured each time a new project or task starts. In many companies it takes as long as 3-5 weeks to procure and provision new equipment, so development organizations must plan ahead or risk delaying projects. Maintaining consistent environments is another persistent challenge. As code moves through development, test, staging and production, configuration changes rarely make it back into earlier stages. If software is to be run in multiple production environments, then each environment needs to be configured and tested. And to troubleshoot problems found in production requires reproducing past environments – easier said than done. Whether the task falls to development, QA or operations, maintaining and reproducing environments is time-consuming and error-prone. Finally, distributed teams just exacerbate the other challenges. Limited resources – In almost every phase, limited hardware poses problems. In architecting new systems there are rarely enough resources to experiment with alternative architectures or new technologies. For developers, limited resources usually means sharing hardware for testing. Testers rarely have enough hardware or time to do all the testing they would like to do - full performance and load testing, testing on complete production architectures, or testing disaster recovery scenarios. And, delays in development often puts pressure on testers to do their work faster to still reach the same deadline. The inability to spin-up additional testing resources at these times causes quality to suffer. The result is that errors are found later in the cycle where they are more expensive to fix. Limited equipment also means staff are constantly provisioning, tearing down, and re-provisioning the same equipment. It takes time, and if environments are not completely wiped clean, additional errors are potentially introduced. Time to procure and provision equipment - As the load on IT departments increases and the release cycles shorten, the wait for equipment to be procured and provisioned takes time away from valuable work. One customer stated it took 3-5 weeks to procure and provision new hardware. Maintaining consistent environments – As code moves through development, test, staging and production, changes to configurations in one stage rarely make it back into earlier stages. As new code is implemented from environments that haven’t been updated, the same errors are re-introduced. Maintaining multiple environments – As if maintaining one consistent environment across many servers isn’t hard enough, most software requires testing on several different types of configurations – different versions of stacks, for different end user environments – one for each possible production scenario. For example, a software company may need to test their software on different operating systems or alongside various software packages. Most companies need to clone production environments to debug problems without impacting the current users.Whether it happens in development or QA - maintaining & reproducing environments is a time consuming task. If the task is distributed across multiple administrators, the coordination of changes made becomes challenging. If the task is consolidated under one administrator, there is a limit to the number of different environments s/he can reliably maintain.Distributed teams or team members – add collaboration requirements and exacerbate all of the issues mentioned.
• #21: There are several usecases for leveraging cloud computing for development and test. We see using the cloud for build and test for applications destined for n-premises deployment as the most popular such usecase.
• #27: We leverage the cloud to reduce your time and effort required to evaluate the early code for the DB2 Galileo. By using the early experience program on the cloud, you avoid the time and effort required to get the hardware, install and patch the OS, install and configure DB2. Most important, you will not have to update or refresh the code every time we deliver a new build (about once a month). You will always be running the latest stable code and will not be dealing with issues that may have already been addressed.