This document provides an informal summary of Docker and related container technologies presented by Santosh Koti on May 29, 2015. It discusses Docker and how it helps standardize application packaging and runtimes. Microservices and how they decompose applications are covered. Distributed systems challenges like failures are also summarized. Kubernetes, an open source container cluster manager from Google, is introduced as a way to manage containers at scale across multiple clouds.

1. Docker & Beyond
-Santosh Koti
Given on May 29,2015 at Equinix
- An opinionated & very informal talk
with bit of fun, TGIF 

2. Disclaimer
• This presentation represents purely my views
& opinions only
• It does not represent either my current or
future employer’s opinions.
• Some of the content may be dated, which may
not hold true any further.
• It is a very opinionated, informal & funny talk
• Hope you enjoy it. 

3. Is there Any Agenda ?
• Hmm.. Probably:
– Dockers
– Impact of Containers
– Micro Services
– Distributed Systems
– Container Orchestration at Scale
– Demo
• “But…nothing is guaranteed in the transit of
time” 

4. Docker - The Linux Container

5. What is Docker ?
• Sometimes containers can be good too (Tomcat ?)
• GitHub Says:
• Big Idea: Ship code/app with it’s run time
environment/dependencies

6. Some more details please ?
Standardizes Application Binaries:
Package/ Image Format
Enables static-sealed/self-sufficient binaries / No external dependencies
Standardizes Application Runtime:
Enables both process isolation & process containment
Process Virtualization
Built for Cloud:
Optimized for large scale application deployment
Misc:
Standardizes the old Java PR – Write once , run anywhere
(for any apps, not just Java )
Sometimes history repeats for the better, if not always 

7. Ok, How it helps ?
• Avoids “But it works on my system!” syndrome
- (Truth is more portable now )
• Enables Apps Portability
• Lightweight than VM
• Enables Micro-services
• Enables better DevOps

8. Built on the shoulders of…?
• Built on number of Linux features
• cgroups: Restrict resources a process can consume
CPU, memory, disk IO
• chroots: Determines what parts of the filesystem a
user can see
• capabilities: Limits what a user can do mount, kill,
chown..
• namespaces: Change a process’s view of the system
Network interfaces, PIDs, users, mounts…

9. How is it different from VM ?
Heavyweight
Lightweight
Sometimes Less is Better 

10. Hmm.... Better than VMs ? *
• VM:
More Isolation, better guaranteed resources
Heavyweight
Can run handful of VMs on a single host.
Takes minutes to start
• Docker :
Resource Isolation is not very strict
Lightweight
Can run 100s of containers even on a single host.
Starts in seconds
Extremely Popular
(Resonance ? with the advent of Cloud/Microservices)

11. So Popular, Even Google is Biased …? 

12. Sounds Fishy, Things can’t be so good ?
Security: “If a user or application has superuser
privileges within the container, the underlying operating
system could, in theory, be cracked.” *
Can get stale , after running for a long time ?
So, run your services as non-root whenever possible
And Grant minimal privileges

13. Docker - The Pied Piper

14. With Docker, is it Customer Container First ?
“The real value of Docker is not technology , It’s getting people
to agree on something”
- Solomon Hykes, Docker Founder
But, Making people agree on something is a hard thing ?
It is not very different here too 
So there is a Docker Governance Board to define the evolving the container-first
standards with contributions from Redhat, Google, Docker, IBM, Microsoft etc.
Move over VMware, Docker is the new interface/API/standard….!
But then too many chefs can spoil the dish 
(Remember JSR/JEE Committe ? )

15. Docker - Reinventing the software eco-system ?
• Infrastructure Level
• Application Level

16. Docker – Impact on Infrastructure Level

17. Docker - Impact on Infrastructure Level ?
• Container-First OS
• CoreOS (Google Backed) , Project Atomic (Redhat)
• One from Intel (ClearOS ?, Sorry can’t remember )
• Rancher OS (Rancher Inc) , Photon (VMware)
• Container-First { Networking, Storage }
• Weave, CoreOS Flannel, Flocker
• Container Scheduling/Orchestration
- Docker Swarm,Spotify Helios
- Google Kubernetes , CoreOS Fleet
• Some More Containers: Rocket (CoreOS)
• Startups : CoreOS, Rancher , Kismatic, ClusterHQ etc
Good on Economy ? Not sure (First law of thermodynamics here ?)
But then every generation needs its own heroes.

18. CoreOS: Container-First OS ?
• Minimal OS to host your containers
• Automatic Updates
• Atomic Updates/Rollbacks
• No package manager like rpm, instead use docker
• In other words, Docker is the new package manager ?
• Built for Cloud
• Enables Immutable OS (read only root fs)
• First class support for linux containers :
Docker & Rocket etc.

19. Docker – Impact on Application Level

20. Docker - Impact on Application Level ?
• Fosters Micro-services
• So applications are structurally decomposed/distributed
• Embrace Fundamentally Distributed Systems
• Emergence of Lean Stacks across languages
( Javascript: NodeJS, Java: Spring Boot,
Scala: Akka Http, Python: Flask, Go : Goji etc )
• Better Developer’s Health  [NOCC ?  ]
• As a result, better software is shipped ?
• So can we recall tagline of KF/LG’s tag line : Good times / Life is Good

21. MicroServices – 101

22. Why Microservices ?
• Decompose application into set of simple-cum-small services
• Often focused on one business capability
• Independently deployable
• Loosely coupled & communicate over HTTP
• Can be developed using different languages/tools
• Easy to develop/debug/prototype
• Easier Developer Onboarding
• Lightweight
• Asynchronous communication
• Fundamentally, distributed in nature

