Introduction to Microservices

Why Microservices?

Microservices have emerged as a popular architectural approach for designing and building software systems for several compelling reasons and advantages. It is a design approach that involves dividing applications into multiple distinct and independent services called "microservices," which offers several benefits, including the autonomy of each service, making it easier to maintain and test in isolation over monolithic architecture.

Figure 1: A sample microservice-based architecture

Figure 1 depicts a simple microservice-based architecture showcasing the services' independent, isolated nature. Each particular entity belonging to the application is isolated into its service. For example, the UserService, OrderService, and NotificationService focus on dealing with different parts of the business.

The overall system is split into services that are driven by independent teams that use their own tech stacks and are even scaled independently.

In a nutshell, each service handles its specific business domain. Therefore, the question arises - "How do you split an application into microservices?". Well, this is where microservices meet Domain Driven Design (DDD).

What is Domain-Driven Design?

Domain-Driven Design (DDD) is an approach to software development that emphasizes modeling software based on the domain it serves. 

It involves understanding and modeling the domain or problem space of the application, fostering close collaboration between domain experts and software developers. This collaboration creates a shared understanding of the domain and ensures the developed software aligns closely with its intricacies.

This means microservices are not only about picking a tech stack for your app. Before you build your app, you'll have to understand the domain you are working with. This will let you know the unique business processes being executed in your organization, thus making it easy to split up the application into tiny microservices.

Doing so creates a distributed architecture where your services no longer have to be deployed together to a single target but instead are deployed separately and can be deployed to multiple targets.

What are Distributed Services?

Distributed services refer to a software architecture and design approach where various application components, modules, or functions are distributed across multiple machines or nodes within a network.

Modern computing commonly uses this approach to improve scalability, availability, and fault tolerance. As shown in Figure 1, microservices are naturally distributed services as each service is isolated from the others and runs in its own instance.

What is a Microservices Architecture?

Microservices and Infrastructure

Microservices architecture places a significant focus on infrastructure, as the way microservices are deployed and managed directly impacts the effectiveness and scalability of the system.

There are several ways in which microservices architecture addresses infrastructure considerations.

1. Containerization: Microservices are often packaged as containers, like Docker, that encapsulate an application and its dependencies, ensuring consistency between development, testing, and production environments. Containerization simplifies deployment and makes it easier to manage infrastructure resources.
2. Orchestration: Microservices are typically deployed and managed using container orchestration platforms like Kubernetes. Kubernetes automates the deployment, scaling, and management of containerized applications. It ensures that microservices are distributed across infrastructure nodes efficiently and can recover from failures.
3. Service Discovery: Microservices need to discover and communicate with each other dynamically. Service discovery tools like etcd, Consul, or Kubernetes built-in service discovery mechanisms help locate and connect to microservices running on different nodes within the infrastructure.
4. Scalability: Microservices architecture emphasizes horizontal scaling, where additional microservice instances can be added as needed to handle increased workloads. Infrastructure must support the dynamic allocation and scaling of resources based on demand.

How to build a microservice?

The first step in building a microservice is breaking down an application into a set of services. Breaking a monolithic application into microservices involves a process of decomposition where you identify discrete functionalities within the monolith and refactor them into separate, independent microservices.

This process requires careful planning and consideration of various factors, as discussed below.

1. Analyze the Monolith: Understand the existing monolithic application thoroughly, including its architecture, dependencies, and functionality.
2. Identify Business Capabilities: Determine the monolith's distinct business capabilities or functionalities. These could be features, modules, or services that can be separated logically.
3. Define Service Boundaries: Establish clear boundaries for each microservice. Identify what each microservice will be responsible for and ensure that these responsibilities are cohesive and well-defined.
4. Data Decoupling: Examine data dependencies and decide how data will be shared between microservices. You may need to introduce data replication, data synchronization, and separate databases for each microservice.
5. Communication Protocols: Define communication protocols and APIs between microservices. RESTful APIs, gRPC, or message queues are commonly used for inter-service communication.
6. Separate Codebases: Create different codebases for each microservice. This may involve extracting relevant code and functionality from the monolith into individual repositories or as packages in a monorepo strategy.
7. Decompose the Database: If the monolithic application relies on a single database, you may need to split the database into smaller databases or schema within a database for each microservice.
8. Implement Service Logic: Develop the business logic for each microservice. Ensure that each microservice can function independently and handle its specific responsibilities.
9. Integration and Testing: Create thorough integration tests to ensure that the microservices can communicate and work together as expected. Use continuous integration (CI) and automated testing to maintain code quality.
10. Documentation: Maintain comprehensive documentation for each microservice, including API documentation and usage guidelines for developers who will interact with the services.

