sep 2023 content update

106-Well Architected/wds/00_workshop_intro/01_workshop_intro.md

@@ -0,0 +1,56 @@
+# Architecting for Success
+
+---
+
+## 106 - Azure Well Architected Workshop
+
+### Workshop Introduction
+
+The Well-Architected Framework (WAF) mindset focuses on overall workload health, highlighting the full picture of the customer's architecture, and the importance of an iterative, five-pillar approach.​ Working within a Well-Architected Framework requires a shift away from narrow, siloed solutions and toward holistic, integrative approaches to solving a customer's infrastructure as a service (IaaS) challenges. At the end of the workshop, participants will be able to:
+
+* Outline customer needs, business priorities, and key architectural characteristics given a realistic customer workload.
+* Conduct a cross-pillar analysis and determine key gaps in the workload's alignment with the Well-Architected Framework.
+* Develop a prioritized list of recommendations and next steps.
+* Practice proactive customer conversations around the Well-Architected Framework.
+
+---
+
+### Basics of the Well-Architected Framework
+
+Employing a Well-Architected Framework begins with understanding the five-pillar approach, which acknowledges that any high-functioning framework addresses the following areas:
+
+* Reliability - The ability of a system to recover from failures and continue to function.
+* Security - Protecting applications and data from threats.
+* Cost optimization - Managing costs to maximize the value delivered.
+* Operational excellence - Operations processes that keep a system running in production.
+* Performance efficiency - The ability of a system to adapt to changes in load.
+
+The strategic and long-term viability of the workload requires an end-to-end, holistic review spanning all five pillars.
+
+---
+
+### Cross-functional areas
+
+Our customers do not think of their needs and goals in terms of pillars. Rather, they seek to accomplish cross-functional goals to meet their business objectives. In this workshop, we'll review a customer scenario and identify solutions for five common cross-functional areas of focus:
+
+* Resiliency - Analyze how business continuity and disaster recovery requirements are being addressed by the workload architecture and operational strategies.
+* Performance and Scale - Analyze the performance and scalability requirements within the workload architecture; evaluate how they contribute to and/or are affected by the overall fault tolerance of the workload.
+* Security, Governance & Identity - Analyze how security, governance, and identity requirements are being addressed by the workload architecture and operational strategies.
+* DevOps - Analyze the automation and deployment strategies for the workload.
+* Observability - Analyze how observability requirements are being addressed by the workload architecture and operational strategies.
+
+---
+
+### An iterative approach
+
+It's also important to recognize that implementing a Well-Architected Framework requires an iterative approach, as described in the workflow diagram.
+
+> ![Well-Architected Framework workflow](/106-Well%20Architected/images/waf_workflow.png)
+
+This workshop is primarily focused on phases one, two, and three, in which you:
+
+* Discover the customer's needs
+* Analyze to identify potential solutions
+* Prioritize—or conduct triage to determine what needs to be implemented first
+
+We will also discuss the optimization that occurs post-implementation to further enhance and refine the customer's architecture.

106-Well Architected/wds/00_workshop_intro/readme.md

@@ -0,0 +1,30 @@
+# Architecting for Success
+
+---
+
+## 106 - Microsoft Azure Well Architected Workshop
+
+---
+
+## Workshop Introduction
+
+At the end of the workshop, participants will be able to:
+
+* Outline customer needs, business priorities, and key architectural characteristics given a realistic customer workload.
+* Conduct a cross-pillar analysis and determine key gaps in the workload's alignment with the Well-Architected Framework.
+* Develop a prioritized list of recommendations and next steps.
+* Practice proactive customer conversations around the Well-Architected Framework.
+
+## Agenda
+
+Time | Session | Type
+---------|----------|---------
+ 1000-1020 | Introduction | General
+ 1020-1040 | How to approach and interact with your customer | General
+ 1040-1100 | Determine customer objectives | Team
+ 1100-1330 | Well-Architected cross-functional areas analysis | Team
+ 1330-1430 | Lunch |
+ 1430-1530 | Develop a prioritized list of recommendations and next steps | Team
+ 1530-1630 | Present recommendations to customer | Team
+ 1630-1730 | Optimizing the customer's workload | Team
+ 1730-1745 | Wrap-up and next steps | General

