Through AWS Route 53, we can employ Geolocation routing, which enables the selection of resources based on the geographic location of the user. By using geolocation routing, we can localize content and display some or all of the website (micro frontends) in the user's language. Additionally, geolocation routing can be used to restrict content distribution to only the assigned locations.

Geolocation works by mapping IP addresses to locations. However, not all IP addresses are mapped to geographic locations, therefore even if geolocation records are created for all seven continents, Amazon Route 53 would still receive DNS queries from locations it cannot identify. Thus, we must develop a default record that handles searches from IP addresses that are not mapped to any location, as well as requests from locations for which geolocation records have not been established. If there is no default record, Route 53 returns "no answer" for queries from those locations.

Micro frontend for different Locations:

• The user requests the website domain, which in our instance is the CloudFront distribution domain.
• CloudFront CDN receives the HTTP request and returns the cached version of the resource if it exists.
• CloudFront sets the cache key and geolocation headers upon a cache miss.
• Depending on the cache behavior defined for the CloudFront distribution, a Lambda function verifies the viewer's geographic location. If the viewer is in the United States, the URL is appended with the location suffix and the request is forwarded to the appropriate micro frontend in the S3 bucket.
• The S3 bucket containing the requested resource is returned.
   

Overview

The micro-frontend architecture introduces microservice development principles to frontend applications. In a micro-frontend architecture, development teams independently build and deploy “child” frontend applications. These applications are combined by a “parent” frontend application that acts as a container to retrieve, display, and integrate various child applications. In this parent/child model, the user interacts with what appears to be a single application. In reality, the users are interacting with several independent applications, published by different teams.

The most challenging aspect of the micro-frontend architecture pattern is integrating child applications with their parent.  Prioritizing the user experience is critical for any frontend application. This refers to ensuring that a user can seamlessly navigate from one child application to another inside the parent application in the context of micro-frontends. It is critical to avoid disruptive behavior such as page refreshes or multiple logins. 

Parent/child integration entails the parent application retrieving and displaying child applications dynamically when the parent application is loaded.

In the proposed architecture, each service team will be running a separate, identical stack to build their application and will use AWS developer tools and Amazon CloudFront to deploy the application to S3. The CI/CD pipelines utilize shared components such as CSS libraries, API wrappers, or custom modules stored in AWS Code Artifact. This drives consistency across parent and child applications.

When retrieving the parent application, the user should be prompted to log in to Okta and retrieve JWTs. The parent application retrieves the child applications from CloudFront and renders them within the parent application following a successful login. Alternatively, the parent application can elect to render the child applications on demand when the user navigates to a particular route. The child applications should not necessitate re-authentication. They must be configured to either use the JWT obtained by the parent application or discreetly retrieve a new JWT from Okta.

Benefits of Micro frontends

• Independent artifacts: Teams can independently deploy their frontend applications with minimum impact on other services in a micro-frontend architecture. These changes will be reflected within the parent application.
• Autonomous squad: Each squad is an authority in its own field. For instance, employees of the policy information team possess specialized knowledge. This consists of the policy information service's data models, business needs, API calls, and user interactions.
• Flexible technology choices: Autonomy allows each team to make technology choices that are independent of other teams. For instance, the policy information service team may build its micro-frontend with Vue.js, while the online transactions team could develop its frontend with Angular.
• Scalable development: Micro-frontend development teams are smaller and can function independently of other teams.
• Easier maintenance: Small, focused frontend repositories facilitate long-term maintenance and testing by making them easier to understand. 
   

Deployment

This figure represents the high-level recommended infra architecture for deploying and delivering, micro frontends on AWS.

a. Hosting 

Amazon Simple Storage Service is the most effective alternative to containers for Micro frontends on AWS (S3). Using Amazon S3, we can store all your frontend static assets, including HTML, JavaScript, CSS, Fonts &, etc. One of the key advantages of using Amazon S3 is that the underlying infrastructure provides 99.99% for high availability for serving micro frontends by default.

However, a frequent constraint exists. In other words, Amazon S3 can only hold static Micro frontend artifacts (no server-side rendering). Nevertheless, it is compatible with the majority of modern frontend frameworks, such as AngularJS, ReactJS, and VueJS, which can be leveraged to build micro frontends.

A few best practices for using S3 with micro frontends:
 

