Chapter 11: Comparing Application Components

In the previous chapter, we concluded Section 3, Infrastructure and Storage Components, by looking at how to migrate existing on-premises workloads into Azure and what different options were available from an architectural and strategic perspective. With this chapter, we begin Section 4, Applications and Databases, by looking at the different options and architectural patterns for building apps in Azure – from essential web apps to microservices and messaging.

In Chapter 7, Designing Compute Solutions, we looked at the different compute technologies in Azure that can be used to run our applications. This chapter will examine some of these again; however, we will see how they affect our overall solution's architectural choices.

By understanding how to combine web apps, API apps, microservices, and messaging patterns, we will learn how to structure our environment to enable secure, flexible, and cost-efficient solutions.

In...

Technical requirements

This chapter will use the Azure portal (https://portal.azure.com) for its examples.

Working with web applications

Azure web apps, or more generally Azure app services, are the first step in migrating from VM-based solutions toward a more flexible, fully managed offering.

They are essentially a managed Internet Information Services (IIS) offering for hosting web applications built with standard web technologies and programming languages.

App services are split into two types of apps – web apps and API apps. Web apps are UI-driven applications whereby the result of any backend programming language is to produce HTML and JavaScript that can be consumed by an end user through a browser.

API apps use the same technologies and programming language as web apps; however, they send pure data in either JSON or XML, rather than sending HTML to a web browser.

Note

XML and JSON are text-based formats for storing and sending information. Technically, XML is a self-describing markup language – this means you can define the data format of a field in a structured...

Managing APIs with Azure API Gateway

When building cloud solutions and web applications, it is common to use APIs – specific types of apps that only return data in JSON or XML. This data is then used by a consuming application, a desktop application, a mobile application, or even a website.

APIs can be used internally or to expose your data to external customers or partners.

An example would be a distribution organization that supplies products to resellers, and therefore needs to provide details of those products and up-to-date pricing and stock levels.

The reseller would use that feed on their website or mobile app to display products to their customers.

In such a scenario, the distribution company can expose its products via an API. However, they need to ensure they only provide details to registered resellers, and each reseller may have their own pricing bands.

The data provider will also use other APIs for internal use only. Each system that provides all these...

Understanding microservices

One of the goals of cloud computing is to provide cost-effective solutions that are dynamic and reliable. In Chapter 7, Designing Compute Solutions, we looked at several different components: containers, Kubernetes, Azure Functions, and Logic Apps.

One of the key differences between these services and more traditional compute options, such as VMs, is the ability to scale the resources they use up and down, dynamically – that is, in response to demand.

This scaling ability is most effectively used when combined with the microservice pattern of development. Understanding microservices helps to review the problems associated with applications that don't use them.

A typical solution comprises a user interface, a backend database or storage mechanism, and some business logic in between. Each of these components has to run on some form of computer, which could be a VM. Using N-tier architectures, we break these components up so that each tier...

Using messaging and events

Microservice components need to send information between each other; however, traditionally, the sender would wait for a reply from the recipient before continuing. An example would be an application that accepts user input and returns a result.

This behavior can cause blocking as one component depends on another, and the more pieces you have that are responsible for discreet operations, the more they must communicate.

To prevent blocking, two alternate patterns are available – events and messaging. Both mechanisms work at a basic level in the same way – they inform other components, either directly or indirectly, but they don't wait for a reply.

Events are notifications to other system components that have happened, but they do not contain any data, although they may include a reference. When events are triggered, they don't expect another component to necessarily do something. It is the job of a consuming component to decide...

Summary

In this chapter, we revisited some of the Azure native compute options and introduced queues, Service Bus, and API gateways, and how these components can be used in modern solutions that follow development patterns such as microservices, messaging, and events.

We looked at how you can use deployment slots to validate application updates before going live and how to use VNet Integration to securely connect backend data services such as storage accounts.

We also examined how you can collate and secure both new and existing API services behind an API gateway and modify and control the access to and the response from your APIs without needing to make any code changes.

Finally, we looked at microservices and messaging patterns to create flexible, cost-efficient, and independent solutions that scale automatically in response to user demand.

In the next chapter, we will look at the options when using databases – both SQL and NoSQL options – and when to choose...

Exam scenario

MegaCorp is re-developing an order management tool for their global operations. The solution will be built on Azure with teams in Europe, the US, and India.

Customers will place orders through a global website but they will be processed in the closest geographical region.

The website will need a web frontend that will make calls to APIs to retrieve the product data and place orders.

As this is a new system, hosting costs need to be kept at a minimum, but with the ability to scale automatically as demand increases. The business wishes to ensure that modern development techniques are used and that all the components are resilient and secure.

The site will also be developed iteratively, with updates rolled out once a month, and the business needs to ensure that those updates do not disrupt live services.

Design an architecture that meets the business needs.

Further reading

You can check out the following links for more information about the topics that were covered in this chapter:

• Azure web app deployment slots: https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots
• Azure Service Bus: https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-messaging-overview
• Azure Storage Queues: https://docs.microsoft.com/en-us/azure/storage/queues/storage-queues-introduction
• Azure Event Grid: https://docs.microsoft.com/en-us/azure/event-grid/overview
• Azure Event Hubs: https://docs.microsoft.com/en-us/azure/event-hubs/event-hubs-about