I like to design applications for more scale, resilience, and manageability. Here are some things to keep in mind:

• Make your applications self-healing as much as possible:
  • Design for failures and handle them
  • Log and monitor
• Build for scaling out:
  • Offload resource intensive tasks
  • Design for scale in
  • Identify bottlenecks
• Partition around resource limits:
  • Understand limits and use partitioning to get around them; you can find more information at the following link: https://docs.microsoft.com/en-us/azure/azure-subscription-service-limits

• Design with DevOps in mind:
  • Monitoring
  • Deploying
  • Escalation
  • Security/auditing
  • Make all thing observable
  • Treat configuration as code
• Design for evolution:
  • Use loose coupling
  • Use asynchronous development patterns whenever possible
  • Use interfaces
  • Design for testing
  • Deploy services independently

There are a magnitude of design patterns to choose from. If you're finding it hard to decide which one to use, you can review them at https://docs.microsoft.com/en-us/azure/architecture/patterns/.

As we move forward, having discussed some common design approaches, Azure also enhances the five pillars of software development. Let's see what are they:

• Scalability
  • Horizontal scale: This is elastic and can be triggered automatically. It is also more cost-effective than vertically scaling.
  • Vertical scale: Can increase the resources assigned to a resource.
  • Scalability Checklist Document: https://docs.microsoft.com/en-us/azure/architecture/checklist/scalability.
  • Scalability Design Patterns for Performance: https://docs.microsoft.com/en-us/azure/architecture/patterns/category/performance-scalability.
• Availability 
  • Defined by resources
  • Availability Design Patterns: https://docs.microsoft.com/en-us/azure/architecture/patterns/category/availability
• Resiliency
  • Closely related to Availability
  • Resiliency Design Patterns: https://docs.microsoft.com/en-us/azure/architecture/resiliency/index

• Management
  • Leverage DevOps in your software development
  • Use instrumentation
  • Visualize and alert
  • Analysis and diagnose
  • Monitoring Design Patterns: https://docs.microsoft.com/en-us/azure/architecture/patterns/category/management-monitoring
• Security
  • Identity management using Azure AD as much as possible
  • Use RBAC as much as possible to protect the infrastructure
  • Secure your applications
  • Use data encryption whenever possible
  • Security Center: https://azure.microsoft.com/en-us/services/security-center/
  • Security Documents: https://docs.microsoft.com/en-us/azure/security/
  • Microsoft Trust Center: https://docs.microsoft.com/en-us/azure/security/

One of the most crucial choices you have to make when building solutions on Azure is whether or not you are working with sensitive information. If the information is sensitive in nature or falls under Personally Identifiable Information (PII), Health Insurance Privacy and Portability Act  (HIPPA), or GDFR, you will need to look at isolated networks environments in Azure. These choices come with consequences, even in closed ecosystems, as you will need to manage things like access (firewalls) and load balancing. However, you do gain extended isolation and can extend your internal network into this more secure piece of Azure.

Several environments fit into this, such as App Service Environment (ASE), Service Fabric, Custom VNets, and so on. It is crucial to understand this as this can drive cost. Isolated environments cost a significant amount more, not only from an Azure perspective but from an organization perspective (as there are more components in Azure to manage).

As fast as Azure changes, I typically look for opportunities to leverage the best of breed to solve issues. Typically, you will look up things based on what you are used to using internally, and Azure offers a bit more. So, when I typically want to do something in Azure, I look for what I am looking to accomplish, not what I am looking to do. For example, I may not look up how to store large amounts of data in SQL and look more at how to store telemetry data in Azure for IoT devices. This opened my eyes to the IoT hub as a transport and CosmosDB, which had the added benefit of speed.