For the past couple of years, BridgePhase has been involved in multiple projects in which cloud computing technology is leveraged. In this series of blogs, we will provide insight gained from real world experiences for various types of “cloud” projects, including implementations of the following common cloud delivery mechanism: Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS). Our first insight will discuss important factors to consider when performing an IaaS migration.
In the early stages of the projects, you must evaluate the available hosting (cloud) providers in order to make an informed decision considering important factors such as service offerings, cost models, performance, security impacts, and organizational impacts. Once a cloud provider is selected, you must design your software architecture based on specific architecture components and restrictions of your cloud provider. In this stage, you’ll need to perform a thorough analysis of the cloud provider’s service offerings and tenant requirements (e.g. required security settings, pre-requisite operating systems requirement, etc.), document all gaps between your current technical environment and customer requirements and what is required and available in the cloud provider, and plan for how to address each gap. Your design should include technical aspects such as sizing of application and database servers, technical architecture of the applications, high availability strategy, load balancing, SAN allocation, active directory, and network integration. Furthermore, your design should contain the architecture and processes for how operational support components (e.g. backup and restores) will be performed in the cloud.
Early planning of a deployment strategy is also critical. It is important to involve project stakeholders in this process so they understand the high level approach, as many misconceptions can occur in this area. This includes the plan to build target environments in the cloud, testing the technical components of the architecture (e.g. high availability testing, performance stress testing), and planning for how the cutover will be performed. It is likely that, to minimize the downtime, cutover must occur in 1 weekend window, so it’s crucial that your plan accounts for factors such as network latency between existing and target “cloud” (for data transfer) and identifying critical external dependencies that impact your cutover.
Once design is complete, review all components of your design as well as the general approach for deployment and cutover with all stakeholders, including representatives from the cloud provider. The cloud provider should begin to provision the servers necessary to begin build activities. The application support team (e.g. application, database and web server experts) will need to work closely with infrastructure resources to build and test the new architecture in the cloud. Infrastructure engineers should ensure the storage is implemented in a manner which maximizes performance of the applications running on it while ensuring that storage is allocated appropriately across volumes. All project stakeholders should be kept informed of progress throughout the build process, as well as ongoing risks and issues.
Ideally, deployment and cutover occur over a single weekend, where an outage of the current “as-is” environment is coordinated and scheduled. Although no application functionally should change with a pure infrastructure migration, it is crucial that even the most minor end user impacts (e.g. URL changes) are planned and accounted for. This can be addressed through coordinated communications and working with Tier 1 help desk personnel to ensure full awareness of the change.
Comments are closed.