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
Re-Architecting Applications for the Cloud | STORM Clouds Services

Best Practice

Re-Architecting Applications for the Cloud

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
  • Force fit to run in cloud environment
  • Resources not optimized – no horizontal scaling
  • Minimal modification done to be cloud compliant
Cloud Adopted
  • Resources not optimize – no automatic elasticity-instance manually started
  • Some modification done to be cloud compliant
Cloud Optimized
  • Resources being optimized – horizontal scaling possible
  • Elastic on instance level – cloud management layer determines when to start/stop additional instances
  • Major modification done to be cloud compliant
Cloud Native
  • Fully cloud aware – can communicate with the cloud management layer to start-up or shutdown instances of itself
  • Designed for failure and self-healing
  • Elastic and resource efficient

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>