Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

DevOps - Nothing Stays the Same

542 views

Published on

Sky Betting & Gaming has become one of the largest online operators in the UK, undergoing a period of sustained high growth in customer numbers, transaction rate, staff size, and number of systems. Five years ago, the company established its first DevOps team, and since then, DevOps has become a major part of the way Sky Betting & Gaming does things. However, what that means keeps changing. Michael Maibaum describes how the DevOps function has changed repeatedly over the last few years to help the company continue to move fast and keep systems operating through organizational and technical challenges.

This version of the presentation excludes speaker notes but has bigger pictures

Published in: Technology
  • Be the first to comment

  • Be the first to like this

DevOps - Nothing Stays the Same

  1. 1. @mmaibaum DevOps - Nothing Stays The Same Michael Maibaum
  2. 2. @mmaibaum Precis Sky Betting & Gaming has become one of the largest online operators in the UK, undergoing a period of sustained high growth in customer numbers, transaction rate, staff size, and number of systems. Five years ago, the company established its first DevOps team, and since then, DevOps has become a major part of the way Sky Betting & Gaming does things. However, what that means keeps changing. Michael Maibaum describes how the DevOps function has changed repeatedly over the last few years to help the company continue to move fast and keep systems operating through organizational and technical challenges. Originally, the DevOps team was established as a group of like-minded engineers keen to smooth the delivery of software into operations and make it run better. As the business grew, the engineering teams were split and the accumulated DevOps knowledge distributed into those new groups, but the team soon found out that things didn’t fit into a distributed function and features of the platform that need ownership. As a result, platform teams were formed to produce products that other teams use. Sky Betting & Gaming’s DevOps experts now come in two categories: those that directly work in or with individual (product) engineering teams and those that deliver a platform that makes life easier for the rest of the engineering function. It is easy to see a narrow definition of DevOps as part of the function of a specific engineering team. However, in the experience of Sky Betting & Gaming, to achieve a truly effective delivery and operational culture (and indeed, DevOps) once you have hundreds of engineers requires investment in the platform as a product in and of itself. Michael outlines the history of DevOps at Sky Betting & Gaming and explains how the company has taken its DevOps philosophy into its vendors as it takes its first steps into the cloud.
  3. 3. @mmaibaum Introducing Sky Betting & Gaming • One of the top 3 online gambling operators in the UK • 3 Categories of product • Sportsbook • Free Sports related content • Gaming
  4. 4. @mmaibaum A Diverse Technology Stack
  5. 5. @mmaibaum In the Beginning
  6. 6. @mmaibaum A Story of Change & Growth 2010 2015 £50M £350M • Business grew slowly for the first 8 years post-acquisition • Interactive tv was seen as the next big thing • Major growth period starts in ~2008
  7. 7. @mmaibaum 2008
  8. 8. @mmaibaum Infrastructure & Ops Only • Tech Team • No in-house development • Hosting and operating third party vendors applications • Waterfall project management and delivery
  9. 9. @mmaibaum Focus on the Web • Increased focus on the web, but still delivered by third party vendor software teams • Starting to deliver real customer & revenue growth at this point, company profits start to grow.
  10. 10. @mmaibaum The End of the Beginning • Business wanted to increase velocity • More frequent change • Cheaper to deliver new features • More control • Time to bring the user experience in-house
  11. 11. @mmaibaum The First Problem How to improve delivery & reliability from the in-house software teams? Vendor Ops Dev
  12. 12. Backlog Wip Done Test Live Delivery Team 1 Infrastructure Service Desk 1st Line On Call The First Answer - 2011 DevOps Team 2nd Line On Call
  13. 13. @mmaibaum DevOps • Build tooling focussed on developer productivity and system reliability • First CI pipelines with Jenkins • Load testing, capacity and scaling (large, peaky events)
  14. 14. @mmaibaum Typical Saturday (Bets & Logins)
  15. 15. @mmaibaum Centralised DevOps? • Probably not want what you want to aspire to • But… Can be a good way to start • Start the cultural shift • Solve the problem of not enough ‘DevOps’ to go around
  16. 16. @mmaibaum DevOps Starting to Work • Fit in well with increasing emphasis of agile delivery (Scrum, then Kanban) • Central team provided a concentration of capability and culture • Demonstrable wins important for adoption • In-House Dev going well enough that we start work on Sky Vegas ‘in-house’ front end
  17. 17. @mmaibaum Commits/MonthCommits/Release
  18. 18. @mmaibaum March 2012 We go from 'does anyone think we will be using the in-house site for Grand National?' to 'does anyone think we *won't* be using the in- house site?'
  19. 19. @mmaibaum Soon we had another problem… How do we manage configuration for Disaster Recovery?
  20. 20. @mmaibaum Config Management ConfigureServer - Many custom perl scripts Revision control via something.pl.freds-test something.pl.bak, something.pl.bak2, something.pl.old, something.pl.not-sure-what-this-is-but-scared-to-delete-it
  21. 21. @mmaibaum Platform Evolution • Another Centralised Team • This time born out of infrastructure and the DevOps team • Created with a specific purpose (fix config management for DR, aka Chef All the Things) • This turned out to be hard - At least 1.5 years effort • Lots of concurrent change, with little effective standardisation
  22. 22. Publish Applications Infrastructure Code (Chef, Ruby, ServerSpec) Publish Application Code (PHP, NodeJS, React, Java) Release Configuration Orchestration
  23. 23. @mmaibaum The Beginning of the Middle The birth of tribes
  24. 24. @mmaibaum DevOps was in danger of becoming Ops • With teams growing and changing the ways they work, a centralised devops team increasingly mis-aligned. • DevOps engineers were spread out around different teams
  25. 25. @mmaibaum Tribes • Inspired by the Spotify white paper • Overall team getting too big • Sub-divide into autonomous teams first at main product level (tribes, e.g. bet/gaming) then squads within those.
  26. 26. Core Tribe Gaming Tribe Infra Tribe Bet Tribe Growing Pains - 2013 Backlog Wip Done Test Live Backlog Wip Done Test Live Web Experience Place & Track Squad Platform Ops Service Desk 1st Line On Call Backlog Wip Done Test Live Backlog Wip Done Test Live Casino Squad Vegas Squad Backlog Wip Done Test Live Backlog Wip Done Test Live Platform Evo Account Squad Backlog Wip Done Test Live Infra Squad SLM Security
  27. 27. @mmaibaum Better… • Alignment with development • Ownership of Ops issues in squads • Knowledge of services each ‘DevOp’ was working with
  28. 28. @mmaibaum But… • The ‘DevOps’ were still the first on-call, cross tribe • Increasingly limited knowledge of other teams services • Team size awkward, • too many services for individuals to know all services, • not big enough to populate on-call with the right Ops skills
  29. 29. @mmaibaum And…
  30. 30. Publish Applications Infrastructure Code (Chef, Ruby, ServerSpec) Publish Application Code (PHP, NodeJS, React, Java) Release Configuration Orchestration
  31. 31. Publish Applications Infrastructure Code (Chef, Ruby, ServerSpec) Publish Application Code (PHP, NodeJS, React, Java) Release Configuration Orchestration Integration/Test/Production
  32. 32. Dev Ops Publish Applications Infrastructure Code (Chef, Ruby, ServerSpec) Publish Application Code (PHP, NodeJS, React, Java) Release Configuration Orchestration Integration/Test
  33. 33. @mmaibaum The Middle of the Middle aka 2014
  34. 34. @mmaibaum Tribes have local focus • Optimising for local concerns • Delivery of that product • Improvement of their technology stack • Improving their processes • Local service delivery teams • Bet WebOps team (monitoring and so on) • Bet SRE team • Bet Delivery Engineering
  35. 35. @mmaibaum Squads taking ownership… • End to end ownership • Design, Build, Run, Change, Fix, Retire • Full support in a team - on call • There are specialists, but they aren’t the only people that can do things
  36. 36. @mmaibaum But… Should everything be a local concern?
  37. 37. @mmaibaum Cross Cutting Platform Features • What happened to Platform Evolution?…. It evolved into Platform Services • There is a wider set of ‘PaaS’ like services that would be useful across the business • Counterbalance ‘everything local’ inefficiencies • What • PlatCI - Our CI as a service platform (Jenkins etc), • Shared Kafka - Messaging Platform as a Service • Self Contained Projects - Get rid of the Dev/Ops tooling projects/tooling splits
  38. 38. Orchestration Application + Config Build Jenkins Publish Cookbook (sbg_myapp) • Infrastructure Code (Chef, Inspec, Custom Resources) • Application Code (PHP, NodeJS, Java) • CI Pipeline (Jenkins Pipeline, Chef) • Integration Tests (Kitchen, Chef)
  39. 39. pscli The ‘Glue’ - enables the consistent composition of toolsets in different environments • Internal Tool • Written in Go • Pulls in various ‘tools’ Docker images • Executes tools in containers, e.g. • ChefDK • Terraform • Packer • AWS Authentication • Hashicorp Vault • Code Generation
  40. 40. pscli generate cookbook myapp Git --volumes-from /git /opt/chefdk ChefDK --volumes-from Docker Registry Code Generator --volumes-from /generator {command runner} ~/workspace/myapp
  41. 41. pscli kitchen converge Git --volumes-from /git {command runner} Kitchen Suite A Kitchen Suite B /opt/chefdk ChefDK --volumes-from Docker Registry
  42. 42. pscli terraform apply /opt/terraform Terraform --volumes-from Docker Registry {command runner}
  43. 43. @mmaibaum Vendors • Bad vendor relationships can cripple progress • Or they can enable it • It is in your interest to help them as much as you can
  44. 44. @mmaibaum Delivery Partners • Bad vendor relationships can cripple progress • Or they can enable it • It is in your interest to help them as much as you can
  45. 45. @mmaibaum Tribes Getting Too Big • Feeling the pain of growth again • Bet Tribe bigger than whole tech organisation was 3 years earlier • Break up of bet tribe into smaller, nested, tribes • Making more specialist roles closer to each ‘product’ delivery squad (e.g. SRE as part of a squad)
  46. 46. @mmaibaum Two kinds of ‘DevOps’ • People in every delivery team, some of these are DevOps specialists but the whole team cares about the whole product lifecycle • People in specialist teams working on shared platform capabilities • Platform Services - Cross Tribe Services • Platform Engineering (Big tribes have their own ‘shared’ services) • Delivery Engineering (Specialists in tribes helping squads optimise reliability & delivery, especially things like release engineering, CI, etc)
  47. 47. @mmaibaum Path Dependency • It really matters where you are, and where you are coming from • At least as much as where you’d like to go to. • There isn’t a path, because there isn’t an environment (and it changes)
  48. 48. @mmaibaum The End?
  49. 49. @mmaibaum There is no End Except of this talk http://engineering.skybettingandgaming.com

×