Download - Implementing Service Oriented Architecture
©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?
CHICAGO
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