After you've broken down your services, it's important to establish correct standards for how your microservices will communicate.

How do microservices communicate with each other?

Communication across services is an important aspect to consider when building microservices. So, whichever approach you adopt, it's essential to ensure that such communication is made to be efficient and robust.

There are two main categories of microservices-based communication:

1. Inter-service communication
2. Intra-service communication

Inter-Service Communication

Inter-service communication in microservices refers to how individual microservices communicate and interact within a microservices architecture.

Microservices can employ two fundamental messaging approaches to interact with other microservices in inter-service communication.

Synchronous Communication

One approach to adopting inter-service communication is through synchronous communication. Synchronous communication is an approach where a service invokes another service through protocols like HTTP or gRPC and waits until the service responds with a response.

Source: https://www.theserverside.com/answer/Synchronous-vs-asynchronous-microservices-communication-patterns

Asynchronous Message Passing

The second approach is through asynchronous message passing. Over here, a service dispatches a message without waiting for an immediate response.

Subsequently, asynchronously, one or more services process the message at their own pace.

Source: https://www.theserverside.com/answer/Synchronous-vs-asynchronous-microservices-communication-patterns

Intra-Service Communication

Intra-service communication in microservices refers to the interactions and communication within a single microservice, encompassing the various components, modules, and layers that make up that microservice.

Simply put - unlike inter-service communication, which involves communication between different microservices, intra-service communication focuses on the internal workings of a single microservice.

But, with either approach you adopt, you have to make sure that you create the perfect balance of communication to ensure that you don't have excessive communication happening in your microservices. If so, this could lead to "chatty" microservices.

What is chattiness in microservices communication?

"Chattiness" refers to a situation where there is excessive or frequent communication between microservices.

It implies that microservices are making many network requests or API calls to each other, which can have several implications and challenges, such as performance overhead, increased complexity, scalability issues, and network traffic.

Figure: A chatty microservice

As shown above, the UserService has excessive communication with the OrderService and itself, which could lead to performance and scaling challenges as there are excessive network calls.

What is the usage of middleware in microservices?

Middleware plays a crucial role in microservices architecture by providing services, tools, and components that facilitate communication, integration, and management of microservices. Let's discuss a few of the usages.

• Inter-Service Communication: Middleware provides communication channels and protocols that enable microservices to communicate with each other. This can include message brokers like RabbitMQ, Apache Kafka, RPC frameworks like gRPC, or RESTful APIs.
• Service Discovery: Service discovery middleware helps microservices locate and connect to other microservices dynamically, especially in dynamic or containerized environments. Tools like Consul, etcd, or Kubernetes service discovery features aid in this process.
• API Gateway: An API gateway is a middleware component that serves as an entry point for external clients to access microservices. It can handle authentication, authorization, request routing, and aggregation of responses from multiple microservices.
• Security and Authentication: Middleware components often provide security features like authentication, authorization, and encryption to ensure secure communication between microservices. Tools like OAuth2, JWT, and API security gateways are used to enhance security.
• Distributed Tracing: Middleware for distributed tracing like Jaeger and Zipkin helps monitor and trace requests as they flow through multiple microservices, aiding in debugging, performance optimization, and understanding the system's behavior.
• Monitoring and Logging: Middleware often includes monitoring and logging components like ELK Stack, Prometheus, and Grafana to track the health, performance, and behavior of microservices. This aids in troubleshooting and performance optimization.

Building Microservices with Node.js

Building microservices with Node.js has become a popular choice due to Node.js's non-blocking, event-driven architecture and extensive ecosystem of libraries and frameworks.

If you want to build Microservices with Node.js, there is a way to significantly accelerate this process by using Amplication.

Amplication is a free and open-source tool designed for backend development. It expedites the creation of Node.js applications by automatically generating fully functional apps with all the boilerplate code - just add in your own business logic. It simplifies your development workflow and enhances productivity, allowing you to concentrate on your primary goal: crafting outstanding applications. Learn More here.

Understanding the basics of REST API

REST (Representational State Transfer) is an architectural style for designing networked applications. REST APIs (Application Programming Interfaces) are a way to expose the functionality of a system or service to other applications through HTTP requests.

How to create a REST API endpoint?

There are many ways we can develop REST APIs. Here, we are using Amplication. It can be done with just a few clicks.