• Use separate buckets for each Micro frontend - doing so will allow you to isolate the lifecycles of each Micro frontend. It will also enable you to offer more specific access permissions to each team with increased granularity.
• Do not directly serve micro frontends using Static Site Hosting – when serving the Micro frontends from Amazon S3, using Static Site Hosting will expose the frontend to the public without any added controls like geographical restrictions. In addition, it will force the use of cross-origin request sharing (CORS) without exposing the entire application through a single domain.
• Separate dynamically uploaded artifacts from Amazon S3 buckets hosting micro frontends.

b. Serving and Caching

Amazon CloudFront is one of the core services that plays multiple roles while serving external Micro frontends. The Content Delivery Network (CDN) capabilities to cache Micro frontends closer to the end-users are one of the prominent features we receive by default. In addition, Amazon CloudFront has gateway functionality for routing requests to various Micro frontends. This feature is particularly useful - it eliminates the need for different gateway services by allowing us to route both micro frontend and microservice requests through a centralized point.

c. Deployment Life Cycle - High Availability

When combining Amazon S3 and CloudFront, we must consider invalidating the CloudFront cache for each deployment, unless we generate unique filenames for each new deployment package.

If needed, invalidating the CloudFront cache is possible by using CloudFront CLI commands. These commands can be executed in the build pipeline for new deployments.

In addition, it is essential to manage the high availability of Micro frontends during deployment. CloudFront caching prevents the potential of downtime if a client hits the Micro frontend during deployment.

d. Deployment Pipeline

The goal of this setup is to ensure that individual micro-frontend repo changes trigger individual code pipelines. This encourages team independence - if only a micro frontend is modified, we only want to trigger its related pipeline and not all the others. This results in faster feedback loop so if anything breaks, the team(s) can work on it immediately. 
 

An AWS Code Pipeline gets started, once a code change is associated. This includes four main steps:

• The Code Pipeline: This manages the Code repo connection and fetches the associated source code.
• The Code Build: This builds the receiving source code into a build artifact. 
• The Code Deploy: This step takes the build artifact from previous steps and deploys them to a single Simple Storage Service (S3). Each micro-frontend will be stored in an independent folder so that they can be deployed individually.
• The Code Build Cache Invalidation: The last step is yet another Code Build step that ensures that the CloudFront cache gets invalidated every time we publish and deploy new artifacts on S3.
• Repo Set Up: This gives an option of setting up a single mono repository with each micro frontend contained within a subfolder or individual repositories for each micro frontend.

Step 1: Decouple by Domain Driven Design (DDD)

Microservices should be designed around business capabilities, not horizontal layers such as data access or messaging. Additionally, microservices must have loose coupling and high functional cohesion. Microservices are loosely coupled - changing one service does not require updating the other services simultaneously. 

A microservice is cohesive if it has a single, well-defined purpose, such as managing user accounts or processing payments.

The DDD approach can be retroactively applied to an existing application as follows:

• Establish a shared vocabulary between all stakeholders. 
• Identify the relevant modules in the monolithic application and apply the shared vocabulary to those modules.
• Define contexts, where you apply explicit boundaries to the identified modules with clearly defined responsibilities. The identified contexts are candidates for refactoring into smaller microservices.

Step 2: Prioritize Service/Module for Migration

An ideal starting point to decouple services is to identify the loosely coupled modules in the monolithic application and can choose a loosely coupled module as one of the first candidates to convert to a microservice. 

To complete a dependency analysis of each module, consider the following:

• The type of dependency: dependencies from data or other modules.
• The scale of the dependency: how a change in the identified module might impact other modules.

Migrating a module with heavy data dependencies is usually a nontrivial task. If we migrate features first and migrate the related data later, we might be temporarily reading from and writing data to multiple databases leading to inconsistency. Therefore, we must account for data integrity and synchronization challenges.

We recommend extracting modules that have different resource requirements compared to the rest of the monolith. For example, if¬¬ a module contains an in-memory database, it can be converted into a service that can subsequently be deployed on hosts with more RAM. When turning modules with particular resource requirements into services, you can scale your application much more easily.

In addition to business criticality, thorough test coverage, the security posture of the application, and organizational buy-in can influence the migration priority of services. Based on the evaluations, you can rank services.

Step 3: Extract a service from the Monolith

After identifying the optimal candidate for a service, we must determine a means for microservice and monolithic modules to coexist. One way to manage this coexistence is to implement an adapter that facilitates the compatibility between the modules. Over time, the microservice absorbs the load and the monolithic component is eliminated. This progressive procedure reduces the risk of migrating from a monolithic application to a microservice as it allows for the gradual detection of bugs and performance concerns.