106-Well Architected/wds/01_prepare_for_your_customer_conversation/01_determine_customer_objectives.md

@@ -0,0 +1,55 @@
+# Architecting for Success
+
+---
+
+## 106 - Microsoft Azure Well Architected Workshop
+
+---
+
+## Prepare for your customer conversation
+
+**Objective**
+By the end of this unit, you will be able to:
+Outline customer needs, business priorities, and key architectural characteristics given a realistic customer workload.
+Conduct a cross-pillar analysis and determine key gaps in the workload's alignment with the Well-Architected Framework.
+
+**Team lead guidance**
+Assign a timekeeper and instruct them to provide a warning when time is running out.
+Encourage all members to share their ideas.
+When necessary, reach out to your coach.
+
+### Overview
+
+In this activity, you'll use the information provided in the customer scenario to create a list of the customer's needs and outline some goals.
+
+### Participant guidance
+
+* Analyze and discuss with your team the information in the customer scenario.
+* Establish the customer needs and determine customer objectives, desired outcomes, and business priorities around PaaS or IaaS.
+* Discuss the following questions with your team and document your answers in the observation chart.  
+  * What are the customer's main objectives?
+  * What are the customer's needs?
+  * What is the key information of the case?
+  * What is the business priority?
+* Document your answers.
+
+Duration: xx minutes
+
+### Participant steps
+
+1. Select either the PaaS scenario or the IaaS scenario, depending on what is most relevant to your group.
+2. Review your chosen customer scenario.
+3. Discuss the questions with your team and document your answers to start identifying solutions for the customer.
+4. Go to the next activity to begin your whiteboarding sessions.
+
+---
+
+### Summary
+
+During this session, you discussed the scenario, establishing the customer's goals and identifying notable challenges and areas of opportunity presented by their current architecture and desired outcomes. Next, you'll analyze the scenario in more depth, brainstorming solutions for five key cross-functional areas of focus.
+
+---
+
+### Team notes area
+
+[This area is left blank for student use]

106-Well Architected/wds/01_prepare_for_your_customer_conversation/02a_customer_scenario_paas.md

