A Hybrid environment offers fertile ground for a lot of different scenarios, and in this post I’ll examine the value of the Hybrid Cloud in the dev/test phase of any project.
One of the reasons that a Hybrid Cloud is such a successful place to do your dev/test can be boiled down to two key points: Cost and Speed .
The historical limitations of a non-Hybrid dev/test environment are familiar to all of us. First, there’s the constant time spent doing the same mundane tasks (setting up and running labs) and the time sunk into these routine tasks do not provide any differentiated value. Second, we all know that there is a lot more to labs than just the hardware; it is never fast, easy, or cheap to spin up and then break down the labs you need – especially at scale. Third, building these labs can sometimes require more work than the element you’re trying to test. For example, how often have your best devs spent hours trying to figure out how or where to get the corporate standard Oracle image to build against rather than building awesome new features? And finally, if you have multiple teams requiring the same capabilities and scale (but in separate sandbox environments) you are going to need a single, powerful central repository for your reference images, as well as a very easy way to replicate them into each sandbox.
If that long paragraph tells us anything, it’s that the way dev/test has been done in the past simply isn’t good enough. But that’s not to say there still aren’t plenty of people trying to do this without a Hybrid Cloud.
If you’re doing all of your dev/test in a public cloud environment, you may have already encountered a few issues, e.g. if you’re building and testing apps that are ultimately going to run on-prem in production, how are you going to manage your continuous integration efficiently? Another concern is the issue of portability – it can be very difficult to easily ensure that the images you’re developing against are the same as what you’ll be using later in your own datacenter. There is also the issue of juggling the different deployment, monitoring, or management tools in each environment. This kind of disconnection can seriously impact the servicing of your apps.
On the other side of the spectrum, doing all your dev/test within a private cloud is also fraught with some real challenges. The foremost concern (as noted at the top of this post) is cost. It is really expensive to own and maintain enough hardware to provide sandboxes for the many unique apps and environments you’ll need. Worst of all, all that hardware will spend a lot of time underutilized due to the unpredictability of demand as you move through different phases of a project. The infrastructure costs can further be compounded by the inefficiencies that occur within your organization when you run into issues like the inability to collaborate with other developers outside your organization because it’s difficult or impossible to safely give them access to your environments in a timely manner. With on-prem environments it can even be difficult for distributed teams to work together (or to work remotely) if that internal environment is in your existing network and requires traditional remote access approaches to access.
With all of that in mind, consider for a moment a few of the advantages of doing dev/test in a Hybrid environment that leverages the public cloud scale of Azure:
The Hybrid Cloud helps customers take advantage of Windows Azure’s scale, elasticity, and per-minute billing to provide more agile and cost effective dev/test labs. This allows you to design a lab solution that lets you balance developer self-service and productivity with standardization and operational control. Microsoft Services can help design the right Windows Azure topology to meet your needs, and we provide a library of lab automation code that makes it fast and efficient to build and operate complex lab environments in the cloud.
Leveraging Azure for your dev/test environment adds flexibility, making your development more agile, while running on new hardware, and there is bottomless availability of dev/test boxes.
Eliminate cap-ex expense and build test environments in Azure that can limitlessly scale. In a Hybrid environment you can stand up complete environments on demand in Azure and then turn them off when you’re done – while only paying for what you need. This means IT can focus on providing the right foundation, and it allows developers to have a self-service experience across clouds.
Use Existing Tools
Continue using the development languages , tools and lifecycle technologies you are using today. Use a common set of identity, management, and deployment technologies across Windows Azure and your private cloud
Build bigger test environments in Azure that simulate real customer load including spikes without resource contention on the cloud’s bottomless resources.
Leave Production Alone
Prevent dev/test apps from affecting on-prem production performance by placing that load in your public Azure cloud.
Access Existing Resources
Securely network from your public Azure cloud to on-prem to test against systems of record.
Deploy Anywhere with No Lock-in
In a Microsoft Hybrid Cloud, your apps and data can move in a friction-free way from one cloud to another. This means dev/test can happen in the public cloud and then move back on-prem for operation – or vice versa.
In a Hybrid environment, developers and IT Pros can quickly build an efficient development and test capability on Windows Azure and combine this with the built in efficiencies that come from leveraging Microsoft Services’ automation library. The automaton library is built in PowerShell against the public Windows Azure Service Management API, so it’s supportable and extendable for future needs.
All of these developer-centric benefits came directly from our regular interactions with – and feedback from – the IT Pros who live and breathe these scenarios and dev/test environments.
One of the things we’ve been told over and over is that, across industries, IT Pros struggle to deploy and manage labs. Recently we were working closely with a major bank that employs thousands of developers and testers. This bank had used a virtualized dev and test environment within their own datacenters for several years but they lacked the self-service and automation capabilities of a Hybrid Cloud. This meant that their developers often had to wait 2+ weeks to have a lab environment set up. The result was pretty predictable: Every project fell behind, the developers often requested far more capacity than they really needed to make up for lost time, and the datacenter’s capacity problems got even worse.
The solution was a Hybrid Cloud. With a Hybrid Cloud in place, the bank moved much of its lab environments into Windows Azure, and the delivery of these environments was immediately faster and well within the controls and workflows that IT developed to align with their regulatory compliance needs. Now that this Hybrid environment is in place, the developers are more productive and can easily collaborate with external teams all over the world to build better apps faster .
When you look at this inventory of benefits, it makes the Hybrid Cloud an incredibly compelling and business-savvy option. There are, of course, other options in the market that emphasize public or private cloud-based scenarios for dev/test. What these other options lack, aside from the benefits bulleted above, is the consistent and regularly updated catalog of services for developing in any environment. A Microsoft Hybrid Cloud environment allows you to move your apps and data between clouds, and this ease of deployment is matched by the seamless use of the tools you use to build: Seamless integration with Visual Studio across all Microsoft clouds – with even more integrations on the way.
If these advantages are things your organization needs, or if they represent tactics to solve ongoing problems, I recommend getting in touch to really explore your options.
Any good discussion about the business value of the Hybrid Cloud deserves a look at the technology which makes it so effective in this scenario:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.