Introduction

This post is part of a series of Cloud Computing Help blog posts covering Azure App Service design considerations.

Part 1:

In this first part of Azure App Service design considerations (https://cloudcomputing.help/blog/azure-app-service-design-considerations-part-1/) we covered initial design considerations for Azure App Service PaaS.

Part 2:

Check the second blog post (Azure App Service Design Considerations Part 2) for additional design considerations which supplement this post. Also refer to the following freely downloadable .pdf document which includes a series of tasks and tools to plan for when designing an Application migration to the Azure App Service PaaS offering: https://cloudcomputing.help/free-downloads/.

Azure App Service design considerations part 3

In this third, and last, part of the Azure App Service design considerations post we cover items which must taken into account from an application developer perspective, when utilizing Azure App Service for migrating their apps or when designing their apps from scratch to be hosted in Azure App Service as Cloud Native apps. From a project management perspective, there are generally two general options when embarking on a Cloud project with Azure app service:

1. You already have an application which is functional and you need to run a PoC on Azure or other public cloud with an application hosting service such as the Azure App Service. After a successful PoC you either convert the Azure PoC subscription to a production one or you create a new subscription and you either migrate all your existing resources there or you re-deploy your resources to thew new subscription.
2. You don’t have a fully functional application yet, in which case you need to migrate your code or containers to Azure App Service in a dev/test subscription, further develop and test your applications and then move to production after sufficient testing.

For a detailed explanation of cloud migration options for software applications, refer to the following article:  https://cloudcomputing.help/blog/cloud-migration-options-for-software-applications/.

As a developer, you need to be aware of the following Azure App Service design considerations while you develop, test and deploy your application in the Azure Cloud. These are primarily based on the Microsoft Azure Well Architected Framework (WAF), which in turn is based on lessons learnt from the field and on a series of Microsoft best practices.

• Application reliability considerations include the following important aspects. You need to review the Microsoft Azure WAF resilience design guidelines (https://learn.microsoft.com/en-us/azure/well-architected/resiliency/app-design) and consider application design best practices for reliability (https://learn.microsoft.com/en-us/azure/well-architected/resiliency/design-best-practices).
  • Build reliability and availability into your apps by gathering requirements.
  • Ensure that application and data platforms meet your reliability requirements.
  • Ensure that your application architecture is resilient to failures.
  • Ensure that applications can operate in the absence of their dependencies.
• Application security considerations and best practices (https://learn.microsoft.com/en-us/azure/well-architected/security/design-apps-services) need to be taken into account as well.
  • Application security design considerations include PaaS application security design (https://learn.microsoft.com/en-us/azure/security/fundamentals/paas-deployments) and networking security design (https://learn.microsoft.com/en-us/azure/well-architected/security/design-network) which meets high security standards.
  • Authenticate through Azure Active Directory. App Service provides an OAuth 2.0 service for your identity provider. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, and mobile phones. Azure AD uses OAuth 2.0 to enable you to authorize access to mobile and web applications.
  • Restrict access based on the need to know and least privilege security principles. Restricting access is imperative for organizations that want to enforce security policies for data access. You can use Azure RBAC to assign permissions to users, groups, and applications at a certain scope. To learn more about granting users access to applications, see Get started with access management.
  • Protect your App Service keys. Azure Key Vault helps safeguard cryptographic keys and secrets that cloud applications and services use. With Key Vault, you can encrypt keys and secrets (such as authentication keys, storage account keys, data encryption keys, .PFX files, and passwords) by using keys that are protected by hardware security modules (HSMs). For added assurance, you can import or generate keys in HSMs. See Azure Key Vault to learn more. You can also use Key Vault to manage your TLS certificates with auto-renewal.
  • Restrict incoming source IP addresses. App Service Environment (ASE) has a virtual network integration feature that helps you restrict incoming source IP addresses through network security groups. Virtual networks enable you to place Azure resources in a non-internet, routable network that you control access to. To learn more, see Integrate your app with an Azure virtual network (VNET integration and usage of private endpoints and private links).
  • Monitor the security state of your App Service environments. Use Microsoft Defender for Cloud to monitor your App Service environments. When Defender for Cloud identifies potential security vulnerabilities, it creates recommendations that guide you through the process of configuring the needed controls.
• Operational excellence design considerations primarily point to making use of automation and devops tools and methodologies in your software development life cycle, by utilizing what is generally known as release engineering (https://learn.microsoft.com/en-us/azure/well-architected/devops/release-engineering-app-dev).
• Performance efficiency design considerations (https://learn.microsoft.com/en-us/azure/well-architected/scalability/design-apps) include the following three pillars. Also refer to the Microsoft provided checklist for application performance efficiency (https://learn.microsoft.com/en-us/azure/well-architected/scalability/performance-efficiency).
  • Making choices that improve performance efficiency (https://learn.microsoft.com/en-us/azure/well-architected/scalability/design-efficiency) is critical to application design.
  • Scaling your application has important considerations. There are generally two ways to scale an application, i.e. scaling up/down and scaling out/in. Scaling out is generally considered the preferred option if you have a stateless application without ARR affinity. For stateful apps, scaling up may be the only option. There are a number of design considerations related to application scaling as outlined in the below links. Review these before designing and testing your application.
    • Design applications for scaling (https://learn.microsoft.com/en-us/azure/well-architected/scalability/design-scale)
    • Autoscaling (https://learn.microsoft.com/en-us/azure/architecture/best-practices/auto-scaling) and best practices for autoscaling (https://learn.microsoft.com/en-us/azure/azure-monitor/autoscale/autoscale-best-practices)
    • Per-app scaling (https://learn.microsoft.com/en-us/azure/app-service/manage-scale-per-app)
    • Training on how to scale your application (https://learn.microsoft.com/en-us/training/modules/scale-apps-app-service/)
  • Cater for application capacity requirements (https://learn.microsoft.com/en-us/azure/well-architected/scalability/design-capacity) while minimizing costs as your business grows.
  • Ensure you have a solid application testing framework to cover performance and load/stress testing in your applications (https://learn.microsoft.com/en-us/azure/well-architected/scalability/test-checklist). You can refer to the my KB article for a procedure on how to perform Azure App Service stress testing.

Remember that implementing Azure WAF involves the following procedure (covering the assess, integrate, triage, implement, monitor phases in a continuous feedback loop).

Besides the Azure WAF App Service design considerations and best practices there are further considerations you need to make as a developer while implementing your application on Azure. Some hand-picked examples of the most important considerations are the following.

• Ensure that you make the most of Azure App Service Application Insights (https://learn.microsoft.com/en-us/azure/azure-monitor/app/app-insights-overview?tabs=net) by implementing auto-instrumentation (https://learn.microsoft.com/en-us/azure/azure-monitor/app/codeless-overview) in your application. Review the Application Insights SDK (https://learn.microsoft.com/en-us/azure/azure-monitor/app/sdk-support-guidance) and the Application Insights planning guide (https://learn.microsoft.com/en-us/azure/azure-monitor/app/separate-resources) for more details.

• Decide how you will be handling your SQL connection strings. There are generally two methods for implementing this. First method is by using Azure Key Vault references (https://learn.microsoft.com/en-us/azure/app-service/app-service-key-vault-references?tabs=azure-cli) and second method is by using the SQL connection string App Service Application settings (https://learn.microsoft.com/en-us/azure/app-service/configure-common?tabs=portal). For the Key Vault method, you need to enable an Azure system-managed identity to your app services, in order for them to be able to access Key Vault. Also you need to consider the expected number of monthly calls to the Key Vault, to optimize costs. For the Application Setting method, at runtime, connection strings are available as environment variables.
• Decide if you need App Service custom backups (https://learn.microsoft.com/en-us/azure/app-service/manage-backup?tabs=portal), which in turn require a separate Azure storage account, or if you are OK with the Azure App Service automatic backups.
• Decide how you will organize your code release cycle by utilizing Azure App Service deployment slots as part of Azure App Service deployment best practices (https://learn.microsoft.com/en-us/azure/app-service/deploy-best-practices). Having a minimum of dev/test and production slots is imperative, even though adding a third “staging” slot is highly recommended. Having multiple deployment slots will have an impact on your resource utilization, since you will be thus adding further load to your existing App Service Plan.

• Decide the Identity and Access Management (IAM) model for your application, by considering the App Service authentication and authorization best practices (https://learn.microsoft.com/en-us/azure/app-service/overview-authentication-authorization). Will you be using SQL authentication only or Azure AD authentication? Will you be using Public Identity Providers in your App Service?
• If you are using some sort of SQL data store, such as Azure SQL, Azure SQL Managed Instance, Azure database for MySQL/MariaDB/PostgreSQL, you need to perform SQL fine tuning for performance as well as query optimizations using the SQL query store. You can find guidance in the following articles.
  • Azure SQL and Azure SQL MI (https://learn.microsoft.com/en-us/azure/azure-sql/database/performance-guidance?view=azuresql)
  • PostgreSQL performance optimizations (https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-monitoring) and best practices (https://azure.microsoft.com/en-us/blog/optimize-performance-using-azure-database-for-postgresql-recommendations/)
  • MySQL performance optimizations (https://learn.microsoft.com/en-us/azure/mysql/flexible-server/tutorial-query-performance-insights)
  • MariaDB performance optimizations (https://learn.microsoft.com/en-us/azure/mariadb/concepts-query-store)
• Consider the replication options for your SQL databases for high availability, as outlined below.
  • Azure SQL replication options (https://learn.microsoft.com/en-us/azure/azure-sql/database/active-geo-replication-overview?view=azuresql)
  • Azure SQL MI (https://learn.microsoft.com/en-us/azure/azure-sql/managed-instance/replication-transactional-overview?view=azuresql)
  • Azure MariaDB (https://learn.microsoft.com/en-us/azure/mariadb/concepts-read-replicas)
  • Azure MySQL (https://learn.microsoft.com/en-us/azure/mysql/single-server/concepts-read-replicas)
  • Azure PostgreSQL (https://learn.microsoft.com/en-us/azure/postgresql/single-server/concepts-read-replicas)

The post Azure App Service design considerations part 3 appeared first on Cloud Computing Help.