@@ -0,0 +1,123 @@
+# Architecting for Success
+
+---
+
+## 106 - Microsoft Azure Well Architected Workshop
+
+---
+
+## Prepare for your customer conversation - Customer scenario: Adatum Deliveries (PaaS)
+
+### Part 1: Current state
+
+![Current Architecture](adatum_paas.png)
+
+Business model, geography, and size
+* Logistics company providing next-day delivery services across the European Union
+* The company is subject to the General Data Protection Regulation (GDPR)
+* Headquartered in Paris, France
+* Manages an international fleet of planes, tracks, and delivery vehicles
+
+Technology landscape
+* An on-premises datacenter (headquarters)
+* A custom Azure-hosted delivery platform (SmartDelivery)
+* Provides services to schedule, track, and fulfill deliveries
+* Serves as a backend for client apps (mobile and browser-based)
+
+Business continuity and disaster recovery (BCDR)
+* No existing disaster recovery plans
+
+Operational model
+* Centralized, following the enterprise operations approach
+* SmartDelivery is an exception, managed by an autonomous development team
+* Includes a newly formed Cloud Center of Excellence (CCoE) team
+
+Cloud security model
+* Relies primarily on network isolation
+
+Internal IT knowledge and experience
+* Expert knowledge of on-premises workloads
+* Some experience with Azure PaaS
+* Gaps in knowledge of Azure-based containerized workloads
+* Gaps in development of cloud-native apps
+* Little experience with Azure
+* Familiarity with DevOps using GitHub Enterprise and Bicep
+
+---
+
+### Part 2: Current workload
+
+SmartDelivery
+* The first and so far only cloud native app onboarded to Azure
+* Owned by the dedicated SmartDelivery development team
+  * Affected recently by a platform outage of Cosmos DB
+  * Led to negative publicity and reputational damage
+  * Designed and deployed as a set of APIs
+  * Container-based backend
+  * Web API-based front end
+  * Majority of API calls are synchronous
+
+Current workload architecture
+* Microservices-based
+* Containerized backend APIs hosted on an Azure Kubernetes Service (AKS) cluster
+  * A single agent pool manually scaled to ten instances
+  * Container images stored in an Azure Container Registry (ACR)
+* Web APIs for client access deployed in an App Service Environment (ASE)
+* Delivery data in a Cosmos DB account configured with locally redundant backups
+
+Environments
+* A single-region deployment (France Central)
+* Isolation between production, staging, and development
+* Each environment uses a matching set of compute and storage resources
+
+Current workload networking
+* An ASE deployment
+  * Accessible via Azure Front Door
+    * ExpressRoute connection from headquarters
+    * A public endpoint from Internet-based clients
+* An AKS cluster
+  * Accessible via a single, public-facing jumpbox Azure VM by the SmartDelivery team
+  * Accessible from the ASE deployment via virtual network peering
+* A Cosmos DB account
+  * Accessible via private endpoint only (not exposed to public internet) from AKS
+* An Azure Storage account
+  * Accessible via private endpoint only (not exposed to public internet)
+* An ACR instance
+  * Accessible via a public endpoint
+
+Current workload DevOps status
+* Development and staging environments
+  * Configured identically to the production environment but not exposed to the public internet via Azure Front Door
+  * Separated physically (separate AKS clusters/ASEs) and logically (application-based)
+* CI/CD pipelines hosted in GitHub Enterprise
+  * Automated by using GitHub Actions and Bicep templates
+* AKS telemetry
+  * Collected by using Azure Application Insights
+  * Stored in an Azure Storage account
+  * Exported to a third-party security information and event management (SIEM) system
+* AKS configuration and troubleshooting
+  * Performed on as-needed basis from the jumpbox Azure VM by the SmartDelivery team (using local credentials)
+
+---
+
+### Part 3: Customer needs
+
+* Recommend a solution that minimizes the impact of regional Cosmos DB outages
+* Enhance the current architectural design to provide 99.95% availability service-level agreement (SLA)
+* Recommend a BCDR strategy that provides recovery point objective (RPO) of six hours and recovery time objective (RTO) of four hours
+* Minimize cost while maintaining the desired SLA, RPO, and RTO, and network isolation, including alternatives for hosting client access APIs (in lieu of ASE)
+* Ensure GDPR compliance and retain all customer data within the EU boundaries
+* Replace synchronous processing with an event-driven, asynchronous approach
+* Identify methods of protecting against AKS pod-level escalation of privileges
+* Ensure network isolation whenever feasible, including microservices and client access APIs, ACR (The SmartDelivery team attempted to implement an ACR private endpoint but had to revert the change due to subsequent failures of GitHub Enterprise deployments) and AKS
+* Leverage Azure-native solutions whenever feasible
+* Minimize operational overhead
+
+---
+
+### Part 4: Customer objections
+
+* The Adatum's Finance department is concerned that implementing a solution providing 99.95% availability SLA will practically double the current cost. They will not approve such a steep increase in budget.
+* The Adatum's CIO considers the 99.95% availability SLA essential to redeeming the company's reputation and will object to any solution that does not meet this goal.
+* The SmartDelivery development team will object to any solution that would complicate or slow down their existing automated deployment process.
+* The CCoE team expects a solution that would facilitate deployment of additional cloud-native workloads like SmartDelivery and will not accept any solution that does not promote repeatability.

106-Well Architected/wds/01_prepare_for_your_customer_conversation/readme.md

@@ -0,0 +1,17 @@
+# Architecting for Success
+
+---
+
+## 106 - Microsoft Azure Well Architected Workshop
+
+---
+
+## Prepare for your customer conversation
+
+**Objective**
+At the end of the unit, participants will be able to:
+
+* Outline customer needs, business priorities, and key architectural characteristics given a realistic customer workload.
+
+**Overview**
+In this unit, you will read the customer scenario to understand their needs and objectives. Select either the platform as a service scenario or the infrastructure as a service scenario, depending on what is most relevant to your group.