All Azure Technologies @ one Place
While the Cloud Adoption Framework (CAF) and the Well-Architected Framework (WAF) both pertain to cloud strategy, they serve distinct purposes and operate at different times. Confusing them or neglecting one for the other can lead to significant challenges in projects.
This article aims to clarify the differences between CAF and WAF, highlight the importance of order in their application, and address the limitations of CAF so you can strategise effectively.
Understanding What Each Framework Addresses
Cloud Adoption Framework (CAF)
Focus on the organisation’s infrastructure and strategy
- Alignment of cloud strategy with business objectives
- Design of landing zones and subscription setups
- Governance around identity and access
- Planning for network structure and connectivity options
- Management of policies, compliance, and costs
- Defining the operating model and team roles
- Strategies for migration planning and execution
Well-Architected Framework (WAF)
Focus on individual workloads
- Factors of reliability, including resilience and recovery benchmarks
- Security aspects such as data safeguarding and threat management
- Cost optimisation concerning usage and efficiency
- Operational excellence through observability and deployment processes
- Performance efficiency focused on scaling and load assessments
In essence, CAF establishes a robust foundation for cloud operations, while WAF ensures that the workloads function effectively once that foundation is laid. They serve different layers and answer different queries, usually managed by separate teams within an organisation.
Reasons for Confusion Between CAF and WAF
The mix-up often arises as both frameworks touch upon security, cost management, and operational processes, which can create a superficial sense of overlap. However, the security aspects addressed by CAF focus on governance policies and identity design, whereas WAF’s security pertains to specific applications and their data protection needs.
Another factor contributing to this confusion is timing. CAF is prominent at the initiation of a cloud journey, leading teams to associate it with early stages. In contrast, WAF becomes relevant during workload assessments, giving it a perception of being a later-stage consideration. This misalignment can lead teams to view CAF as a one-time task instead of an ongoing commitment.
Many teams do not genuinely confuse CAF and WAF; they often rush through CAF, considering it complete. Consequently, WAF becomes merely a remedial task on a frail base. Dheeraj Negi, Senior Azure Platform Architect
Consequences of a Weak Foundation
Treating CAF as a simple check-in the project timeline can lead to gradual but severe issues. Initial workloads may function smoothly, but as the complexity of teams, subscriptions, and services increases, problems begin to emerge:
- Governance Oversights. Teams may deploy directly into production without appropriate policy enforcement, leading to unexpected costs due to undefined budgets and tags.
- Network Limitations. Landing zones crafted for a few workloads may not support an expanding set, resulting in connectivity issues that require retrofitting.
- Identity Issues. An unchecked proliferation of service principals without proper lifecycle management results in broader-than-intended privileged access and incomplete audit trails.
- WAF as a Temporary Fix. Routine workload reviews may repeatedly uncover the same foundational issues—such as logging, access control, and network segmentation—because they weren’t adequately addressed initially.
It’s similar to arranging furniture in a house with a faulty foundation. Begin with CAF, then proceed to WAF. This is the correct sequence for operations. Suresh Guntha, Senior Principal Cloud Architect
Establishing the Right Order
A clear mental model can simplify this understanding: CAF lays the groundwork, while WAF elevates quality. Both are essential, but the foundation must come first.
1
Establish a Strong Foundation (CAF) Develop landing zones, governance policies, identity frameworks, and network structures. This isn’t about achieving perfection but making intentional choices about how the platform will function, rather than deploying blindly.
2
Assess Workloads Using WAF’s Five Pillars Once the foundation is stable, apply WAF to evaluate each workload rigorously. This encompasses reliability, security, cost efficiency, operational observability, and performance considerations, all on a platform that can support them effectively.
3
Approach Both as Ongoing Practices, Not One-Off Tasks CAF isn’t a phase to complete; it’s a continuous process. As your organisation evolves, teams expand, and regulations change, your platform must adapt as well. Regular WAF reviews should occur at significant milestone changes, before major launches, and as the scale grows.
Clarifying Ownership It’s crucial to have a dedicated platform team that treats CAF as a project with clear timelines, while workload teams must view WAF reviews as serious assessments rather than mere compliance checks. Both frameworks require explicit ownership to be effective.
Honesty on CAF’s Limitations
While CAF provides valuable guidance and has advanced greatly over the years, it does have notable gaps that users should be aware of before relying solely on it.
Azure-Specific Focus
CAF is tailored for Azure. If your organisation runs across platforms like AWS or GCP, you’ll need to supplement it with models such as the CNCF Cloud Maturity Model or the frameworks from those vendors.
IaaS and Migration Emphasis
The most comprehensive guidance from CAF pertains to VM migrations and landing zones. Although there has been improvement in modernisation guidance, there are still gaps if you are pursuing cloud-native development from the outset.
Challenges for Smaller Teams
Implementing CAF in its entirety assumes access to dedicated cloud architects and governance specialists. For small or medium-sized teams, the full framework can overwhelm and lead to paralysis—spending more time on frameworks than on actual deployment.
Neglect of the “Manage” Phase
The “Manage” phase, which involves ongoing operations and optimisation following migration, is frequently overlooked. Teams often achieve migration but later find that operations lack cohesion and costs spiral out of control.
Addressing Concerns on Deprecated Terraform Modules You may have heard discussions regarding the “deprecation” of CAF—this primarily concerns the CAF Terraform modules (AZTFMOD), not the framework itself. The CAF strategy, methodology, and guidance documents remain actively updated. Microsoft’s Azure Verified Modules (AVM) are now the recommended approach for Infrastructure as Code (IaC) implementation.
Conclusion
The most common mistake I observe is not confusion between CAF and WAF, but rather underestimating the requirements for effective implementation of CAF. Teams often see the deployment of landing zones as the finish line, when in fact, it is merely the starting point. Governance must be enforced, identity frameworks sustained, and network structures need to evolve alongside the organisation, not just in conjunction with the initial workload.
Weak foundations lead WAF reviews to feel like archaeological digs, where teams uncover issues that should have been resolved earlier. Repeatedly identifying the same challenges across workloads occurs when the underlying causes have never been addressed.
The key takeaway is that CAF should not be regarded as a standalone project with a defined end, nor should WAF be viewed as a task completed before going live. Both are continuous practices that necessitate clear ownership. Identify who is responsible for the platform and for each workload, ensuring that both teams have accountability, which will help alleviate much of the confusion surrounding CAF and WAF.
Share this content:
Discover more from Qureshi
Subscribe to get the latest posts sent to your email.