Typically, monolithic applications have their own monolithic databases. One of the principles of a microservices architecture is to have one database for each microservice. Therefore, when modernizing monolithic applications into microservices, split the identified monolithic database according to the service boundaries.

To determine where to split a monolithic database, first, analyze the database mappings. As part of the service extraction analysis, gather some insights on the microservices that have to be created. Analyzing database consumption and mapping tables and other database objects to the new microservices can be accomplished using the same method.

This picture depicts the transition from monolithic to microservices database architecture.

However, splitting a monolithic database is complex because there might not be a clear separation between database objects. Additionally, you must address concerns like data synchronization, transactional integrity, joins, and latency.

Pros & Cons of Microservices database are:

Approach for Data Migration

Data migration from Monolithic to Microservices DB

As data migration is a crucial aspect of the successful implementation of a new application, the following should be considered:

• In addition to data for functionality, reference/lookup data should be transferred.
• Ensure inbound data migration is scheduled to return modified/added Microservice data to the monolithic DB.
• Source data should be directly extracted from DB, REST API, or Excel/CSV.
• In a microservice architecture, the ETL process should be utilized to ensure data is stored in the most recent DB version.
• Develop a detailed functional specification document to capture what has to be converted.
• Prepare a document outlining the migration strategy.
• Define the key success factors.
• Collaborate with the business and technical teams over data cleansing.
• Create a comprehensive migration architecture.
• Prepare a detailed migration strategy or plan outlining every aspect of the migration.
• Analyze the tools and strategies for data migration.
• Analyze the data validation details and data conversion testing strategy.
• Determine the Acceptance Criteria for a successful migration.
• Identify the potential threat and risk mitigation.
• Identify source data and dependent data from source systems.
• Assess if formats and data sensitivity require encryption.
• Define data volume and the resulting constraints.
• Connect with customers to clean up data or to get core data.
• Develop a data migration project plan.

Typical monolithic applications are built using different layers—a user interface (UI) layer, a business layer, and a persistence layer. A central idea of a microservices architecture is to split functionalities into cohesive verticals — not by technological layers, but by implementing a specific domain.

This figure represents the high-level recommended architecture, based on microservices on AWS. In our case Micro frontend-based web/mobile app use REST APIs for communicating with the back end.

a.API Gateway

APIs are the front door of microservices, which means that APIs serve as the entry point for applications logic behind a set of programmatic interfaces, typically RESTful web services API. This API accepts and processes calls from clients, and might implement functionality such as traffic management, request filtering, routing, caching, authentication, and authorization.

Architecting, deploying, monitoring, continuously improving, and maintaining an API can be a time-consuming task. Sometimes different versions of APIs need to be run to assure backward compatibility for all clients. The different stages of the development cycle (for example, development, testing, and production) further multiply operational efforts.

Authorization is a critical feature for all APIs, but it is usually complex to build and involves repetitive work. When an API is published and becomes successful, the next challenge is to manage and monitor.

Other important challenges include throttling requests to protect the backend services, caching API responses, handling request and response transformation, and generating API definitions and documentation.

Amazon API Gateway addresses these challenges and reduces the operational complexity of creating and maintaining RESTful APIs. API Gateway allows you to create your APIs programmatically by importing Swagger definitions, using either the AWS API or the AWS Management Console. API Gateway serves as a front door to any web application running on Amazon EC2 or Amazon ECS.

b. Server Less Microservices

A common approach to reducing operational efforts for deployment is container-based deployment. In the above architecture approach, Docker containers are used with Fargate, so it is not necessary to care about the underlying infrastructure. 

In addition to DynamoDB, Amazon Aurora Serverless is used, which is an on-demand, auto-scaling configuration for Amazon Aurora, where the database will automatically start up, shut down, and scale capacity up or down based on your application's needs.

c.    Disaster Recovery

These microservices will be implemented using the Twelve-Factor Application patterns. This means that the main focus for disaster recovery should be on the downstream services that maintain the state of the application. For example, these can be file systems, databases, or queues.

The disaster recovery strategy will be planned based on the recovery time objective and recovery point objective. 

The recovery time objective is the maximum acceptable delay between the interruption of service and restoration of service. This objective determines what is considered an acceptable time window when service is unavailable and is defined by the organization. 

The recovery point objective is the maximum acceptable amount of time since the last data recovery point. This objective determines what is considered an acceptable loss of data between the last recovery point and the interruption of service and is defined by the organization.

d.    High Availability 

Amazon ECR hosts images in a highly available and high-performance architecture, enabling it to reliably deploy images for container applications across Availability Zones.