A look into why Channel 4 needed to speed up the software delivery pipeline and how a Micro services architecture, a CI/CD approach and Docker is helping to make that happen. Video: Coming Soon Join DevOps Exchange London here: http://www.meetup.com/DevOps-Exchange-London Follow DOXLON on twitter http://www.twitter.com/doxlon

1. Speeding up software delivery at
Channel 4
Where we were, are and going to
be

2. • Terrestrial UK broadcaster
• First terrestrial on-demand service in the UK
• We build, deploy and manage
– Websites
– Web services
– VoD Services
– Device apps
– Data services
• Ad funded commercial model
Background to C4

3. • We want to create the best personalised
user experience
• To deliver the best experience we need to
innovate and get enhancements into
production efficiently
• Application architecture, tools, practices
constraining us.
Business Problem

4. • Early adopter of cloud (circa 2009)
• Cloud first strategy
• Templated stacks via custom deployment
framework (Bash + xml)
Where we were…

5. • Monolithic programme metadata DB
• Deficiencies in cloud management
• High test and deployment overhead
• Onerous release process
• Dev dependency on sys engineering
Problems!

6. • Tactical & Strategic
• Bolts and braces
• PoC, evaluate, drop or adopt
• MVP
Approach

7. • Tag, query, manage
• Open up access
– Tools
– Config
• Release more
– Get everyone ready
Tactical

8. • Decompose the monolith
• CI/CD approach
• Self service and more automation
• Change mind-sets
• Promote shared responsibility
Strategic

9. • Micro service architecture
Where we are

10. The Monolith!

11. The Micro!

12. • First class CI/CD orchestration tool
• Integrate testing into an automated pipeline
• Standardise development practices
– TDD
• Swagger
– Framework use
– Improve operational support within apps
• Metrics
• Operations endpoints
– Docker implementation
Move towards CI/CD Practices

13. Bamboo + Jira

14. Automated Pipeline

15. Tooling
PMCF

16. • Spec -> Build Test -> Cut Code
Swagger

17. Embedded Ops Support

18. Standard Dockerfile

19. • Improved efficiency
• Change & product lifecycle visibility
• Better understanding of Docker
• Happy people J
Outcomes

20. • Implement feature branching / toggling
across our apps
• Fully self service project initialisation
• Harvest metrics, store and expose
• Docker clustering
• Service virtualisation
What we’re going next

21. New pipeline

22. • Move towards continuous deployment
• Canary releasing
– Backwards compatibility
– Traffic shaping
• Scorecard deployments
– Leverage metrics, central logging etc
– Fail fast, fix forward
What we’re doing next next

23. • Highly distributed architecture
– Dependency management
– Inter process comms overhead
• Our experience with Storm
– Fault tolerance
• Docker scheduling logic
• Support model
Nuts we’ll need to crack

24. • brendanfoxen@gmail.com
• https://www.linkedin.com/in/brendanfoxen
Thanks! J