This article was authored by AzureCAT Marc van Eijk. It was edited by Bruce Hamilton and reviewed by Damir Bersinic, Gavin Kemp, Daniel Neumann, and Emmanuel Sache.
Table of Contents:
- Overview - This article
- Summary & Learn more
Microsoft Azure is the only consistent hybrid cloud. It allows you to reuse your development investments and enables applications that can span global Azure, the sovereign Azure clouds, and Azure Stack, which is an extension of Azure in your datacenter. Applications that span clouds are also referred to as hybrid applications.
The Azure Application Architecture Guide describes a structured approach for designing applications that are scalable, resilient, and highly available. The considerations described in the Azure Application Architecture Guide equally apply to applications that are designed for a single cloud and for applications that span clouds.
This article augments the Pillars of software quality discussed in the Azure Application Architecture Guide, focusing specifically on designing hybrid applications. In addition, we add a placement pillar as hybrid applications are not exclusive to one cloud or one on-premises datacenter.
Hybrid scenarios vary greatly with the resources that are available for development, and span considerations such as geography, security, Internet access, and other considerations. Although this guide cannot enumerate your specific considerations, it can provide some key guidelines and best practices for you to follow. Successfully designing, configuring, deploying, and maintaining a hybrid application architecture involves many design considerations that might not be inherently known to you.
This document aims to aggregate the possible questions that might arise when implementing hybrid applications and provides considerations (these pillars) and best practices to work with them. By addressing these questions during the design phase, you’ll avoid the issues they could cause in production.
Essentially, these are questions you need to think about before creating a hybrid application. To get started, you need to do the following:
- Identify and evaluate the application components.
- Evaluate application components against the pillars.
Each component of an application has its own specific role within the larger application and should be reviewed with all design considerations. Each component’s requirements and features should map to these considerations to help determine the application architecture.
Decompose your application into its components by studying your application’s architecture and determining what it consists of. Components can also include other applications that your application interacts with. As you identify the components, evaluate your intended hybrid operations according to their characteristics, such as the following:
- What is the purpose of the component?
- What are the interdependencies between the components?
For example, an application can have a front-end and back-end defined as two components. In a hybrid scenario, the front-end is in one cloud and the back-end is in the other. The application provides communication channels between the front-end and the user, and also between the front-end and the back-end.
An application component is defined by many forms and scenarios. The most important task is identifying them and their cloud or on-premises location.
The common application components to include in your inventory are listed in Table 1.
Table 1. Common application components
For each component, evaluate its characteristics for each pillar. As you evaluate each component with all of the pillars, questions you might not have considered may become known to you that affect the design of the hybrid application. Acting on these considerations could add value in optimizing your application. Table 2 provides a description of each pillar as it relates to hybrid applications.
Table 2. Pillars
Next Article: Placement