aws re:invent 2016: preparing for a large-scale migration to aws (ent212)
TRANSCRIPT
© 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Mario Thomas, AWS Professional Services
Greg Cope, Financial Times
November 29, 2016
Cloud Readiness & MigrationGetting ready for a large-scale migration to AWS
ENT212
What to Expect from the Session
• Find out what we mean by ‘large-scale migration’
• Why are you migrating?
• What you should consider before migrating
• Are you ready for a migration?
• Is your organization mature enough?
• Hear from a customer that has been there
• Preparing the business case for migration
A large-scale migration typically involves migrating
hundreds of servers and/or application workloads to
AWS. We often talk to customers who are moving
more than 500 servers and/or application
workloads to AWS.
A workload is all of the constituent parts of an
application needed to make it available to end users;
connectivity, data centers, servers, software, people
and 3rd parties.
Why migrate?
Why migrate?
• A change of organizational leadership / ownership /
strategy
• Introduction of a new compliance regime
• Experiencing regular service issues
• The customer base is growing and becoming more
geographically dispersed
• We can’t stay ahead of the curve when it comes to
security
Why migrate?
• We’re maintaining technology debt
• We don’t have the IT resources to maintain competitive
advantage
• We don’t have the agility to keep up with disruptors
entering our market
• We can’t grow our business because our IT cannot keep
pace with that growth
• We don’t innovate
Why migrate?
• Pay for what you need
• Reduced capex and reduced opex
• Improved productivity
• Improve security
• Enter new markets / fail fast
• Cost avoidance
• Operational resilience
• Business agility
How did we get here?
• IT and the loss of innovation
How did we get here?
• IT and the loss of innovation
• The dot com boom and bust
• Maintaining technical debt
• Enter the cloud
• The return of IT as an innovator
• Addressing technical debt
• The need to migrate
Migration considerations
Migration considerations
• Do you know what you want to move and by when?
• Do you have the buy-in of the business?
• Do you have cloud ready people in your organization?
• Do you know what your cloud security posture is?
• Do you know how cloud will impact your people?
• Do you know how cloud will impact your customers?
• Do you have the resources for the migration?
Migration readiness
Are you ready for the cloud
• How do I know what workloads I have?
• Which workloads should I migrate and in what order?
• How much is it going to cost me to migrate?
• How long will the migration take?
• What impact will there be on people and partners?
• How much will I save by migrating?
• What other business benefits will I gain?
Organisational maturity
Organizational maturity
• Business
• Platform
• Process
• People
• Maturity
• Operations
• Security
Organizational maturity
• Use Cloud Adoption Framework (CAF) to perform a
maturity assessment
• Use the results to identify gaps in organizational maturity
for the adoption of cloud
• Address gaps either as an activity within the migration or
prior to commencing the migration – do not leave until
after the migration
Recap
Recap
1. We covered what we mean by a large-scale migration
2. We discussed why you would embark on a migration to
the cloud
3. What to consider before embarking on a migration
4. Determining if you’re ready for a migration
5. Evaluating your organizational maturity for the cloud
Case Study: Financial Times
Smart Cloud MigrationFinancial Times approach
Greg Cope
What I am going to cover
Introduction
FT’s approach in detail
Challengettes
Summary
1
2
3
4
Introduction
Financial Times
Brexit slide…
Me…
Head of Platform Architecture and Security
Been at the FT a while
AWS Certified
Based here…
1
2
3
4
FT’s approach in detail
It’s not always about…
£££
FT’s strategy…from our 2014 business case
Speed to market
Delivery efficiency
Reduce capex / opex
1
2
3
Speed to market
Delivery efficiency
Reduce capex / opex
Challengettes
You might have a great strategy
Upskilling the organisation
Cost control (the smart bits…)
1
2
Avoid…
Most techies (me included)
The smart bits of cloud are all…
Most techies / organisations (me included)
Upskill the organisation
Consultants ($$$$$$$$...vs short)
Hire in ($$$$...quick)
Train staff ($$...long time)
• Takes commitment from organisation
• Takes time
Hybrid (Consultants & training)
1
2
3
4
Upskill the organisation
Costs…uh oh
How can you avoid the classic story
FT’s Smart Cloud use strategy
Dedicated team (thanks FT’ers!)
Use AWS higher level services rather than ‘instances’
Switch off non-production
Review operating systems costs
Use newer instance types
Reserved instances
1
2
3
4
5
6
Obligatory server-less slide
Metric: on-demand as a % of the overall bill
Switch off non-production
Metric: non-production less than 16 instance
hours/day ~ weekends 2 hours
Review operating systems costs
How much does your OS cost you?
• Simple CPU costs vs $?
• Licence/subscription costs overheads?
With uServices and 12 Factor applications become less
coupled to their OS
1
2
Metric: Less expensive OS instances as % of
whole estate
Newer instances
New instances are often more performant, at around
25% cheaper:
Metric: zero old instance types
Previous Gen. Current Gen. % Saving Saving Per Hour
t1.micro t2.micro 7.5% $0.006
m1.large m4.large 23.2% $0.058
m1.xlarge m4.xlarge 26.2% $0.115
Reserved instance types
FT’s 1-year Reserved Instances (RIs) savings estimate
of ~34%
Only useful afterall of the previous steps are
done…otherwise you are buying the wrong RI
1
2
Metric: X number of RIs applied
Challengettes
Roll-out approach
Work with a team to demonstrate:
• that it is possible
• That it works (saves $$$$)
• Act as techy evangelists
Other challengettes
IP firewall rules broken when hosts come up with new IP
Monitoring noise
Schedulers broke
Differences between similar OS’
1
2
3
4
Game it (team dashboards)
Game it (team dashboards)
Summary
FT’s strategy…reminder
Speed to market
Delivery efficiency
Reduce capex / opex
1
2
3
But…much higher instance productivity + $$$
saved
Did we achieve our business case?
Thanks,
For listening …
To all the lovely FT people who have worked on this over
the years
AWS Cost optimisation; http://goo.gl/M9hLC3
https://github.com/Financial-Times/ec2-powercycle
Preparing the Business Case
Establishing an effective business case for the
adoption of AWS for your application workloads
requires knowledge of how your organization does
things now.
By understanding your existing on-premises or co-
location environments as well as the things that sit
around them you will be able to lay the groundwork
for an effective business case.
Preparing the Business Case
Discovery ConfirmationBusiness
Case
Collection of key data
points:
• People Costs
• 3rd Party Costs
• Infrastructure Costs
• Application Costs
• Migration Costs
• Current intangibles
Current Budget
Customer sign off of
current budget review:
• Review of budget by
customer
• Customer to confirm
it is accurate
• Budget used as basis
for business case
Business Case
AWS prepare business case:
• AWS analyze data points
• Multiple operating models
considered and presented
• Costs for future state
included
• Comparative budget’s
included
• Cash flow forecast included
• Measuring value benefits of
the migration
The Role of Cloud Economics
The Role of Cloud Economics
• Concerned with the cost savings achievable in the cloud
• A focus on tangible benefits of the cloud:• migration bubble
• total cost of ownership
• cost optimization
• payback period
• And intangible benefits:• time to market
• developer productivity
• agility
The Role of Cloud Economics
$
1 2 3 4 50
TCO
Migration Cost
Cost Optimising / BAU
Current / Do Nothing
AWS Environment
Payback
Period
Time
Cost
Intangible
Benefits
The Role of Cloud Economics
• Leads to development of a cloud business case• internal rate of return
• net present value
• return on investment
The Role of Cloud Economics
Migration Bubble
Discovery TCO
Cost Optimisation
o Application
discovery
o Current
costs of
applications
o Exit costs of
migration
o Compare
on-prem/co-
lo to cloud
o Consider
like-for-like
o Recalculate
for six R’s
o 11 principles
of cost
optimization
o Apply to
TCO models
Confirmation
Current Budget
Customer sign off of
current budget review:
• Review of budget by
customer
• Customer to confirm
it is accurate
• Budget used as basis
for business case
Collection of key data
points:
• People Costs
• 3rd Party Costs
• Infrastructure Costs
• Application Costs
• Migration Costs
• Current intangibles
Total Cost of Migration (TCM)
$
1 2 3 4 50
TCO
Migration Cost
Cost Optimising / BAU
Current / Do Nothing
AWS Environment
Payback
Period
Time
Cost
Intangible
Benefits
Total Cost of Migration (TCM)
• All migrations have a cost, even small migrations
• The investment needed to achieve the migration is often
called the migration cost or the migration bubble
• Costs typically include:• discovery, planning and assessment costs
• proof of concept (POC) activities
• migration tooling
• application readiness
• staff readiness and training
• software licensing changes
Total Cost of Migration (TCM)
• Continued…• running duplicate environments during migration
• lease penalties
• redundancies / restructuring / re-deployment
• external consultancy
• The migration bubble can be controlled• Migration planning can help
• Migrations can be optimized for cost, speed and risk or
balanced for all three
Total Cost of Operation / Ownership (TCO)
$
1 2 3 4 50
TCO
Migration Cost
Cost Optimising / BAU
Current / Do Nothing
AWS Environment
Payback
Period
Time
Cost
Intangible
Benefits
Total Cost of Operation / Ownership (TCO)
• TCO provides a comparative total cost of ownership
analysis for on-premises workloads as compared to the
cloud• Is valid up until migration actually takes place
• Doesn’t consider use of higher level services
• Is not a price quote or forecast of your future spend
• Answers the question: “How much would it cost to keep
all of this in the cloud”
Cost Optimization (CO)
$
1 2 3 4 50
TCO
Migration Cost
Cost Optimising / BAU
Current / Do Nothing
AWS Environment
Payback
Period
Time
Cost
Intangible
Benefits
Cost Optimization (CO)
$ $
Paying for what
you use
Paying for what
you need
Cost Optimisation (CO)
Simple Stimulating Stretching
Consolidated Billing
Permissions
Tagging
Idle Resources
Design for Elasticity
Instance Right Sizing
Storage
Purchasing Options
OS Licencing
Offloading Architecture
Higher Level Services
Tangible vs. Intangible Benefits
Intangible Benefits
$
1 2 3 4 50
TCO
Migration Cost
Cost Optimising / BAU
Current / Do Nothing
AWS Environment
Payback
Period
Time
Cost
Intangible
Benefits
Tangible cost savings associated with migration to
the cloud are not the only benefits to be gained from
it. Analyzing the intangible benefits a migration
could have on your business and your bottom line
can lead to a more rounded business case for
justifying it and a greater urgency to complete the
migration.
Intangible Benefits
$tangible
benefit
intangible
benefits…
Intangible Benefits
• Intangible (value) benefits will depend on your business
• There are numerous KPIs and they can even be
applicable across industries
• You may already be measuring them
• You may already be reporting performance against them
Discovery of Data Points
Data Points and Effort
Data Points
Eff
ort
High effort,
many data
points. Leads
to a high
quality
business case.
Low effort, many
data points.
Difficult to build
compelling
business case.
Low effort, few
data points.
Unusable
business case.
High effort, few
data points.
Leads to an
inaccurate
business case.
Discovery of Data Points
People
Costs
3rd Party
Costs
Infrastructure
Costs
Application
Costs
Migration
Costs
Discovery of Data Points – People
People Costs
People costs include (and are not limited to):
• Direct people costs (employees):
• Recruitment, retention, replacement and retirement costs
• Activity costs including undertstanding time and motion
• Training and development costs
• Direct people costs (contractors):
• Recruitment, retention, replacement and retirement costs
• Cost per hour/day/week/month
Discovery of Data Points – 3rd Party
3rd Party Costs
3rd Party costs include (and are not limited to):
• Contract related costs
• Fixed costs (maintenance, etc.)
• Variable costs (innovation, change requests, etc.)
• Variation penalties / early termination penalties
• Software licences (e.g., orchestration tools / multi-cloud)
• Activity costs including undertstanding time and motion
Discovery of Data Points - Infrastructure
Infrastructure Costs
Infrastructure costs include (and are not limited to):
• Data centre costs
• Lease term remaining
• Lease termination penalties
• Cost of reduced footprint
• Connectivity
• Leased lines to the data centre
• Servers
• Number of physical servers
• Number of virtual servers
• Virtual servers mapped to their physical counterparts
• Specification (CPUs, cores, RAM)
• Performance characteristics (CPU/RAM/IO min/max/avg.)
• Storage (SAN, NAS, direct-attached)
• Network connectivity (peak throughput)
• Dependencies on other servers
Discovery of Data Points - Infrastructure
Infrastructure Costs
Infrastructure costs include (and are not limited to):
• Upcoming refreshes
• Existing end of life plans
• Date purchased / instantiated, time remaining on capex
• Cost of purchase / instantiation, cost remaining on capex, lease penalties
• Depreciation / amortization approach
Discovery of Data Points - Applications
Application Costs
At the same time as you perform server discovery, you should also be
establishing what applications (“workloads”) you are running. The more
data points you can collect about your applications, the better equipped you
will be to make a decision about how they will feature in the migration:
• Number of application workloads
• Map workloads to the underlying servers
• Establish workload dependencies (both server and other workloads)
• Perform a “Six Rs” analysis of each workload
• Review OS licensing and the underlying OS (move to Amazon Linux?)
• Understand upcoming application changes
• Re-examine the Six Rs analysis and understand scope for:
• R1 > R2 or R5
• R3 > R4
• R5 > R4
• R6 > R5 or R4
Discovery of Data Points - ApplicationsPattern
Label
Migration
Pattern NamePattern Description Examples
Retain
• Client will keep host / application in their source environment
• Minimal analysis/validation of scope and application affinity
• Dependency on integrating service management
Unresolved Physical Dependencies
Mainframe/AS400
Non x86 UNIX Applications
Retire
• Application and host decommission on source
• No migration to target
• Application owner approvals needed
Existing Decommission Program Scope
UNIX, AIX, SCO;
Clustered host for DR, alternative HA hosts
Re-Hosting
• Like for Like application migration to target cloud
• Minimal effort to make the application work on the target cloud infrastructure (Minimal
application layout change)
• Storage migration will be needed (without conversion)
• UAT - Some level of application testing
Simple to Medium V2V, P2V
Storage: Local to DASD
RHEL 6 above
Win 2008 above
Re-Platform
• Up-Version of the OS and/or Database onto the target cloud
• Storage migration will be needed (without conversion)
• Some level of application changes
• Application reinstallation on the target
• UAT is highly recommended
• Database to AWS RDS
W2K3 to Win 2012; Win 2008 below; RHEL below;
Oracle 8 to 11; All databases
New application releases
All clusters (MS cluster, DR)
MS SQL same technology (RDS)
Re-Factoring
• OS and/or Database porting
• Middleware and application change to cloud service offering
• Data conversion; Database transition to MySQL, Aurora, etc.
• UAT required
AIX to Linux
Oracle to SQL; SQL to Aurora
Middleware, IBM products
Re-Architect
• Application architecture changes may also require Up-Version or Porting
• Middleware, data modernization; application consolidation / stacking
• UAT required; HPC Grid, No ITIL
Any custom application change
Complex / Highly complex application migration
R1
R2
R3
R4
R5
R6
Ap
plicati
on
Mo
dern
izati
on
/ C
han
ge E
ffo
rt
Discovery of Data Points - Applications
• Application maintenance costs
• Innovation / ongoing development / bug fixes
• Managed service organisation
• Licensing landscape
• Licenses in place
• Transferability of licences
• Upcoming licence renewals
• Economics of R1 and possibly R2 will change following migrations of
other workloads
Discovery of Data Points - Migration
Migration Costs
We need to establish the costs of migrating your workloads. This will be
based upon which ‘R’ the workload falls into.
• Planning and designing migration
• Development effort
• Testing effort
• Acceptance effort
• Deployment effort
• Landing zone configuration
• Licensing
• Data migration
• Cut over
• Roll back plan
Discovery of Data Points - Migration
Migration Velocity
The speed of your migration to AWS will directly affect the size (cost) of the
Migration Bubble. Creating a migration rhythm will drive the entire business
to work to achieve the migration.
• Identify which apps can move most easily
• Create prioritized move groups
• Organize in sprints and sprint teams for fast results
• Be able to forecast the entire project timescale
• Create a high-level multi-year/month project plan
• The migration should be fast paced and demonstrate a commitment to
migrating the workloads because of its velocity
Current Budget Review
Current Budget Review
Current Budget Review
The data points we collect are collated into a budget statement which will
present back to you the run rate cost of your current workloads. Key points
of review:
1. Planned capital expenditure
2. Monthly operations budget
3. Depreciation / amortization
4. Overall budget review
Once agreed, the budget statement can then be used as a baseline for the
business case comparison.
Business Case Preparation
Business Case Preparation
Business Case Preparation
Following sign-off of the budget statement, we will set about creating the
business case:
1. Review current budget
2. Review all data points
3. Licence review and future state forecast
4. Instance right-sizing
5. Higher-level service review
6. Total cost of migration modelling
7. Total cost of operation modelling
8. Cost optimization modelling
9. Final business case reviews
10. Executive summary
11. Backing data
Next Steps
Next Steps
1. Business case is finalized
2. Models and assumptions in business case tested
3. Business case updated with any changes
4. Business case finalised for business and Board review
5. Business case approved
Recap
Recap
1. We covered what we mean by a large-scale migration
2. We discussed why you would embark on a migration to
the cloud
3. What to consider before embarking on a migration
4. Determining if you’re ready for a migration
5. Evaluating your organizational maturity for the cloud
6. Building the business case for migration
Questions
Thank you!
Remember to complete
your evaluations!
Related Sessions
• ENT204
• ENT218
• ENT304
• ENT308