Downloaded 104 times
Uploaded byDocker, Inc.
DockerCon SF 2015: Enabling Microservices @Orbitz
The presentation discusses transitioning from a monolithic architecture to microservices at Orbitz, emphasizing the use of Docker and automated deployment pipelines for over 500 applications. It details the continuous delivery process, including testing, deployment, and health checks, while also highlighting the tools used such as Jenkins and Ansible. The key takeaway is the importance of creating a flexible and automated deployment platform that reduces human intervention in the release process.
More Related Content
Similar to DockerCon SF 2015: Enabling Microservices @Orbitz
![[BDD 2025 - Artificial Intelligence] AI for the Underdogs: Innovation for Sma...](https://cdn.slidesharecdn.com/ss_thumbnails/ai-aifortheunderdogsinnovationforsmallbusinesses-251124030839-72a599a4-thumbnail.jpg?width=640&height=640&fit=bounds)
![[BDD 2025 - Full-Stack Development] Agentic AI Architecture: Redefining Syste...](https://cdn.slidesharecdn.com/ss_thumbnails/fs-agenticaiarchitectureredefiningsystemcommunication-251124030838-e6c70cc2-thumbnail.jpg?width=640&height=640&fit=bounds)
![Support, Monitoring, Continuous Improvement & Scaling Agentic Automation [3/3]](https://cdn.slidesharecdn.com/ss_thumbnails/agenticcommunityseries-day3-cfd-251120170304-ddef8112-thumbnail.jpg?width=640&height=640&fit=bounds)
![[BDD 2025 - Mobile Development] Exploring Apple’s On-Device FoundationModels](https://cdn.slidesharecdn.com/ss_thumbnails/md-exploringappleson-devicefoundationmodels-251124030840-d690542c-thumbnail.jpg?width=640&height=640&fit=bounds)
![[BDD 2025 - Mobile Development] Crafting Immersive UI with E2E and AGSL Shade...](https://cdn.slidesharecdn.com/ss_thumbnails/md-craftingimmersiveuiwithe2eandagslshaderveronicaputrianggraini-251124030840-0c677f44-thumbnail.jpg?width=640&height=640&fit=bounds)
DockerCon SF 2015: Enabling Microservices @Orbitz
- 1. Enabling Microservices @Orbitz SteveHoffman @bacoboy Rick Fast @tortiepoint Senior Principal Engineers
- 5. Agenda • Brief ArchitectureOverview/History • From Monolithic to Services to Microservices with Docker • Automated Pipelines • Questions
- 6.
- 7. #dockercon 2000 Yes, we areSTILL hiring! @OrbitzTalent
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18. #dockercon 2012 • Multiple Brands •Websites • Webservices • Multiple Backends • 500+ apps / thousands of instances • Deployments Daily (sometimes more) 2015
- 19.
- 20. #dockercon Different Provisioning Tools DEVOPS Application Platform!=
- 21. #dockercon A New Experiment •Microservices? • Decompose single “service” into the actual 40+ sub-services - Any change to sub-service was a deployment of many • Could it be a simple Spring Boot App in Docker (12 factor?) • Backward compatible with existing service infrastructure. • Code to Production w/o help from other Humans
- 22. #dockercon The Docker Slave aka“The Rickbot” App App App
- 23.
- 24.
- 25.
- 26.
- 27.
- 28.
- 29.
- 30.
- 31.
- 32.
- 33.
- 34.
- 35.
- 36.
- 37. A Little MoreBackground
- 38.
- 39.
- 40. #dockercon Editorial Module • AContinuously Deployed Microservice • www.orbitz.com - (scroll down)
- 41.
- 42.
- 43.
- 44.
- 45. #dockercon Pre-Continuous Delivery 1.2-BETA-20150401-113002 Test Discard TestDiscard 1.2-BETA-20150402-093002 Build Build And so on…
- 46. #dockercon Pre-Continuous Delivery 1.2-BETA-20150401-113002 Test Discard TestDiscard 1.2-BETA-20150402-093002 Build Build Test Deploy 1.2 Build
- 47. Continuous Delivery withJenkins, Docker, and Ansible (And then Marathon)
- 48. #dockercon Yo rfast-mbp:git rfast$ yomicroservice _-----_ | | .--------------------------. |--(o)--| | Welcome to the kickass | `---------´ | Microservice | ( _´U`_ ) | generator! | /___A___ '--------------------------' | ~ | __'.___.'__ ´ ` |° ´ Y ` ? Enter the name of your service. (E.G. "my-service")
- 49.
- 50.
- 51.
- 52.
- 53.
- 54.
- 55.
- 56.
- 57. #dockercon Build if(…) { x ++; } 1.2 Merge 1.2. editorial-module.jar ./gradlewbuild {BUILD_NUMBER}
- 58.
- 59. #dockercon Build 1.2 Merge editorial-module.jar FROM orbitz/java-8 ADD build/editorial-module.jar/opt/orbitz CWD /opt/orbitz CMD java -jar editorial-module.jar if(…) { x ++; } 171.2.
- 60.
- 61.
- 62. #dockercon Deploy - hosts: dev -tasks: - name: find previous images docker_facts: image=orbitz/{{application}} register: previous - name: deploy new image docker: image=orbitz/{{application}}:{{version}} … - name: wait for service wait_for: port={{port}} … - name: check health endpoint uri: url="http://{{fqdn}}:{{port}}/health" … - name: kill old image docker: {{previous}} git pull playbook.yml (abridged)
- 63. #dockercon host-001 host-002 host-003host-004 host-005 - hosts: dev
- 64.
- 65.
- 66.
- 67.
- 68.
- 69.
- 70.
- 71.
- 72.
- 73. #dockercon How to handlefailure?
- 74. #dockercon What happens whena VM is moved?
- 75. #dockercon What if Ineed to add capacity?
- 76. #dockercon Deploy (Second Attempt) -hosts: dev - tasks: - name: find previous images docker_facts: image=orbitz/{{application}} register: previous - name: deploy new image docker: image=orbitz/{{application}}:{{version}} … - name: wait for service wait_for: port={{port}} … - name: check health endpoint uri: url="http://{{fqdn}}:{{port}}/health" … - name: kill old image docker: {{previous}} git pull playbook.yml (abridged)
- 77. #dockercon Deploy (Second Attempt) -hosts: dev - tasks: - name: find previous images docker_facts: image=orbitz/{{application}} register: previous - name: deploy new image docker: image=orbitz/{{application}}:{{version}} … - name: wait for service wait_for: port={{port}} … - name: check health endpoint uri: url="http://{{fqdn}}:{{port}}/health" … - name: kill old image git pull playbook.yml (abridged) - hosts: localhost - tasks: - name: marathon deploy marathon: image=orbitz/{{application}}:{{version}} instances=3
- 78. #dockercon Deploy (Second Attempt) Newhost setup
- 79. #dockercon Deploy (Second Attempt) MesosAgent New host setup 1.2.16
- 80. #dockercon Deploy (Second Attempt) -tasks: marathon: … playbook.yml 1.2.16 1.2.16 1.2.16
- 81. #dockercon Deploy (Second Attempt) -tasks: marathon: … 1.2.16 1.2.16 1.2.16
- 82. #dockercon Deploy (Second Attempt) -tasks: marathon: … PUT /apps/editorial-module { “image”: “orbitz/editorial-module:1.2.17” … } 1.2.16 1.2.16 1.2.16
- 83. #dockercon Deploy (Second Attempt) PUT/apps/editorial-module { “image”: “orbitz/editorial-module:1.2.17” … } - tasks: marathon: … 1.2.16 1.2.16 1.2.16 app = GET /v2/apps/editorial-module if not app then deploy_id = POST /v2/apps { “image”: “orbitz/editorial-module:1.2.17”, “id”: “editorial-module” } else deploy_id = PUT /v2/apps/editorial-module { “image”: “orbitz/editorial-module:1.2.17” } end if while GET /v2/deployments contains deploy_id // still deploying end // deploy complete
- 84. #dockercon Deploy (Second Attempt) -tasks: marathon: … PUT /apps/editorial-module { “image”: “orbitz/editorial-module:1.2.17” … } 1.2.16 1.2.16 1.2.16
- 85. #dockercon Deploy (Second Attempt) -tasks: marathon: … 1.2.16 1.2.16 1.2.16
- 86. #dockercon Deploy (Second Attempt) -tasks: marathon: … 1.2.16 1.2.16 1.2.16 1.2.17 1.2.17 1.2.17
- 87. #dockercon Deploy (Second Attempt) -tasks: marathon: … /health 1.2.16 1.2.16 1.2.16 1.2.17 1.2.17 1.2.17
- 88. #dockercon Deploy (Second Attempt) -tasks: marathon: … /health 200 OK 200 OK 200 OK 1.2.16 1.2.16 1.2.16 1.2.17 1.2.17 1.2.17
- 89. #dockercon - tasks: marathon: … 1.2.171.2.17 1.2.17
- 90. #dockercon And off tothe next environment… 1.2.17 1.2.17 1.2.17
- 91.
- 92.
- 93.
- 94.
- 95.
- 96.
- 97.
- 98.
- 99.
- 100.
- 101.
- 102. #dockercon What’s inside thecontainers? • Spring Boot • Dropwizard Metrics (formerly Coda Hale, Yammer) • Consul Registration/Discovery • Logstash + Logback • Swagger • Hystrix • Retrofit + Consul OrbitzWorldwide/consul-client
- 103. #dockercon –You “Why didn’t youuse {{.x}}?”
- 104. #dockercon Keeping an eyeon… Kubernetes Amazon Elastic Container Service Docker Swarm
- 105. #dockercon Summary • Create ashared platform for docker deployments using shared and app-specific “localhost” helpers — this was ours, yours SHOULD look different — adapt to change, don’t fight it. • Take people out of the release process - Docker - repeatable applications - Chef - repeatable infrastructure — Environment aware - Jenkins - repeatable releases • Delineate configuration concerns: - Known at Compile time — Bake into Docker image - Known at Boot time — Bake into Playbook/Launcher - parameter to Docker run - Changes Anytime — Externalize (consul K/V, etcd, zookeeper)
- 106.