Data Center Architecture and Cloud Concepts
Data Center Architecture and Cloud Concepts
Modern applications no longer depend on a one-to-one relationship between one server and one workload. Learn how virtualization, pooled cloud resources, virtual networks, automation, and software-defined infrastructure create services that are scalable, elastic, secure, and resilient.
Cloud Computing Foundations
In the traditional model, an application commonly occupied a dedicated server even when it used only a fraction of that server's CPU and memory. Virtualization partitions physical compute resources so multiple guest operating systems can share one host. A hypervisor controls CPU, memory, storage, and device access while making every virtual machine (VM) behave as though it owns the hardware.
Cloud computing extends virtualization by pooling compute, network, and storage resources across many hosts and exposing them remotely as on-demand services. Workloads can move away from failed hosts, capacity can be added, and users do not need to know the physical location of the resources.
Consolidation
Multiple VMs improve hardware utilization and reduce power, space, and isolated server administration.
Automation
Standardized resources can be requested, configured, measured, and released with minimal manual work.
Elastic service
Capacity can follow demand rather than remaining permanently sized for the highest possible load.
Five Essential Cloud Characteristics
On-demand self-service
Customers provision CPU, memory, storage, networking, and instances automatically without provider staff handling every request.
Broad network access
Services are reachable through standard networks and client platforms such as phones, laptops, and desktops.
Resource pooling
Provider resources serve multiple consumers using abstraction and multitenancy; exact physical placement is generally hidden.
Rapid elasticity
Resources expand and contract quickly with demand and may appear effectively unlimited to the consumer.
Measured service
Usage such as CPU, storage, traffic, and accounts is metered, reported, controlled, and often used for billing.
Cloud Deployment Models
| Model | Who uses it? | Strengths and trade-offs |
|---|---|---|
| Private cloud | One organization; on- or off-premises | Greater control, customization, privacy, and legacy support; requires capital, maintenance, forecasting, and refresh cycles |
| Public cloud | Multiple customers on provider infrastructure | Pay-as-you-go access and high elasticity; less hardware control and possible regulatory or data-location constraints |
| Hybrid cloud | Connected private and public environments | Places workloads by risk, cost, or demand; integration, identity, data movement, and policy become more complex |
| Community cloud | Organizations with common requirements | Shared governance, cost, compliance, or mission needs across a defined community |
Cloud bursting
In a hybrid design, cloud bursting temporarily extends a private workload into public-cloud capacity during peaks. It requires compatible applications, secure connectivity, synchronized data, predictable licensing, and policies that decide when scaling occurs.
SaaS, PaaS, IaaS, and DaaS
| Service | Customer mainly manages | Provider mainly supplies | Typical use |
|---|---|---|---|
| SaaS | Users, settings, and data | Complete application and underlying stack | Web mail, collaboration, CRM |
| PaaS | Application code and data | Runtime, middleware, OS, and infrastructure | Developing and deploying applications |
| IaaS | Guest OS, applications, data, and many network controls | Physical data center, servers, storage, and virtualization | Virtual servers and networks |
| DaaS | Desktop policies, applications, and user access | Hosted virtual desktop platform | Remote, managed workspaces |
NFV and the Virtual Private Cloud
Network Function Virtualization (NFV) implements network functions in software instead of requiring a dedicated physical appliance. Virtual firewalls, routers, switches, load balancers, and VPN concentrators can be deployed, moved, scaled, and automated with workloads.
Virtual firewall
Filters traffic between virtual networks or workloads. It may be hypervisor-integrated, a virtual appliance, or a cloud-native managed service.
Virtual router
Routes between virtual subnets and can provide dynamic routing, VPN, or gateway functions without a dedicated chassis.
Virtual switch
Connects VMs to each other and to physical uplinks; it applies VLAN, forwarding, security, and monitoring policies.
A Virtual Private Cloud (VPC) is a logically isolated network created within a public-cloud provider. Designers choose address ranges, subnets, routes, gateways, security controls, and connections to other networks.
Connectivity Options and Cloud Gateways
| Method | How it works | Best fit |
|---|---|---|
| Internet VPN | Encrypted tunnel across a public network | Quick, cost-effective site or user connectivity; performance follows Internet conditions |
| Private direct connection | Dedicated or provider-partner circuit into the cloud | Predictable performance, private routing, high throughput, or consistent latency |
| Remote administration | RDP, SSH, file transfer, console, or provider tools | Managing cloud VMs; secure with least privilege, MFA, bastions, and restricted management paths |
Internet gateway
Connects a VPC to the public Internet. Public IP addressing, routes, and security policy determine what is reachable.
NAT gateway
Lets private workloads initiate outbound Internet connections without accepting unsolicited inbound sessions.
Proxy server
Intermediates application requests and may filter, authenticate, cache, inspect, or conceal internal clients.
Static NAT maps one inside address to one outside address; dynamic NAT selects from a pool; PAT distinguishes many internal sessions through one or a few public addresses by using transport ports.
Multitenancy, Elasticity, and Scalability
Multitenancy
Multiple customers share provider infrastructure while logical isolation protects each tenant's workloads and data. Failures in isolation can create cross-tenant risk.
Elasticity
Resources automatically grow and shrink in response to real-time demand. Scale-down limits waste after a spike passes.
Scalability
A system's ability to handle increased workload by adding capacity. Scaling may be planned and need not be automatic or reversible.
| Scaling method | Action | Example |
|---|---|---|
| Vertical (scale up/down) | Change resources on one instance | Add CPU or memory to a VM |
| Horizontal (scale out/in) | Change the number of instances | Add web servers behind a load balancer |
Cloud Network Security
Network security groups (NSGs) apply allow/deny rules to virtual interfaces, instances, or resource groups. Network security lists commonly apply rules at subnet boundaries. Provider terminology varies, so focus on rule scope, direction, protocol, port, source, destination, priority, and whether rules are stateful or stateless.
On-premises
The organization owns physical security, facilities, hardware, virtualization, operating systems, applications, identity, data, monitoring, and recovery.
Cloud shared responsibility
The provider secures the cloud infrastructure; the customer secures its configuration and use of cloud services. The boundary changes among IaaS, PaaS, and SaaS.
Zero Trust Architecture
Zero Trust assumes no implicit trust based on network location. Every access request is authenticated and authorized using identity, device, context, and policy; access is limited by least privilege and continually evaluated.
Infrastructure as Code, Automation, and Orchestration
Infrastructure as Code (IaC) represents infrastructure configuration in machine-readable files. Versioned templates can provision networks, routes, servers, security rules, and services consistently across environments.
Imperative
Specifies ordered commands. The operator tells Docker how to construct the environment, one action at a time.
Declarative
Specifies the desired end state. The operator describes what should exist, and Docker Compose determines the actions required.
Docker Lab: Build the Same Web Service Two Ways
Both examples run an NGINX web server inside a Docker network and publish it at http://localhost:8080. They can be run using Docker Desktop or Docker Engine on a local PC, or in a Killercoda Docker playground terminal.
docker --version. For the declarative example, also check docker compose version.Example A — Imperative
Run each instruction in order. Docker performs exactly the action requested by each command.
docker network create demo-net
docker run -d \
--name imperative-web \
--network demo-net \
-p 8080:80 \
nginx:alpine
docker ps
curl http://localhost:8080What happened? You explicitly created the network and then created the container by stating its name, network, port mapping, image, and background mode.
docker rm -f imperative-web
docker network rm demo-netExample B — Declarative
Create a file named compose.yaml and place the desired configuration below inside it.
services:
web:
image: nginx:alpine
container_name: declarative-web
ports:
- "8080:80"
networks:
- demo-net
networks:
demo-net:
driver: bridgeFrom the directory containing the file, apply the desired state:
docker compose up -d
docker compose ps
curl http://localhost:8080What happened? The file declares that a web service and bridge network should exist. Compose compares that declaration with the current environment and performs the required actions.
docker compose downdocker compose up -d normally reuses matching resources and changes only what is needed.How to Run the Lab
- Local PC: Start Docker Desktop, or ensure Docker Engine is running. Open PowerShell, Command Prompt, Terminal, or a Linux shell.
- Killercoda: Start a Docker playground and use its terminal. For the Compose example, create
compose.yamlwith the built-in editor or a terminal editor. - Run Example A, verify NGINX with
curl, and perform its cleanup. - Create
compose.yaml, run Example B, verify it, and finish withdocker compose down.
Virtualization Lab: Clone a VM and Build a Firewall Server
This optional local-PC exercise demonstrates repeatable virtual infrastructure with Oracle VirtualBox. You will import a prepared Xubuntu appliance as vm1, clone it as vm2, and configure vm2 as a small Linux firewall/router between an isolated lab network and VirtualBox NAT.
| Machine | VirtualBox adapters | Lab role and address |
|---|---|---|
| vm1 | Adapter 1: Internal Network, name labnet | Client VM: 10.20.0.10/24; gateway 10.20.0.1 |
| vm2 | Adapter 1: NAT Adapter 2: Internal Network, name labnet | Firewall/router: WAN from NAT; LAN 10.20.0.1/24 |
- Prepare VirtualBox: Install Oracle VirtualBox on the local PC and ensure sufficient disk space. Download
XubuntuFocal-ssh.ova. Because this is a third-party appliance, verify its source and scan it before use. - Import vm1: In VirtualBox, choose File → Import Appliance, select the OVA, set the VM name to
vm1, review its CPU/RAM settings, and select Import. Start it once and use the credentials supplied with the appliance. - Clone vm2: Shut down vm1. Right-click vm1, choose Clone, name it
vm2, select Generate new MAC addresses for all network adapters, and create a full clone. - Build the topology: With both VMs powered off, give vm1 one Internal Network adapter named
labnet. Give vm2 Adapter 1 as NAT and Adapter 2 as Internal Network namedlabnet. The internal-network name must match exactly. - Identify interfaces on vm2: Start vm2 and run
ip -br linkandip route. The interface on the default route is the WAN adapter; the other Ethernet interface is the LAN adapter.
WAN=$(ip route show default | awk '{print $5; exit}')
LAN=$(ip -br link | awk -v wan="$WAN" '$1 != "lo" && $1 != wan {print $1; exit}')
sudo ip link set "$LAN" up
sudo ip addr flush dev "$LAN"
sudo ip addr add 10.20.0.1/24 dev "$LAN"
sudo sysctl -w net.ipv4.ip_forward=1
sudo apt update && sudo apt install -y nftables
sudo nft -f - <<EOF
table ip labfw {
chain forward {
type filter hook forward priority 0; policy drop;
iifname "$LAN" oifname "$WAN" ct state new,established,related accept
iifname "$WAN" oifname "$LAN" ct state established,related accept
}
chain postrouting {
type nat hook postrouting priority 100; policy accept;
oifname "$WAN" masquerade
}
}
EOF
sudo nft list rulesetThese rules allow vm1 to initiate traffic through vm2, allow only related return traffic toward vm1, drop other forwarded traffic, and apply source NAT on the WAN side.
- Configure vm1: Start vm1, identify its Ethernet interface with
ip -br link, replaceLAN_INTERFACEbelow with that name, and apply the temporary client configuration.
sudo ip link set LAN_INTERFACE up
sudo ip addr flush dev LAN_INTERFACE
sudo ip addr add 10.20.0.10/24 dev LAN_INTERFACE
sudo ip route replace default via 10.20.0.1
ping -c 3 10.20.0.1
ping -c 3 1.1.1.1- Verify the firewall path: On vm2, run
sudo nft list rulesetandip route. On vm1, confirm that the gateway ping succeeds and thatping 1.1.1.1reaches the Internet through vm2. - Observe the result: Shut down vm2 and retry the external ping from vm1. It should fail, proving that vm2 is the forwarding and firewall point. Restart vm2 before continuing.
- Reset safely: The
ip,sysctl -w, and in-memory nftables settings above are intended for a temporary lab and normally disappear after a reboot. Take a VirtualBox snapshot before making the configuration persistent.
10.20.0.0/24 network.| Concept | Purpose |
|---|---|
| Automation | Completes a task with minimal human action |
| Orchestration | Coordinates multiple automated tasks, systems, dependencies, and workflows |
| Playbooks/templates | Package repeatable steps or desired configurations |
| Dynamic inventory | Discovers changing cloud resources instead of relying on a static host list |
| Configuration drift | Actual infrastructure diverges from its approved baseline or code |
| Source control | Records versions, authorship, branches, reviews, conflicts, and rollback history |
Upgrades should pass through testing, staged deployment, validation, and rollback planning. Reusable code reduces variation, but unsafe templates can reproduce mistakes at cloud speed.
SDN, APIs, VXLAN, SASE, and SSE
Software-Defined Networking (SDN) separates centralized policy and control decisions from packet forwarding. It supports application-aware networking, zero-touch provisioning, transport independence, and consistent policy management.
SDN planes
The management plane configures and monitors devices; the control plane calculates paths and builds forwarding state; the data plane forwards packets.
APIs
Northbound APIs connect applications to controllers. Southbound APIs connect controllers to forwarding infrastructure.
VXLAN
Encapsulates Layer 2 frames across a Layer 3 underlay and uses a 24-bit VXLAN Network Identifier, supporting about 16 million logical segments and large data-center fabrics.
DCI
Data Center Interconnect links separate data centers so networks, services, replication, or workloads can operate across sites.
SASE
Combines WAN connectivity—commonly SD-WAN—with cloud-delivered security functions near users and resources.
SSE
The security-focused subset of SASE, commonly including secure web gateway, CASB, and Zero Trust Network Access without the WAN component.
Choose the Best Cloud Concept
Select a scenario to reveal the most suitable primary model, technology, or characteristic.
The recommended answer will appear here.