Microservices architecture is an alternative to monolithic architecture, where the application is divided into smaller, independent services that communicate over a network. Each service typically handles a specific business function and can be developed, deployed, and scaled independently.

• Decoupled Components: Each service operates independently, with its own codebase and database
• Independent Deployment: Services can be updated and deployed independently without affecting the entire system
• Horizontal Scaling: Scaling can be achieved by adding more instances of specific services
• Technology Diversity: Teams can use different technologies for different services based on their requirements

• The complexity of a microservice application makes it increasingly easier to manage the system as the code base grows
• Is easier to scale, especially when their individual modules have conflicting resource requirements
• Is possible to scale individual components, you don't need to scale the whole application,
• Is easier to bring new developers on board, which is especially useful with rotating team members

For the past few sprints, some things have changed:

• The client has presented new requirements loosely coupled with the old ones
• The client is showing increasingly more interest in using the app, growing usage
• Team has decided to move the frontend implementation for the pdf report service to a backend one
• Team members have rotated and now we work with a backend specialist with experience in Microservices

Given that, we notice that there are new loosely coupled functionalities with different expected usage and, now we work with a team member knowledgeable with Microservices, guiding the development of the project in this direction is possible and necessary.

Migrating to microservices isn't a trivial task. We need to define a new architecture and for this, we'll need to make use of different services from Amazon.

Each service will be allocated in a different EC2 instance. Since each instance represents a different virtual machine, they can be allocated in different Availability Zones, having different IPs. Since user must be kept in the dark and not be disturbed with the changes, we need to add a component to redirect queries based on the service required. That's where the API Gateway comes into play. All user queries will be directed to the API Gateway, with no possibility to contact the EC2 instance directly.

The API Gateway will check the query and decide to which instance redirect the query. We can also do other stuff, like apply throttling or marshalling to queries.

Then, the query will be delivered to the Network Load Balancer to finally being sent to the corresponding EC2 instance.

When the service finishes execution, the result will be returned through the same path and be finally being sent to the user through the API Gateway.

Given that all these nodes will share the same Virtual Private Cloud (VPC) outside user's reach, the only way to communicate for the user will be through the API Gateway.

A test was implemented using Direct Public Integration. This means that different EC2 instances can be reached by the API Gateway and the public internet. To access the API Gateway, queries must be made to the following address and with the following format: Address: <GATEWAY_ADDRESS>//

Currently, only the "test" stage is configured. So, for example:

• If we want to access the list of students on the first instance we need to query: https://946co3j3sd.execute-api.us-east-2.amazonaws.com/test/api/v1/students
• If we want to access the healthcheck on the second instance we need to query: https://946co3j3sd.execute-api.us-east-2.amazonaws.com/test/health

The next steps would be to set the different EC2 instances in a private network and having the API Gateway to be the only way to communicate. For this, we're going to need an AWS Session Manager

Decoupled Components: Each service operates independently, with its own codebase and databaseff

Microservices are easier to scale, especially when their individual modules have conflicting resource requirements

Since we have services like characterization and PDF report generation who use the same data, a way to let these services scale independently is to add DB replicas, which are read-only copies of a DB instance which are asynchronously updated whenever there is a change on the original, which allows for reads and writes. Normally, we would use this to balance queries, but we can restrain access to replicas for microservices to allow for independent scaling.

AWS Docs Youtube - Tutorial