11 templated serverless IFTTT, Microsoft Flow free-style serverless AWS Lambda, Microsoft Services PaaS Heroku, Google App Engine containerized Docker/rkt with Marathon or Kubernetes traditional multi-tier monolith on bare metal or VM agility level of control
The why and the what: • Containers vs VMs • app-level dependency management • lightweight (startup time, footprint, average runtime) • isolation & security containerization runtime specification deployment day 2 operations
• namespaces (isolation) • Isolate PIDs between processes • Isolate process to network resources • Isolate the hostname to fake it out (UTS) • Isolate the filesystem mount points (chroot) • Isolate inter process communication (IPC) • Isolate specific users to specific processes • cgroups (limiting & accounting) https://sysadmincasts.com/episodes/14-introduction-to-linux-control-groups-cgroups containerization runtime specification deployment day 2 operations
don't bake credentials into images … rather do: $ docker run -d -e API_TOKEN=SECRET somedatabase $ docker run -d -v $(pwd):/fsecret:/fsecret:ro somedatabase Even better: use key-value in-memory stores such as Square's KeyWhiz, HashiCorp's Vault, or Crypt or native solutions such as Kubernetes Secrets containerization runtime specification deployment day 2 operations
35 DNS-based easy to integrate SRV records no health checks TTL Proxy-based no port conflicts fast failover no UDP management of VIPs (Minuteman) or service ports (Marathon-lb) Application-aware developer fully in control and full-feature implementation effort requires distributed state management (ZK, etcd or Consul) examples: Mesos-DNS,Consul examples: Minuteman, Marathon-lb examples: roll-your-own, Finagle containerization runtime specification deployment day 2 operations
rolling deployment bring up N instances of new app & terminate N instances of old app until all old instances are gone goal: minimize capacity requirements blue-green deployment launch a new stack and switch traffic from old to new when the new instances are healthy goal: minimize impact of regressions, friction, delays, and allow easy rollbacks canary deployment bring up a new stack, start by routing a small portion of traffic to the new app, and slowly increase goal: test production traffic slowly & safely containerization runtime specification deployment day 2 operations
37 • Based on health checks • Policy via • minimumHealthCapacity float value between 0—1, specifies % of app instances to maintain healthy while performing deployment • maximumOverCapacity float value between 0 — 1, specifies the maximum % of instances that can be over capacity during deployment containerization runtime specification deployment day 2 operations