Your options for having a software development lab in the cloud are increasing. Here’s how to get your dev lab there.
If you're ready to move your lab to the cloud, start by transitioning some applications or services there. Public cloud lab services are easy and cheap to try out. You can customize the networking, hardware, and storage properties of the public cloud lab to match your in-house test labs, and you can easily scale these configurations to hundreds of concurrent machines that represent thousands of users. Each configuration is completely isolated, so you can run multiple environments concurrently without impacting other users.
Since most software applications are deployed in a multitier model--database, application, and Web tiers--reproducing complex bugs and resolving them quickly is a huge challenge in any cloud lab, public or private. Development and test teams often establish multiple test labs with identical environments to do this, but multiple test labs are costly to set up, underutilized, and time consuming to manage.
One way to make this task easier is to use standardized development and test environment templates like the one provided by Skytap Cloud, which lets developers quickly provision new environments. With templates, developers can perform destructive tests, whereby they change database settings, application settings, and router policies; see how the application behaves; and then return to the baseline setup by redeploying the source template. Because each configuration is encapsulated, you can install tools, test application behavior, and restore the clean version. An entire virtual data center with all of its machines, data, memory state, network settings, and application state can be retained within a template. As you move through the development life cycle, you can preserve points where you encounter problems. Templates can be shared with remote teams for rapid bug reproduction and resolution.
Three Areas To Assess
While it's exciting to jump right into a cloud lab, pay attention to three underlying elements:
>> Standardize. The more standardized your existing lab is, the easier it will be to move it into the cloud. If your lab is highly customized and uses a number of different platforms and application stacks, moving it into a cloud may not get you much. Standardization enables widespread adoption of cloud resources within your company, without which you'll be unlikely to see cost savings.
When you launch new software development projects, take a firm stand on standardization. If you can't standardize across the enterprise on development and test systems, you won't have enough scale to capitalize on the cost savings a private cloud offers, and it will take a lot of effort to set up all the distinct environments you need in the public cloud.
>> Get the process right. It's easy to stand up resources in a virtual environment, but who turns them off? The easier it is for users to request services from the cloud, the more complex the back-end process needs to be to monitor and decommission them when they're no longer in use. This is especially true if the meter is running in a public cloud.
From the service request to provisioning and managing the lab, you must have established processes if you're going to automate the tasks involved and achieve the benefits of rapid, on-demand provisioning and scale. Problem- and error-control processes that detect, log, categorize, investigate, document, and repair problems as they occur are particularly important. Having an integrated change management process, including a change advisory board that will keep stakeholders aware of lab changes and extend production changes to the lab, also is vital.
The best server provisioning, orchestration, and management tools won't compensate for a lack of process. When you shift those tools to the cloud, they won't get you the cost savings you're looking for and may mask some of the problems the lack of a good process is causing.
>> Establish governance. In both a public and a private cloud lab, you must have asset management, provisioning, and configuration management tools to monitor and track virtual resources and report on key indicators. The ability to manage lab capacity is just as important in the cloud as in conventional on-premises labs, but you'll need different tools and processes. Unfortunately, available management tools are aimed at virtualized production data centers and aren't that useful for a cloud lab. They often lack the automation controls that will help companies realize the cost savings they're seeking in the cloud lab. Vendors like VMware, Hewlett-Packard, and IBM have or plan to have tools that can help; custom tools are also an option.
You'll also need a versioning control tool to keep everyone on the development team focused on the same baseline version of the product they're working on and ensure that edits are being done on the correct build. Concurrent Versions System provides this functionality, and many other tools can be tailored. IBM, Spectrum, and other vendors have SCM tools that provide version control and other support in a virtualized lab environment.
The bottom line when you deploy your cloud lab is to continually monitor costs and keep re-evaluating your TCO model. Public cloud labs can be lifesavers for companies that need to set up and scale fast. For others, security, control, portability, and integration issues will push them to private cloud labs. Know the business case before you make a move and continue to evaluate whether the cloud lab you choose is living up to expectations.
SaaS As Innovation Driver?Software as a service is the clear No. 1 way enterprises consume cloud. InformationWeek's SaaS Innovation Survey reveals three tips to get the most from SaaS: Make it a popularity contest. Have an escape plan. And remember that identity is the new perimeter.
InformationWeek Tech Digest August 03, 2015The networking industry agrees that software-defined networking is the way of the future. So where are all the deployments? We take a look at where SDN is being deployed and what's getting in the way of deployments.