The following talk discusses the opportunity to leverage on docker to create an hybrid logical cloud built simultaneously on top of traditionnal datacenters and public cloud vendors and enabling to manage new kind of containers (Windows, linux over ARM). It also discusses the value of such capacity for applications in a contexte of topology orchestrations and micro service oriented applications.

1. Adrien Blind
DevOps Coach, Docker Captain
@adrienblind
Docker, cornerstone of an hybrid cloud ?

2. Rise of the orchestration

3. @adrienblind
Fine-grained, highly decoupled and
atomic purpose centric services
Designed
for failure
Multi-versioned
Horizontally
scalable
Micro services
Stateless
Share-nothing
Immutable
Continuously
delivered
Distributed

4. @adrienblind
Docker fits microservice paradigms
‘’A universal, self-sufficient and standard artifact embedding an app module,
and its subsequent infrastructure configuration’’
 Docker provides both the artifact and the ecosystem to handle it!
Immutable
Portable Lightweight
Incremental
Versionned/taggedDisposable

5. @adrienblind
Application
From containers to application topologies
An application is made of several components interacting each together
Microservice A
Microservice B
Hadoop cluster
Third-part service
ambassador

6. @adrienblind
From Enterprise Services buses to full-mesh topologies
Service Service Service
Service Service
>
ServiceService
Service
Service
Service
Service discovery challenge
App App
ESB

7. @adrienblind
Network challenge
The necessary porosity of your IS requires to stick security closer
to each application: sandbox your apps and expose protected interfaces!
Network is part of application topology
Security is an app topic, not just infra. concern
Onboard security in feature teamSecDevOps

8. @adrienblind
Distributed application
Compute (service/task)
Storage (volume) Transport (network)
Topology
(Stack)
 Docker shifted from container infra.to object-oriented app. topologies
CaaS platform
Clustering (swarm)
Image mgmt
(registry)
Hosting (node)
Provisioning (machine)
... relying on an CaaS platform 
The rise of the orchestration

9. @adrienblind
Docker 1.12 orchestration
 Directly over Internet ?
 Swarm mode secures interactions between its nodes (TLS mutual auth, authz, & encryption)
 Overlay network trafic may be encrypted across nodes too (use switch --opt encrypted to use IPSEC)
 Built in the engine
 Decentralized
 More secured
 More resilient

10. @adrienblind
$ docker-machine create -d virtualbox m1
$ docker swarm init --advertise-addr [m1_ip]
$ docker-machine create -d virtualbox m2
$ eval $(docker-machine env m2)
$ docker swarm join --token [mytoken] [m1_ip]:2377 --advertise-addr [m2_ip]
…
$ docker node ls
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS
1o46ikaidagi91w940h81byd1 w1 Ready Active
3bboy53bjyeqd9ad0tsegju51 m2 Ready Active Reachable
48yqo4607pfzkpct4jz9t1t9y m3 Ready Active Reachable
6fyvwd6cc4nguth29ycexaxat * m1 Ready Active Leader
Cluster setup example

11. @adrienblind
Docker network & service
Create an overlay network dedicated to the app:
$ docker network create appnet
Depicts the desired runtime behavior of a given image :
networking, resiliency, quotas...  shift to state-
machine paradigms
$ docker service create --name front -–network appnet
–-replicas 3 -p 80:80/tcp nginx:latest
Attach the containers to a given network
Define the desired amount of instances for this service (named « tasks »)
Attach each instance to a transversal L4 loadbalancer instance, reachable on each
node of the cluster

12. @adrienblind
Example
LB LB LB LB
Network
Dynamic level 4 LB
All containers
belonging to a same
app are connected
through an overlay
network
Overlay network

13. @adrienblind
Docker stack
docker-compose enabled to depicts and
trigger a complete app topology from the client
side
docker stack enables to feed the server-
side orchestrator with a complete app topology

14. Hybridate clouds

15. @adrienblind
 Almost all cloud vendors provide their own complete,
ready-to-use docker CaaS stacks:
 Amazon ECS
 Azure Container Service
 Google Container Engine
 You may create your own docker Swarm CaaS leveraging
on several providers at the same time
 Your own traditional DC
 Various Cloud vendors
Cloud provider hybridation

16. @adrienblind
 Less lock-in
 Progressive cloud migration
 Elasticity / overflooding
 Keep docker native ergonomy easing adoption
 Cloud arbitration?
 …
Cloud provider hybridation

17. @adrienblind
 Scale the application through
docker service replicas
 Scale the swarm cluster capacity
leveraging on docker-machine tool,
controling AWS, Azure, etc. providers
Scale up, scale down
AVOID
CONFUSION

18. Hybridate technologies

19. @adrienblind
Windows containers are here!
Two Windows Containers types:
 Windows Server Containers, that are similar than Linux containers in the concepts
 Hyper-V Containers, that runs inside a small virtual machine on Hyper-V
https://blogs.msdn.microsoft.com/jcorioland/2016/10/13/getting-started-with-windows-containers

20. @adrienblind
 What
 Tiny servers based on ARM architecture
 Poor per-core perf but up to 54 cores per SoC + good I/Os
 Why / Pros
 Green IT: better perf/watt & density ratio
 Cost efficiency for massive threading usecases:
bigdata/grids/horizontally scalable apps ?
 Pitfalls / Cons
 Litteraly rebuild apps for ARM
 Only fits some usecases, not a silverbullet!
ARM: end of the x86 hegemony ?
ARM v8 architecture
Up to 54 cores/SoC + 1TB RAM
Cavium srv: 384 cores enclosed in 2U

21. @adrienblind
Hybrid orchestration
App 3
App 2
App 1
X64/WIN X64/LINUX ARM/LINUX
 Extend the picture
 ARM computing rises
 Windows containers arrives
 The app topology integrates various techs
which must be orchestrated together

22. Conclusion

23. @adrienblind
Cloud hybridation
Raspberry
(ARM)
Win 2016
SWARM
CLUSTER
Linux
X86_64
Linux
X86_64
Linux
X86_64
Linux
X86_64
Linux
X86_64
INTERNET

24. @adrienblind
 Containers are more & more universal
workload units
 Orchestration is more than ever the key
 You may wish to keep control while
delegating commodities
Conclusion

25. Adrien Blind
DevOps Coach, Docker Captain
@adrienblind
Thank you!