The screenshots below can be used to walk through the flow of creating REST APIs.

1. Click on "Add New Project"

1. Give your new project a descriptive name

1. Click "Add Resource" and select "Service"

1. Name your service

5. Connect to a git repository where Amplication will create a PR with your generated code

6. Select the options you want to generate for your service. In particular, which endpoints to generate - REST and/or GraphQL

7. Choose your microservices repository pattern - monorepo or polyrepo.

8. Select which database you want for your service

9. Choose if you want to manually create a data model or start from a template (you can also import your existing DB Schema later on)

10. You can select or skip adding authentication for your service.

11. Yay! We are done with our service creation using REST APIs.

12. Next, you will be redirected to the following screen showing you the details and controls for your new service

13. After you click "Commit Changes & Build", a Pull-Request is created in your repository, and you can now see the code that Amplication generated for you:

How can you connect a frontend with a microservice?

Connecting the frontend with the service layer involves making HTTP requests to the API endpoints exposed by the service layer. Those API endpoints will usually be RESTful or GraphQL endpoints.

This allows the frontend to interact with and retrieve data from the backend service.

The BFF (Backend For Frontend) pattern is an architectural design pattern used to develop microservices-based applications, particularly those with diverse client interfaces such as web, mobile, and other devices. The BFF pattern involves creating a separate backend service for each frontend application or client type.

Consider the user-facing application as consisting of two components: a client-side application located outside your system's boundaries and a server-side component known as the BFF (Backend For Frontend) within your system's boundaries. The BFF is a variation of the API Gateway pattern but adds an extra layer between microservices and each client type. Instead of a single entry point, it introduces multiple gateways.

This approach enables you to create custom APIs tailored to the specific requirements of each client type, like mobile, web, desktop, voice assistant, etc. It eliminates the need to consolidate everything in a single location. Moreover, it keeps your backend services "clean" from specific API concerns that are client-type-specific: Your backend services can serve "pure" domain-driven APIs, and all the client-specific translations are located in the BFF(s). The diagram below illustrates this concept.

Source: https://medium.com/mobilepeople/backend-for-frontend-pattern-why-you-need-to-know-it-46f94ce420b0

Microservices + Security

Security is a crucial aspect when building microservices. Only authorized users must have access to your APIs. So, how can you secure your microservices?

Choose an Authentication Mechanism

Secure your microservices through token-based authentication (JWT or OAuth 2.0), API keys, or session-based authentication, depending on your application's requirements.

Centralized Authentication Service

Consider using a centralized authentication service if you have multiple microservices. This allows users to authenticate once and obtain tokens for subsequent requests. If you are using an API Gateway, Authentication and Authorization will usually be centralized there.

Secure Communication

Ensure that communication between microservices and clients is encrypted using TLS (usually HTTPS) or other secure protocols to prevent eavesdropping and data interception.

Implement Authentication Middleware

Each microservice should include authentication middleware to validate incoming requests. Verify tokens or credentials and extract user identity.

Token Validation

For token-based authentication, validate JWT tokens or OAuth 2.0 tokens using libraries or frameworks that support token validation. Ensure token expiration checks.

User and Role Management

Implement user and role management within each microservice or use an external identity provider to manage user identities and permissions.

Role-Based Access Control (RBAC)

Implement RBAC to define roles and permissions. Assign roles to users and use them to control access to specific microservice endpoints or resources.

Authorization Middleware

Include authorization middleware in each microservice to enforce access control based on user roles and permissions. This middleware should check whether the authenticated user has the necessary permissions to perform the requested action.

Fine-Grained Access Control

Consider implementing fine-grained access control to control access to individual resources or data records within a microservice based on user attributes, roles, or ownership.

In general, it's essential to consider the Top 10 OWASP API Security Risks and implement preventive strategies that help overcome these API Security risks.

💡Pro Tip: When you build your microservices with Amplication, many of the above concerns are already taken care of automatically - each generated service comes with built-in authentication and authorization middleware. You can manage roles and permissions for your APIs easily from within the Amplication interface, and the generated code will already include the relevant middleware decorators (Guards) to enforce the authorization based on what you defined in Amplication.

Testing Microservices

Unit testing

Unit testing microservices involves testing individual components or units of a microservice in isolation to ensure they function correctly.

These tests are designed to verify the behavior of your microservices' most minor testable parts, such as functions, methods, or classes, without external dependencies.

