©2015,  Amazon  Web  Services,  Inc.  or  its  affiliates.  All  rights  reserved

Implementing Service Oriented Architectures Real World App Migrations to AWS

Bradley Clerkin – Solution Principal @ Slalom

Assumptions

•  You understand the “why cloud”. •  You are considering a set of applications or

environments to move to AWS. •  You want to hear about the real challenges of

executing an application migration to AWS.

Agenda

•  Migration stories •  Realities of app migrations •  Approach to successful app migrations •  Q & A

Migration Stories

Retail Servicing Platform (Story 1)

Primary facility goes down

Secondary is deemed unusable

48 hour outage ensues

“Customer impact was high, but the impact on reputation was almost immeasurable.” -CTO

The Ideal

Lift & Shift + Big Bang

Build advanced automation to

support concurrent deployments

Mirror production architecture in

AWS

Push the big red DR button to

migrate everything 6 Months

The Actual

Single Service Migrations

Automation was complex and only feasible in AWS

Apps required refactoring to run in

AWS

Pushed a red DR button for each

service 12 Months

Financial Services Firm (Story 2)

End of life, out of capacity on-prem

infrastructure

Home grown loan origination and servicing app

running on open source technology

Company looking to scale 10x in a

few years

“Our greatest challenge is in providing the capacity to meet the almost unknown future demands of the business.” –Senior

Director of IT

The Ideal

Lift & Shift + Big Bang

Build advanced automation to support auto

scaling

Focus on building services

Cause no impact on existing release

cycles 4 Months

The Actual

Two flops and one Big Bang

Automation required large

investment of time from App SMEs

Building services was cost and

resource prohibitive

Impacted two release cycles in order to integrate

AWS with development flows

8 Months +

Commonalties

•  With estimation, the devil is in the details. •  Applications had to be refactored. •  Automation tools and AWS platform services

were heavily utilized. •  It was a group effort including partner, AWS, and

internal resources. •  SME resources from Slalom were utilized.

Realities of App Migrations

Lift & Shift migrations may not be as they seem

•  L & S appears technically viable on the surface. •  Non cloud optimized architectures are

expensive. •  Most goals of cloud require cloud optimized

architectures. •  Outages are typical in L & S scenarios. •  This leads to failed cloud enablement efforts.

Applications will have to be refactored for AWS

•  Fight the urge to fully rewrite the application. •  Avoid the shiny stuff when refactoring. •  Understand application dependencies and

constraints. •  Complete a cost benefit analysis when

determining what to refactor. •  Understand how much holding onto your

existing architecture is going to cost.

Technical Debt

Technical debt is a metaphor referring to the debt created from legacy systems and long-maintained architectures. If the debt is not repaid by correcting the suboptimal solution, then it will continue to accumulate interest. This interest takes the form of increasing complications when trying to resolve or repay.

Technical debt must be paid down

•  Migrations are the collections agencies for technical debt.

•  It can be embarrassing. Don’t play the blame game.

•  Have a strategy for dealing with technical debt. •  Focus on education and prevention.

Automation tooling plays a critical role in migration projects

•  New automation tools are like an inheritance check in the mail.

•  Make sure that the “why” is clearly defined. •  Automation projects are continuous

improvement projects. •  Treat your automation artifacts like codebases.

Big Bang migrations are troublesome

•  BB delays critical production validation. •  Operational resources greatly benefit from gradual

changes. •  The benefits of AWS are only realized at the end of

BB migrations. •  The act of migration itself isn’t the benefit you want

to share, but rather the new capabilities realized once an app is in AWS.

•  In most cases, hybrid solutions are valid solutions.

Limit the focus placed on building your own services

•  Cloud enables a constant conversation between BYO and service consumption.

•  Focus on industry standard protocols and available features.

•  Services that have proprietary components still fit into standard architectures.

•  Make sure you select the right cloud vendor from the start.

Approaching Cloud Migrations

Phase Focused Approach

App Analysis

Backlog & T-Shirt Sizing

