Cloud Migration: Application Delivery Assessment

In a previous post we stated that the architecture, design & implementation of given application is a key factor in achieving cloud migration goals. Each application has it's own personality, influenced by various factors over time: business goals, available budget, available skillset, geopolitical factors (RFPs, statutory & contractual compliance, etc.), etc.

Enterprise with large application portfolios may not have visibility into the full breadth and depth of application delivery attributes. This can lead to the mis-perception that a cloud migration will improve the reliability, security, performance, cost of these applications, when that (alone) may not be the case. In order to ensure a predictable & successful cloud migration we present a comprehensive, detailed Application Delivery Assessment methodology; a "no dark corners" approach.

The methodology consists of three primary work streams:

  1. Establish a reference architecture & best practices;
  2. Assess current application against reference architecture & best practices;
  3. Summarize & plan for remediation

Establish Reference Architecture & Best Practices

Often this is a one-time/infrequent activity if there are lots of applications of the same 'type', for example web-delivered transactional applications. A reference architecture should be created for differing types of applications (message switching, batch processing, etc).

Effectively this defines what "good" looks like for the organization's application portfolio. The structure & details will be influenced by many non-functional requirements: security/privacy goals, cost/budget considerations, performance goals, reliability goals, etc.

As a high-level generalization, here is a 'crayola' architecture diagram for web-delivered transactional applications:

Web Delivery Application Reference Architecture

In practice this would be supported by:

  • detailed deployment diagrams showing preferred network connectivity types, load balancing/fault tolerance, auto-scale/auto-heal constructs, etc.
  • documentation listing the best practices & recommended design / configuration throughout the architecture

Best Practices & Recommended Configurations

Best practices & recommendations are broken down across non-functional areas & the individual tiers of the architecture (per the above diagram):

  • Performance
  • Security
  • Scalability
  • Cost
  • Availability
  • Serviceability (monitoring & management)

Assess current application delivery model

The devil is in the details. At a high level the assessment involves understanding the current application deployment model and performing a gap-fit to the reference architecture, noting deficiencies along the way. However, this should not be an 'ivory tower' assessment - there are many critical details to assess.

As we will be assessing a large number of items it is important to structure the capture of results; the below table is an example of what could be used for this. From this data we can produce summaries & support detailed prioritization & planning of remediation activities.

Tier Category Item Deficiency Impact Recommendations
Client Transport / Protocol Performance Compression of HTTP responses Compression not enabled High Enable HTTP compression
Client Transport / Protocol Performance HTTP Keep-Alives Enabled Keep-Alives not enabled High Enable HTTP Keep-Alives (persistent connections)
Client Transport / Protocol Performance HTTP/2 Enabled Keep-Alives not enabled Medium Enable HTTP/2 to improve delivery latency
Application Tier Availability Application state (sessions, caches, etc) shared across the cluster (not per-instance) Redis cluster used for session & cache storage None None
Data Tier Availability Databases replicated across at least two availability zones in support of near-zero RTO AWS RDS - Aurora used with read replicas in two additional availability zones None None
Application Tier Availability Application servers load-balanced across at least two availability zones AWS ALB used to balance across three availability zones None None

As evidenced by these examples the assessment touches on architectural items (is there redundancy?) and implementation items (proper configuration of HTTP headers, etc.) - all of which play a role in delivering a a highly-reliable customer experience.

Summarize & plan for remediation

Results from the assessment can be summarized from the captured data, broken down by tier & impact:

Tier Category High Medium Low None
Client Transport / Protocol Performance 5 3 2 10
Client Transport / Protocol Security 2 2 0 15
Data Tier Availability 2 0 0 25

Establishing a remediation plan is heavily dependent on your goals & timeline; a critical path should be established along with a short/medium/long term roadmap for remediating delivery deficiencies.

I hope this has provided insight into the breadth & depth of assessment necessary to achieve cloud migration goals; in future posts will incorporate your feedback and present strategies for re-architecting applications for high reliability cloud delivery.


Chris Lee    


Chris is an experienced technology professional specializing in helping enterprises with their cloud transformation journey. Passionate about reliability, cost efficiency & innovative technologies.