3V0-21.25 IT Architectures, Technologies, Standards

IT Architectures, Technologies, Standards Detailed Explanation

1. IT Architectures

1.1 Common Architecture Models

Here we talk about how applications are structured. Imagine you’re designing an online shop. You can build it in different ways.

1.1.1 Monolithic architecture

A monolithic application is like a single big box that contains everything:

• User Interface (UI)

• Business Logic (rules: prices, discounts, etc.)

• Data Access (talking to the database)

All of this is packaged and deployed as one unit (one .war/.jar/.exe, one big app).

Key idea:

All major parts of the application live together, compiled and deployed together.

Pros (why people like it, especially at the start):

• Simple to start:

  • Development is straightforward: one codebase, one project.

  • Easy for small teams and simple applications.

• Easy initial deployment:

  • Just deploy one thing to one server.

  • Fewer moving parts = fewer things to configure.

Cons (why it becomes painful later):

• Hard to scale parts independently:

  • If only the checkout function is busy, you still have to scale the entire app.

  • You can’t just scale “one module”; you must run more copies of the whole app.

• Tight coupling:

  • Everything depends on everything.

  • Changing one part may break others.

• Difficult to change over time:

  • As the codebase grows, it becomes a “big ball of mud”.

  • New developers find it hard to understand.

  • Large deployments are risky—changing one feature requires redeploying the entire app.

Simple analogy:
A monolithic app is like a single big restaurant that does everything in one room: cooking, storage, cashier, cleaning. Easy to open when you’re small; very messy when you’re popular and crowded.

1.1.2 Client–Server architecture

This is an older but still important model.

Key idea:

We separate the client (front-end, user-side) and the server (back-end, data and logic).

• Client:

  • Usually runs on the user’s device (browser, mobile app, desktop app).

  • Handles display and user input (clicks, typing).

• Server:

  • Runs centrally (in the data center or cloud).

  • Handles heavy logic, data storage, security.

Classic 2-tier example:

• Tier 1: Client app (e.g., Windows application).

• Tier 2: Database server (Oracle, SQL Server, etc.).

The client connects directly to the database.

Limitations:

• Scalability:

  • If many clients connect directly to one database, the DB can become a bottleneck.

• Separation of concerns:

  • A lot of logic may end up on the client or inside the database.

  • Harder to share logic between different client types (web, mobile).

Analogy:
Imagine a library:

• Clients = people visiting the library.

• Server = the library building with all books.

• Everyone must go to the same library building; if too many people come, it becomes crowded and slow.

1.1.3 3-tier / n-tier architecture

To improve on simple client–server, we separate the system into tiers (layers).

Typical 3-tier design:

1. Presentation tier (UI)

   • Web pages, mobile app UI, desktop UI

   • What users see and interact with

2. Application / Logic tier

   • Business rules: “Can this user create an order?”, “How is tax calculated?”

   • Runs on application servers (Java EE, .NET, Node.js, etc.)

3. Data tier

   • Databases (SQL, NoSQL), file storage, object storage

   • Safely stores data

Why this helps (benefits):

• Better scalability:

  • You can independently scale the application tier (add more app servers).

  • Database and application can be tuned separately.

• Security zoning:

  • Place UI servers in a DMZ (demilitarized zone), app servers in an internal network, DBs in a secured network.

  • Different firewall rules for each tier.

• Better management and reuse:

  • Business logic in one place can be reused by multiple UIs.

  • Easier to maintain than putting everything in client or DB.

n-tier just means more than 3 layers, for example:

• Presentation tier

• API gateway tier

• Business logic tier

• Integration tier

• Data tier

1.1.4 Service-Oriented Architecture (SOA)

Now we move from “tiers” to services.

Key idea:

The system is built from services that provide specific business functions and communicate using standard protocols.

• Each service does a business task (e.g., “Customer Service”, “Order Service”, “Payment Service”).

• Services communicate over the network using standard protocols like SOAP over HTTP, sometimes REST.

Typical characteristics:

• Often uses an Enterprise Service Bus (ESB):

  • A central “message bus” through which services talk.

  • Handles routing, transformation, security, logging.

• Services are often coarse-grained (bigger chunks of functionality than microservices).

• Strong focus on reuse and integration of existing systems (legacy apps, ERPs, etc.).

Pros:

• Encourages reusable business services.

• Helps integrate many different systems.

• Standard protocols allow different platforms and languages to work together.

Cons:

• Can become complex and heavyweight.

• ESB can turn into a bottleneck or single point of failure.

• Governance and versioning can be hard.

1.1.5 Microservices architecture

Microservices is a more modern refinement of the service idea.

Key idea:

Split the application into many small, independently deployable services, each with a clear responsibility.

