Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in /homepages/25/d403724996/htdocs/stormclouds/services/wp-content/themes/Divi/includes/builder/functions.php on line 4993
Plan Carefully and Automate the Migration | STORM Clouds Services

Best Practice

Plan Carefully and Automate the Migration
A typical migration project life cycle

A typical migration project life cycle

Application migration is the process of redeploying an application, typically on newer platforms and infrastructure. Comprehensive planning, driven by a disciplined migration process will contribute greatly to a successful redeployment of the applications to a new cloud environment. Successful initiatives have developed sophisticated, multi-phased migration methodologies to reduce implementation risk and speed up the migration process. The diagram on the right illustrates a typical migration project life cycle [[i]]

During the migration process the following technical considerations must be taken into account [[ii], [iii]]:

  • The creation of a detailed inventory of the current application portfolio really helps in terms of understanding the scope of a migration effort. This includes capturing information regarding the number of programs, scripts, and external interfaces involved. It also includes hardware and software configuration information, including operating system versions, database versions, features/functionalities in use, and similar information.
  • A security audit of the application and its data is vital. The cloud service’s security features may be very different from those of the in-house environment, and the security risks and the measures applied to counter them must be assessed carefully.
  • Temporary subsystems can be established to facilitate migrations.
  • Standardization and automation can help reduce the risk of migration errors. Virtual machine templates can be rapidly deployed and bring an environment online in a day. Automated data integrity and validation methods can be used to verify and validate data, databases and files during the initial synchronization.
  • The creation of migration tools, which ensure a high level of automation along with accuracy in migration can result in less time spent in migration and testing.

The STORM CLOUDS approach

STORM CLOUDS followed a multi-phase migration process, which included all the necessary steps that ensured the smooth deployment of the selected Smart City applications to the STORM CLOUDS Platform. The process started with the assessment of each application regarding its readiness for the new Cloud environment, its architecture and its functional and non-functional requirements. This analysis led to some necessary improvements in order the application to be optimised for the SCP. Afterward, the code and data deployed in the platform’s Application and Data Service Layers, respectively. The process was completed with the validation that the application was fully operational in the new Cloud environment.

The following diagram presents the STORM CLOUDS migration process.

The STORM CLOUDS migration process

The STORM CLOUDS migration process

The STORM CLOUDS migration process includes the following six steps:

Step 1 – Assessment of applications’ readiness for the Cloud

The 1st step aims to evaluate if the services are ready for the cloud environment. Aspects such as customization, regulatory compliance, complex service architectures and service maturity are carefully investigated, as they would negatively impact the cloudification process. A crucial aspect is the availability of both the application’s source code and documentation (installation manual, code dependencies, required software packages, etc.). Finally, the commitment of the application’s development and support team should be ensured.

Step 2 – Assessment of the already used hosting environment

The 2nd step aims to analyse the environment used to host the services. The analysis covers both the network (e.g. configuration, connectivity requirements from the municipality premises to the cloud environment, and supplementary services such as SMTP, DNS and WWW) and architecture (e.g. use of resources, underlining technologies, licenses, and security mechanisms) of the service.

Step 3 – Analysis of functional and non-functional requirements

The 3rd step aims to define the technical characteristics of the Virtual Machines that will host the applications on the new Cloud Environment. The analysis of the functional requirements covers technical details (e.g. Operating System, Scripting Language, Database, Web/Application Server, Data Formats, Frameworks/Libraries and External Services used), interoperability issues, and static characteristics such as hard-coded IP address and directory paths. Furthermore, the analysis of the non-functional requirements addresses issues related to the proper functioning of the application such as security, regulatory compliance, performance, availability, backup; privacy, reusability, and interoperability. An estimation of the use of resources regarding RAM, Disk Space, CPUs, Bandwidth, Hits/Month, Registered Users, Max On-line Users, and Average On-line Users contributes to the calculation of the expected workload per application. An important characteristic that should be examined in this step is if the application’s design supports its deployment in multiple servers. In that case, the application will take full advantage of the performance benefits that cloud offers.

Step 4 – Optimisation for the Cloud Environment

The 4th step aims to solve the problems identified in the previous step, so the application to be ready for deployment in the new environment. Moreover, it includes modifications that enable the application to support natively the most prominent Cloud characteristics (e.g. high-availability and scalability). The latter is closely related to the available budget or the internal IT capabilities.

Step 5 – Deployment

The 5th step aims to transfer the ready to be cloudified applications to the new Cloud environment. The deployment process includes the following actions:

  1. setup of the cloud environment that will host the selected services;
  2. launch the VM instances that will host the applications and their data (e.g. database and file sharing modules).
  3. migrated both the applications and their data to the Cloud environment

Step 6 – Validation

The final step aims not only to ensure that the deployed applications are operational but especially that they meet the initial set of requirements regarding cloudification. The validation is made in collaboration with the municipalities and includes functional tests ensuring that the deployed application performs as designed.

Automation

The cloud encourages automation because the infrastructure is programmable. To ensure a high level of automation along with accuracy in the migration of the applications to the cloud, a set of tools and procedures have been designed and developed. The automatic deployment is implemented using Heat, the OpenStack “orchestration engine to launch multiple composite cloud applications based on templates in the form of text files that can be treated like code” [[iv]]. The aim of orchestration is to create a human -and machine- accessible service for managing the entire lifecycle of infrastructure and applications within the SCP Cloud environment.

The 1st step in the automation process is to prepare the bash shell scripts that will configure the VM hosting the application, and install and configure the application and its dependencies.

The 2nd step is to create the Heat scripts (Heat Templates) that describe the infrastructure (servers, floating IPs, security groups, ports) of the cloud applications and to integrate with them the application’s installation and configuration scripts made at the previous step.

The available Heat Templates allow interested cities to automatically deploy the selected applications from the cloud-based service portfolio, as well as the municipalities to re-deploy their services in another instance of STORM CLOUDS Platform.

References

[i] Laszewski T, Nauduri P, 2012, Migrating to the cloud: Oracle client/server modernization, Syngress, Elsevier Inc.

[ii] Best Practices for Federal Agency Adoption of Commercial Cloud Solutions, 2015, Professional Services Council, viewed November 6, 2015 <https://goo.gl/j5NbfF>

[iii] Migrating Applications to Public Cloud Services: Roadmap for Success, 2013, Cloud Standards Customer Council, viewed November 5, 2015 <http://goo.gl/EGHN8l>

[iv] OpenStack Wiki – Heat, viewed November 7, 2015 <https://wiki.openstack.org/wiki/Heat>