Adapt Environment Management to Cloud Deployments with Plutora
Despite the prevalence of public and private clouds in the enterprise, most IT departments still adhere to operational models designed for physical infrastructure and servers that involve complex environment setup processes. As a result, organizations miss opportunities to take advantage of dynamic cloud-based deployments for non-production environments.
There are a number of reasons why it is often too difficult for enterprises to stand up a non-production environment for testing or staging. Databases have to be provisioned, application servers need to be configured, and a testing environment for a complex system can take weeks or months to properly certify as ready for use. This involves a lot of coordination and effort to setup environments. Organizations typically simplify setup by treating environments as permanent because they lack a tool like Plutora to help them keep track of environment management efforts.
Cloud vs. Colo: What's the Difference?
Before the advent of cloud computing systems such as OpenStack and EC2, we had Colocation Centers. Companies rented physical space and installed servers in data centers. For example, in 2001 I remember shipping expensive physical infrastructure to colo facilities. Applications were installed on these physical assets directly, and in 2001, if you needed a new testing environment you would order more physical servers and send them to your data center. Colos were all CapEx; your environments were your physical servers.
Fast-forward 14 years and most large enterprises are either using or planning to use a private cloud such as OpenStack. Many of these companies are still renting space in colo facilities. They still have dedicated data centers to run private clouds, but there's now an opportunity to model environment capacity as a dynamic function. If you need a new environment you don't need to purchase more servers. You just provision more cores on-the-fly to adapt to changing demand.
This is the vision of cloud computing - the ability to react to demand as needed. Unfortunately, this vision runs into an obstacle - most organizations don't plan for dynamic environments because they are too difficult to manage and model.
So, what happens? A company invests millions in standing up internal clouds only to have application teams fire up static environments that run for years. In other words, your application teams use your cloud like an old colo because they haven't adapted to the cloud. They don't take advantage of the dynamic capabilities of cloud computing because it takes too much effort to "hydrate" an environment.
Infrastructure Isn't the Problem: It's the Applications
Application setup time is prohibitive and the challenge isn't purely technical. When a large e-commerce site needs to setup an end-to-end testing environment, this might require ten departments to coordinate the efforts of over fifty people on infrastructure, database, and application configuration efforts. This work may involve an end-to-end architecture, including everything from the website to transaction databases that fuel orders. Instead of accounting for this setup time, many organizations just write this off as lost time.
In a static environment, this setup process happens so infrequently it isn't even tracked and this is the root of the problem. If you only have to setup your QA and staging environments once every two years why bother optimizing this process? (Hint: In the cloud it should happen more frequently.)
There is a better way to address setup complexity. Start using Plutora to orchestrate the hundreds of steps necessary for standing up an environment. Use the tools we've designed to properly account for the time and effort it takes to get an environment ready for use. Once you've done this and identified the necessary effort, you can use Plutora to factor environment setup time into your release schedules.
Use Plutora to Track Environments: Take Advantage of the Cloud
You have two sides to the environment setup problem. On one side you have the requirement for many application teams to maintain multiple environments for parallel development tracks. On the other side you have the effort involved in setting up and tearing down complex end-to-end testing environments. What can be done?
First, no amount of planning is going to do away with the requirement for QA and staging environments, but properly planning when capacity is needed can help you identify opportunities for environment sharing and reuse. Even though your teams may require multiple staging and QA systems, a tool like Plutora can help you establish schedules for these systems so that you can effectively scale up or scale down cloud-based resources for environments as they are needed.
Planning and tracking tasks involved in environment setup can also help you identify potential areas for automation that will reduce the time required to stand up and tear down testing environments.
Times Have Changed, So Should Your Approach to Environment Management...
In the more static situation of 2001 where you provisioned physical servers and mapped them to non-production environments, it didn't make sense to optimize environment setup and tear down because it was impractical to automate across the full architecture.
In 2015, it only takes a few minutes to spin up hundreds of virtual machines on a private cloud. Your organization needs to use a solution like Plutora to start capturing and optimizing the environment setup process so that you can take full advantage of the cloud. When you install OpenStack or start using Amazon EC2, you should adopt Plutora to help you manage your environments.