The document discusses how Pearson is integrating Docker to address challenges in their vast and diverse tech stack across various cloud platforms. Docker presents a solution by providing a standard deployment method and allowing developers to choose their technology freely, while also ensuring operational consistency. The presentation emphasizes the importance of containerization for modern applications and suggests a shift towards platform as a service with a focus on immutable infrastructure.

1. Is Docker the answer to the Stack x Platform x Cloud explosion thats
engulfed the Enterprise?
Is IaaS really the right model? or just the one that worked?
Has PaaS’s time finally arrived.
Can Docker make OS, library, stack choices irrelevant to hosting and Ops?
This talk looks at how Pearson is investigating and moving towards
Docker, what we’ve learned so far, and what you can learn from our
experiences.
Synopsis

2. Docker at Pearson
Removing environmental differences.
name: Simon Vans-Colina
twitter: @simonvc
disclaimer: Views are my own and may not
represent those of my employer etc.

3. Docker@Pearson so far.

4. Why?
Pearson is a big company.
Many integrated businesses.
Basically ALL the stacks.
(node, ruby, django, php, drupal, java)
On lots of clouds.
(Google, Rackspace, Rightscale, vCloud,
AWS, Datapipe, Azure)

5. With many toolsets
Chef, Puppet, Ansible, Rightscripts, tarball,
scripted etc
“The nice thing about standards is there’s so many to choose from.” --Andrew S. Tanenbaum
Ubuntu, RHEL, Centos, and the other one.

6. An on going problem
We’re adding technologies faster than we’re
converging them.
Large enterprise problem: by the time you
standardize on something, its obsolete.

7. How did we get here?
Devs just want to host their apps.
But.. without the restrictions on their
technology.
So they go lower and ask for cloud
infrastructure.

8. Devs vs Ops
What devs want: Their choice of technology.
Not to get woken up in the middle of the
night.
What ops want: Their choice of technology
so they know what to do in the middle of
the night.

9. Docker to the Rescue
A common deploy method.
Consistent rollback method.
Convergence happens not-at-deploy-time.

10. Baby Steps.
**Except when it doesn’t
It’s not ready for production*
*it works**
API and tool changing to fast build tooling around.

11. Baby Steps.
1. Use it for build processes.
Jenkins in Docker.*
*This did not go well.. See 12factor.net
RPM creation in docker.
Replace virtualenv/rbenv

12. Baby Steps.
2. Use it for isolating low risk services.
Restful X services
DevOps tooling into Docker.

13. Post 1.0..
Make Docker a valid deploy target.
Replace .egg gem npm .deb, .rpm, .war
with containers.
Build supporting infrastructure.
etcd / supervisord / confd

14. Host Networking
docker run --net=host busybox ip a
Makes docker a lot simpler conceptually.
Equivalent to a generic virtualenv now.

15. Zombies: Or your docker
container is probably
broken.
http://phusion.github.
io/baseimage-docker/

16. Apps fit for platform.
12 Factors is a good guide for the kinds of
apps that will benefit from containerization.
http://12factor.net/

17. A DevOps Social Contract
Ops: “If you can make your app/stack run in
a docker container, we can host it”
and
Devs: “We need ensure our app can be
containerized.”

18. Great opportunities
Zero Downtime releasing.*
*(does not fix db/schema problems)
Deploy wide, instead of deep. Average load
over many apps, avoid autoscaling.

19. Save £££
Stop using AWS instances for isolation..
Paying for VM’s when you don’t need to.
lots of £

20. Docker is fast.
Alias vim=’docker run -i -t -v $(pwd):/host
simonvc/vim’

21. Mindset differences.
Immutable infrastructure:
Provisioning less important.
Containerised apps:
Centralised Logging more important.
Membership and discovery important.
Live Config (etcd) not provisioned config.

22. The new paradigm
Platform as a service.
Scale all apps widely.
Stack Agnosticism.
Immutable/Disposable infrastructure.
Commoditized operating systems.

23. Docker is awesome.
Radical disruptive technology.
Time to reassess:
● Restricted tech stacks
● Convergent config systems
(chef/puppet)
● Re-using or Upgrading systems

24. @simonvc
Come work for Pearson
“Always Learning”
Management that gets DevOps. Interesting problems.