This is the talk I gave at Agile2014 discussing how to think about your deployment choices as surfaces on an airplane. Paper airplanes were thrown as a part of this talk.
1. R E D U C I N G R E S I S TA N C E
D E P L O Y M E N T A S A S U R FA C E
J E F F R E Y H U LT E N
W H I T E PA G E S , I N C .
F L I C K R . C O M / P H O T O S / D E G E U Z E N / 2 9 8 0 6 3 7 9 5 1
A G I L E 2 0 1 4
3. T H E R E WA S A
D E V E L O P E R ,
W R I T I N G A W E B
A P P L I C AT I O N
F L I C K R . C O M / P H O T O S / Y O U R D O N / 2 6 8 1 6 8 6 2 2 0
O N C E U P O N A T I M E
4. S H E D E P L O Y E D
C O D E T O
P R O D U C T I O N
B Y H A N D
F L I C K R . C O M / P H O T O S / S E E M I N G L E E / 8 1 8 4 4 4 0 4 1 1
A N D E V E RY D A Y
5. H E R T E A M M AT E
O V E R W R O T E
H E R C H A N G E S
F L I C K R . C O M / P H O T O S / P H I L F O T O S / 5 5 6 5 5 2 9 6 9 9
U N T I L O N E D A Y
6. S H E D E C I D E
T O PA C K A G E
H E R C O D E
F L I C K R . C O M / P H O T O S / H A L F B I S Q U E D / 2 3 5 3 8 4 5 6 8 8
B E C A U S E O F T H I S
7. T H AT D I D N ’ T
A C C O U N T F O R
C O N F I G U R AT I O N
F L I C K R . C O M / P H O T O S / J O H N C A B E L L / 5 8 8 4 4 9 0 5 8 8
B U T,
8. S H E D E P L O Y E D
T H AT PA C K A G E
W I T H C H E F *
* or other configuration
management tool, our protagonist
isn’t picky… F L I C K R . C O M / P H O T O S / E M E D I A / 1 3 8 7 0 7 0 1 8 9 4
S O ,
9. S H E D E P L O Y E D
T H AT PA C K A G E
W I T H P U P P E T *
* I told you she isn’t picky… F L I C K R . C O M / P H O T O S / J E Y H / 2 7 9 6 2 2 3 8 0 4
S O ,
10. D E P L O Y M E N T
T I M E
C O M P L E X I T Y
F L I C K R . C O M / P H O T O S / B I T T E R J U G / 7 6 7 0 0 5 5 2 1 0
B U T T H A T L E D T O
11. S H E P U T I T I N
A D O C K E R
C O N TA I N E R *
* or AMI… Like I said, not picky…
FLICKR.COM/PHOTOS/33280166@N02/5354725682
U N T I L F I N A L LY
12. S H E A P P L I E D
T H E P R I N C I PA L S
O F T H E T W E LV E
FA C T O R A P P
http://12factor.net/ F L I C K R . C O M / P H O T O S / P E T E R R A S / 9 8 8 3 5 8 2 1 0 6
A N D
13. S H E C H O S E H E R
C O N S T R A I N T S T O
F R E E H E R S E L F O F
D E P L O Y M E N T PA I N
F L I C K R . C O M / P H O T O S / C H I O T S R U N / 4 9 0 4 2 6 1 1 5 0
A N D E V E R S I N C E T H A T D A Y
15. T H E T W E LV E FA C T O R S
• I. Codebase
One codebase tracked in revision
control, many deploys
• II. Dependencies
Explicitly declare and isolate
dependencies
• III. Config
Store config in the environment
• IV. Backing Services
Treat backing services as attached
resources
• V. Build, release, run
Strictly separate build and run stages
• VI. Processes
Execute the app as one or more
stateless processes
• VII. Port binding
Export services via port binding
• VIII. Concurrency
Scale out via the process model
• IX. Disposability
Maximize robustness with fast startup
and graceful shutdown
• X. Dev/prod parity
Keep development, staging, and
production as similar as possible
• XI. Logs
Treat logs as event streams
• XII. Admin processes
Run admin/management tasks as one-
off processes
16. T H E O N E
FA C T O R
F L I C K R . C O M / P H O T O S / A N I R U D H K O U L / 3 7 2 5 9 3 9 5 9 4
K E E P
I T
S I M P L E A N D
S T R A I G H T F O R WA R D
17. S I M P L E A I N ’ T
E A S Y
"Steve Jobs Headshot 2010-CROP" by Matthew Yohe (talk)(Transfered by fetchcomms/Original uploaded by Matt Yohe) - I (Matt Yohe (talk)) created this work entirely by myself. (Original uploaded on en.wikipedia). Licensed under Creative Commons Attribution-Share Alike 3.0 via
Wikimedia Commons - http://commons.wikimedia.org/wiki/File:Steve_Jobs_Headshot_2010-CROP.jpg#mediaviewer/File:Steve_Jobs_Headshot_2010-CROP.jpg
“Simple can be harder than
complex: You have to work
hard to get your thinking
clean to make it simple. But
it’s worth it in the end
because once you get there,
you can move mountains.”
― Steve Jobs
18. A H A R D S E L L ?
"Edsger Wybe Dijkstra" by Hamilton Richards - manuscripts of Edsger W. Dijkstra, University Texas at Austin. Licensed under Creative Commons Attribution-Share Alike 3.0 via Wikimedia Commons - http://commons.wikimedia.org/wiki/File:Edsger_Wybe_Dijkstra.jpg#mediaviewer/
File:Edsger_Wybe_Dijkstra.jpg
“Simplicity is a great virtue
but it requires hard work to
achieve it and education to
appreciate it. And to make
matters worse: complexity
sells better.”
― Edsger Dijkstra
21. Y O U ’ R E A
P I E C E O F
PA P E R
B U T
F L I C K R . C O M / P H O T O S / 9 4 2 4 6 3 8 3 @ N 0 0 / 8 6 3 7 4 2 1 2 1 9
22. I N C R E A S E L I F T
& D E C R E A S E
D R A G
F L I G H T R E Q U I R E S T H A T Y O U
F L I C K R . C O M / P H O T O S / J A S O N - S A M F I E L D / 5 3 8 7 9 3 4 8 3 2
23. D O E S N ’ T H AV E
E N O U G H
S T R U C T U R E
A F R E S H S H E E T O F PA P E R
F L I C K R . C O M / P H O T O S / T H I B A U D _ S A I N T I N / 1 4 4 5 1 1 7 5 8 4 5
24. H A S N O L I F T
A B A L L O F PA P E R
F L I C K R . C O M / P H O T O S / 3 3 8 5 2 6 8 8 @ N 0 8 / 4 4 6 2 0 2 9 7 8 8
25. A N D Y O U C A N
F LY
F L I C K R . C O M / P H O T O S / C H R I S C H A N P H O T O G R A P H Y / 3 6 1 1 6 8 6 7 8 4
B U T F O L D T H E PA P E R
C A R E F U L LY
26. D E P L O Y M E N T S U R FA C E ?
S O W H A T C O N S T I T U T E S
27. L I B R A R I E S A N D
F R A M E W O R K S ?
I S I T
F L I C K R . C O M / P H O T O S / S PA M / 5 0 8 6 1 6 8 7 3 9
28. R U N T I M E S ?
W H A T A B O U T
F L I C K R . C O M / P H O T O S / R O FA N AT O R / 6 4 5 4 1 0 8 7 3 1
29. C O M M O N
S E R V I C E S ?
C O U L D I T B E
F L I C K R . C O M / P H O T O S / 1 S T P I X _ D I E C A S T _ D I O R A M A S / 7 1 0 4 4 8 9 7 1 5
30. W I R E
P R O T O C O L S ?
H O W A B O U T
F L I C K R . C O M / P H O T O S / K T G E E K / 6 2 6 4 0 1 8 7 6 4
31. B U S I N E S S
P R A C T I C E S ?
O R
F L I C K R . C O M / P H O T O S / F R E D E R I C K M D R O C K S / 6 1 5 4 6 7 8 0 6 8
33. A C O N T R O L
E V E RY S U R FA C E R E Q U I R E S
F L I C K R . C O M / P H O T O S / D AW I L S O N / 5 1 2 8 6 9 4 7 7 4
34. L I B R A R I E S A N D F R A M E W O R K S
• Does the third party framework solve more problems
than it creates?
• Will that still be as true in the last week of the project
as it is in the first?
• Is there a simpler way?
36. R U N T I M E S
• Runtime: Ruby VM, JVM, Erlang VM, Binary Executable
• How many runtimes are needed to serve your
customers?
• Are you adding complexity because your runtime
doesn’t work the way you need to?
37. E X A M P L E : R U B Y, U N I C O R N ,
A N D C O N N E C T I O N P O O L S
38. R U N T I M E S ? N O T L A N G U A G E S ?
• Languages are (mostly) a build time concern.
• Runtimes are a deploy time concern.
39. – R I C H H I C K E Y
We program with constructs[...] but we are in a
business of artifacts.
40. C O M M O N S E R V I C E S
• How many data stores/in-memory caches/load
balancers are you using?
• Does your team have the expertise to support them
all?
• Does your team have the time/‘bandwidth’ to learn a
new service?
• Nothing is a simple as the packaging says.
41. D U P L I C AT E C O M M O N S E R V I C E S
Postgres & MySQL
Redis & Memcache
Riak & Cassandra
Nginx & Apache HTTPd
Zookeeper & etcd
ActiveMQ & Rabbit MQ
42. W I R E P R O T O C O L S
• Eventually you will need to look at the traffic.
• Can you inspect your services on the wire?
• Does a new wire protocol justify the additional
complexity?
43. D U P L I C AT E W I R E P R O T O C O L S
HTTP & ???
Avro & Thrift & Protobuf
JSON & XML
44. B U S I N E S S P R A C T I C E S
• Do your practices lift you up or drag you down?
• Do you release features faster than the code rots?
• Do you expect to find all defects before you go to
production?
45. - E D S G E R W D I J K S T R A
The art of programming is the art of organizing
complexity, of mastering multitude and avoiding
its bastard chaos as effectively as possible.
F L I C K R . C O M / P H O T O S / 2 9 4 8 7 7 6 7 @ N 0 2 / 4 2 5 5 0 2 6 8 7 2
46. R E M E M B E R
O U R
D E V E L O P E R ?
F L I C K R . C O M / P H O T O S / Y O U R D O N / 2 6 8 1 6 8 6 2 2 0
I N T H E B E G I N N I N G …
47. S T R AT E G I E S O F D E P L O Y M E N T
• Manual Push
• Package Push
• Configuration Management Tool (Chef/Puppet)
• Docker Container
48. M A N U A L P U S H
$ for s in 1 2 3; do
rsync -a ~/src web${s}.example.com:/opt/app;
ssh web${s}.example.com
sudo service apache2 restart;
done
49. M A N U A L P U S H
$ for s in 1 2 3; do
rsync -a ~/src web${s}.example.com:/opt/app;
ssh web${s}.example.com
sudo service apache2 restart;
done
50. C R E AT E PA C K A G E
$ fpm -s dir -d deb -n myapp -v 1.2.3 ~/src
Created deb package {:path=>”myapp_1.2.3_amd64.deb”}
51. I N S TA L L PA C K A G E
$ sudo dpkg -i myapp_1.2.3_amd64.deb
52. C H E F R E C I P E
apt_package “myapp” do
source “/path/to/myapp_1.2.3_amd64.deb”
action :install
end
53. D O C K E R F I L E
FROM ubuntu:trusty
MAINTAINER Debbie Dev <ddev@myappco.com>
ADD ./myapp_1.2.3_amd64.deb /opt/pkgs
RUN dpkg -i /opt/pkgs/myapp_1.2.3_amd64.deb
ENV ENVIRONMENT prod
CMD service start myapp
54. The first step toward the management of
disease was replacement of demon theories and
humours theories by the germ theory. That very
step, the beginning of hope, in itself dashed all
hopes of magical solutions.
It told workers that progress would be made
stepwise, at great effort, and that a persistent,
unremitting care would have to be paid to a
discipline of cleanliness.
So it is with software engineering today.
– F R E D B R O O K S
F L I C K R . C O M / P H O T O S / N I A I D / 5 9 5 0 8 7 0 3 0 0
55. F I N D I N G M E
Jeffrey Hulten
@jhulten
linkedin.com/in/jhulten
jhulten@whitepages.com
57. S E S S I O N F E E D B A C K
Please provide feedback on this session!
You can do so in 3 ways:
• Visit this session on the Mobile App. Click Session Feedback.
• Scan the unique QR Code for this session located at the front
and back of the room.
• Visit the unique URL for this session located at the front and
back of the room.
Thank you for providing your feedback