VBD: Add initial containers checklist

.vscode/cspell.json

@@ -32,6 +32,7 @@
         "azurerm",
         "azuresecret",
         "azureuser",
+        "BCDR",
         "Bookstore",
         "CICD",
         "Cleanup",
@@ -47,6 +48,7 @@
         "filesystembackup",
         "GMSA",
         "GZRS",
+        "Heptio",
         "hostnames",
         "isnt",
         "jumpbox",
@@ -61,6 +63,7 @@
         "millicores",
         "machinelearningservices",
         "MSRC",
+        "nodepool",
         "nouser",
         "npuser",
         "openservicemesh",

Scenarios/Initial-Containers-Checklist/README.md

@@ -0,0 +1,46 @@
+# Application Migration to Azure Kubernetes Service Guide
+## Architectural and Non-Functional Requirements Checklist
+
+
+Migrating a web application to Azure Kubernetes Service (AKS) involves careful planning and consideration to ensure a successful and smooth transition. As you analyze your application's architecture to determine its suitability for containerization and microservices this list attempts to provide guidance and key considerations to keep in mind during the migration process.</br>
+
+
+|  Topic       |  Guidance |
+|--------------|-----------|
+|Azure subscription that will host Azure Kubernetes service and other required resources.|[Subscriptions, licenses, accounts, and tenants for Microsoft's cloud offerings](https://learn.microsoft.com/en-us/microsoft-365/enterprise/subscriptions-licenses-accounts-and-tenants-for-microsoft-cloud-offerings?view=o365-worldwide)|
+|The dependency graph of the application is known and documented, including databases and network storage, and all external services (such as other web applications) that the application relies on or that rely on this application, and can be assessed and migrated simultaneously, or components remain as-is without loss of connectivity or degradation of service.| Azure Application Insights supports [several scenarios](https://learn.microsoft.com/en-us/azure/azure-monitor/app/codeless-overview) and generates an Application Map that helps visualize how your application interacts with other resources. |
+|Service Level Agreements (SLA) for Online Services|[Licensing Documents (microsoft.com)](https://www.microsoft.com/licensing/docs/view/Service-Level-Agreements-SLA-for-Online-Services?lang=1&year=2023)|
+|Requirement of advanced configuration for the application workload to adhere to regulatory compliances.|[Azure compliance documentation](https://learn.microsoft.com/en-us/azure/compliance/)|
+|Security|Container security protects the entire end-to-end pipeline from build to the application workloads running in Azure Kubernetes Service (AKS). </br> </br>Kubernetes includes security components, such as pod security standards and Secrets. Azure includes components like Active Directory, Microsoft Defender for Containers, Azure Policy, Azure Key Vault, network security groups, and orchestrated cluster upgrades.</br></br>See guidance provided here [Security concepts for applications and clusters in Azure Kubernetes Service](https://learn.microsoft.com/en-us/azure/aks/concepts-security)|
+|BCDR Requirements|When your applications store and consume data persisted on disks or in files, you need to take regular backups or snapshots of that data, back up your data using an appropriate tool for your storage type, such as Velero or Azure Backup. Verify the integrity and security of those backups.</br> </br>[Azure Backup now allows you to back up AKS clusters](https://learn.microsoft.com/en-us/azure/backup/azure-kubernetes-service-cluster-backup) (cluster resources and persistent volumes attached to the cluster) using a backup extension </br> </br>[Velero](https://github.com/vmware-tanzu/velero) (formerly Heptio Ark) gives you tools to back up and restore your Kubernetes cluster resources and persistent volumes. You can run Velero with a public cloud platform or on-premises.|
+
+## Runtime Environment Checklist
+|  Topic       |  Guidance |
+|--------------|-----------|
+|Application Architecture|Analyze your application's architecture to determine its suitability for containerization and microservices. Identify stateless and stateful components that need to be migrated.|
+|Application Containerization|Containerize your application, Azure Migrate offers a unified platform to assess and migrate to Azure on-premises servers, infrastructure, applications, and data. For AKS, you can use Azure Migrate for the following tasks: </br>-[Containerizing ASP.NET applications and migrating to AKS.](https://learn.microsoft.com/en-us/azure/migrate/tutorial-app-containerization-aspnet-kubernetes) </br>-[Containerizing Java web applications and migrating to AKS](https://learn.microsoft.com/en-us/azure/migrate/tutorial-app-containerization-java-kubernetes)|
+| Networking | Think about your organization's security posture and requirements as well as the visibility of your application that will be hosted on AKS. AKS can support a private or public networking configuration, but it will still require egress to the internet to retrieve node image and package updates. Consider whether your security requirements would entail service such as Azure Firewall to filter egress, private endpoints or service endpoints for private resource access or an internal load balancer in front of the cluster to keep it hidden from public consumption. For information on networking considerations, reference [Microsoft Learn](https://learn.microsoft.com/en-us/azure/aks/concepts-network) for additional information. |
+|Operating System| Determine which OS, Linux or Windows, that your application should run on. If you have an application that runs on Linux, we recommend migrating to a Linux nodepool on AKS. If your application must run on Windows, the following limitations apply to Windows Server node pools:</br> </br>AKS supports Windows Server 2019 and 2022 node pools. Windows Server 2022 is the default operating system for Kubernetes versions 1.25.0 and higher. Windows Server 2019 is the default OS for earlier versions.</br></br>-The AKS cluster can have a maximum of 10 node pools. </br>-The AKS cluster can have a maximum of 100 nodes in each node pool.</br>-The Windows Server node pool name has a limit of six characters.</br></br>[Limitations](https://learn.microsoft.com/en-us/azure/aks/learn/quick-windows-container-deploy-cli#limitations)
+|Monitoring|AKS generates the same kinds of monitoring data as other Azure resources that are described in Monitoring data from Azure resources. See Monitoring AKS data reference for detailed information on the metrics and logs created by AKS.</br> </br>AKS generates the same kinds of monitoring data as other Azure resources that are described in Monitoring data from Azure resources. See Monitoring AKS data reference for detailed information on the metrics and logs created by AKS.</br> </br> Refer to [Monitor Azure Kubernetes Service (AKS)](https://learn.microsoft.com/en-us/azure/aks/monitor-aks)
+|Cost Optimization|Cost optimization is about understanding your different configuration options and recommended best practices to reduce unnecessary expenses and improve operational efficiencies. Before you use this article, you should see the cost optimization section in the Azure Well-Architected Framework.</br></br>When discussing cost optimization with Azure Kubernetes Service, it's important to distinguish between cost of cluster resources and cost of workload resources. Cluster resources are a shared responsibility between the cluster admin and their resource provider, while workload resources are the domain of a developer. Azure Kubernetes Service has considerations and recommendations for both of these roles.</br></br> Refer to [Optimize costs in Azure Kubernetes Service (AKS)](https://learn.microsoft.com/en-us/azure/aks/best-practices-cost)|
+|Scaling|Azure Kubernetes Service (AKS) can be scaled-in and out depending upon infrastructure needs (requiring more or less capacity), adding node pools with special capabilities like GPU, or application needs, in this case you have several factors like number and rate of concurrent connections, number of requests, back-end latencies on AKS applications.</br></br>The most common scalability options for AKS are the cluster autoscaler and the horizontal pod autoscaler. The cluster autoscaler adjusts the number of nodes based on the requested compute resources in the node pool. The horizontal pod autoscaler (HPA) adjusts the number of pods in a deployment depending on CPU utilization or other configured metrics.</br></br>[Scalability considerations for Azure Kubernetes Service environments](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/scenarios/app-platform/aks/scalability)|
+| Resource Requirements| Assess your application's current resource requirements (CPU, memory, storage). Containers can be allocated for specific resource limits and understanding these requirements is important for proper container sizing. These limits also go hand in hand with scaling. You need to ensure you have enough resources to scale your application during peak traffic. |
+
+
+## Application Dependencies Checklist
+|  Topic       |  Guidance  |
+|--------------|------------|
+|Persistent Storage| Pods are stateless and anything saved to the file system on the pod does not persist passed the lifecycle of the pod. Consider if your application requires access to files either stored on the filesystem or from a remote location. AKS supports various storage options such as Azure Disks, Azure Files, and persistent volumes (PVs). | 
+| Virtual Directory/Filesystem | It is a common practice to store web app content under site root or on the mounted virtual directories. Any files that require persistent changes will be reset during pod restarts and will not transfer across pods. It is recommended that any files that have changes that need to persist to store them in a persistent volume mounted to the node. External storage guarantees the maintenance of files and is accessible across all pods which supports consistency across all instances of the application. Find more info [here](https://learn.microsoft.com/azure/aks/concepts-storage#storage-classes) about the different types of storage you can mount to identify the option that best fits your applications data storage requirements. |
+| Native OS Operations | Any operations that require direct access to part of the OS such as applications writing to the registry are supported in AKS, but since containers are stateless, you should be mindful of these actions because anything that needs to persist beyond the life of the pod will be reset when the pods are destroyed or restarted. |
+| Session Management and Caching | Since containers are stateless, it is recommended to transition state management models to use services such as Redis Cache to store the session information outside of the cluster to prevent deletion when pods are destroyed or restarted. This model also helps reduce memory consumption on the container. If your application manages state locally, consider moving to an external state management provider. |
+| Domain Services | AKS supports Windows Authentication and Group Managed Service Accounts (GMSA) through a [PowerShell module](https://learn.microsoft.com/virtualization/windowscontainers/manage-containers/gmsa-aks-ps-module). For more information on Windows specific domain information, checkout our [checklist for Windows workloads on AKS](https://github.com/Azure-Samples/LegacyDotNetAppMigrationWorkshop/blob/main/Containers-Migration-Checklist.md)|
+| Reliability | A reliable web application is one that is both resilient and available. Resiliency is the ability of the system to recover from failures and continue to function. The goal of resiliency is to return the application to a fully functioning state after a failure occurs. Availability is a measure of whether your users can access your web application when they need to. You should use the Retry and Circuit Breaker patterns as critical first steps toward improving application reliability. These design patterns introduce self-healing qualities and help your application maximize the reliability features of the cloud.  Pay particular attention to your application’s startup code (for example, your project’s startup.cs, deferred initialization of services in your IoC container, etc.).  While not required for a successful migration, you’ll gain full advantage of AKS’s horizontal pod autoscaler (HPA) features by ensuring that your application can start reliably.| 
+| Third Party Solutions| Identify whether your application is dependent on any third party libraries, apis, or packages that need to run within the container. Examine the licenses of third-party dependencies to ensure compliance with your organization's licensing policies and legal requirements. Some dependencies may have restrictive licenses that could impact your application's distribution. |
+
+## Things to consider
+|  Topic       |  Solution |
+|--------------|-----------|
+| Goals for Migration | Consider why you want to move your application to Kubernetes/a container based hosting model. Does it make sense for your application lifecycle? Does it fit into your organizational priorities for cloud strategy and governance? What are you looking to change or improve in your application? |
+|Organizational Experience with Kubernetes| The configuration, orchestration and management associated with hosting applications on Kubernetes can be a big learning curve for some organizations who are unfamiliar with the process, especially if they are used to a manual deployment process or on-premises environment. There are a lot of decisions, customization options and security considerations that require extra review by multiple teams within an organization. For example, AKS requires the ability to egress to the internet via a public IP address to retrieve image and package updates. A security team may have an issue with this and require the need for a firewall for all egress from the cluster. It's important to make sure Kubernetes is the right decision for your organization at this point in time. It may ultimately be the correct landing spot for your applications, but an intermediary step such as hosting your containerized application on App Service or Container Apps, may help ease the transition into a cloud environment with continuous deployment.|
+| Ingress | Linux workloads are supported by all commonly used ingress controllers including Nginx, Application Gateway and Traefik. Windows Containers are supported by most ingress controllers with a couple of caveats. <ul><li>Nginx supports ingress to Windows containers, but it must deployed on a Linux nodepool in the same cluster. </li><li>Application Gateway supports ingress to Windows Containers, but it does not support Windows Authentication. For guidance on handling ingress with Windows Authentication and GMSA, refer to the [Azure Architecture Center documentation on ingress with Windows Containers](https://learn.microsoft.com/azure/architecture/reference-architectures/containers/aks/windows-containers-on-aks#ingress-design) and the [AKS Windows baseline](https://github.com/Azure/aks-baseline-windows) for a technical reference implementation.</li></ul>|