Structured Container Delivery
Oscar
Renalias
Accenture Container
Platforms Lead

Infrastructure
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
Container
Business Case

So you want to run containers?
Container Platform

Dev Tools
Official Repositories
Operating Systems
Big Data
Service Discovery
Build / Continuous Integration
Configuration Management
Management
Storage
Clustering & Scheduling
Networking
Infrastructure & Service Providers
Security
Monitoring & Logging
Where do we start?

Container Platform
Architecture

Container Platform Architecture
Principles Patterns Capabilities
Reference Implementations

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
Multi-tenancy – keep
teams isolated

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

Clustering Security Service Discovery Persistence
What features do we need?
Clustering
Load balancing
Fail-over
Authentication
Authorization
Encryption
Digital Signature
Service Lookup &
Indirection
Publishing &
Subscribing
APIs
Image
Persistence
Versioning
Data persistence

Infrastructure
Runtime
Platform
Administration
Public/
Private 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 components do we need?

Getting opinionated: Component Reference Architecture for Docker
Datacenter on AWS
Infrastructure
Runtime
Services
Administration
Orchestration Resource Management Service Discovery
Data Access
Browser Containers
Data
Metrics
DevOps
CloudWatch
Networking
Overlay Network Flocker
Docker Compose
Universal Control
Plane
Overlay DNS (intra-
cluster)
EC2
Storage
Registry
Docker Trusted
Registry
Docker Volumes
Storage
EBS
Service Discovery
Interlock
Container OS
Docker Docker
Amazon Linux
Engine
Host OS
Container Tooling
Monitoring
CloudWatch
Logging
CloudWatch Logs
Image build/
Deployment
Jenkins CI

How about the old stuff?
Container Platform
Old stuff New stuff

Efficiently migrating
existingapplications to containers

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
Centralizing the migration effort

Migration Factory
Docker
Migration Team
Migration Framework
Container
Patterns
Container
Best
Practices
Base
Images
Container Reference Architecture
Legacy
Application
Expertise + Framework + Feedback loop

Establish Overall
Migration Plan
Perform Detailed
Migration Planning
Upgrade/Migrate
Applications
Certify/Deploy
Applications
Migration & RolloutDiscovery & Assessment
High-Level
Assessment
& Planning
Detailed
Application
Assessment Testing &
Certification
App. Architecture
Recommendations
Container Infrastructure
Planning
Rollout &
Decom-
mission
Containerize
Application

@oscarrenalias
github.com/accenture
oscar.renalias@accenture.com
www.linkedin.com/oscarrenalias
www.slideshare.net/oscarrenalias

Thank you!