Downloaded 14 times
![~ (master ✔) docker images | grep watchdog
watchdog_web [...] 38.74 MB](https://image.slidesharecdn.com/deploying3timesadaywithoutadowntimerockettechsummmit2015-151001170835-lva1-app6892/75/Deploying-3-times-a-day-without-a-downtime-Rocket-Tech-Summit-in-Berlin-49-2048.jpg)
!["Resilience is accepting your [...] reality"
https://en.wikipedia.org/wiki/Elizabeth_Edwards](https://image.slidesharecdn.com/deploying3timesadaywithoutadowntimerockettechsummmit2015-151001170835-lva1-app6892/75/Deploying-3-times-a-day-without-a-downtime-Rocket-Tech-Summit-in-Berlin-72-2048.jpg)
Uploaded byAlessandro Nadalin
Deploying 3 times a day without a downtime @ Rocket Tech Summit in Berlin
Alessandro Nadalin's presentation at the Rocket Tech Summit 2015 focuses on how Namshi deploys microservices multiple times a day without downtime by utilizing Docker and a decentralized approach. The company emphasizes resilience, robustness, simplicity, safety, and pragmatism in their software development processes, aiming to keep teams small and communication efficient. Nadalin highlights the importance of maintaining a flexible deployment workflow and the use of internal infrastructure for testing to ensure a seamless operational environment.
More Related Content
Similar to Deploying 3 times a day without a downtime @ Rocket Tech Summit in Berlin
Deploying 3 times a day without a downtime @ Rocket Tech Summit in Berlin
- 1. Deploying 3 times aday without any downtimeAlessandro Nadalin - VP Tech @ Namshi.com Rocket Tech Summit 2015 - September 2015 - Berlin
- 2. When was thelast time that *.namshi.com was down?
- 3.
- 4.
- 5.
- 7.
- 8.
- 9.
- 10.
- 11. SOA ~40 services docker heavy onJS devoted to experimenting
- 12. SOA ~40 services docker heavy onJS devoted to experimenting Result?
- 14. A bit ofhistory...
- 15. “When are youguys gonna deploy it?”
- 16.
- 17.
- 18.
- 19.
- 20. This is howit works @ Namshi
- 21. We don’t likecentralization
- 22. Single Point ofFailure
- 23. On error, rollbackall the things!
- 24.
- 25.
- 26. Don’t wait tomorrowfor what you can get today
- 27.
- 28.
- 29.
- 30. ~40 services *⅔ people = ~100 engineers
- 32. ~15 people rotate,assume different roles
- 33.
- 34.
- 35. “adding manpower to a late projectmakes it later” https://goo.gl/Bc0uBf
- 36. Communication overhead takes time toget used to the whole thing
- 37. keep things small,flat, plain and simple
- 38. means small teams,simple software
- 39. What is thesimplest way to get devs their development environment?
- 40. FROM alpine RUN apkadd --update nodejs COPY . /src CMD node /src/index.js
- 41. FROM alpine RUN apkadd --update nodejs COPY . /src CMD node /src/index.js Docker
- 42. How long doesit take to get started with any of the microservices?
- 43. git clone git@github.com:namshi/stuff.git cdstuff echo “127.0.0.1 stuff.namshi.com” >> /etc/hosts docker-compose up
- 44. git clone git@github.com:namshi/stuff.git(20s) cd stuff echo “127.0.0.1 stuff.namshi.com” >> /etc/hosts docker-compose up
- 45. git clone git@github.com:namshi/stuff.git(20s) cd stuff (...) echo “127.0.0.1 stuff.namshi.com” >> /etc/hosts docker-compose up
- 46. git clone git@github.com:namshi/stuff.git(20s) cd stuff (...) echo “127.0.0.1 stuff.namshi.com” >> /etc/hosts (...) docker-compose up
- 47. git clone git@github.com:namshi/stuff.git(20s) cd stuff (...) echo “127.0.0.1 stuff.namshi.com” >> /etc/hosts (...) docker-compose up (depends on the image)
- 48. git clone git@github.com:namshi/stuff.git(20s) cd stuff (...) echo “127.0.0.1 stuff.namshi.com” >> /etc/hosts (...) docker-compose up (~5s with alpine)
- 49. ~ (master ✔)docker images | grep watchdog watchdog_web [...] 38.74 MB
- 50. Make it sothat it takes <2m to start hacking on your services
- 51.
- 52. How do weget this stuff to production?
- 53. FROM alpine RUN apkadd --update nodejs COPY . /src CMD node /src/index.js
- 54. FROM alpine RUN apkadd --update nodejs COPY . /src CMD node /src/index.js It’s that simple.
- 55. Ok, but howdo I get to deploy the container?
- 56. There’s a bot foreverything
- 57. @c3po deploy app1patch-1 to staging
- 58. All it takesis a 100 locs or so
- 59. Is it reallywithout a downtime?
- 60. We’re actually downevery time we deploy
- 61. it’s just thatno one notices
- 62. keep a secondarysetup up&running
- 63. deploy there (withdowntime), switch the LB
- 64.
- 65. Everything seems simple, buthow do you glue all of this?
- 68.
- 69.
- 70. We build followingfew principles:
- 71.
- 72. "Resilience is acceptingyour [...] reality" https://en.wikipedia.org/wiki/Elizabeth_Edwards
- 73.
- 74. "Be conservative inwhat you send, be liberal in what you accept" https://en.wikipedia.org/wiki/Robustness_principle
- 75.
- 76. "Innovation is sayingno to 1,000 things" http://www.goodreads.com/quotes/629613-people-think-focus-means-saying-yes-to-the- thing-you-ve
- 77.
- 78. "Each calling functionmust check non-void function return values, and the validity of parameters must be checked inside each function." http://sdtimes.com/nasas-10-rules-developing-safety-critical-code/
- 79.
- 80. "Each calling functionmust check non-void function return values, and the validity of parameters must be checked inside each function, unless you are 1000% freaking sure" http://sdtimes.com/nasas-10-rules-developing-safety-critical-code/
- 81. How does thetypical workflow look like?
- 83. spend time spec-ingthings out before accepting them in the backlog
- 84. “if it’s notsimple enough, it’s wrong”
- 86. +1 from alead, less formal review from peers
- 87. “more deletions, lessadditions”
- 89. “we process 5builds in parallel, don’t piss others off”
- 91. “don’t test everything, justwhat you fear”
- 92.
- 93.
- 94.
- 95.
- 96. MVA novice engineers arethe ones who can’t abstract
- 97. MVA novice engineers arethe ones who can’t abstract senior engineers are the ones who can abstract
- 98. MVA novice engineers arethe ones who can’t abstract senior engineers are the ones who can abstract great engineers are the ones who know when to abstract
- 99.
- 100.
- 101. failure is alwaysan option
- 102.
- 103.
- 104.
- 105.
- 106. parallel deployments basedon cookie
- 107.
- 108. use the internalinfra as a testing platform
- 109.
- 110. simplify the dangerousstuff, think 3ice before touching
- 111.
- 112. Desktop is thenew Blackberry
- 113. Whether you are runningeverything through an isomorphic JavaScript framework
- 114. every day https://eng.asana.com/2014/02/scaling-asana-com/ &https://asana.com/luna
- 115. or fatass rubyfrontends
- 116. 30 times aday https://github.com/blog/1241-deploying-at-github
- 117. or you’re just thatcrazy
- 118.
- 119.
- 120. Roll it outlive.
- 121.
- 122.