Migrations of existing enterprise applications to the cloud can be complex. There are no migration methodologies or magic bullets that enable a simple lift and shift or automated migration. Typical migration projects take a great deal of discovery work, re-architecture, and refactoring. In this session, we will share known challenges and considerations that must be accounted for when designing, planning, and executing a migration. Topics will include: scale-out and distributed architectures, geographic dispersion, leveraging existing cloud services, and logging & monitoring. In addition, this session will address how in-depth discovery efforts can be paired with configuration management, automation, and source control to minimize the risk of future technical debt. Finally, we’ll cover the business and technical factors the affect the complexity of application refactoring.

1. ©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

2. 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.

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

4. Migration Stories

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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 +

11. 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.

12. Realities of App Migrations

13. 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.

14. 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.

15. 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.

16. 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.

17. 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.

18. 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.

19. 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.

20. Approaching Cloud Migrations

21. Phase Focused Approach
App
Analysis
Backlog &
T-Shirt
Sizing
Build
Supporting
Pipeline
Non-Prod
Migration
Prod
Migration
Optimization

22. 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

23. 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.

24. 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.

25. 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

26. 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.

27. 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.

28. 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.

29. 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.

30. Questions?
bradleyc@slalom.com

31. CHICAGO

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

33. 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.

34. 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

35. 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

36. 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