The applications that have been selected to be migrated to the Cloud may require significant changes to take full advantage of Cloud’ characteristics such as high availability and scalability. In particular, as application instances are ephemeral and can be started, stopped or fail at any time, they must be stateless and share nothing. All persistent data must go to external services (e.g. databases, file storage, message queues, caches). Applications should be re-architected in order to take full advantage of the Cloud’s features [[i]].
Traditional vs Cloud Aligned Application Architectures (Source: New Relic)
Moving an application to the cloud will require some work under the hood. However, choosing to re-architect an application is ideal when: [[ii]]
- Hardware cost is substantial. Re-architecting an application for the cloud means access to world-class hardware without needing a world-class budget. Companies are able to pay as they go and avoid the investment required for more hardware.
- IT staffing levels are low. Moving to the cloud automates a lot of the server and application management, as well as maintenance tasks that would otherwise be performed by in-house IT staff.
- Geolocation is a requirement. The cost to do geolocation on the cloud is miniscule since many data centres are located in central regions.
- The application needs to scale for predicted, but infrequent, uptime. The cloud allows systems that have occasional spikes, such as an e-commerce application that sees a lot of activity on Black Friday, to quickly and easily scale servers on demand without an expensive hardware investment or footprint.
Determining the right migration strategy for an application depends on its level of cloud alignment, cloud readiness, potential benefits achieved from migrating, and risks. There are several application migration common methods and approaches, which should consider the Public Authorities for their existing applications [[i]].
Application Migration Common Methods and Approaches ((Source: New Relic)
Depending on the changes the candidate applications reach different Cloud maturity levels. The characteristics of each level are presented in the following table: [[i]]
| Maturity Level | Characteristics |
| Cloud Washed |
|
| Cloud Adopted |
|
| Cloud Optimized |
|
| Cloud Native |
|
The STORM CLOUDS approach
The STORM CLOUDS platform supports two different architectures; a “scale-up” architecture for applications with traditional architectures (Figure 1) and a “scale-out” architecture for applications with Cloud-aligned architectures (Figure 2).
Figure 1 – SCP “Scale-up” Architecture for traditional applications
Figure 2 – SCP “Scale-out” Architecture for Cloud-ready applications
The “scale-up” architecture is the one where the application can benefit from more resources, such as CPU and memory, being added to a single server or node. In contrast, the “scale-out” architecture is the one where an application scales by additional nodes being made available for the workload; that is, it scales horizontally.
Scale-out applications can take advantage of the pay-by-usage cost model of the cloud. When there are increased requests for an application, more nodes can be deployed to handle the increased load. When the requests slow down, the additional nodes can be powered off to reduce costs.
Although virtualisation technologies have started to support the dynamic scale-up and scale-down of a single VM’s resources (memory, CPU and disk space), this action requires, at the moment, the use of custom scripts. On the contrary, the systems that support the scale-out architectures provide native support to the dynamic increase of resources.
References
[i] New Relic, 2015, Cloud Migration Cookbook: A Guide to Moving Your Apps to the Cloud, viewed June 15, 2016, <https://goo.gl/DYAqX5>
[ii] Headspring, 2014, Migrating to the Cloud: Re-Platforming Legacy Enterprise Applications, Best Practices Guide, viewed June 15, 2016 <https://goo.gl/shTHBi>