This document provides key lessons learned from cloud migrations. It discusses technical lessons like using automation, revision control, and automated testing in cloud migrations. It also covers cultural lessons such as moving from a "gate keeping" to open access model, improving collaboration, and adopting Lean principles. Additionally, it addresses business considerations like managing risk, failure, skills, and contractors when moving to the cloud. The overall message is that cloud migrations require changes to both tools and culture to fully realize the benefits.

1. Key Lessons from Cloud Migrations
It’s all the rage
Mandi Walls
Dublin AWSUG
February 15, 2017

2. Mandi Walls
Technical Community Manager for EMEA
@lnxchk
mandi@chef.io

3. Who Is Chef?

4. “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?

5. Do you HAVE to go to the Cloud?
• Well….
• You need cloud-approximate features
• APIs
• Resources-on-Demand

6. Cost

7. Lessons Learned About Costs
• The saga of chargeback accounting
• Budgeting
• Reclaiming overhead from on-prem
• Timing with contracts for managed services

8. Work Patterns

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

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

11. Lift + Shift

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

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

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

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

16. Technical Lessons
The Fun Stuff

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

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

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

20. Culture Lessons
The Messy Stuff

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

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

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

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

25. Business Stuff
The “Culture + Tools = €€€€” Stuff

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

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

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

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

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

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

33. We Are Chef
• https://chef.io
• Find us! https://events.chef.io/
• https://learn.chef.io