• Each microservice:

  • Handles one small domain (e.g., “Cart”, “Catalog”, “Billing”).

  • Has its own codebase, often its own database (or schema).

• Services communicate through:

  • REST APIs (HTTP/JSON)

  • gRPC (binary, fast)

  • Messaging (Kafka, RabbitMQ, etc.)

Pros:

• Independent scaling:

  • If only the “Checkout” service is busy, you scale only that service.

• Independent deployments:

  • Teams can deploy changes to one microservice without touching others.

• Technology diversity:

  • Different microservices can use different languages and databases if needed.

• Supports agile development & DevOps:

  • Small teams can own individual services end-to-end.

Cons:

• Distributed complexity:

  • More network communication → network failures, timeouts, retries.

  • Difficult to debug cross-service issues (need centralized logging & tracing).

• Data consistency challenges:

  • Each service has its own data; distributed transactions are hard.

  • Use patterns like eventual consistency, sagas.

• Operational overhead:

  • Many deployable units → need strong automation, CI/CD, observability.

Analogy:
Instead of one big supermarket (monolith), you now have many small specialized shops: bakery, butcher, fruits shop, etc. Flexible, but also more complex to manage.

1.1.6 Event-driven architecture

This is more about how parts communicate than how they are structured.

Key idea:

Components communicate by sending and receiving events, usually via a message broker.

• An event is a record that something happened:

  • “OrderPlaced”, “UserRegistered”, “PaymentFailed”.

• Components publish events to a central system (message queue, event bus).

• Other components subscribe to events they care about.

Typical technologies (conceptually):

• Message queues: RabbitMQ, ActiveMQ

• Event streams: Apache Kafka

• Pub/Sub systems

Why use event-driven architecture?

• Decoupling:

  • Producers don’t need to know who consumes the events.

  • New consumers can subscribe later with no change to producers.

• Resilience:

  • If consumers are temporarily down, events can be stored and processed later.

• Scalable processing:

  • Multiple consumers can process different events in parallel.

• Useful for real-time and asynchronous processing:

  • Notifications, analytics, log collection, asynchronous workflows.

Analogy:
Imagine a public announcement board in an office:

• When something happens, someone posts a notice (“Meeting at 4pm”).

• Whoever cares reads it.

• The person posting the notice doesn’t need to know exactly who will read it.

1.2 Infrastructure Architectural Patterns

Now we move from application architecture (how software is built) to infrastructure architecture (how hardware and core platforms are arranged).

1.2.1 Scale-up vs. scale-out

These are two strategies for handling more load.

Scale-up (vertical scaling):

Add more resources (CPU, RAM) to a single machine.

• Example:

  • Upgrade a server from 16 cores to 32 cores.

  • Upgrade RAM from 64 GB to 256 GB.

Pros:

• Simple from an application perspective:

  • The app still runs on a single server.

  • No need for complex clustering or distribution.

Cons:

• There is a hardware limit: at some point you can’t add more CPU or RAM.

• Large high-end servers are expensive.

• Single point of failure: if that “big” server dies, everything on it dies.

Scale-out (horizontal scaling):

Add more nodes (servers) to share the workload.

• Example:

  • Instead of one big server, use 10 medium servers.

  • Run app instances across all of them, maybe behind a load balancer.

Pros:

• Better fault tolerance:

  • If one node fails, others keep running.

• Easier to grow:

  • Add more nodes when needed.

• Often cost-effective:

  • Many small servers vs. one huge server.

Cons:

• Application must be designed for distribution (stateless design, session handling, etc.).

• Requires load balancing, possibly shared data storage.

In vSphere context:

• vSphere clusters are designed for scale-out:

  • Many ESXi hosts in a cluster.

  • HA and DRS use this cluster to provide redundancy and load balancing.

1.2.2 High availability (HA) architectures

Goal:

Minimize downtime when failures happen.

Key elements:

• Redundant nodes:

  • Multiple servers run workloads; if one fails, others can take over.

• Clustering:

  • Group of servers that share workloads, often with automatic failover.

• Failover mechanisms:

  • Automatic detection of failure and movement or restart of services/VMs.

No Single Point of Failure (SPOF):

• A SPOF is any component which, if it fails, will bring down the whole system.

• HA designs work to eliminate or minimize SPOFs by having:

  • Redundant power (dual PSUs, dual power feeds).

  • Redundant network interfaces and switches.

  • Redundant storage paths (multipathing to storage arrays).

In vSphere:

• vSphere HA:

  • Detects host failures.

  • Restarts VMs on surviving hosts in the cluster.

• You also design:

  • Redundant physical switches and NICs.

  • Multiple storage paths (MPIO).

  • Possibly multiple vCenter instances with proper backup/restore.

1.2.3 Disaster recovery (DR) architectures

Goal:

