Dev/Test Cloud: A Good First Step
Often times, our clients don’t know how to approach the adoption of cloud-based capabilities and technologies. They’ve seen the writing on the wall and know that they need to get their company’s internal cloud running, but are afraid to take that risky first step. After all, as we have written on this blog, there is mass market consternation surrounding the cloud and the underlying technical capabilities that provide cloud enabled services.
We advise our clients to take measured first steps when deploying internal or external clouds. As Sheppard wrote here a few weeks ago, these initial steps can help to make the cloud concrete for both the IT department and the business. If your company is looking to develop an internal cloud, there is no better place to test the water than in a development or test environment.
By starting in the test and development environments, the team gets a sense for how the technology is deployed. A more integrated understanding of the enablers and constraints that exist within the environment are gained, and, more importantly, one can envision how constraints can be addressed and potentially overcome throughout various stages of deployment. You can move your experimental cloud infrastructure through development, test and production environments just as you would an application.
Taking this approach has several key advantages.
- Obviously starting with development environment limits your risk. If you’re new to internal or external clouds, the first few times you move workloads can be tricky. While disruptions to development or test environments aren’t desirable, they generally cause far less consternation than production disruptions.
- Creating a cloud environment for development and test shortens development lifecycles. Imagine how much more effective your developers would be if their server requests could be filled instantly instead of requiring the days or weeks that it takes today.
- We have found massive landfills in most companies’ development and test environments. Upwards of 30–40 percent of available infrastructure often sits completely idle. We all know there are dozens of reasons why this happens; a fickle business unit delays a project, a lazy developer fails to file the paperwork to release his servers, a vendor overstates the dev/test requirements for their product, etc…. With a cloud deployment, the idle resources from these projects can be shared with more active test and development efforts, greatly reducing the need for additional hardware.
If you have been contemplating adopting cloud technologies within your firm, then take a look at your current portfolio of projects and determine if you may have a project that would be a candidate for taking this approach.
Category: Cloud Computing
About the Author
Tom is a Delivery Leader and Chief Architect of Enterprise Systems Management with Adaptivity. Tom is responsible for driving transformational change for Adaptivity's clients that are embracing cloud technologies in order to transform the way in which their IT systems deliver increased business value and agility for their business. Tom brings over 18 years experience in defining strategic objectives and applying leadership skills to achieve dramatic, bottom-line results. Tom’s broad expertise spans IT operations, financial management, enterprise-level system architecture/design and LAN/WAN data/voice systems administration.View Author Profile










Hello Tom
the most telling part of the argument is the points you made in statement #2, namely 30-40% of the development equipment is idle on any given day.
this means arguing for a movement to cloud can be made in terms of a cost play, which has at least some chance of funding.