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 particular, we will examine the following topics:
- Working with web applications
- Managing APIs with Azure API Gateway
- Understanding microservices
- Using messaging and events
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 way. When used to transfer data between systems, it is commonly used in conjunction with Simple Object Access Protocol (SOAP).
JSON is a much simpler key-value notation, resulting in much smaller and arguably more comfortable files for reading. Representational State Transfer (REST) uses JSON to define a standard for also allowing systems to communicate. However, REST is easier to use and more flexible and has gradually become the more popular option.
Both web apps and API apps can be built using the following languages and frameworks: ASP.NET, ASP.NET Core, Java, Ruby, Node.js, PHP, and Python.
App services are linked to an App Service plan, which defines the amount of CPU and RAM that is available to your applications. You can also assign multiple app services to the same App Service plan to share resources. In some ways, an app service is analogous to a VM running various websites. Therefore, hosting multiple app services on a single App Service plan can be cost-efficient; however, you will have more applications competing for the same CPU and RAM resources.
App services can be easily scaled by defining CPU- and RAM-based thresholds so that as additional resources are required, additional instances of an app can be added. This is known as scaling out, unlike scaling up, which consists of adding more RAM and CPU to an existing instance.
Scaling out is far quicker and more flexible (scaling up is a manual process). However, your applications need to be written in such a way as to be aware that the end compute device serving your user may change from one request to the next. In essence, this means that applications should be built to be stateless, that is, to not store information on the backend needed to track the user interaction.
App services offer features over and above simple hosting and scaling, such as deployment slots.
Leave a Reply