Application Environments & Infrastructure Isolation

TL;DR: An application environment provides the infrastructure context in which an application runs, while infrastructure isolation defines the boundaries between that environment and other workloads.

In the previous post, Infrastructure Composition, we discussed how an Application Environment combines networking, subnets, routing, security policies, compute resources, databases, storage, and observability into a single operational stack designed to run an application.

However, running a single composition is rarely sufficient. Infrastructure Isolation addresses the requirement to separate development, staging, and production workloads into distinct execution spaces to contain blast radiuses and enforce security boundaries.

This article breaks down these two core concepts separately before synthesizing them to show how to build scalable, isolated application environments.

Application Environments

Do you remember this?

Application Environment
│
├── Network
│   ├── VPC / VNet
│   ├── Subnets
│   └── Routing
│
├── Security
│   ├── Firewall rules
│   ├── IAM
│   └── Secrets
│
├── Compute
│   ├── Kubernetes cluster
│   └── Node pools
│
├── Data
│   ├── Database
│   └── Object storage
│
└── Observability
    ├── Logs
    ├── Metrics
    └── Alerts

An application environment is the infrastructure context in which an application runs.

A typical application may have:

Application
    │
    ├── Development
    ├── Testing
    ├── Staging
    └── Production

Each environment can contain a similar collection of resources:

Production
├── Application
├── Database
├── Cache
├── Message Queue
├── Network
├── Secrets
├── Monitoring
└── Storage

The important point is that an environment is a logical boundary around a collection of infrastructure resources and services that together support an application or workload.

For example, an application might have:

dev.example.com
    └── Development environment

staging.example.com
    └── Staging environment

example.com
    └── Production environment

The environments may use the same architecture while having different capacity, configuration, data, access policies, and operational characteristics.

Infrastructure Isolation

Isolation answers a different question:

How do we prevent resources belonging to one workload, environment, or team from interfering with another?

There are several levels of isolation.

At the simplest level:

VM A <-> VM B

VMs provide process and resource boundaries.

Containers provide another layer:

Host
├── Container A
├── Container B
└── Container C

Kubernetes extends this concept:

Cluster
├── Namespace: team-a
│   ├── App A
│   └── App B
│
└── Namespace: team-b
    ├── App C
    └── App D

Cloud platforms can provide stronger infrastructure boundaries:

Cloud
├── Subscription / Account A
│   └── Production
│
└── Subscription / Account B
    └── Development

And networks add another dimension:

VPC / VNet
├── Public subnet
├── Application subnet
└── Database subnet

So isolation isn’t necessarily one technology. It is a collection of boundaries applied at different layers.

Application Environments & Infrastructure Isolation

Consider three applications:

Application A
Application B
Application C

You could give each application completely independent infrastructure:

A > Cluster A > Network A > Database A

B > Cluster B > Network B > Database B

C > Cluster C > Network C > Database C

This gives strong isolation, but it can become expensive and difficult to operate.

Alternatively:

             Shared Cluster
                  │
        ┌─────────┼─────────┐
        ↓         ↓         ↓
     Team A     Team B    Team C
     Namespace  Namespace Namespace

This provides resource sharing while maintaining logical boundaries.

The platform engineer therefore has to decide where the isolation boundary should exist.

That could be:

Organization > Cloud Account / Subscription > Network > Cluster > Namespace > Workload > Container > Process

Each layer provides different levels of isolation, cost, operational complexity, and security.

A developer generally wants to say something like:

I need an application environment.

They shouldn’t have to manually construct:

VNet
Subnet
NSG
IAM
Kubernetes namespace
Database
Storage
Secrets
DNS
Monitoring
Backup

That where Infrastructure Composition, connects.

Infrastructure Composition might define:

Application Environment
        │
        ├── Network
        ├── Compute
        ├── Database
        ├── Storage
        ├── Identity
        ├── Secrets
        └── Observability

Then the platform can instantiate that composition repeatedly:

Application
    │
    ├── Dev Environment
    ├── Test Environment
    ├── Staging Environment
    └── Production Environment

while applying different isolation policies to each.

For example:

Dev
└── Shared Kubernetes Cluster
    └── Namespace

Staging
└── Shared Kubernetes Cluster
    └── Namespace + NetworkPolicy

Production
└── Dedicated Cluster
    └── Dedicated Network

Same conceptual application environment, different implementation and isolation level.

Application environments define the infrastructure context in which a workload operates, while infrastructure isolation defines the boundaries that separate that workload from other workloads.

And this leads to next topics:

Application Environments > Infrastructure Isolation > Developer Portals > Service Catalogs > Golden Paths

Back to Certified Cloud Native Platform Engineering Associate Preparation