Recover the system when an entire site fails (data center outage, natural disaster, etc.).

This is different from normal HA:

• HA: handles failure of a host inside one data center.

• DR: handles failure of an entire data center or region.

Key concepts:

• RPO (Recovery Point Objective):

  • How much data loss is acceptable?

  • Example: RPO = 15 minutes → at most 15 minutes of data can be lost.

• RTO (Recovery Time Objective):

  • How much downtime is acceptable?

  • Example: RTO = 2 hours → services must be restored within 2 hours after disaster.

Architectural mechanisms:

• A secondary site (or region):

  • Could be another physical data center or cloud region.

• Replication of data:

  • Synchronous replication:

    • Writes are committed to both primary and secondary before acknowledging.

    • Very low RPO (near zero data loss) but requires low latency between sites.

  • Asynchronous replication:

    • Data is sent to secondary site with some delay.

    • Higher RPO (some data loss possible), more tolerant of long distance.

In vSphere context:

• vSphere Replication:

  • Replicates VMs from one site to another.

• Array-based replication:

  • Storage arrays mirror data to another array.

• Site Recovery Manager (SRM):

  • Orchestrates failover and failback.

  • Automates recovery plans, startup order, network mappings.

1.2.4 On-premises / cloud / hybrid / multi-cloud

These terms describe where your workloads run.

On-premises (on-prem):

• Your own data center or server room.

• You own the hardware, networking, power, cooling, etc.

Pros:

• Full control over hardware and configuration.

• May be better for strict compliance or data residency requirements.

Cons:

• Capital expense (CapEx):

  • Need large upfront investment in hardware, facilities.

• You are responsible for hardware maintenance, upgrades, and lifecycle.

Public cloud:

• Compute, storage, and services provided by cloud providers (AWS, Azure, GCP, etc.).

• Pay-as-you-go, subscription or consumption model.

Pros:

• Elasticity: scale up/down quickly.

• Fast time-to-market (no waiting for hardware delivery).

• Many managed services.

Cons:

• Ongoing operational cost (OpEx) can grow over time.

• Less direct control over underlying hardware.

• Data egress costs and vendor lock-in risks.

Hybrid cloud:

Combination of on-prem and public cloud, with workloads able to move or span between them.

• Example:

  • Core systems on-prem (due to regulations).

  • Burst workloads to cloud during peak seasons.

• VMware example:

  • VMware Cloud on AWS:

    • Run vSphere clusters on AWS infrastructure.

    • Integrate with on-prem vSphere for VM migration (vMotion, HCX, etc.).

Benefits:

• Flexibility: keep sensitive workloads on-prem, move others to cloud.

• Gradual migration rather than “all or nothing”.

Multi-cloud:

Use multiple public cloud providers (e.g., AWS + Azure + GCP), plus maybe on-prem.

Reasons:

• Resilience: avoid dependency on a single provider.

• Best-of-breed services: use specific services where each provider is strongest.

• Negotiation power and compliance reasons.

Challenges:

• Different tools and APIs on each cloud.

• Complexity in networking, identity, security, cost management.

• Need for good governance and standardization across clouds.

2. IT Technologies Relevant to vSphere

2.1 Compute Virtualization

Compute virtualization is what allows vSphere to run many virtual machines (VMs) on one physical server.
To understand how this works, you need to understand hypervisors, CPUs, memory virtualization, and performance considerations.

2.1.1 Hypervisor concept

A hypervisor is the software layer that allows multiple VMs to share a single physical machine.

There are two types:

Type 1 Hypervisor (bare-metal):

• Installed directly on hardware

• No host operating system underneath

• VMware ESXi is a Type 1 hypervisor

• Most enterprise environments use Type 1 because it is:

  • More secure

  • More efficient

  • Designed for high-performance workloads

Type 2 Hypervisor:

• Runs on top of an existing operating system (Windows/Linux/Mac)

• Examples: VMware Workstation, VMware Fusion

• Used mainly for learning and development, not production data centers

What a hypervisor does:

• Abstracts CPU, memory, network, and storage into virtual hardware

• Each VM sees a “fake” set of hardware (e.g., VMware Virtual CPU, virtual NIC)

• ESXi manages the scheduling, resource sharing, and isolation

Beginner analogy:
A hypervisor is like a hotel manager:

• The physical building (server) is shared by many guests (VMs)

• Each guest gets a room with furniture (virtual hardware)

• The manager ensures fair resource usage and isolation between guests

2.1.2 vCPU and pCPU

To understand CPU virtualization, you need two terms:

• pCPU (physical CPU):

  • A real CPU core or hardware thread

• vCPU (virtual CPU):

  • A “virtual” core presented to a VM

A VM might have 2 vCPUs or 8 vCPUs, but the actual server might have 24 pCPUs.
ESXi’s job is to schedule vCPUs onto pCPUs in a fair and efficient way.

