How Postman adopted Docker

least friction and overhead to getting started and adopting docker in production

About Postman

3+ million users

1.5+ million mau

30+ member team

Our Stack25+ micro services

10+ mill peak req/hr140+ gb in/day

nodejsdocker

jan 2017

postman’s operations middleware

early adopterslate 2014 ⇢ small team ⇢ frugal operations

early goal was to ship and validate andspend less time on operations

why docker?cloud is vm ⇢ no chef/puppet expertise ⇢

exactness

since cloud is a VM in some form,no guarantee that VM based system will work

if a startup needs to switch cloud provider

operational flexibility

centralised (hub) ⇢ code coupled ⇢ maintainable ⇢ unobtrusive

common base image for all applications

image per application is stored alongside code

docker image file is treated as code (goes through PR, etc)

common server setup and standardisation is moved to base image and remaining overrides

to per-service image

å

developer prepares code and environment ci tests code using centrally inherited image

image is orchestrated into production services

zero downtimehot reboot ⇢ live deployments ⇢ live rollback

no need to reboot entire server

build and deploy applications as a secondary image and then swap

auto instrumentationlog stream (volumes) ⇢ system tuning

written once in base image and then re-used across all services

public network segment

private network segment

server 1 server 2 server n

load balancer orchestrator

public network segment

private network segment

server 1 server 2 server n

load balancer orchestrator

service one service two

communication bus | shared resources | service discovery and registration

we use Beanstalk for orchestration andconceptually this can be Kubernetes or anything else

production emulation

faster debugging ⇢ portable configuration (env)

any system (even a local machine) can be

connected to any load balancer and hence facilitate debugging

security surfacecentrally controlled ⇢ managed updates

Summarising• Just “choose” docker to get started (even if using

minimal features) and see value in long run• Start using docker in deployment keeping individual

docker files in source code.• Use a single source image (to inherit from) for all

deployments• Configure security, logging and other basics in the

source environment and keep on improving it.

our window to developer freedom

fun and freedombilling notification ⇢ team setup ⇢ one-click

docker

do not bother how much cost your

team is raking up until s**t hits the

roof

once the service has been tested

here (or locally), we move it to production

instances in AWS

@shamasisgetpostman.com