Is your feature request related to a problem? Please describe.
When we deploy SQL VMs to host the databases we'll need a VNET and associated resources

Describe the solution you'd like
To keep things simple, we could re-use the existing VNET created when we choose to use private endpoints

Describe alternatives you've considered
We could create separate VNETs for each tier

• Add additional subnets for the database and web tiers
• Add NSGs for each subnet
• Add a Bastion subnet
• Remove public IP from jumpbox
• Remove NSG from jumpbox

We should also split up the createResources.bicep so that it improves readability. We should split this into modules for front end, back end and Database.

• Create a core infrastructure module for shared resources across IAAS & PAAS
• Create a module for deploying Front end on IAAS and call from createResources.bicep
• Create a module for deploying Front end on PAAS and call from createResources.bicep
• Create a module for deploying Middle tier on IAAS and call from createResources.bicep
• Create a module for deploying Middle tier on PAAS and call from createResources.bicep
• Create a module for deploying Back end on IAAS and call from createResources.bicep
• Create a module for deploying Back end on PAAS and call from createResources.bicep

Is your feature request related to a problem? Please describe.
I'd like to demo using this application and chaos studio / load testing on IAAS workloads.

Describe the solution you'd like
I'd like to move the React UI from App Service to IIS on IAAS VMs. There should be a parameter flag, similar to the private endpoints one to say whether it should be deployed on IAAS/PAAS.

• Modify pipeline to deploy React app to IIS

Describe the bug
The backend VMs for IIS are showing as unhealthy for Azure Front Door because the NSG is wrong.

Expected behavior
We need to change the NSG rule so that it is FrontDoor.Backend as the source and VNET as the target

Describe the bug
This is happening due to trying to use hardcoded API URLs in the actions yaml which are looking for the container apps environment

In the current codebase, the carts API is only called if a user is logged in. It would be good to enable this so it's always called in order to enable more chaos experiments to be run on the environment

The container apps environment for the internal carts API is still being deployed when the deploy APIs on IAAS is enabled. Will be related to the fact that there is a conditional on this resource to deploy when privatendpoints is enabled

Right now the main part of the workshop relies on workshop users to generate the chaos experiments.

There is also another way of running the workshop where the proctors create some chaos for all participant teams. It would be good to capture these so these need not have to be built from scratch.

Some examples:

1. network latency between tiers
2. High CPU or memory pressure on the IIS VMs
3. network packet loss between Prod API and its SQL database

Is your feature request related to a problem? Please describe.
I'd like to demo using this application and chaos studio / load testing on IAAS workloads.

Describe the solution you'd like
A simple first step would be to move the SQL databases from Azure SQL to SQL cluster on IAAS VMs. There should be a parameter flag, similar to the private endpoints one to say whether it should be deployed on IAAS/PAAS.

• #2
• Create bicep code to deploy a SQL cluster across 3 AZs
• Understand if the SQL connection string needs to be updated

When running initial deployment we're getting dependency errors when creating the NSGs as the vnet hasn't been deployed yet

We should use AVM for all bicep modules.

When IIS VMs are deployed, the front door web endpoint should be updated to point at the load balancer and the route should be changed to use HTTP instead of HTTPS

We need a list of ten experiments that can be run on the environment, including prompt for each one, suggested ways of achieving the challenge, expected outcomes and what monitoring needs to be enabled to pick it up. The experiments should build on each other like in an openhack.
Suggested experiments to run:

• Bring down Front end website
• Disable products API
• Disable product images
• Disable carts API
• Simulate an identity outage
• Slow down but don't disable the SQL server
• Create intermittent response from main website
• Prevent the APIs from authenticating to the SQL server

In order to allow bastion tunnel from dev machine to SQL server we need to upgrade Bastion to the standard SKU and enable native client

In order to clean up the code and follow best practice, we should switch to using Azure Verified Modules.

• Core infrastructure module
• IAAS Front end module
• PAAS Front end module
• #42
• #41
• #38
• PAAS Back end module

the background load test required for chaos needs to be added to the repo

This load test tests all of:

1. Product API
2. Cart API
3. Homepage
4. Images

Ideally add a CSV or two to randomise these to make the tests more realistic.

Start using Azure Verified modules for the middle tier PAAS resources

Is your feature request related to a problem? Please describe.
I'd like to demo using this application and chaos studio / load testing on IAAS workloads.

Describe the solution you'd like
I'd like to move the React UI from App Service to IIS on IAAS VMs. There should be a parameter flag, similar to the private endpoints one to say whether it should be deployed on IAAS/PAAS.

• #2
• Create bicep code to deploy three IIS VMs across 3 AZs
• Create a load balancer in front of the VMs to distribute traffic
• #4

Create a runbook for running a Game Day hack

Describe the bug
The docker container isn't running on the VMs. Need to change the ACRPASSWORD in the actions file

Move middle tier IAAS VMs to Azure Verified Modules