Design considerations include:

1. vCPU : pCPU ratio

   • ESXi allows CPU overcommit, meaning total vCPU count > total pCPU count

   • Safe ratios vary by workload type

     • Light workloads: high ratios (e.g., 10:1) often safe

     • Heavy CPU workloads (databases, analytics): lower ratios (1:1 to 3:1)

2. CPU contention

   • Too many vCPUs leads to problems:

     • High CPU Ready (%RDY)

     • High Co-Stop (%CSTP) for multi-vCPU VMs

   • Oversizing vCPUs can hurt performance more than undersizing

3. NUMA boundaries

   • Modern servers use NUMA nodes (multiple CPU sockets or memory regions)

   • Best performance = VM’s vCPUs and memory fit inside a single NUMA node

   • vSphere auto-optimizes this in most cases, but design matters for large VMs

Beginner tip:
More vCPUs ≠ faster VM
Always size according to actual workload need.

2.1.3 Memory virtualization

Memory virtualization is how ESXi can run many VMs even when total VM RAM > physical RAM.

Key techniques:

1. Transparent Page Sharing (TPS)

• Identical memory pages between VMs are merged

• Saves memory by storing shared pages only once

• Mostly disabled by default today for security reasons but still works within a VM

2. Ballooning (vmmemctl driver)

• Forces VMs to return unused memory back to ESXi

• Allows ESXi to reclaim RAM gracefully during contention

3. Memory compression

• Before swapping, ESXi tries to compress memory pages

• Faster than disk swapping

4. Swapping

• Last resort

• ESXi writes memory pages to a swap file on storage

• Dramatically slower than RAM

• Should be avoided in good designs

Huge pages & NUMA locality

• ESXi uses 2MB large pages, improving performance

• NUMA locality means memory on the same NUMA node as the VM’s vCPUs

Beginner summary:
Memory virtualization allows ESXi to run more VMs, but performance remains good only if you avoid swapping and respect NUMA.

2.2 Storage Technologies

Storage is critical in virtualization because all VMs live on shared datastores.
vSphere supports several storage types, each with different architectures and use cases.

2.2.1 Block storage

Block storage provides raw blocks of storage via SAN technologies such as:

• Fibre Channel (FC)

• iSCSI

• FCoE (Fibre Channel over Ethernet)

Block storage is used for VMFS datastores.

VMFS characteristics:

• Clustered file system

• Allows multiple hosts to share the same datastore safely

• Enables vMotion, HA, DRS, etc.

When to use block storage:

• High-performance environments

• Enterprise storage arrays

• Environments needing strong multipathing support

2.2.2 File storage

File storage provides access to shared files via:

• NFS (Network File System) v3 or v4.1

ESXi mounts the share and treats it as a datastore.

Pros:

• Easy to configure

• No need for VMFS

• Flexible and scalable

• Often used in environments where storage teams prefer NAS

Cons:

• Performance heavily depends on the network

• Not as tightly integrated as VMFS (though still well-supported)

2.2.3 Object storage

Object storage is different:

• Not block or file

• Stores objects accessed via APIs (REST/S3)

Used for:

• Backups

• Logs

• Cloud-native apps

• Archival data

Not used directly as a vSphere datastore (except in vSAN object-based internal use).

2.2.4 RAID and data protection

RAID protects data through redundancy:

• RAID 1: mirror (2 copies)

• RAID 5: 1 parity disk

• RAID 6: 2 parity disks

• RAID 10: stripe + mirror

Trade-offs:

• RAID 10 = best performance, most disk usage

• RAID 6 = good protection, lower write performance

• RAID 5 = more capacity-efficient but less resilient

2.2.5 vSphere storage options

VMware supports three main datastore types:

1. VMFS datastores (block storage)

2. NFS datastores (file storage)

3. vSAN (hyperconverged storage that pools local disks from hosts)

vSAN is important for modern designs:

• No external array needed

• Storage is distributed across ESXi hosts

• All managed via vCenter

• Uses storage policies such as FTT, RAID-1/5/6, etc.

2.3 Network Technologies

Networking is essential for virtualization because VMs, storage, and ESXi hosts all communicate via networks.

2.3.1 Physical networking

This is the hardware layer:

• Switches (Layer 2)

• Routers (Layer 3)

• VLANs (network segmentation)

• Trunking (802.1Q)

  • Allows multiple VLANs over one physical link

Redundancy techniques:

• Dual NICs

• Dual switches

• Link Aggregation (LACP or static EtherChannel)

2.3.2 Virtual networking

vSphere provides:

1. vSphere Standard Switch (vSS)

• Each host has its own local vSwitch

• Good for small environments

• Simple but not centrally managed