For example, in our microservice we built earlier, we can unit test the OrderService by mocking its database and external API calls and ensuring that the OrderService is error-free on its own.

Integration testing

Integration testing involves verifying that different microservices work together correctly when interacting as part of a larger system.

These tests ensure that the integrated microservices can exchange data and collaborate effectively.

Deploying Microservices to a Production Environment

Deploying microservices to a production environment requires careful planning and execution to ensure your application's stability, reliability, and scalability. Let's discuss some of the key steps and considerations attached to that.

• Containerization and Orchestration: We need first to containerize the microservices using technologies like Docker. Containers provide consistency across development, testing, and production environments. Use container orchestration platforms like Kubernetes to manage and deploy containers at scale.
• 💡 Did you know? Amplication provides a Dockerfile for containerizing your services out of the box and has a plugin to create a Helm Chart for your services to ease container orchestration.
• Infrastructure as Code (IaC): Define your infrastructure using code (IaC) to automate the provisioning of resources such as virtual machines, load balancers, and databases. Tools like Terraform, Pulumi, and AWS CloudFormation can help.
• Continuous Integration and Continuous Deployment (CI/CD): Implement a CI/CD pipeline to automate microservices' build, testing, and deployment. This pipeline should include unit tests, integration tests, and automated deployment steps.
• 💡Did you know? Amplication has a plugin for GitHub Actions that creates an initial CI pipeline for your service!
• Environment Configuration: Maintain separate environment configurations like development, staging, and production to ensure consistency and minimize human error during deployments.
• Secret Management: Securely stores sensitive configuration data and secrets using tools like AWS Secrets Manager or HashiCorp Vault. Avoid hardcoding secrets in code or configuration files.
• Monitoring and Logging: Implement monitoring and logging solutions to track the health and performance of your microservices in real time. Tools like Prometheus, Grafana, and ELK Stack (Elasticsearch, Logstash, Kibana) can help.
• 💡You guessed it! Amplication has a plugin for OpenTelemetry that instruments your generated services with tracing and sends tracing to Jaeger!

Scaling microservices

Scaling microservices involves adjusting the capacity of your microservice-based application to handle increased loads, traffic, or data volume while maintaining performance, reliability, and responsiveness. Scaling can be done vertically (scaling up) and horizontally (scaling out). A key benefit of a microservices architecture, compared to a monolithic one, is the ability to individually scale each microservice - allowing a cost-efficient operation (usually, high-load only affects specific microservices and not the entire application).

Vertical Scaling

Vertical scaling refers to upgrading the resources of an individual microservice instance, such as CPU and memory, to manage higher workloads effectively.

The main upside of this approach - there is no need to worry about the architecture of having multiple instances of the same microservice and how to coordinate and synchronize them. It is a simple approach and does not involve changing your architecture or code. The downsides of this approach are: a) Vertical scaling is eventually limited (There is only so much RAM and CPU you can provision in a single instance) and gets expensive very quickly; b) It might involve some downtime as in many cases, vertical scaling of an instance involves provisioning a new, bigger instance, and then migrating your microservice to run on the new instance.

Source: https://data-flair.training/blogs/scaling-in-microsoft-azure/

Horizontal Scaling

Horizontal scaling involves adding more microservice instances to distribute the workload and handle increased traffic. This is usually the recommended scaling approach in many cases since it's cheaper (in most cases) and allows "infinite scale". In addition, scaling back down is very easy in this method - just remove some of the instances. It does require however some architectural planning to ensure that multiple instances of the same microservice "play nicely" together in terms of data consistency, coordination and synchronization, session stickiness concerns, and not locking mutual resources.

Source: https://data-flair.training/blogs/scaling-in-microsoft-azure/

Common Challenges and Best Practices

Microservices architecture offers numerous benefits but comes with its own challenges.

Scalability

• Challenge: Scaling individual microservices while maintaining overall system performance can be challenging.
• Best Practices: Implement auto-scaling based on real-time metrics. Use container orchestration platforms like Kubernetes for efficient scaling. Conduct performance testing to identify bottlenecks.

Security

• Challenge: Ensuring security across multiple microservices and managing authentication and authorization can be complex.
• Best Practices: Implement a zero-trust security model with proper authentication like OAuth 2.0 and authorization like RBAC. Use API gateways for security enforcement. Regularly update and patch dependencies to address security vulnerabilities.

Deployment and DevOps

