DockerCon - The missing piece : when Docker networking unleashes software archtecture 2.0
1. The missing piece: when Docker networking
unleashes software architecture 2.0
A. Blind
DevOps coach
Societe Generale
@adrienblind
L. Grangeau
Solutions architect
Finaxys
@laurentgrangeau
2. Agenda
2 - Starters
Docker networking
& volume features
discovered
4 - Dessert
Taste-an-app
1 - Apetizer
Back on current
Docker paradigms
3 - Main course
Application
architecture shifts
4. Back on Docker paradigms
‘’A universal, self-sufficient and standard artifact embedding an app
module, and its subsequent infrastructure configuration’’
Immutable
Versionned
Light
Portable
Disposable
Programatic
Social
Incremental
It’s mainly focused on enclosing computing
capabilities: what about storage ? Network ?
8. Docker networking
The Container Network Model (CNM)
A docker container
Endpoint
A docker container
Endpoint
A docker container
EndpointEndpoint
Network sandbox Network sandbox Network sandbox
Front network Back network
13. Docker networking
Docker Compose evolved to embrace
new networking features
$ docker-compose --x-networking
--x-network-driver=overlay up
$ docker-compose up
27. Security paradigms shifts
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!
28. Security paradigms shifts
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 teamSecDevOps
30. Network paradigms shifts
SDNs propose network solutions embracing
cloud paradigms
Massively multi-tenant
Thousands tenants, massively scalable
Easy & fast (de)provisioning
Infra as code, API centric
Infrastructure agnostic
L3, does not stick with lower levels (physical designs, vlans & co)
Decouple infrastructure & tenants lifecycles
Cross technology, vendor agnostic
31. From Enterprise Services buses
to full-mesh topologies
ESB
Service Service Service
Service Service
>
ServiceService
Service
Service
Service
Micro services
32. Fine-grained, highly decoupled and
atomic purpose centric services
Designed
for failure
Multi-versioned
Scalable
Micro services
Stateless
Share-nothing
Immutable
Continuously
delivered
Distributed
34. Resilience & scalability: apps problem now!
Vertical > horizontal
Apps designed for failure & scalability
Data to be externalized
Dumber infrastructure
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
35. « Organizations which design systems... are constrained to
produce designs which are copies of the communication structures
of these organizations ». - M. Conway, 1968
Consider shifting your organization if you
wish to shift your architecture
Forget about the central architects myth of
organizing, integrating everything
Consider changing your organization to expect
changing the architecture! promote feature teams
Organization
36. Docker suits perfectly new applications
challenges
Create docker networks to isolate applications
Docker container properties fits micro-services challenges
Resilience & scalability is mostly about multiplying containers
Expect to discuss roles shift in organization
39. Application design
Provider micro serviceConsumers
The python app module exposes a REST service searching
information in the MongoDB
The NGINX reverse proxy forward app. requests on one of the
python instance registered in Consul
Find
40. Application topology & runtime
The whole application topology is stored as:
docker-compose yaml file
docker-compose args (aka --x-networking & --x-network-driver)
You can scale up or down the python instances of the micro-
service using traditionnal docker-compose scale command
41. Network view
Only the load balancer VIP is exposed externally
A WAF instance could secure this entrypoint
SDN « dockerconeu15 »
Host network
Provider micro serviceConsumers
42. Network view - advanced
Provider micro service
Consumers
SDN « front »
SDN « back »
Host network
Back
Middle
Front
‘’To enhance security
you may decouple
each application tier’’
43. Zoom on the registry usages
Between micro-services, consumers asks the
registry where a desired micro-service is located
Inside a micro-service, NGINX is made aware of
the backend API instances available, via the registry
At container level, the registrator enable to registers
any container instances, grouped per type
At infrastructure level, the registry is used by swarm
(internally) to be aware of the cluster’s participants
Noticed the different usages of a registry ?
You may consider using different registries for each usage : for example an
internal registry for the micro service internal topology
45. Docker shifted from universal containers to
object-oriented infrastructure
Security is an app concern
Software is eating the world: application
architecture is the key, infrastructure is commodity