2. vSphere Distributed Switch (vDS)

• Centralized management via vCenter

• Consistent across all hosts

• Advanced features:

  • NIOC (Network I/O Control)

  • Port mirroring

  • LACP

  • VLAN and MTU health checks

Key concepts:

• Port groups: logical ports for VMs or VMkernel

• VMkernel interfaces:

  • Management

  • vMotion

  • vSAN

  • iSCSI/NFS

• NIC teaming:

  • Load balancing and failover policies

2.3.3 Network services

These are common IT services that vSphere depends on:

• DNS: hostnames → IP

• DHCP: automatic IP assignment

• NTP: time synchronization (vSphere REQUIRE accurate time!)

• Directory services: LDAP, Active Directory

• Firewalls: control traffic

• Load balancers: distribute traffic across servers

2.3.4 Software-Defined Networking (SDN)

SDN allows network behavior to be managed through software instead of manual switch configuration.

VMware NSX provides:

• Overlay networking (VXLAN or GENEVE)

• Distributed firewall

• Micro-segmentation

  • Security at the VM-level

• Logical routers

• Load balancing

• VPN

NSX is extremely powerful in enterprise and cloud designs.

2.4 Platform & Cloud Technologies

These modern technologies integrate with vSphere.

2.4.1 Containers & Kubernetes

Containers:

• Lightweight packages containing application code + dependencies

• Do not contain a full OS

• Start faster and consume fewer resources than VMs

Kubernetes:

• Orchestrates containers

• Manages scaling, healing, networking, and deployments

VMware Tanzu / vSphere with Tanzu:

• Integrates Kubernetes directly into vSphere

• Allows running container workloads alongside VMs

• Provides Namespaces, PodVMs, Harbor registry, etc.

2.4.2 Automation & IaC

Automation is essential for modern operations.

PowerCLI:

• VMware automation using PowerShell

• Script VM creation, host configuration, reporting, etc.

REST APIs:

• Manage vCenter, ESXi, vSAN programmatically

Infrastructure as Code (IaC):

• Treat infrastructure like version-controlled code

• Tools like Terraform, Ansible (conceptually relevant)

• Enables:

  • Repeatable deployments

  • Consistent environments

  • Automated provisioning

3. IT Standards & Frameworks

3.1 Architecture & Governance

3.1.1 TOGAF

TOGAF is an enterprise architecture framework.

Key components:

• Architecture domains:

  • Business

  • Application

  • Data

  • Technology

• ADM (Architecture Development Method):

  • A step-by-step method for building enterprise architecture

  • Very structured process

TOGAF influences how architects document and justify decisions.

3.1.2 ISO/IEC standards

Several standards influence VMware designs:

• ISO 27001: Information security

• ISO 20000: IT service management

• ISO 22301: Business continuity

These standards push requirements such as:

• Encryption

• Access controls

• DR planning

• Monitoring

• Operational processes

3.2 Service Management

ITIL

ITIL defines best practices for IT operations.

Key processes relevant to vSphere architecture:

• Incident management (restore service)

• Problem management (root cause analysis)

• Change management (approve and track changes)

• Capacity management (prevent overload)

• Availability management (design for uptime)

• Release management (structured deployments)

VMware designs often need to align with ITIL processes.

3.3 Design Quality Attributes (NFRs)

These are non-functional requirements (NFRs) and they directly affect VMware design choices:

• Availability: HA, FT, clustering, redundancy

• Performance: resource sizing, network bandwidth, storage latency

• Scalability: scale-out clusters, resource pools

• Security: RBAC, encryption, isolation

• Manageability: automation, monitoring, operations tooling

• Recoverability: backup, replication, DR runbooks, RPO/RTO

These NFRs shape almost every vSphere design decision.

IT Architectures, Technologies, Standards (Additional Content)

1. Conceptual, Logical and Physical Design

1.1 Definitions of the Three Design Layers

When you design any VMware-based solution, you should be very clear which “level” you are working at. This is important both in real projects and in exam scenarios.

Conceptual Design

Focus: business capabilities and high-level needs.

• It describes what the solution must achieve from a business perspective.

• It does not mention specific products, versions, models, IPs, or VLANs.

Typical content:

• Business goals and outcomes.

• High-level availability and recovery objectives.

• What kinds of users and workloads will be supported.

• Constraints and risks at a business level.

Example conceptual statements:

• “Provide a highly available virtualization platform capable of supporting dual-site or tri-site disaster recovery.”

• “Critical business services require RPO ≤ 15 minutes and RTO ≤ 1 hour.”

At this level, you might talk about “a highly available platform across two data centers” but not about “vSphere 8 on Dell R750 with vSAN RAID-1.”

Logical Design

Focus: components and their functional relationships.

