Cloud & Infrastructure Architecture

We start with workload requirements rather than a preferred destination.
We look at factors such as:

• availability and recovery requirements,
• latency and network dependencies,
• data location and security,
• application architecture,
• performance and capacity,
• platform dependencies,
• operating skills,
• cost and commercial commitments,
• portability and future change.

Some workloads benefit strongly from managed cloud services. Others may fit private infrastructure better. Many enterprise systems need a hybrid architecture during transition or for the longer term.
The target should follow the workload.

Hybrid architecture connects workloads and services running in different environments, typically public cloud with private cloud, colocation or on-premises infrastructure.
The difficult part is rarely drawing two environments on the same diagram.
Identity, routing, DNS, security, latency, monitoring and failure handling need to work across the boundary.
AWS specifically warns that hybrid-network reliability depends on both environments and the connections between them, because a failure in one network path can affect the availability of the complete workload.

No.
Adding another environment can actually add more failure modes if workloads depend on synchronous services across unreliable or slow network links.
Hybrid resilience needs deliberate design.
For example, Microsoft recommends redundant connectivity paths, different peering locations and, for critical workloads, geographically diverse connectivity rather than relying on a single private circuit.
We look at the complete service path rather than assuming two locations automatically mean high availability.

We first identify the business flows that must remain available and what failure the business can tolerate.
From there we define availability and recovery targets and examine failure domains across compute, storage, data, networking and dependent services.
The architecture may then use multiple instances, zones, sites or regions where those measures are justified.
Google’s reliability guidance follows the same principle: distribute critical workload components across independent failure domains when the required availability justifies it.

No.
Multi-region architectures can improve resilience against regional failures, but they also add cost, data replication, operational complexity and additional failure modes.
The architecture should reflect the business impact of an outage.
For some systems, zone-level redundancy and tested regional recovery are enough. For others, regional failure cannot be tolerated and a multi-region model is justified.
Microsoft’s current Well-Architected guidance explicitly treats reliability as a trade-off with cost, security and operational complexity rather than something that should simply be maximized.

We look at bandwidth, latency, routing, availability, security and the importance of the workloads using the connection.
Depending on the environment, this can include provider-native private connectivity, carrier services, VPN, SD-WAN or combinations of several paths.
The important part is avoiding a hidden network single point of failure.
Microsoft, for example, recommends redundant ExpressRoute circuits from different peering locations for higher resilience and allows VPN to provide an additional path in suitable scenarios.
The same architectural principle applies regardless of cloud provider: the backup path has to support the workload when the primary path is gone.

Yes.
We are cloud agnostic and can design architectures involving public, regional or sovereign cloud providers together with private and on-premises infrastructure.
But we do not recommend multi-cloud simply to say that an organization uses several providers.
A multi-cloud design should solve a concrete requirement such as workload placement, regulatory constraints, acquisition history, geographic needs, service capability or concentration risk.
Otherwise it can increase networking, identity, skills and operational complexity without creating equivalent value.

The exact deliverables depend on scope, but typically include:

• target infrastructure architecture,
• workload placement decisions,
• network and connectivity architecture,
• availability and failure-domain model,
• backup and disaster recovery approach,
• security and management architecture,
• architecture decision records,
• risks and assumptions,
• implementation roadmap.

For critical systems, we can also define implementation checkpoints and continue through Architecture Review & Assurance.