• Challenge: Coordinating deployments and managing the CI/CD pipeline for a large number of microservices can be challenging.
• Best Practices: Implement a robust CI/CD pipeline with automated testing and deployment processes. Use containerization like Docker and container orchestration like Kubernetes for consistency and scalability. Make sure that each microservice is completely independent in terms of deployment.

Versioning and API Management

• Challenge: Managing API versions and ensuring backward compatibility is crucial when multiple services depend on APIs.
• Best Practices: Use versioned APIs and introduce backward-compatible changes whenever possible. Implement API gateways for version management and transformation.

Monitoring and Debugging

• Challenge: Debugging and monitoring microservices across a distributed system is difficult. It's much easier to follow the flow of a request in a monolith compared to tracking a request that is handled in a distributed manner.
• Best Practices: Implement centralized logging and use distributed tracing tools like Zipkin and Jaeger for visibility into requests across services. Implement health checks and metrics for monitoring.

Handling Database Transactions

Handling database transactions in a microservices architecture can be complex due to the distributed nature of the system.

Microservices often have their own databases, and ensuring data consistency and maintaining transactional integrity across services requires careful planning and the use of appropriate strategies.

Figure: Database per Microservice

As shown above, having a single database per microservice helps adopt better data modeling requirements and even lets you scale the database in and out independently. This way, you have more flexibility in handling DB-level bottlenecks.

Therefore, when you're building microservices, having a separate database per service is often recommended. But, there are certain areas that you should consider when doing so:

1. Microservices and Data Isolation: Each microservice should have its database. This isolation allows services to manage data independently without interfering with other services.

2. Distributed Transactions: Avoid distributed transactions whenever possible. They can be complex to implement and negatively impact system performance. Use them as a last resort when no other option is viable.

3. Eventual Consistency: Embrace the eventual consistency model. In a microservices architecture, it's often acceptable for data to be temporarily inconsistent across services but eventually converge to a consistent state.

4. Adopt The Saga Pattern: Implement the Saga pattern to manage long-running and multi-step transactions across multiple microservices. Sagas consist of local transactions and compensating actions to maintain consistency.

DevOps with Microservices

DevOps practices are essential when working with microservices to ensure seamless collaboration between development and operations teams, automate processes, and maintain the agility and reliability required in a microservices architecture.

Here are some critical considerations for DevOps with microservices:

Automation

Continuous Integration (CI)

Implement CI pipelines that automatically build, test, and package microservices whenever code changes are pushed to version control repositories.

Continuous Delivery/Deployment (CD)

Automate the deployment process of new microservice versions to different environments like preview, staging, and production.

Infrastructure as Code (IaC)

Use IaC tools like Terraform, Pulumi, or AWS CloudFormation to automate the provisioning and configuration of infrastructure resources, including containers, VMs, Network resources, Storage resources, etc.

Containerization

Use containerization technologies like Docker to package microservices and their dependencies consistently. This ensures that microservices can run consistently across different environments. Implement container orchestration platforms like Kubernetes or Docker Swarm to automate containerized microservices' deployment, scaling, and management.

Microservices Monitoring

Implement monitoring and observability tools to track the health and performance of microservices in real time. Collect metrics, logs, and traces to diagnose issues quickly. Use tools like Prometheus, Grafana, ELK Stack (Elasticsearch, Logstash, Kibana), and distributed tracing like Zipkin or Jaeger for comprehensive monitoring.

Deployment Strategies

Implement deployment strategies like blue-green deployments and canary releases to minimize downtime and risks when rolling out new versions of microservices. Automate rollbacks if issues are detected after a deployment, ensuring a fast recovery process.

Wrapping Up

In this comprehensive guide, we've delved into the world of microservices, exploring the concepts, architecture, benefits, and challenges of this transformative software development approach. Microservices promise agility, scalability, and improved maintainability, but they also require careful planning, design, and governance to realize their full potential. By breaking down monolithic applications into smaller, independently deployable services, organizations can respond to changing business needs faster and more flexibly.

We've discussed topics such as building microservices with Node.js, Handling security in microservices, testing microservices, and the importance of well-defined APIs. DevOps practices are crucial in successfully implementing microservices, facilitating automation, continuous integration, and continuous delivery. Monitoring and observability tools help maintain system health, while security practices protect sensitive data.

As you embark on your microservices journey, remember there is no one-size-fits-all solution. Microservices should be tailored to your organization's specific needs and constraints. When adopting this architecture, consider factors like team culture, skill sets, and existing infrastructure.

Good luck with building your perfect microservices architecture, and I really hope you will find this blog post useful in doing so.