• It answers “how the solution is structured” without going into hardware SKUs.

• You are allowed to mention technologies (vSphere, vSAN, NSX) but you still stay away from specific hardware models and exact configuration values.

• It shows logical groupings and boundaries: clusters, network zones, storage tiers.

Typical content:

• Number and types of clusters (management, production, DMZ, ROBO).

• Logical networks (management, vMotion, storage, application networks).

• Logical storage layout (vSAN for production, NFS for backup, etc.).

• High-level security zones and trust boundaries.

Example logical statements:

• “Create separate Production and Test clusters, each using shared storage.”

• “Define Management, vMotion, Storage, and Application networks as separate logical segments.”

Here you decide that there will be a vSAN-backed management cluster and a SAN-backed production cluster, but you do not yet state “six Dell R750 hosts with 25 GbE.”

Physical Design

Focus: concrete implementation and deployment details.

• It answers “exactly what will be deployed where and how.”

• It includes specific hardware, software versions, IP schemas, and cabling.

Typical content:

• Server models, CPU type, core counts, RAM sizes.

• Network topology: TOR switches, uplink speeds, port counts, VLAN IDs.

• Detailed IP addressing scheme for all networks.

• Storage arrays, RAID layout, cache/capacity disk types.

• vSphere, vSAN, NSX and other product versions.

Example physical statements:

• “Deploy 8 servers, each with 2 × CPUs and 512 GB RAM, connected redundantly to two TOR switches.”

• “Use vSphere 8.x with a vSAN datastore configured as RAID-1, FTT=1.”

At this level, your design can be handed directly to implementation engineers.

1.2 Relationship Between Conceptual, Logical and Physical Design

The three layers are tightly related and should be consistent with one another.

• Conceptual design
  Describes what needs to be achieved.
  Example: “Provide highly available infrastructure for production workloads across two sites with defined RPO/RTO.”

• Logical design
  Describes which logical components and interactions will achieve the conceptual goals.
  Example: “Two vSphere clusters per site (Management and Production), stretched L2 networks, vSAN stretched cluster for critical workloads.”

• Physical design
  Describes the exact hardware, software and configurations needed to implement the logical design.
  Example: “Site A and Site B each have 6 ESXi hosts of model X, dual 25 GbE NICs, VLAN 10/20/30, vSAN RAID-1 with FTT=1, witness in a third site.”

In practice:

• You start with conceptual design to align with business and stakeholders.

• You refine it into logical design to define architecture components and relationships.

• You translate the logical design into physical design to implement and operate the solution.

Abstraction decreases and detail increases as you move from conceptual to logical to physical.

2. Cloud Service Models and Shared Responsibility

2.1 IaaS, PaaS and SaaS Basics

Cloud service models define which parts of the stack are managed by the provider and which remain your responsibility.

IaaS (Infrastructure as a Service)

What the provider offers:

• Core infrastructure: compute, storage, networking.

• Data center facilities, power, cooling.

• Underlying hypervisors and physical servers.

What the customer manages:

• Operating systems and patches.

• Middleware (web servers, app servers, runtimes).

• Applications and services.

• Data, identity, and access control.

Examples:

• Virtual machines in public cloud.

• VMware Cloud on AWS clusters providing vSphere-based IaaS.

Design implications:

• You still need OS hardening, patching, backup, and monitoring.

• Network and security design above the hypervisor layer remains your responsibility.

• You can often reuse on-premises vSphere operational practices.

PaaS (Platform as a Service)

What the provider offers:

• Runtime platform including OS, runtime, middleware, databases, and management.

• Scaling, patching, and high availability of the platform components.

What the customer manages:

• Application code and configuration.

• Application data.

• Access control at the application level.

Examples:

• Managed database services.

• Application platforms.

• Managed Kubernetes platforms.

Design implications:

• Less focus on managing OS and middleware.

• More focus on application architecture, data modeling, and integration.

• Operational model changes: you design for the SLA and API of the platform rather than for VMs.

SaaS (Software as a Service)

What the provider offers:

• Fully managed, ready-to-use applications.

• Underlying infrastructure, platform, and application stack.

What the customer manages:

• Business usage and configuration.

• Users, roles, and data contents.

• Some security and data retention settings depending on the product.

Examples:

• Online productivity suites.

• CRM or HR SaaS applications.

Design implications:

• You focus on identity integration, data lifecycle, and compliance.

• You no longer design infrastructure for that particular workload.

• You must integrate SaaS services with your identity, logging, and governance frameworks.

2.2 Shared Responsibility Model

In any cloud model, security and compliance are shared between provider and customer. The boundary shifts depending on IaaS/PaaS/SaaS, but both sides have responsibilities.

Provider responsibilities (typical):

• Facility and physical security (data centers, access control, power).

