We'll begin with some key takeaways in cloud versus on-premise development practices. In the cloud, there are many ways to solve a problem, so work at keeping it simple – try not to engineer your way to complexity. Keep in mind the basics behind application architecture, shown in Figure 1, and work at solving the layers as simply as you possibly can.

Everyone in their journey to the cloud has been bitten by the complexity bug and has learned that lesson:

Figure 1: The basic application architecture layers

Tackling these layers and defining them as early as possible is an essential part of the cloud architecture and will enable each part of the organization to contribute to the application as a whole, meaning security, development, operations, and testing get an early seat at the table. The biggest part of being a successful cloud architect is learning to empower those around you to be successful in their roles and to...

Without further ado, let's work through some of the main architectural approaches for different application ecosystems. For each of these architectures, we'll also discuss the five principles you should support in your cloud governance:

• The cost management of the solution
• How to define a security baseline
• How to define resource consistency
• How to define an identity baseline
• How to accelerate deployment of the solution

You can also find a wealth of architectural information on Microsoft's Azure documentation pages: https://bit.ly/35Dnzo7.

Architecting a microservices ecosystem

Microservices have become a popular architectural style in application ecosystems, as they help provide a decomposed, highly scalable, resilient, and simple deployment model that can evolve quickly when necessary. Today's world of smaller functional blocks rather than large monolithic application tiers has found a friend...

Applications in the cloud have to be able to respond to issues or faults such as unavailability, data or network loss, time-outs, or service transition. Some of these issues can be temporary and a basic retry may overcome them, while others will take more work. The first thing to do is to create your applications with resiliency and self-healing in mind.

The foundations of a self-healing system consist of:

• Automatic detection of the issue
• Taking action to respond to the issue detected
• Auditing all relevant information about the issue

Self-healing applications rely on designing your applications for resiliency, which means you need to plan for failure with minimal downtime and data loss.

Designing for resiliency

There are two main characteristics of resilient applications:

• They can recover gracefully from failures and experience minimal downtime
• They run in a healthy...

As we have discussed, security is at the foundation of cloud principles, and key to this in Azure is understanding how RBAC works. As we showed earlier in the chapter, leveraging management groups is also extremely helpful in your subscription access management, and with RBAC you only provide users the minimum amount of access needed to complete their jobs. This can also be coupled with Privileged Identity Management (PIM) should the need arise for a member to elevate their access or "just-in-time" their access within a given environment for a given time, which helps with approvals and auditing.

It's worth getting more details on the following list of tools and resources that are available in Azure to aid in security:

• RBAC
• Antimalware
• MFA
• PIM
• ExpressRoute
• VPN (alternatively called Virtual Network Gateway)
• Identity Protection
• Security Center
• Intelligent Security Graph

Identity...

The first thing that you always run into when discussing containers is, why should I care about containers? This is usually answered in one of two ways. Firstly, containers provide the freedom to move your application from on-premise to the cloud or within the cloud to another cloud provider with no code change to your application. Secondly, each application is self-contained, meaning all application elements and their versions are contained within the boundaries of the container, so changing a library for an application won't negatively affect or spark a redeployment of all the applications that shared the library.

So, what are containers? I like to use a shoebox analogy to describe containers. A shoebox is pretty standardized and small. You can only fit so much in them, and they tend to have a single function like storing your photos. You can store this shoebox and move it around pretty easily. It does, however, require a shelf or floor...

We've touched on a lot of topics in a short space of time, but hopefully you've gained an overview of the various architectures available for building applications with Azure. We've also looked at application design best practices, mostly focused on security, and finished with a look at working with containers in Azure. In the next chapter, we'll look at DevOps and how its methodology integrates with the cloud.