lessons learned from cloud migrations

Key Lessons from Cloud MigrationsIt’s all the rageMandi WallsDublin AWSUG February 15, 2017

Mandi Walls

Technical Community Manager for EMEA@lnxchkmandi@chef.io

Who Is Chef?

“The Cloud”

• External IaaS services• Internal shared services or other “private cloud” / “hybrid cloud” solutions• Anything in between• Does it look weird to datacenter techs?• Does it come with a direct bill to your team?

Do you HAVE to go to the Cloud?

• Well….• You need cloud-approximate features• APIs• Resources-on-Demand

Cost

Lessons Learned About Costs

• The saga of chargeback accounting• Budgeting• Reclaiming overhead from on-prem • Timing with contracts for managed services

Work Patterns

Abandon All and Start Over

• Completely re-tool all teams for new projects• Challenges for learning, scaling• Too many new things all at once can hurt the project team’s ability to ship

• Heavy cognitive burden to technical and product teams• Consider the benefits of existing tools

https://www.flickr.com/photos/91010083@N07/32787463861/

Taking All Your Baggage With You

• Reimplementing years of infrastructure and security decisions, just in the cloud• Creating ticket queues to have someone from your team work in the cloud

provider’s interface• Continuing to ship at long intervals, and not investing in new features that the

provider has produced

Lift + Shift

Including the Whole Team

• Early cloud projects often started through discontent of one team or another• Dev or test teams wanted their own platforms to work on• New initiatives didn’t have the budget to buy hardware or more capacity at MSPs

• Investigation and migration projects started by executives happen differently• They caught on to “that cloud thing” eventually• Hasn’t always lead to the best implementations

Nebulous Goals

• Everyone’s had cloud projects that cost less than the original platform. Everyone’s also had cloud projects that end up costing more

• So there is a key to the project, knowing what the goal is• Time-frame goals, like expiring contracts – “We need to be out of $datacenter before Mar 1”

Retooling for Risk

• Using a cloud project to get off an older platform• Lower the cost of experimenting with new platforms• Make expanding to more global regions more accessible

Different Thinking for New Platforms

• We’ve been through this too• SaaS + on prem + service in IaaS• We’re now a service on AWS

• Meet needs you didn’t know you had when you started• This is not a 5-year plan

• Maybe a 5-month plan

Technical LessonsThe Fun Stuff

Automation

• Were you automated before going to cloud?• Cloud is easier with automation

• Automated, full-stack application policies• Package and service installation

• Your provider has repositories! You don’t have to build your own for basics!• Versionable, testable, repeatable workflow• Scalable application policies• Management of interdependencies across nodes

Revision Control

• Findings from State of DevOps report• Everyone must use version control

• Dev• Ops• You• Me• The dog your hipster office mate brings to work

• You’re not using revision control if all your work is in the webui

Automated Testing

• Difficult tasks – automating the testing of applications developed internally and COTS or contract work

• Different tools for different languages and platforms• Delivers a lot of value, but costs a lot to get going• Unfortunately met a lot of orgs that struggle with this or choose to postpone

Culture LessonsThe Messy Stuff

Access vs Gate Keeping

• Putting the cloud behind just another set of locked doors doesn’t lead to the kind of benefits execs are looking for• But it might feel good for some folks on the team

• Open access is hard to get used to• Processes and required practices – “Tag your instances”, “We reap every other week”

Collaboration

• Ideological shift for Operations folks used to working alone• Also difficult for specialized techs in silos – Storage Ops, NetOps, Security

• Adding these roles into IaaS can be non-trivial, or not supported at all• Go with best practices or a selection of acceptable options instead of person-created bespoke

• Talking to people vs just putting in tickets and waiting• The stereotypical “throw it over the wall”

CAMS to CALMS

• CAMS: Culture, Automation, Metrics, Sharing (c. 2010)• CALMS: Culture, Automation, Lean, Metrics, Sharing• Using Lean to break through the logjam of enterprise processes• The Lean lesson came late to technical teams

Learning to Lean

• Eliminate non-value-added action – Don’t do things that don’t add value just because you’ve always done them

• Pull over Push – Spend time on the things customers want to use. Don’t spend time thinking about ways to force them to use things they don’t want

• Kaizen – Continuously improve people, processes, tools• Kaikaku – Be willing to change the whole thing if it isn’t working• Small Batch + Experimentation – Often learned from Agile

Business StuffThe “Culture + Tools = €€€€” Stuff

Failure

• Accepting failure as part of experimentation• It’s cheaper now, right?

• Practice recognizing how much risk is involved in each experiment • The cost of an individual failure

• Failing with transient, cloud-based resources vs failing with capital-intensive on-prem or MSP

Blameless Culture

• Recognizing that complex systems have complex problems• The system may be too complex for one human to fully understand• Research in other systems fields

• Aerospace and aviation, nuclear power generation, etc• “Human error” is often cited but not often the actual problem

• The humans didn’t know your system didn’t have redundant error handling• The humans didn’t know there wasn’t alerting on a subsystem they weren’t told about

Business Value

• Fits in with Lean• Work on the things that will add value to users, even if they aren’t the most fun

• “Eating your vegetables”• Minimize NIH in favor of reuse• Keep shiny things under control

Managing Risk

• Small batches to manage the near-term costs• Validate with customers in short timeframes• Introducing near-term volatility to mitigate long-term risk

We spent a year building this thing but no one liked it!

Skills x Contractors x Employees

• Managing the skill matrix of the people working on the project is important• Your company depends on having skilled technical staff all the time• Harder to do when folks are leaving after 6 months to find something more

interesting• Bringing on a contractor to help a project get off the ground is great! But part of

their contract should be to train up and document for your staff

All In Balance

• Some feels contradictory• Look at new features that will help you towards your goals, but don’t get bogged down

• Create meaningful experiments and pilots• Know what you’re looking for and what the goals should be• Work out how to measure the outcomes – direct metrics or proxies

• Get expert advice and upskill the beginners

https://www.flickr.com/photos/aeu04117/5199030961/

We Are Chef

• https://chef.io• Find us! https://events.chef.io/• https://learn.chef.io