With the growing popularity of micro services and containers there are a plethora of stories of success and failure, patterns and anti-patterns. This talk aims to give insight to one such implementation of containerised services at a 170 year-old FTSE100 organisation. We will touch on what it took to get a project like this off the ground, how we made technology choices that aligned to our strategy and what we discovered when working collaboratively with our development community around application readiness. This represents the story to date of an in-flight engineering project to modernise the digital estate of a global enterprise organisation and how the scale of the operation is leading us to challenge some of the established beliefs around DevOps. Attendees will walk away with some advice on how to start similar initiatives in their organisation, how their technology strategy will impact their own tool/provider choices and what to look out for in the application space that can inhibit or support adoption.

1. An Example of a End
to End Stack for the
Container Age
Chris Jackson
May 2016
1
qingqing. Shutterstock

2. Me
Ex-Racker
Frustrated Coder
Education Disrupter
Reformed Leader
This…
@chriswiggy
2

3. My Work
Inspiring Mission
Passionate People
From ISBN to FQDN
Embrace the Challenge
3

4. How Well Do You Know Pearson?
4
Quiz Time - Which of these do you think Pearson has owned or owns?

5. 5
We cannot solve our problems with
the same thinking we used when
we created them.
Albert Einstein
Education is what remains
after one has forgotten
everything he learned
in school.
Albert Einstein

6. Pearson Today
Becoming a digital education leader
40,000 staff globally
Over 30,000 servers and 2,000 apps
400+ Developer Teams
Diverse portfolio of applications

7. Application Portfolio Today
• Complicated
• Monolithic
• Difficult to Change
• Slow Moving
7

8. Technology Operations
• Pearson’s central IT organisation
• Victim of “Shadow IT”
• Application Cemetery
• Fragmented approach
• Bottlenecked customers
8

9. What Did Our Developers Think?
9

10. Review - Problem Statement
• 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…
10

11. 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
11
• 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…

12. Bitesize - Born Different
12

13. Bitesize - Timeline to Date
• August 2015 - Initial Pilot approved
• September 2015 - Alpha customer agreed
• December 2015 - Bitesize chosen as preferred PaaS solution for Pearson
• December 2015 - Pilot closes, project extension agreed
• March 2016 - First non-production application environments loaded
• April 2016 - Full project funding approved
• June 2016 - First production workloads
13

14. Question…
14
Were we lucky, or was this by design?

15. “I'm a greater believer in luck, and I find the harder
I work the more I have of it”
Thomas Jefferson

16. Eating the Elephant
1.Our Approach
2.DevOps
3.Technology
16

17. Products in Enterprise IT
Having a Product Approach Gets You:
• Customer focus
• There is no Enterprise IT “Stick”
• A clear set of metrics to measure your success
• A dedicated commitment to iterate
• We’re a start-up in an Enterprise…
• Sustainable out of the box
17
“Most organizations have a “project” mindset when it
comes to software as well. The functional roles emerge
from their silos as needed to work on the project, and
then disband once done. Good software development
benefits from a “product” mindset where the team,
instead, stays dedicated to the product.”
Michael Coté
https://medium.com/@cote/roles-and-responsibilities-for-devops-
and-agile-teams-fdacbffb4cb4#.4i8bm63t5

18. Serving Developers
Creating a World Class Developer Experience…
18

19. Why Containers?
19

20. Open Source at Pearson
20
Ingress ControllerPython Client Kubernetes Pack
KnowledgeEducation
Sharing Information
Open Source
Sharing Code

21. DevOps at Pearson
21
What It SHOULD Be How It SCALES Out
We need a common and uniting initiative!

22. Marketing Slide…
22

23. What’s In Our Product?
23

24. “Simple can be harder than complex: You have to work hard to get your
thinking clean to make it simple. But it’s worth it in the end because once
you get there, you can move mountains.”
Steve Jobs

25. Delivery Pipeline
25
I need a…

26. DevXOps
26
Developers Operations
QA Security Network
Other functions are “channel partners” for the pipeline Delivered via a pull from a git repository

27. Runtime Environment
27

28. Multi-Region Deployments
28
Compute
Region
A1
Compute
Region
A2
Compute
Region
A3
PII Data Region One
Compute
Region
B1
Compute
Region
B2
Compute
Region
B3
PII Data Region Two
Global Platform Runtime & Orchestration
Regional Platform
Services
Regional Platform
Services
Infrastructure Repository Application Repository
Regional Configuration:
Database Creation
Database Credentials
Character Set
Language Pack
Global Configuration:
Database Schema
Database Connection String
Localisation Context

29. If This… Then That - The New Operations
29
Things that Happen Desired Response Mechanism to Execute
Stuff We Care About Stuff We 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
…

30. What Are We Doing Next?

31. Business Roadmap
Rubber stamping a product, not a project
Building a better home for a high-performing engineering team
Developing a talent pipeline and career track for the future
Capability assessments for teams, applications, processes
Manage “change shock”
Alignment, alignment, alignment!
31

32. Technical Roadmap
Data persistence on native containers
Logging solutions for Operations and Developers
Consistent access control and RBAC
Increasing deployment frequency of Platform
Expansion of the deployment DSL
Operations run-books
Intelligent Service Bots (aka Sentient Managed Services)?!?!
32

33. Key Points
1.Running cool tech is easy, getting people on board takes time
2.Do not underestimate your impact on your company’s innovation
3.Tooling is a distraction in a higher-order value conversation
4.Think about your product and your direct and channel customers
5.Platform adoption drives application improvement and vice-versa
33

34. The End to End Stack?
34
Build It Run It
*Stuff in the Middle*
Trust & Feedback

35. Get Involved?
https://github.com/orgs/pearsontechnology/
More coming soon…!
@chriswiggy
We’re hiring… http://pearson-technology.jobs/
35