DevOps, Hybrid Cloud & Sandboxes

DevOps and hybrid clouds are quickly becoming mainstream. By next year, nearly 25% of the Global 2000 IT organizations will adopt DevOps methodologies for bringing applications into production IT, according to Gartner. In addition, 56% of workloads will be in private or hybrid cloud environments within the next two years, based on the 451 Research Customer Insight, Voice of the Enterprise Cloud, Q4-2014 survey.

Given such acceptance, how can developers build and test applications using best practices for DevOps and continuous deployment into production IT when it is also a hybrid cloud environment?

This challenge is driving the adoption of a number of technologies, including containers, DevOps tools, and sandboxes. Think of these technologies as addressing the “what,” “how" and “where” parts of the challenge.

Containers (the “what”) -- Putting your applications into containers allows them to look uniform as they cross between non-production and production environments, and between on premise and cloud.  

DevOps Tools (the “how”) -- Using DevOps tools that automate the steps from programming to testing to production deployment is designed to address the “how” part of the challenge. 

Sandboxes (the “ where”) -- Sandboxes address the real question of “where” do I develop my application, so that the environment and infrastructure that it runs on look the same from the development lab to the test lab to the production data center or cloud.

Sandboxes are self-contained infrastructure environments that can be configured to look exactly like the final target deployment environment, but created and run anywhere. For example, developers can create a sandbox that looks like the production environment,  from network and hardware to OS versions and software to cloud APIs. They do their development in that sandbox for a short period of time and when they are done, they tear down the sandbox. 

Testers can do the same thing, and in addition, they can run a bunch of tests with the sandbox configured to look like their internal IT environment and then automatically reconfigure the sandbox on the fly to look like the external cloud environment and run more tests. This approach allows testers to test all of the possible environments that the application could run in, without disrupting the actual production infrastructure.

We know that a child’s sandbox is a protected space where you have complete control and others are allowed in only if you invite them. You can bring in your own toys to the sandbox and make anything you want in the sand. If you don’t like it, just stomp it out and start over. 

Technically, IT sandboxes follow these same rules.  Sandboxes also provide reservations and scheduling times for many people so that whole teams of developers and/or testers can share physical and virtual infrastructure on-the-fly for hours, days or weeks at a time. Finally, a good sandbox solution can be triggered from the outside, for example, from a DevOps tool.  

In the world of hybrid clouds, applications need to be deployable on both on- premise infrastructure and public cloud infrastructure. Sandboxes allow developers to mimic both environments and define applications that can run successfully in both types of infrastructure. The sandbox can also be used to test in both types of infrastructure.  

Of course, in a perfect world, containers, DevOps tools and sandboxes can be combined to enable continuous deployment in a hybrid cloud. Package your applications in containers, use DevOps tools to manage and automate the process of moving through the development cycle, and create sandboxes for each step in the development cycle that mimics the actual target production infrastructure on which those applications need to run.