Integrating a Public Cloud option into your Enterprise environment is not unlike integrating a new datacenter. Lighting up a new datacenter requires certain components to be in place before services are available. For example; core services such as networking, interconnectivity and Active Directory and Role Based Access Control “RBAC” should be reviewed and configured. RBAC determines who is able to access the environment and what they are able to do. In our discussions with customers we call these Public Cloud Foundational services.
While this is a very simplified list, it can be complex. For example consider backup, DR and monitoring when building a Hybrid environment. Often we have very established ways of doing these things in the enterprise and ideally a single framework for management. Public Cloud Providers offer alternatives to these Enterprise solutions that are optimized and tightly integrated into the platform. For example: does it make sense to apply your same standard backup solution to workloads in the Cloud or should you consider the Public provider alternative?
Once the foundational services are in place, you are ready to consider the migration. Migration to Public Cloud is a little different than “Lifting and Shifting” a workload. In Enterprise virtualization environments, the infrastructure looks after the application resiliency. In Public Cloud the application architecture needs to manage resiliency and availability of the app. This means that each individual application is its own micro-architecture. While you may be able to lift and shift some workloads, others may need to be redesigned into the Public Cloud.
Failure to carefully consider the migration approach may lead to decreased availability of the application in the Cloud. For example, Azure has a Service Level Agreement of three 9’s (99.9 percent uptime) based on an Availability Set in Infrastructure as a Service “IaaS”. An Availability Set consists of two or more virtual workloads running on separate host hypervisors. When Microsoft patches the host hypervisors they guarantee that they will not reboot the virtual workloads at the same time to meet the SLA. If you are running on a single instance however you will experience outages.
The number of applications that will need re-architecting can have a dramatic impact on your migration timeframe. Understanding the percentage of applications that you have that are truly Cloud ready allows you to create two migration streams. One that moves quickly with the ideal Cloud candidates and the other that reviews whether the application should be replaced, re-architected or perhaps remain in the enterprise environment.
The key to success is in placing the applications in the environment that delivers the best business value. As the environment will be a hybrid of enterprise and public, it is more important to align them then it is to move them to cloud for the sake of moving them. Surprisingly, while obvious, many strategies often take an all or nothing approach. The “We are moving everything to Cloud” mantra should be “We are Cloud enabling our core business applications while maintaining others in the Enterprise”.
In the next post we will have a brief look at the operational and management considerations pre and post migration.