23. Ok, But What is the dark side ?
• Code Duplication in Polygot environment
• Complexity of Distributed Systems : fault tolerance,
unreliable networks, asynchronicity, transactions etc
• More Operational Overhead
• System Testing gets Harder
• “Asynchronous systems are great when we can decompose work into
genuinely separate independent tasks which can happen out of order at
different times.”
• When things have to happen synchronously/ transactionally in an
inherent asynchronous architecture, it gets more complex.
For more : http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html

24. Microservices – Major Challenge ?
• Determining the right level of granularity for service
component is one of the biggest challenges
• Define granularity by Business Functionality ?

25. Microservices Pattern 1– API Focused ?
• Fine Grained - when API focused

26. Microservices Pattern 2 – Application Focused ?
• Coarse Grained – when Application focused

27. Microservices Pattern 3 - Messaging ?
• Non-RESTful communication with other services
• Asynchronous Messaging, Error Handling, Reliability,
whenever data is produced/consumed at different velocity

28. Microservices Pattern 4 - Orchestration ?
• Used for transactional request processing
• Generally required if you need to make (synchronous) inter-service
communication across service components
• Required when service components are too fine grained/ incorrectly
partitioned from a business standpoint.
• Generally complex, re-design, prefer messaging if possible *
• Rollbacks are harder
• Undesired Coupling
• Common practice: Violate DRY & copy the shared functionality
• (Sometimes it is good to break the rules)
• For more: Software Architecture Patterns, O’REILLY 2015

29. Distributed Systems - 101

30. Distributed Systems – What ?
“A collection of independent systems that appears to its users as a single
system”
“Everything fails all the time” – Werner Vogels , Amazon CTO
Failure is the norm, not the exception
So, design for failure
CAP Theorem (Consistency, Availability & Partition)
- Choose Two
- Foundation DB defies ?
- Lacks Formal Verification,
unlike Hoare’s CSP ?

31. Distributed Systems – Little more ?
Simultaneity/Synchronocity is hard
“There is No Now ” in distributed systems
For more : https://queue.acm.org/detail.cfm?id=2745385
Design for “Eventual Consistency ”
As events get more complex, we tend to talk about probability ,
not certainty, same is the case here (not just in software systems, everywhere)
So we express intent in distributed systems, as things keep going out of place
But the tag line of TCS says – Experience Certainty ? 

32. Distributed Systems – Blue Print ?
• Anything can fail.
• When Worker Nodes fail, Master Node replicates worker nodes
• Master nodes can fail , Paxos (ZooKeeper), Raft (etcd) to rescue
-- One of the standby nodes will be elected by
consensus protocols(Paxos / Raft)
Master Node
Worker Node1 Worker Node2 Worker Node3
StandBy Master
Node 1
StandBy Master
Node2
Raft/
Paxos

33. Kubernetes – The Container Cluster Manager
(Container Orchestration & Scheduling)

34. Kubernetes – What ?
• Greek word for ‘The person who steers the ship’
• Orchestrator for running Docker containers at scale
• Supports multi-cloud environments
• Backed by Google’s decades of experience
• Endorsed by the big players : Redhat, Microsoft, IBM,
CoreOS, Mesosphere etc
• Open Source
• Still in beta, very active community

35. Kubernetes – How does it help me ?
• Enables to build & manage container-based distributed
systems at large scale/cloud scale.
• Supports container deployment / scheduling
• Supports container orchestration / high availability of
services
• Enhances efficient resource utilization across the
cluster (saves money too )
• Can manage multiple clusters at the same time
• REST API Support
• Supports Docker & Rocket containers
• It is a distributed system by itself

36. Kubernetes – Big Picture ?
Kube-Master
Server
Kubelet –
Worker Nodes

37. Kubernetes - Key Concepts
• Cluster: A group of nodes on which containers are scheduled
• Container: A sealed application package (Docker)
• Pod: A small group of tightly coupled Containers
example: content syncer & web server
• Replication Controller: A loop that drives current state towards desired
state
• Service: A set of running pods that work together
• example: load-balanced backends
• Labels: Identifying metadata attached to other objects
• example: phase=canary vs. phase=prod
• Selector: A query against labels, producing a set result
• example: all pods where label phase == prod

38. Kubernetes – How do they all fit in ?
(Master Node)

39. Kubernetes – How do they all fit in ?
(Worker Node)
Recieves
Commands from
Master
Node
Health
Service Proxy

40. Kubernetes – Pods ?
• Small group of containers & volumes
• Tightly coupled
• The atom/unit of cluster scheduling & placement
• Shared namespace :
- share IP address & localhost, storage volume
• Ephemeral (like Snapchat ?)
- can die and be replaced

41. Kubernetes – Labels ?
• Naming, Identification of Kubernetes cluster
objects
• Supports Querying/Grouping

42. Kubernetes – Replication Controllers ?
• Ensures high availability of pods
• Recreates Pods, maintains desired state of cluster
• Fine grained control for scaling
• if too few, start new ones
• if too many, kill some

43. Kubernetes – Services ?
• A group of pods that act as one == Service
• Load Balanced Access to Pods
• Gets a stable virtual IP and port
- called the service portal
- also a DNS name

44. Demo – On Google Cloud

45. Demo App ?

46. Create a Container Cluster
1) gcloud auth login
2) gcloud alpha container clusters create CLUSTER_NAME --
zone ZONE –user=admin –password=lostintime
There is a REST API too..

47. Further Reading

48. Further Reading ?
• Immutable Infrastructure (CoreOS)
• Portable Infrastructure (Rancher)
• Unikernel Systems
• http://www.slideshare.net/Codemotion/devel
opers-guide-to-containers-mandy-waite
• http://www.oreilly.com/programming/free/fil
es/software-architecture-patterns.pdf

49. Thank You
(!wot) 