AWS reInvent Executive Summit

I’m not going to blog the main reInvent keynote as the announcements will be covered extensively elsewhere, but it was an experience.

Session: Large scale migrations to the cloud

Stephen Orban, Head of Enterprise Strategy AWS

Starts with several examples of companies that have done large scale migration: fastest 9 months, motivations are cost savings and (more important) agility.

Companies are viewing the move as a cultural transformation to a tech company and getting many staff certified.

A common migration pattern seen in successful moves is:

1. Small new projects to gain skills and business case
2. Portfolio discovery and planning
3. Application design, migration and validation
4. Modern operating models for apps

Phase 1: get executive sponsorship, not just from in IT. This is key differentiator between projects that fail and projects that succeed. Get quick wins and learn before the larger moves and take a holistic approach across people, process and tech.

Some companies also create cloud centre of excellence across different lines of business (so a staff re-org) but upskill and train existing staff.

Next create business case based on KPIs. Possible cases

1. They claim 30% instance cost savings for simple lift’n’shift and then further savings through instance sizing, powerdowns out of hours etc.
2. Increased developer productivity. Reckon 50% increase from no waiting for infrastructure plus use of services that don’t need to be maintained
3. Cost avoidance: migration triggered by upcoming data centre renewals etc

Phases 2 and 3 Map data and applications to generate cost models, migration patterns, resource model and project plan

Partners can help automate the discovery (Cloudamize, ATADAta, RiscNetworks, TSO Logic and AWS Application Discovery Service)

They recommend lift’n’shift not cloud native first as easier to scale systems once they are in the cloud. Can be automated but some customers do it manually initially to learn how it works. Then create reference architectures, defined in code via CloudFormation, and best practice documents.

Some companies take it further and also re-platform (flit and re-shape e.g. Oracle -> Postgres but should timebox to two weeks work only and just re-host if it can’t be done in two weeks), re-architect or just replace some applications with SaaS while lift’n’shifting the bulk of apps. Of course not all apps need moving: some have no owner or use: BP have a three person team that just finds unused apps and shuts them off!

Final interesting aside: all of AWS’ enterprise customers run some form of hybrid infrastructure with a mix of on-prem and cloud.

For more info, AWS has a Migration Acceleration Programme and of course they have a service to track it all with the AWS Migration Hub

Session: Fireside chat with Andy Jassy

A discussion between Andy Jasey, AWS CEO and Rick Dalzell, former Amazon CIO (1997–2007). This was wide ranging and informal so there was no way I could blog it and I don’t think it’ll be streamed, which is a shame as it’s was a great discussion on how Amazon moved from a standard centralised IT setup to its current services based distributed organisation.

Mass Migration Workshop

This was a 4 hour workshop to cover why and how to migrate. Some of the overall stuff about the broad approach is the same as I blogged above, so I won’t cover it again.

In AWS’ view, transitions move through three stages of adoption

1. Commodity — low risk. Lift and shift existing applications as is
2. Modern — innovation with automation. Start to move some apps to be cloud native
3. Enterprise strong with standards — everything in the infrastructure built from code with defined patterns of architecture, SLAs, OLAs etc

and organisations grow expertise in stages:

1. Reply on partners and AWS
2. Strategic — concentrated expertise in Cloud Centre of Excellence
3. Ingrained expertise
4. Managed SIs & MSPs with a healthy balance

There was a lot of emphasis on cultural change, cloud as an enabler of velocity and what organisational structures support the move. To make this concrete, we had a session on how Capital 1 did their AWS migration:

Start with two pizza teams but with no change of reporting structures. Teams of 8–10 including applications, security, infrastructure and development. Maybe engage a partner to sit with the team and work doing pair programming for knowledge transformation. The team must ship something live, important but not critical.

Now split the team. They are now the experts so split the 10 into 2 teams of 5 and add in 5 new novices. Repeat the whole process.

Sample job titles for these teams: Technical programme manager, Infrastructure Engineer, Software Quality Engineer, Software Development Engineer, Security Engineer, Engineering Manager.

Big focus on certification, aiming for 10% certified to start — the CTO included!

A theme of the day is that cloud migrations aren’t about technology but a cultural change

Finally there was a recommendation to divide applications into different tiers with a three layer differentiation of apps (like Wardley’s PSE model)

and then use this classification to pick which ones to move when.

Sizing and pricing

Then it went a bit wrong: we did a pricing model exercise based on rough data, which showed a saving from moving to AWS of -$1m p.a. Not the answer AWS wanted! I’ll need to look more closely but I think it’s driven by the massive discounts we get on hardware (especially storage) and licensing on premise making AWS more expensive.

No mass migration for us just yet.