Applications come in all shapes and sizes, often with an interesting pedigree influenced by numerous factors over their lifecycle. This can make for interesting challenges when migrating those applications to a cloud platform. In this article we'll dig into strategies for both establishing clear and measurable cloud migration goals and assessing the architectural state of applications to be migrated.
First, let's set some clear and measurable goals to achieve as a result of migrating to the cloud. The table below lists some potential cloud migration goals; as every situation is different you will need to adjust & prioritize these according to your needs.
|Cloud Migration Goal (KPI)||Target|
|Engineered Availability / SLA||99.xx%|
|Delivery Cost (infrastructure)||reduce by xx%|
|Delivery Cost (operations - labor)||reduce by xx%|
|Time to market||
reduce by xx%
increase frequency of updates
|Security Compliance||Reduce non-compliance items by xx%|
...there are many additional goals that could be listed here; in my experience, these are the "cornerstone" items that shape the overall solution (better, faster, AND cheaper!).
Now comes the fun part - assessing the current architecture of an application to identify challenges in achieving the stated goals. For clarity on the scope of application architecture used here we take a holistic perspective, including everything involved in delivering the product - data centers, networks, systems/servers/storage, software - and people & processes. While we want to understand the entire breadth of the application, we'll be selective on the depth - we're less interested in the current state of some areas (for example, network and storage) as they'll be subsumed by cloud infrastructure.
We're keenly interested in looking at areas that directly align to our cloud migration goals; questions to be answered:
- What is the overall transaction flow of the solution? Integration points, clients, connectivity, etc;
- How 'large' is the solution? Number of servers? Amount of storage? Bandwidth use?
- Does the current architecture use redundant components - database servers, load balancers, etc?
- What is the state management model for the application? Stateless (or shared state)?
- What is the scalability model for the application?
- How are users / customers / tenants added? How frequently?
- How does the application scale in various dimensions - more users, higher transaction volume, shifts in usage patterns?
- What are the usage patterns for the application - hours of operation, etc?
- What are existing service levels or related contractual obligations, including penalties?
- What is the Software Development Lifecycle (SDLC)? How frequently are updates released? How is the development workflow managed? Is there a Continuous Integration pipeline in place?
Some finer points to consider:
- Are there disparate usage patterns on database servers? For example, are large (possibly infrequently accessed) BLOBs stored alongside relational data?
- If the application is not currently load balanced there may be challenges in doing so - explore the state management model (how are sessions stored, caching of data, etc);
- If the technical footprint is large (# of servers), will the architecture support auto-scaling, which allows scalability under load and cost-savings in off-peak times;
Having performed this analysis on many applications, I can't underscore enough the importance of:
- a) establishing clear goals to provide structure to the work plan;
- b) taking a holistic approach to assessing the current state of application architecture;
- c) planning for development work to align applications with stated goals;
The architecture, design and implementation of the application software is often the limiting factor in achieving your cloud migration goals.
I hope this has provided a solid high-level overview of cloud migration considerations; in subsequent posts will incorporate your feedback as we dive into strategies for (incrementally) re-architecting applications to make better use of cloud reliability, elasticity and cost containment capabilities.