Reducing Resistance: Deployment as Surface
Upcoming SlideShare
Loading in...5
×
 

Reducing Resistance: Deployment as Surface

on

  • 524 views

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.

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.

Statistics

Views

Total Views
524
Views on SlideShare
507
Embed Views
17

Actions

Likes
1
Downloads
2
Comments
0

3 Embeds 17

https://twitter.com 11
https://www.linkedin.com 4
http://www.linkedin.com 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Reducing Resistance: Deployment as Surface Reducing Resistance: Deployment as Surface Presentation Transcript

  • 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
  • F I R S T, A S T O RY…
  • 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 View slide
  • 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 View slide
  • 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
  • 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
  • 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,
  • 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 ,
  • 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 ,
  • 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
  • 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
  • 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
  • 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
  • T W E LV E FA C T O R S ?
  • 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
  • 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
  • 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
  • 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
  • D E P L O Y M E N T: A N A N A L O G Y
  • Y O U WA N T T O F LY I M A G I N E
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • Y E S
  • 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
  • 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?
  • E X A M P L E : R U B Y A P I S E R V I C E
  • 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?
  • 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
  • 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.
  • – R I C H H I C K E Y We program with constructs[...] but we are in a business of artifacts.
  • 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.
  • 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
  • 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?
  • 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
  • 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?
  • - 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
  • 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 …
  • 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
  • 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
  • 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
  • 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”}
  • I N S TA L L PA C K A G E $ sudo dpkg -i myapp_1.2.3_amd64.deb
  • 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
  • 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
  • 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
  • F I N D I N G M E Jeffrey Hulten @jhulten linkedin.com/in/jhulten jhulten@whitepages.com
  • Q & A
  • 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