With tools like Docker Toolbox, the entry barrier to Docker and containers is rather low. However, it takes a lot more to design, build and run an entire container platform, at scale, for production applications.
This talk will focus on why it is important to have a well-defined reference model for building container platforms that guides container engineers and architects through the process of identifying platform concerns, patterns, components as well as the interactions between them in order to deliver a set of platform capabilities (service discovery, load balancing, security, and others) to support containerized applications using existing tooling.
As part of this session will also see how a container architecture has enabled real projects in their delivery of container platforms.
4. Container Benefits
Infrastructure
Efficiency
DevOps
Architecture
Virtualization/
Cloud savings
Hardware savings
Flexible platforms
Predictability
Flexible application
environments
Efficiency
Alignment with
modern architectures
Developer
Productivity
• Reduce/eliminate virtualization licenses for workloads to be
containerized
• Reduce number of hardware blades/servers/cloud instances
• Faster container startup times means instances can be turned off
when not used, or dynamically scaled according to demand
• Minimize environment and configuration defects in new
environment setup by packaging all components and
dependencies in containers
• Provision an arbitrary number of application environments
easily, when needed, and destroy them when done
• Minimize human effort / involvement with deploying code to
new environments
• Containers are a great runtime platforms for modern scalable
and high performance application architectures, e.g.
microservices
• Greatly reduce the amount of time needed for a developer to
create a working application environment locally
$$$
$$$
$
$$
$$$
⭐ ⭐ ⭐
⭐
⭐ ⭐
Benefit Type
5. So you want to run containers?
Container Platform
Old stuff New stuff
7. Understanding how to design for, and with containers
Business Continuity
Operations Agility Prepare for Failure Fit for Purpose
Adaptability and Flexibility
Infrastructure
Independence
Information Security
Leverage service discovery
for inter/external service
lookup
Use standard protocols to
interact with interfaces
Use standardized and best-
practice components
Reuse services offered by
platform and extend
components if necessary
Data Integrity Communications
Prefer container image
digital-signing
Use isolated networking
between containers,
regardless of their location
Prefer lightweight
infrastructure components
Use container clustering
and/or other HA practices
Use external persistence
data sources for container
data
Leverage DevOps practices
for container image build
and deployment
L1
Principles
L2
Decisions
Leverage dynamic routing
capabilities
Monitor container
infrastructure components
Limit container access
Use private or secure hosted
image registry
Container as the build
artifact
Immutable infrastructure,
deploy by replacing old
containers with new ones
Make sure that logs aren't
retained only in containers
Version container images in
repository
Encourage reuse of
container definitions
Data and process must be
encapsulated
8. How do we do <…> with containers?
• Operations agility: This pattern handles complex architecture in
build process where multiple version of packages are to be
managed
Architecture Pattern: Container as build output
Conceptual View
Enabling Principles
• Usability: There should be no reason to not build
containers using a Continuous Integration platform and
leverage the automation and versioning capabilities
provided.
Risks & Issues
• Operability: Best used when continuos integrationis
needed
• Versioning: Continuous Integration platform is also
responsible for versioning containers and publishing them
to a private/public Docker registryfor consumption
Benefits / Force
Integrate the container build process withina Continuous Integration
tool and ensures repeatability of the build process. Additionally, the
CI platform is alsoresponsible for versioning containers and
publishing them to a private/public Docker registry for consumption.
Overview
SCM Jenkins Docker
Internal
Registry
Receive Code
Build Container
Tag Container
Push Container
• Prepare for failure: As one contaioner provides only one service,
isolation is preserved. And failure of one unit in system do not
affect other services.
• Operations agility: As each container offers single service it can
be used by multiple applicationwithout affecting others
Architecture Pattern: One service per container
Conceptual View
Enabling Principles
• Operability : As only one service (process) is run in the
container, this pattern requires careful consideration of
its operational concerns such as logging, monitoring and
restarting the container should the process inside crash.
Risks & Issues
• Maintainability: Smaller, lightweight containers
• Operability: Stacks are easier to compose by combining
and linking containers withdifferent components
• Security: Smaller attacksurface incase of vulnerabilities
Benefits / Force
The “one service per container” app enforces anapproach where a
container runs only a single applicationor service. No process
manager is used within the container.
Implement an application packaged withina container, as the only
one process that runs within the container.
Overview
Logging Monitoring
Data Storage Frontend
9. Infrastructure
Runtime
Platform
Administration
Public/Privat
e Cloud
VM Bare Metal
Host OS Container OS
Container
Engine
Container
Tooling
Browser
Application
Integrations
Containers
Data
Registry
Storage
Orchestration
Resource
Management
Service
Discovery
Data AccessNetworkingMetrics
DevOps
Image Build/
Deployment
Monitoring
Logging
What should the platform do?
10. Example: Component Reference Architecture for Docker Datacenter on AWS
Infrastructure
Runtime
Services
Administration
Container OS
Orchestration Resource Management Service Discovery
Data Access
Browser Containers
Data
Metrics
DevOps
CloudWatch
Networking
Overlay Network Flocker
Docker Docker
Amazon Linux
Docker Compose
Universal Control
Plane
Overlay DNS (intra-
cluster)
EC2
Storage
Registry
Docker Trusted
Registry
Docker Volumes
Storage
EBS
Service Discovery
Interlock
Engine
Host OS
Container Tooling
Image build/
Deployment
Docker Trusted
Registry
Monitoring
CloudWatch
Logging
CloudWatch Logs
Image build/
Deployment
Jenkins CI
11. How about the old stuff?
Container Platform
Old stuff New stuff
13. Central Internal Team Project-based migration Migration factory
Centralized team working in
concert with project teams to
coordinate and migrate
projects to the new platform
Leverage existing project
team group to orchestrate and
execute migration effort
+ Fast, efficient deployment
+ Shared team provides
economies of scale and
knowledge sharing
+ Optimized resource model
+ Focused on migration
delivery and managed to
avoid cost overruns
- Increased number of
resources
- Limited cross-team
knowledge sharing
- Lengthier migration
- Inconsistent migrations
- Team has other priorities
- Limited or non-existent
container skills
- Limited migration skills
Migration conducted by an
internal team, staffed by
current IT resources
Containers everywhere. Clients are very interested and are can definitely see the business case.
Containers have clear benefits, but how do we get there?
So you want to run containers, but where do you start?
We need a container platform. What should be in there? What capabilities do we need? What components should provide those capabilities?
Once we have a platform, we can build stateless microservices, yay. But there’s a whole lot of legacy applications that could greatly benefit from running on containers, not least because of infrastructure cost and licensing savings.
So you want to run containers, but where do you start?
We need a container platform. What should be in there? What capabilities do we need? What components should provide those capabilities?
Once we have a platform, we can build stateless microservices, yay. But there’s a whole lot of legacy applications that could greatly benefit from running on containers, not least because of infrastructure cost and licensing savings.