Build Supporting

Pipeline Non-Prod Migration

Prod Migration Optimization

Perform an app analysis Outputs: Current State Gap Analysis & Product Roadmap

Twelve-Factor Analysis •  Codebase •  Dependencies •  Config •  Backing services •  Build, release, run •  Processes •  Port binding •  Concurrency •  Disposability •  Dev/prod parity •  Logs •  Admin processes

AWS Readiness Analysis •  Dependency mapping •  Security and compliance •  Licensing •  Instance •  Elasticity •  Load balancing / Proxy •  Authentication •  Design for failure •  Database •  Data storage •  File sharing •  AWS services parity

More at 12factor.net and in AWS Architecture Center

Conduct a current state gap analysis

•  There is no “right” format. •  Compare current state

against a standard. •  Highlight gaps. •  Theorize how to close

identified gaps.

Produce a product roadmap

•  Contains a phased plan for architecture changes and migration activities.

•  Allows for cross team and executive level communication.

•  Drives the current and long term project efforts.

Construct a backlog and perform t-shirt sizing

•  Document task details for implementing the first phase of the product roadmap.

•  Assign a complexity rating of S, M, L. •  It’s critical to remember it’s not about time but rather

complexity.

Key Summary Issue Type Status Priority Description Acceptance Criteria Estimate (T-Shirt) Assumptions

DR-­‐196   Build and Deploy

Story Backlog Minor This story will encompass tasks necessary to complete the orchestration for standing

up instances.

Create build artifacts Deploy to AWS

Jenkins project created to support standing up an application stack

Cloudformation configuration created Large

- Define Jenkins job to build the Ansible artifacts (in flight)

- Create another job to build those jobs (based on monitoring new role creation; build

chain) (in flight) - Deployment portion: next phase

Architect and build the supporting deployment pipeline

•  Acts as a factor for migrating workloads and dealing with technical debt.

•  Typically consists of repositories, build server, orchestration server, configuration management tooling, and log management.

Migrate non-prod

•  Allows engineering teams to learn about AWS. •  Enables rapid realization of the advertised benefits. •  Limits the initial scope of operating in the cloud. •  Ensures environments are built from similar

artifacts. •  Once non-prod is conquered, other environments

follow suit quickly.

Migrate prod

•  The greatest obstacles are in operational sign-off. •  Be prepared to answer the hard questions. •  Continuously educate others on the project. •  It is possible to automate a portion of this education. •  If possible, extend the pipeline to production.

Optimize prod

•  Baseline production applications in AWS. •  Utilize logging extensively in optimization efforts. •  Improve cost and performance efficiency of

components. •  Continue education and product roadmap

efforts.

Questions?

bradleyc@slalom.com

SAN FRANCISCO

Dashboards and Measurement

•  Report on your migration project status. •  Introduce operational app status. •  Measure business metrics. •  Error dashboard. •  Present this information live.

Start in development environments

•  Allows individuals building the applications to understand the new services and APIs.

•  If you have to refactor the app the effort has to start in Dev.

•  In many organizations the deployment of infrastructure is a major bottleneck.

•  Limits the initial scope and risk of operating in the cloud. •  Plan to build Prod from Dev artifacts. •  Once Development is conquered other environments

follow suite quickly.

Challenges once you start to win

•  Limiting account sprawl •  Guard rails rather then lock down •  User education •  Auditing at scale •  AWS limits •  Inner cloud migrations

Someone has to own AWS

•  Should be a cross functional team •  Sets the standards and guard rails •  Acts a center of excellence •  Publishes the right way to do things •  Spends time educating and enabling •  Owns cost optimization

Inter cloud migrations

•  How to build the cloud for enterprise scale is hard •  Many patterns and “correct” solutions •  What worked at 50 instances likely won’t work at

500 •  Same is true for 5000 •  Trying to solve for 5000 at 50 doesn’t work either…

because you’ll miss something •  Continuous improvement concepts should be

applied to cloud architectures