Design Application Landing Zone

Last time I wrote about How to choose the right solution to deploy our application

How to choose the right solution to deploy my application? | by Mariem Kharrat | Medium

In this article, I will look to necessary steps to design our web application landing zone;

The complexity of application deployment continues to grow in today’s rapidly evolving technology landscape. Factors such as application architecture, development technologies and deployment environments need to be carefully considered prior to release. One critical aspect that is often overlooked when considering the deployment environment is the design of the application landing zone (LZ). It is important to note that, although popularly considered, Landing Zones are not dependent on specific development technologies. They play a critical role in ensuring the smooth and efficient deployment of applications, regardless of the underlying technologies used.

Before we dive into the Application Landing Zone, let’s take a quick look at the Landing Zone (LZ) and why it’s a critical step in your environment design. In simple terms, an Azure Landing Zone is a foundational environment that provides the infrastructure, networking, security, and governance framework for you to host your applications in the cloud. It serves as the backbone of your Azure environment and lays the foundation for future deployments. The LZ plays a critical role in your environment design for several reasons, including standardisation, security, scalability, compliance, and cost management.

Enterprise Landing zone architecture reference — Azure landing zone design areas — Cloud Adoption Framework | Microsoft Learn

Landing zone preparation and implementation is part of the first and the third phase(Ready) of the Cloud Adoption Framework; just right after the prioritization decisions made during strategy and plan conversation had a direct impact on the most appropriate Landing zone to support your application plan. The following are the most critical consideration when designing a Landing Zone for Web Application:

• Application Architecture: Match the landing zone to the architecture of the application, whether monolithic, microservices or containerised.
• Dependencies: Ensure connectivity to external services or databases required by the application, taking into account containerised environments where applicable.
• Data Management: Choose the right data service for your storage needs like sql database, NoSQL DB or document DB; considering the evolution of the application on the future
• Performance: Optimize performance with caching, CDN usage, taking into consideration accessibility of the application .
• Compliance: Meet regulatory standards such as GDPR or HIPAA with proper security controls, ensuring compliance in both traditional and containerized environments.
• Authentication/Access: Implement authentication mechanisms such as B2C or MFA, ensuring compatibility with containerized environments if applicable.
• Monitoring: Use a monitoring solution for performance tracking, considering monitoring solutions suitable for containerized environments.
• Disaster Recovery: Plan for backup and disaster recovery with Azure Site Recovery, considering container-specific backup and recovery strategies if applicable.

Web application Landing Zone Scenario:

A Company XYZ specialized on financial service has an application hosted on premise; the application has multiple component that we will look to together one by one

Application current architecture is as following

XYZ current architecture

Let’s analyse what we have on the High level Architecture:

The application is multi-platform, with both Web and Mobile apps. It is container-based, featuring an API gateway along with 3 APIs and 2 databases. Here’s a closer look at each component:

When we took a closer look to the architecture with the Team we find the following:

FrontEnd:

• Angular

API Gateway

• API Gateway with Ocelot

Backend API

• First API:.NET Core API focused on the business logic
• Second API: NodeJS API focused on analytics logic
• Third API : Utilized for static tasks and complex treatment

DataBases

• First DataBase: MSSQL 2019 deployed on Windows server
• Second DataBase: Mongodb deployed on Linux Server

Upon inquiring with XYZ’s Team about their requirements for transitioning to the cloud, they responded:

“We aim to optimize our Ops and Dev team’s time and minimize changes to the environment while ensuring readiness for the cloud without compromising security aspects.”

Upon receiving this response, we began contemplating a landing zone architecture that we could propose to the team.

As first step, we looked at the services that we can choose complying with XYZ’s Team requirement:

1. We will propose keeping the K8S cluster and we will take advantage of the Azure K8S Service and deploy the container to the Azure container registry
2. We will optimize the time of the administration of both Databases and we will propose modernisation by using PaaS services for MSSQL we take advantages of the Azure SQL Database and for the MongoDB we will propose Azure CosmosDB

As second, step we need to look to the holistic landing zone from the consideration we earlier mention it on the article; we already treated the application architecture, the dependencies and the data management during the first step and now will go over the rest of the areas of focus:

• Authentication/Access: To make sure the accessibility to our services secure; first we propose a Hub& Spoke typologie to prevent direct access to the all services for administration, deployments, updates. since the application is accesible from external users we propose Application Gateawy WAF to manage and secure the traffic to the application
• Compliance: To meet regulatory standards that customer needs to follow; we proposed the use of Microsoft Defender for Cloud(Microsoft XDR solution) first to protect our applications from cyber threats and vulnerabilities and within Microsoft defender for cloud is highly recommended the use of the regulatory compliance feature in order to follow the environment compliance score.
• Monitoring: As we may all know that monitoring is critical component for application and cloud based solutions which will assure the continuity and evolvement of the solution. We propos Azure Monitor specifically; application insight, container, monitor for azure SQL and for Azure cosmos DB with this we have 4 monitoring solutions in one. where we can be also using azure Monitor to monitor VMs, Storage accounts , Key vaults, Azure Cache for redis and many more.
• Disaster Recovery : To ensure the continuity and availability of the application, we propose that the customer first secures a backup of all application data using Azure Backup. We also need to consider scenarios where the application may need to be available in a region other than the primary deployment region. To achieve this, for the databases, the customer can use the built-in replication features of Cosmos DB and SQL Database. For the AKS cluster, the customer has two options: implement an Active-Active environment (High Availability) with a multi-region deployment or use Velero, a VMware technology, for Kubernetes disaster recovery.

And we that we can share the first draft for our application landing zone

Application Landing Zone based on Scenario

The architecture we propose is flowing Microsoft Azure landing zone best practices and based on Enterprise-scale for small enterprises landing zone and Baseline architecture for an AKS cluster — Azure Architecture Center | Microsoft Learn.

Thank you for reading the article! I hope is useful for you and your business 😊