The following talk first comes back on key aspects of microservices architectures. It then shifts to Docker, to explain in this context the benefits of containers and especially the new orchestration features appeared with version 1.12.

1. Adrien Blind
DevOps Coach & Docker captain
@adrienblind
Unleash software architecture
leveraging on Docker

2. Come back on
microservices

3. @adrienblind
Fine-grained, highly decoupled and
atomic purpose centric services
Designed
for failure
Multi-versioned
Scalable
Microservices characteristics
Stateless
Immutable
Continuously
delivered

4. @adrienblind
From Enterprise Services buses
to full-mesh topologies
ESB
Service Service Service
Service Service
>
ServiceService
Service
Service
Service
Interactions
App App

5. @adrienblind
Security paradigms shifts (1/2)
Your IT opens up
• Externalization (housing, hosting)
• Cloud (IaaS/PaaS/SaaS)
Open up your IS
• B2B, services exposition
• Multi tenancy
More & more breaches appears in your Great Wall of China!

6. @adrienblind
Security paradigms shifts (2/2)
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

7. @adrienblind
 Apps designed for failure & scalability
 Data to be externalized
 Dumber infrastructure
Resilience & scalability: apps problem now!
 Structured: MongoDB, Hadoop, Cassandra, Elastic Search...
 Binaries: object storage with Ceph, OpenStack Swift...
 Helpful patterns: stateless, multi-versioning, loose coupling...
 Infrastructure rationalization
 Low-cost, poor-SLA commodity
Vertical > Horizontal

8. @adrienblind
Merge app & infra conf. lifecycles
System conf v.5.79
Middleware v.69.3
App code v1.2.3
 Product version = app version +
infra version
 Whenever you change a single
line of code or a system lib., you
build up a new artifact
More & more full stack & immutable

9. Is the PaaS a silver
bullet?

10. @adrienblind
 PaaS offers can offload several
topics
 …But it requires you to stick to their
paradigms which may creates locks
& limitations
 … and may delays adoption of new
practices/fmk/…
What about the PaaS ?

11. @adrienblind
IaaSCapacity (VM, Storage, Netwk…)
PaaSApp. (code)
CaaSContainer
What about the CaaS

12. Down to the CaaS

13. @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
Versionned/taggedContinuously
delivered
Full stack

14. @adrienblind
App
From containers to apps
An application is made of several components
interacting each together

15. @adrienblind
Distributed application
Compute (service/task)
Storage (volume) Transport (network)
Topology
(compose, bundle,
deploy, 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

16. @adrienblind
Docker 1.12 swarm mode
 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

17. @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 swarm join-token worker
To add a worker to this swarm, run the following command:
docker swarm join
--token [TOKEN] [m1_ip]:2377
… (joined a third manager, plus a worker)
$ 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

18. @adrienblind
Docker service
Depicts the desired runtime behavior of a given
image : networking, resiliency, quotas...  shift to
state-machine paradigms
$ docker service create --name front -–network app
–-replicas 3 -p 80:80/tcp myapi: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

19. @adrienblind
Example
$ docker network create --driver overlay myappnet
$ docker service create --name mybackenddb --env
MYSQL_ROOT_PASSWORD=plop --env MYSQL_DATABASE=plop
--network myappnet mysql:latest
$ docker service create --name myapi --env DB_HOST=mybackenddb
--env DB_PASSWORD=passwd env DB_NAME=plop --network myappnet
--publish 80:80 --replicas 3 myapi:latest
$ docker service ls
ID NAME REPLICAS IMAGE COMMAND
14utiklw5g6s mybackenddb 1/1 mysql:latest
c9vnvebcylg5 myapi 3/3 myapi:latest
$ docker service update --replicas 7 myapi

20. @adrienblind
Example
LB LB LB LB
Network
Dynamic LB on each
manager + workers
hosting containers of
the app
All containers
belonging to a same
app are connected
through an overlay
network
App dedicated overlay network
myapi
myapi myapi myapimybackenddb

21. @adrienblind
Docker stack (experimental)
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

22. Conclusion

23. @adrienblind
 It’s all about a devops story: part of the infra
aspects are integrated in the app’s side, the
rest is commoditized
 CaaS approach offers a good balance between
the value of the PaaS and autonomy of IaaS
Conclusion

24. @adrienblind
 What
 Formerly about abstracting low layers (ie.
infra) : close to PaaS approach
 Now more related to FaaS/event-driven
programming (like AWS Lambdas).
Consider app=data+transformation
 Why / Pros
 Cost saving: avoid running permanently a
server « waiting » for requests
 Industrialize your own platform, stop
reinventing the wheel, avoid pure cloud
vendors lock-in (ie w/ AWS lambdas for
instance)
Serverless / Event-driven prg.
OpenWhisk frameworkGoogle Trend results for
« serverless »
Client
API
Gateway
Search
Compute
Something
DB
Auth

25. Adrien Blind
DevOps Coach & Docker captain
@adrienblind
Thank you!