• Underlying hardware and virtualization platform security.

• Network infrastructure inside the provider data centers.

• Patching and maintaining the cloud control plane and core services.

• Baseline protections such as DDoS mitigation and infrastructure monitoring.

Customer responsibilities (typical):

• VM operating system and middleware hardening.

• Patching guest OS and applications.

• Identity management, accounts, roles, and authentication (including MFA).

• Application security (input validation, encryption, secure coding).

• Data protection: encryption, backup, retention policies, and access control.

• Compliance with industry and regional regulations for their data.

Designing cloud-related solutions requires:

• Clear identification of which controls are implemented by the cloud provider.

• Explicit design of additional controls the enterprise must implement to close gaps.

• Alignment with internal security and compliance teams to ensure end-to-end coverage.

3. Security and Compliance

3.1 Core Security Principles

Security design must be applied consistently across VMware and cloud architectures.

Least Privilege

• Every account should be granted only the minimum set of permissions required to perform its tasks.

• Avoid using all-powerful accounts such as “Administrator” or “root” for routine operations.

• Regularly review role assignments and privileges to ensure they still match job responsibilities.

Benefits:

• Reduces blast radius if credentials are compromised.

• Limits accidental misconfigurations by non-expert users.

• Simplifies audit and compliance.

RBAC (Role-Based Access Control)

• Define roles that group permissions by function (for example, VM operator, storage admin, network admin).

• Assign roles to user groups rather than to individual users when possible.

• Use hierarchical scoping (vCenter, datacenter, cluster, folder, VM) to restrict what resources a role can affect.

Benefits:

• Easier to manage permissions for large teams.

• Consistent security model across projects and environments.

• Better traceability and accountability for operations.

Identity and Authentication

• Integrate vCenter and other components with enterprise directories such as Active Directory or LDAP.

• Use Single Sign-On (SSO) to centralize authentication.

• Enforce strong authentication methods, including multi-factor authentication (MFA), where supported.

Benefits:

• Centralized identity lifecycle management.

• Reduced risk of orphaned or local accounts.

• Stronger defense against credential theft.

Encryption

There are two primary aspects:

• Encryption at rest
  Protects stored data (for example, VM disks, backup repositories, vSAN objects).

  • Helps mitigate risk if physical media or snapshots are stolen.

  • Requires careful key management, typically via a Key Management Server (KMS).

• Encryption in transit
  Protects data as it travels over networks.

  • Use TLS/SSL for management interfaces, APIs, and application traffic.

  • Use secure protocols for remote access (SSH, HTTPS).

  • Consider encrypting east–west traffic within data centers where required.

Both types of encryption must be designed with performance, key rotation, and operational processes in mind.

3.2 Common Compliance Requirements

Compliance frameworks drive many design decisions.

Examples:

• PCI-DSS
  Applies to systems handling payment card data.
  Requires strong controls on data storage, transmission, and access:

  • Network segmentation between cardholder data environment and other zones.

  • Strong encryption and key management.

  • Strict logging, monitoring, and vulnerability management.

• GDPR and Data Sovereignty
  Applies to personal data of individuals in certain jurisdictions.
  Requirements include:

  • Strict control over how personal data is collected, processed, stored, and transferred.

  • Restrictions on cross-border data transfers.

  • Data subject rights (deletion, correction, access).

• Industry- or region-specific regulations
  For finance, government, healthcare and others:

  • Data residency requirements.

  • Minimum retention periods for records and logs.

  • Additional security controls and reporting obligations.

Impact on architecture design:

• Data center and region selection (to comply with data residency and sovereignty).

• Encryption strategy (which datasets must be encrypted, how keys are managed).

• Access control design (segregation of duties, privileged access management).

• Logging and audit retention (how long logs must be kept, how they are protected).

4. Monitoring, Logging and Observability

4.1 Monitoring and Capacity Management

Monitoring is about tracking system health and performance in real time and over time.

Core monitoring areas:

• Hosts and VMs

  • CPU utilization and CPU Ready.

  • Memory utilization and indicators of contention.

  • Disk throughput and latency.

  • Network utilization and packet error rates.

• Storage systems

  • Capacity usage and free space trends.

  • IOPS and latency per datastore or volume.

  • Health of storage paths and components.

• Network devices and links

  • Port status and error counters.

  • Bandwidth utilization on key links.

  • Health of load balancers, firewalls, and virtual switches.

Capacity management:

• Uses historical data to predict when resources will be exhausted.

• Supports decisions such as:

  • When to add additional hosts or storage.

  • When to rebalance workloads between clusters or sites.

• Should be aligned with non-functional requirements such as performance and scalability.

A good design defines:

• What needs to be monitored.

• Thresholds and alerting policies.

• How monitoring data feeds into capacity planning.

