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:
- Establish a reference architecture & best practices;
- Assess current application against reference architecture & best practices;
- 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:
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):
- 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.
|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:
|Client Transport / Protocol||Performance||5||3||2||10|
|Client Transport / Protocol||Security||2||2||0||15|
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.