Cloud Computing Patterns, Mechanisms > Containerization Patterns > Multi-Container Isolation Control
Multi-Container Isolation Control (Erl, Naserpour)
How can the isolation level required by different cloud services in containers be met?
Problem
Cloud service deployments may end up residing in containers that have specific deployment location requirements that, when not adhered to, can cause conflicts and runtime processing problems.
Solution
A control mechanism is used to dictate where each cloud service or container can or cannot be deployed, based on pre-defined rules. Often factors, such as performance, licensing, governance and regulatory requirements are the basis of these rules.
Application
The control mechanism is created by defining affinity and anti-affinity rules and enforcing them at runtime. The control mechanism can comprise multiple rulesets and can be applied to a single cloud service or container and a single or multiple hosts, or a combination of different cloud services, containers and hosts.
Mechanisms
Compound Patterns
Burst In, Burst Out to Private Cloud, Burst Out to Public Cloud, Cloud Authentication, Cloud Balancing, Elastic Environment, Infrastructure-as-a-Service (IaaS), Isolated Trust Boundary, Multitenant Environment, Platform-as-a-Service (PaaS), Private Cloud, Public Cloud, Resilient Environment, Resource Workload Management, Secure Burst Out to Private Cloud/Public Cloud, Software-as-a-Service (SaaS)
Containers A and B need to be isolated on two different physical hosts.
This pattern is covered in CCP Module 5: Advanced Cloud Architecture.
For more information regarding the Cloud Certified Professional (CCP) curriculum, visit www.arcitura.com/ccp.