The Virtualization Practice will be moving from our internal virtual environment and cloud configuration to an external hosted cloud configuration, at least temporarily. However, what we have found is that not all clouds are alike (we all knew that), and that some of our processes were not cloud friendly but what does it mean for moving to the cloud? How do we manage our change to these processes as we move to the cloud?
When moving to the cloud, you have two options today: Software as a Service (SaaS) or some form of Infrastructure as a Service (IaaS). Each have their appeal however to move to SaaS, the applications you want to move must exist in the cloud, if they do not then you either need to create them using a Platform as a Service (PaaS) such as CloudFoundry or go the IaaS option, which is the default for many cases. Given that we want to move our DMZ set of VMs, or customer facing workloads, we could use either SaaS or IaaS options as Mail and Web services exist as SaaS instances in many cloud frameworks. But we cannot just look at what is available, we also need to consider our current management techniques, security and compliance requirements, code we have written, and any other options that impact our use of SaaS. In other words, there is quite a bit of change involved with moving to the cloud.
Change
No one likes change, but when we are moving to the cloud we have to embrace change. It is a conundrum. We should manage this change just like we would manage moving to the cloud. It at least should be part of any plan for movement to the cloud. The environment will change in at least the following ways:
- Governance mechanisms will change
- Security mechanisms will change
- Compliance mechanisms will change
- Management mechanisms will change
- Application deployment will change
- Patching mechanisms will change
The list is fairly endless. Perhaps the bit issue is that when we are moving to the cloud we throw on top of that movement a huge amount of change. This could be the downfall of any migration, cause a large amount of uncertainty, increase fear of the unknown, etc. In other words, the change becomes to great to fathom.
Moving to the Cloud: Change Slowly
The goal with moving to the cloud is to get your workloads into the cloud, but that does not mean jumping in with both feet first. Instead we should consider staging in the necessary changes to complete any moving to the cloud project. Such changes could include:
- Switch to governance methods that are cloud friendly, do not change the way we look at the data
- Switch to security mechanisms supported by a cloud
- Switch to compliance mechanisms supported by a cloud
- Switch to management mechanisms supported within a cloud
- Change our application deployment as if we were deploying into a cloud
- Change our patching mechanism as if we were patching within the cloud
In other words, do all the leg work up front on process so that we have a well defined set of guidelines for managing our cloud environment even if the environment is not yet in a cloud. This will take documentation, understanding of cloud strategies, and techniques available within the cloud. Once you have all this in place, then moving to the cloud will become much easier. You may even want to stage into your datacenter your own cloud, and then branch from that cloud to a public or hosted private cloud using a hybrid cloud approach.
Moving to the Cloud can be successful if there is a lot of planning to manage the change in how we do things, how we see things, even the way we think about things.