4.2 Logging and Auditing

Centralized logging is essential in medium and large environments.

Benefits of a centralized log platform:

• Collects logs from ESXi hosts, vCenter, storage arrays, network devices, and guest operating systems.

• Allows unified search and correlation across components.

• Provides a single source of truth for troubleshooting and security investigations.

Key use cases:

• Troubleshooting

  • Identify the sequence of events leading up to an incident.

  • Correlate logs across hosts, VMs, and storage.

• Security incident investigation

  • Determine which accounts performed actions and when.

  • Trace lateral movement and access attempts.

• Compliance

  • Satisfy requirements for log retention (for example, keeping audit logs for a specific number of months or years).

  • Demonstrate control over administrative actions and configuration changes.

A solid design defines:

• Which logs must be collected.

• Where they are stored and for how long.

• Who can access logs and how access is controlled.

4.3 Observability

Observability goes beyond simple monitoring.

• Metrics
  Quantitative measures such as CPU utilization, request latency, error rate, throughput.

• Logs
  Structured or unstructured event data capturing what components did and when.

• Traces
  End-to-end request paths across multiple services, especially important in microservices and distributed systems.

Goals of observability:

• Quickly determine the root cause of failures in complex systems.

• Understand the internal state of the system from its outputs.

• Validate that the system meets performance, availability, and reliability objectives.

In modern architectures:

• VM-based workloads coexist with containerized and microservices-based workloads.

• A design should integrate infrastructure and application observability:

  • Infrastructure metrics and logs (vSphere, vSAN, NSX).

  • Application-level metrics, logs, and traces.

  • Correlation between layers.

5. Hardware and Virtualization Features

5.1 CPU Virtualization Support

Modern hypervisors rely on CPU hardware extensions to achieve efficient virtualization.

Hardware virtualization extensions:

• Examples include Intel VT-x, Intel EPT (Extended Page Tables), AMD-V, and AMD RVI.

• They offload key virtualization tasks from the hypervisor to the CPU.

Benefits:

• Reduced overhead for context switching between guest and host.

• More efficient memory virtualization and address translation.

• Generally improved performance and scalability for virtual machines.

Design implications:

• BIOS/UEFI must have virtualization features enabled for ESXi to use them.

• Hardware compatibility lists should be checked for full support.

• High-performance workloads benefit significantly from proper CPU feature configuration.

5.2 Boot and Root of Trust

How a host boots affects its security posture.

UEFI vs Legacy BIOS:

• UEFI is the modern firmware standard and is preferred in new designs.

  • Supports larger boot volumes.

  • Provides better support for Secure Boot and modern hardware.

• Legacy BIOS is supported but does not provide the same level of security integration.

Secure Boot:

• Ensures that only signed and trusted components are loaded during the boot process.

• Establishes a chain of trust from firmware to bootloader, hypervisor, and drivers.

• Helps prevent malware that attempts to tamper with the boot sequence (such as bootkits and rootkits).

Design implications:

• Hosts should be configured with UEFI and Secure Boot where possible.

• Updating or adding unsigned drivers or VIBs may fail when Secure Boot is enabled; lifecycle processes must account for this.

• Trusted Platform Modules (TPMs) can be used alongside Secure Boot to provide attestation of host integrity.

5.3 Hardware Acceleration and GPU/vGPU

Certain workloads require specialized hardware acceleration to meet performance goals.

GPU passthrough and vGPU:

• GPU passthrough

  • Assigns an entire physical GPU directly to a single VM.

  • Provides near-native performance.

  • Limits sharing to one VM per GPU.

• vGPU (virtual GPU)

  • Allows a physical GPU to be shared by multiple VMs.

  • Each VM sees a virtual GPU with a defined slice of resources.

  • Suitable for VDI, AI/ML, 3D graphics, and other GPU-intensive workloads.

Design considerations:

• GPU resource allocation model (dedicated vs shared).

• Isolation and security requirements between tenants or workloads.

• Driver and firmware compatibility across ESXi, vCenter, and guest OS.

• Impact on cluster design: which hosts carry GPUs and how DRS/HA must be configured.

Other hardware accelerators:

• Encryption accelerators and cryptographic offload engines.

• Compression offload.

• SmartNICs and DPUs for network and security offload.

Impact on virtualization design:

• Host selection and quantity must account for accelerated workloads.

• Resource pools and clusters may be dedicated or tagged for GPU/accelerated workloads.

• Performance, cost, and scalability must be balanced:

  • Not all workloads need accelerators; design should target them where they add value.

  • Operational processes (monitoring, firmware updates, troubleshooting) must include these devices.

In short, hardware features and accelerators directly influence:

• Host models, densities, and counts.

• How workloads are grouped and scheduled.

• How you design for performance, scalability, and total cost of ownership.