This document summarizes Liberty Mutual's journey with Docker EE to modernize applications and enable continuous deployment to the cloud. It discusses how Liberty Mutual started with Docker Datacenter 1.0 in 2015 to containerize applications and build a microservices architecture. They later upgraded to Docker Datacenter 2.1 to improve configuration management and reduce overhead. As of 2017, Liberty Mutual had over 330 services in production and Jenkins performing hundreds of deploys per day across 100 nodes and over 1500 services. The company aims to further automate operations using Kubernetes and improve security and inventory management. Alignment with agile teams was important to their success with Docker EE.

1. v
Liberty Mutual’s Journey with Docker EE
All Roads Lead to the Cloud

2. Sr. Architect, Liberty Mutual
Eric Drobisewski
Architect, Liberty Mutual
Michael Letourneau

3. • In business since 1912
• 50,000+ employees in 800+ offices worldwide
• Diversified insurer with operations in 30 countries
and economies
• Is the 3rd largest property and casualty insurer in
the US based on 2017 direct written premium data
• Ranks 68th on Fortune 100 list of largest US
corporations based on 2017 revenue
• Reported $39.4 billion in annual consolidated
revenue as of Dec. 31, 2017
Liberty Mutual
Global enterprise headquartered
in Boston, Mass.

4. Public
Cloud
Software-
Centric
Continuous
Deployment
Balanced
Investments
Leading the Change
Our people are the core of driving innovative technology transformation
Customer-
Driven

5. Containerize Traditional /
Legacy Applications
• Improve CapEx / OpEx,
Build & Test for
Continuous Integration,
Cloud Migration, Cloud
Portability, Security
Modernize Traditional / Legacy
Apps into Microservices
• Identify existing services
(SOA) that can be refactored
into micro-services
• Accelerate dev & deploy
cycle times, simplify lifecycle,
improve security
Build New Microservices
and Modern Apps
• Enable greenfield modern application
development and delivery
• Improve developer experience
To improve our velocity at scale we must enable multiple paths!
A Single Lane Road is not Enough

6. Circa: Fall 2015
Our Early Days

7. U.S. Consumer Markets

8. • Java Batch
• WebUI
• Database
Sales
Compensation
• Changing Requirements
• Different Services
• Netflix OSS
NextGen
Architecture
Our Start

9. Dev à Prod Automate CI/CD
Encryption Enablement
Our Start – Part II

10. • Needs to be totally cloud based – AWS
• Went with the beta version of the Docker Datacenter
Quickstart
• Used existing internal Jenkins for CI/CD
Round 1

11. BUT....
• Interlock 1.0 - Well it was a 1.0 release
• Needed a way to modify the custom
hardware image
• Not a HUGE amount of usage of our
environment at this time, beyond the significant
Goal application the microservice architecture
team is testing and iterating over their designs
and some base services
Round 1 fun?

12. Round 2
+ +

14. GOTCHAS
• Configuration management
• Cloud formation dependencies
• Too much overlay
• DTR got very FULL
• HRM caveats
GOOD STUFF
• Jenkins is great
• Overlays are great
• LOTS of builds
• LOTS of usage
Round 2 fun (mostly)

15. Goal!
Monolithic Application
Multiple Java Batch
Processes
Web User Interface
&
Database
Multiple Java Batch
Containers
Web User Interface in
Specialized Container
&
Database in RDS

16. June 2017 Live August 2017 December 2017
Our world from start to today
• DDC V1
• Intelock
• Modified Quickstart
• Chef
• DDC 2.1
• HRM
• DDC 2.1.5
• Multi-HRM + Fixes
Production
330+
services
Non-production
Jenkins
does 100s of
deploys a day
• 100 nodes
• 518 Stacks
• 1520 Services
• 1977 Running
Containers
Round 1 Round 2 GOAL!
Today

17. • Containers are going
to be our life blood
• Looking into Kubernetes
• More Automation
• Faster Infrastructure Upgrades
• Inventory Management
• Aqua Security Controls
Our Future

18. • Vendor Partnership
• "Friendly Testers"
• I/O
• CPU
Lessons learned
• Workload
• Education
• Tech Debt
• Security First
Agile Team Alignment is a Must!