DOES16 London - Chris Jackson - Disrupting an Enterprise from the Inside
•
1 like•324 views
This document summarizes the story of Project Bitesize, an internal startup at a company to address issues with their IT operations. It was founded in August 2015 to fix problems like a slow and bureaucratic internal IT, lack of standards, and a 3-year planning horizon. They chose to use containers and open source tools. Over time, Project Bitesize grew to provide a next-generation application platform and global technical community for developers. It aims to transform skills, engage employees, and become a sentient managed service to automate operational responses. The document outlines some of the challenges they faced early on and areas where they are seeking help or involvement from others in the company.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to DOES16 London - Chris Jackson - Disrupting an Enterprise from the Inside
Similar to DOES16 London - Chris Jackson - Disrupting an Enterprise from the Inside (20)
More from Gene Kim
More from Gene Kim (20)
Recently uploaded
Recently uploaded (20)
DOES16 London - Chris Jackson - Disrupting an Enterprise from the Inside
- 1. The Start-Up In Your Enterprise Our Story of Disruption Chris Jackson July 2016 1 qingqing. Shutterstock
- 2. Me 2
- 3. My Work Established in 1844 Adaption is in Our History Inspiring Mission Passionate People From ISBN to FQDN Embrace the Challenge! 3
- 4. Organisational Context 4 CIO/COO/CTO Technology Operations Global Product OPERATIONS NETWORK NEW: CLOUD PRODUCT ENGINEERING DEVELOPMENT PRODUCT DESIGN … SECURITY QA EA
- 5. A Brief History… • Internal IT bureaucratic and slow to deliver • Lack of standards in application design and build • Spotty adoption of QA and Security standards • Release process is manual, slow and high-risk • Absence of collaboration between engineering and ops • Roadmap planning horizon is 3-years out A perfect storm is brewing… 5
- 6. Our Inception Point • On the precipice of perpetually failing • Previous initiatives were huge programs • Developers running their own tooling • Business headwinds increasing • New leadership • End to end review of tech strategy 6 • Appetite to do something different • Appetite to do something different • Appetite to do something different • Appetite to do something different • Appetite to do something different • Appetite to do something different Introducing Project Bitesize…
- 7. Bitesize - Born Different 7
- 8. Bitesize - Our Start-Up Story 8 Aug’15 Sep’15 Oct’15 Nov’15 Dec’15 Jan’16 Feb’16 Mar’16 Apr’16 May’16 Jun’16 FOUNDED CUSTOMER #1 VC ONBOARDED (Selected as Preferred Platform) CUSTOMERS #2,3,4 A-SERIES FUNDING PRODUCTION! Copyright HBO Entertainment
- 10. 10 PROBLEM #1 Fixing DevOps “We don’t need Ops, we already have a DevOps team with Jenkins”
- 11. 11 PROBLEM #2 What Is the Product? Understanding what Developers want…
- 12. 12 PROBLEM #3 Governance Governance is what prevails when there is a vacuum of common sense. Me, every day… “ ”
- 13. 13 So What Did We Do?
- 15. Open Source at Pearson 15 Ingress ControllerPython Client Kubernetes Pack KnowledgeEducation Sharing Information Open Source Sharing Code
- 17. Accidentally #serverless 17 Developers “I need a…” “I want to…” Platform API Developer Tooling Interfaces/Plugins… Platform Tooling & Automation Global Enabling Functions (TechOps, Security, QA…) Human feedback loops, reinforce system trust model
- 18. Platform API Abstraction 18 Security Engineer Network Engineer Testing Engineer Project Manager Architect Application Engineer Cloud Platform Engineering Global PMO Enterprise Architecture Customer Teams CISO Group Global Network Global QA Group A Vehicle for Enabling Functions Application Developer Community
- 19. DevOps Target For Pearson 19 Global Technical Community Community Engagement Developer Experience Next-Generation Application Platform Best Practice and Standards Initiatives New Technology Adoption & Integration Hackathons, Brown Bags and Meetups “Do we already have a … I can contribute to”
- 20. If This… Then That - The New Operations 20 Things that Happen Desired Response Mechanism to Execute Stuff People Care About Stuff People Concentrate On Trigger Systems Workflows Tooling “A synthetic transaction is failing” “I want to deploy my application” “Our A/B soak completed successfully” … Re-spawn pods, notify owners Execute deployment process Converge all production instances to B deployment …
- 21. Cognitive Learning & Decision Making Systems (e.g. Watson) Long Term Vision 21 Trigger Systems Log Analytics, Monitoring, SOC… Operational Run Books Codified and On-Demand Service/App Metadata Service Registry/Discovery A Sentient Managed Service..?
- 23. Areas for Breakout Discussion 23 • How does our Startup manage “hyper-growth”? • When does DevOps it stop being DevOps? • How do we recognise productivity gains vs cost savings? • Skill transformation, how do we engage Pearson’s veterans? • Setting the maturity bar, how do we qualify Platform suitability?
- 24. Get Involved? https://github.com/orgs/pearsontechnology/ More coming soon…! @chriswiggy We’re hiring… http://pearson-technology.jobs/ 24
Editor's Notes
- What is an “end to end stack”? When you include people, the technology takes a back seat - I had a lot of “yup” moments listening to Jez this morning So this talk is as much about getting an initiative off the ground as it is about a showcase of cool tech
- Ex-Racker Frustrated Coder Education Disrupter Reformed Leader This… @chriswiggy Tell the story of realising that my aspirations to be an engineer lead me to being a leader… I succeed through others Expectation set - this means I may not have all the technical details some of you may crave! My mentality - why not?
- Pearson PLC was incorporated the same year Samuel Morse invented the code that inherited his name - thats over 170 years ago Its a job with high moral fibre Digital transformation to a global education platform Good place for someone who’s mentality is “why not”!!
- How we’re structure Self service, highly done automation, very approachable service teams; consult and help and optimize and support Consult vs. open heart surgery PaaS: continuous delivery pipeline; how do we give developers an 80% experience; runtimes and containers VMs -> containers is a couple lines of config changes 1 person is COO/CIO/CTO Team of SVPs who runs tech ops (enterprise IT) VP hosting/delivery; I work for him; all next generation infrastructure comes from my team 8 engineers across US and UK; we spend a lot of
- Insert large enterprise logo here right? Umbrella company: Used to buy companies: production company for Baywatch! Pay off 20-30 years of M&A debt 7 different Ops models: traditional Ops problems, but supersized into AWS (running on unreliable commodity gear: not “HA, won’t go down”): driven by a CTO, “move everything to AWS”; circa 2012: led to backlash to governance and controls; then tried to build competitor (“private cloud”): “enterprise virtualization with API”; fundamentally wasn’t fit for purpose Walked into Pearson where everyone actively hates IT; “not just passive aggressive disdain, active hate” Can’t just embed Ops into Dev teams; they’ll just go native
- Outline the chat we had that started this all. Here is how we snatched victory from the jaws of defeat…
- From day one of our pilot, we’ve tried to be different… not for the sake of trying to aggravate and upset people, but because we need to break the short circuits happening inside talented people We’re a startup inside an enterprise… Our job is to disrupt sustainably from the inside.
- Why did we get approved? containerisation: densification of hosting estate developer productivity recognition that we needed to innovate more to go digital
- This is why we call it Bitesize
- In large enterprise, every word gets one shot; if it doesn’t work, and it didn’t work; we already broke private cloud and DevOps We had turned DevOps in to a justification for another Silo We found this wasn’t about a resistance to DevOps, it was a resistance to current operations. For us, starting our transformation was about admitting mistakes and re-establishing credibility. Make the effort and earn trust/respect… you’ll have credit in the bank when you need to spend it. Example from this week - perf testing Self-preservation based on fear of failure
- If you have a product, who is your customer? How do you generate developer engagement - who are we competing with? Developers want DIY but not do everything Self-service but do it for me Don’t get me out of bed at 3am And I don’t want to wait for any of this AND I reserve the right to change this at any time…
- Water-scrum-fall Capital asset programmes PMO Funding model: traditional Pearson wants a 5 year plan, write of costs against planned benefits; but I don’t know what I’ll be doing in 5 months, let alone 5 years We’re one of a few strategic programs, with capex and opex, which other leaders must support; we capitalize as much as we can; long term, we’ll need funding from dev groups, right? Currently, no mechanism to do chargeback/chargethrough
- When you’re coming to the party late, you’d better bring something interesting We need infrastructure as code, easy to change, easy to test, easy to ship One of the few benefits of being so late to the market is we can skip stuff others tried already - Config management, state management, metadata fragmentation… Macro-scale, we’re trying to simplify and standardise Pearson: less natural mutation in containers We need to globally deploy, a container is a unit of deployment that we can consider a standard as it is reproducible as long as our platform layer is consistent
- The affinity with education and OSS around sharing knowledge is undeniable We’re embracing open source because: Its cheap We attract better engineers It sets expectations about what we need to be capable of internally The more we share, the more open we become, the more we share problems
- Simple goal - standardised delivery pipeline capable of delivering a consistent application binary to any cloud platform anywhere in the world Automatically… explain cycle time - didn't want to scare them!!!
- DevOps per page 1 of the textbook won’t scale 400+ dev teams != 400 DevOps!! Our product aims to deliver a no-ops experience to a user, when in reality it couldn’t be further from the truth What do our people do with the time? Build relationships, reinforce feedback loops with deeper human interaction
- DevOps per page 1 of the textbook won’t scale 400+ dev teams != 400 DevOps!! Our product aims to deliver a no-ops experience to a user, when in reality it couldn’t be further from the truth What do our people do with the time? Build relationships, reinforce feedback loops with deeper human interaction
- simple yaml workflows - > how do we want Pearson/app/platform to respond when X happens… Stackstorm By looking at trigger and action, we don’t care what tool we need and we can change it with minimal overhead Designing the abstraction of this is key, simple API/Provider model The future of operations is more engineering…
- Pearson’s motto is “Always Learning” - we’re applying that to our platform, how do we build a learning platform to avoid incidents and points where customers will get a less than desirable experience?