The Well-Architected Framework provides recommendations to helparchitects, developers, administrators, and other cloud practitioners design andoperate a cloud topology that's secure, efficient, resilient, high-performing,cost-effective, and sustainable.

A cross-functional team of experts at Google validates the recommendations inthe Well-Architected Framework. The team curates the Well-Architected Framework toreflect the expanding capabilities of Google Cloud, industry best practices,community knowledge, and feedback from you. For a summary of the significantchanges to the Well-Architected Framework, seeWhat's new.

The Well-Architected Framework is relevant to applications built for the cloudandfor workloads migrated from on-premises to Google Cloud, hybrid clouddeployments, and multi-cloud environments.

Well-Architected Framework pillars and perspectives

The recommendations in the Well-Architected Framework are organized into pillars andcross-pillar perspectives, as shown in the following diagram.

• Apillar in the Well-Architected Framework providesprinciples and recommendations for a specific non-functional focus area:security, reliability, performance, cost, operations, or sustainability.

• Aperspective in the Well-Architected Frameworkis a cross-pillar view of recommendations for a specific technology or industry.The recommendations in a perspective align with the general principles andrecommendations in the pillars.

  For example, the financial services industry (FSI) perspectiverecommends a disaster recovery strategy that meets regulatory requirements fordata residency. This FSI-specific recommendation aligns with the reliabilitypillar's principle about realistic targets, because the data residencyrequirements influence the choice of failover region and, consequently, therecovery objectives.

Pillars

constructionOperational excellence

Efficiently deploy, operate, monitor, and manage your cloud workloads.

securitySecurity, privacy, and compliance

Maximize the security of your data and workloads in the cloud, design forprivacy, and align with regulatory requirements and standards.

restoreReliability

Design and operate resilient and highly available workloads in the cloud.

paymentCost optimization

Maximize the business value of your investment in Google Cloud.

speedPerformance optimization

Design and tune your cloud resources for optimal performance.

ecoSustainability

Build and manage cloud workloads that are environmentally sustainable.

Cross-pillar perspectives

saved_searchAI and ML

A cross-pillar view of technology-specific recommendations for AI and MLworkloads.

saved_searchFinancial services industry (FSI)

A cross-pillar view of industry-specific recommendations for FSI workloads.

Core principles

Before you explore the recommendations in each pillar of the Well-Architected Framework,review the following core principles:

Design for change

No system is static. The needs of its users, the goals of the team that buildsthe system, and the system itself are constantly changing. With the need for changein mind, build a development and production process that enables teams toregularly deliver small changes and get fast feedback on those changes.Consistently demonstrating the ability to deploy changes helps to build trustwith stakeholders, including the teams responsible for the system, and the usersof the system. UsingDORA's software delivery metrics can help your team monitor the speed, ease, and safety of making changes to thesystem.

Document your architecture

When you start to move your workloads to the cloud or build your applications,lack of documentation about the system can be a major obstacle. Documentationis especially important for correctly visualizing the architecture of yourcurrent deployments.

Quality documentation isn't achieved by producing a specificamount of documentation, but by how clear content is, how useful it is, and howit's maintained as the system changes.

A properly documented cloud architecture establishes a common language andstandards, which enable cross-functional teams to communicate and collaborateeffectively. The documentation also provides the information that's necessary toidentify and guide future design decisions. Documentation should be written withyour use cases in mind, to provide context for the design decisions.

Over time, your design decisions will evolve and change. The change historyprovides the context that your teams require to align initiatives, avoidduplication, and measure performance changes effectively over time. Change logsare particularly valuable when you onboard a new cloud architect who is not yetfamiliar with your current design, strategy, or history.

Analysis by DORA has found a clear link between documentation quality and organizationalperformance — the organization's ability to meet their performance andprofitability goals.

Simplify your design and use fully managed services

Simplicity is crucial for design. If your architecture is too complex tounderstand, it will be difficult to implement the design and manage it overtime. Where feasible, use fully managed services to minimize the risks, time,and effort associated with managing and maintaining baseline systems.

If you're already running your workloads in production, test with managedservices to see how they might help to reduce operational complexities. Ifyou're developing new workloads, then start simple, establish a minimal viableproduct (MVP), and resist the urge to over-engineer. You can identifyexceptional use cases, iterate, and improve your systems incrementally overtime.

Decouple your architecture

Research from DORA shows that architecture is an important predictor for achieving continuousdelivery. Decoupling is a technique that's used to separate your applicationsand service components into smaller components that can operate independently.For example, you might separate a monolithic application stack into individualservice components. In a loosely coupled architecture, an application can runits functions independently, regardless of the various dependencies.

A decoupled architecture gives you increased flexibility to do the following:

• Apply independent upgrades.
• Enforce specific security controls.
• Establish reliability goals for each subsystem.
• Monitor health.
• Granularly control performance and cost parameters.

You can start the decoupling process early in your design phase or incorporateit as part of your system upgrades as you scale.

Use a stateless architecture

A stateless architecture can increase both the reliability and scalability ofyour applications.

Stateful applications rely on various dependencies to perform tasks, such aslocal caching of data. Stateful applications often require additional mechanismsto capture progress and restart gracefully. Stateless applications can performtasks without significant local dependencies by using shared storage or cachedservices. A stateless architecture enables your applications to scale up quicklywith minimum boot dependencies. The applications can withstand hard restarts,have lower downtime, and provide better performance for end users.