From Local to Global: The Azure Migration That Increased Our Efficiency and Security

Context: The Original System Overview

In one of my jobs I worked on a robust management system, developed in Java, integrated with RabbitMQ and PostgreSQL, with the mission of controlling payments, shipping and inventories of a large e-commerce platform. The original system, which operated locally in an on-premises data center, was no longer meeting the growing demands for scalability and reliability. This system was facing challenges such as high latency in critical transactions, maintenance difficulties and an increase in operational costs as workloads grew.

The objective of this migration was not only to move the system to the cloud, but also to improve the architecture to make it more scalable, resilient and efficient. The choice of Azure as the cloud platform was driven by its ability to meet the specific needs of a modern, robust architecture while supporting best practices in security, governance, and cost optimization, as described in Azure Well -Architected Framework.

System Context: The New Model in Azure

Overview

The new system is designed to be highly scalable, resilient and easy to manage, using the principles of the Azure Well-Architected Framework. The architecture is designed to handle increased traffic, ensure high availability and reduce operational costs. Migrating to Azure didn't just mean moving existing components, but also reviewing and modernizing the architecture to ensure the system was agile, secure and efficient.

The architecture was planned in four levels of the C4 Model, with an emphasis on a clear view of the context, containers, components and code. This would ensure that all stakeholders – from engineers to managers – are aligned regarding the scalability and reliability objectives of the new system.

Context (Context Diagram)

The context diagram illustrates the payment, freight and inventory management system as a whole. The system interacts with various external components such as customers, payment systems and transport platforms. This diagram focuses on how users and external systems interact with the system.

The new system was divided into three main business areas:

1. Payment Management: Processes financial transactions using integration with payment gateways and other external financial services.
2. Freight Management: Interacts with logistics providers to calculate and monitor order delivery status.
3. Inventory Management: Monitors stock levels and generates automatic alerts when items are close to shortage.

Each of these areas has been treated as a separate microservice, facilitating independent scalability and simplified management. The context diagram focuses on the interactions between these services and external platforms, such as payment systems, shipping systems, and user services.

Containers (Container Diagram)

The container diagram focuses on the main software containers within the architecture. Each service was transformed into a separate application container, leveraging the containerization capabilities of Kubernetes on Azure. RabbitMQ has been replaced by an Azure Service Bus to improve asynchronous communication, while PostgreSQL has been migrated to Azure Database for PostgreSQL, with optimizations to ensure greater availability and scalability.

Main containers include:

1. Frontend Web (App): A web application that interacts with users to manage orders, payments, shipping and inventory. This application has been moved to Azure App Service.
2. API Gateway: A service that manages the routing of requests to specific payment, shipping and inventory microservices. Uses Azure API Management to manage security, authentication, and traffic control.
3. Payment Microservice: Responsible for processing and validating financial transactions. It has been restructured to communicate with payment gateways and carry out transactions securely. It was hosted on Azure Kubernetes Service (AKS).
4. Shipping Microservice: Responsible for calculating shipping costs and monitoring the status of deliveries. This service communicates with external logistics providers via RESTful APIs and was hosted in containers on AKS.
5. Inventory Microservice: Responsible for controlling inventory, issuing low stock alerts and communicating with sales systems to ensure products are available to customers. This service has also been moved to AKS.
6. PostgreSQL Database: The database was migrated to Azure Database for PostgreSQL, offering high availability and automatic backup. The migration was carried out with the help of the Azure Database Migration Service tool.
7. Service Bus (RabbitMQ replaced by Azure Service Bus): Manages asynchronous message queues between microservices, ensuring that transactions and business processes occur in an efficient and resilient manner.

Component (Component Diagram)

The component diagram focuses on the internal architecture of each of the microservices. Each component is represented as an autonomous and easily scalable software unit.

Payment Microservice

Key components include:

1. Payment Processing Component: Responsible for communicating with the payment gateway, validating and processing payments. Uses Azure Key Vault to securely store credentials and sensitive information.
2. Notification Component: Sends notifications to the customer and admin about the payment status.

Shipping Microservice

Key components include:

1. Shipping Calculation Component: Interacts with external APIs to calculate shipping cost based on weight, destination and other variables. It has been adapted to use Azure Logic Apps to integrate with third-party services.
2. Tracking Component: Monitors order delivery status and updates customers automatically via Azure Functions.

Inventory Microservice

Key components include:

Inventory Control Component: Responsible for monitoring and adjusting stock levels. Integrates with sales systems to ensure products do not run out without a scheduled restock.
Alerts Component: Generates alerts for those responsible for stock replenishment when levels reach the minimum.

Code (Code Diagram)

Payment Microservice:

Shipping Microservice:

Inventory Microservice:

Conclusion: Migration Improvements and Results

The system migration to Azure brought several significant improvements:

1. Scalability: The use of Azure Kubernetes Service (AKS) and Azure App Service allowed each microservice to scale independently according to the workload, ensuring that the system could handle traffic spikes without problems.
2. Resilience: Using Azure Service Bus for asynchronous messaging and Azure Database for PostgreSQL with high availability ensured that the system was more resilient to failures and outages.
3. Optimized Costs: Migration to the cloud allowed cost optimization through the pay-as-you-go model, in addition to reducing infrastructure and maintenance costs for physical servers.
4. Security: Using Azure Key Vault for the secure storage of credentials and implementing security practices such as multi-factor authentication (MFA) and strict access control have increased the overall security of the system.

Using best practices from the Azure Well-Architected Framework and implementing the C4 Model, the migration not only modernized the architecture but also ensured a more reliable, scalable, and secure system.

The above is the detailed content of From Local to Global: The Azure Migration That Increased Our Efficiency and Security. For more information, please follow other related articles on the PHP Chinese website!