Introduction to Microservices Architecture Patterns

Welcome! Let's explore microservices and how they communicate with clients and among themselves. Discover their strengths and challenges in a nutshell.

What to expect?

• Application Architecture Patterns
  • Microservices Architecture
  • Monolithic Architecture
• Microservices Communication Patterns
  • Client-to-Service Communication
    • API Gateway
    • Variation: Backends for Frontends(BFF)
  • Service-to-Service Communication
• When to Opt for Microservices?
• Summary
• References

Application Architecture Patterns

An application architecture pattern is like a plan that shows how different parts of an app fit together. Think of it as a map for developers, guiding them on how to organize things inside the app.

We're going to talk about two main patterns: Monolithic and Microservices architecture.

1. Monolithic Architecture: In this setup, the whole app is built as a single unit. It's like having one big box that contains everything like the user interface, logic, and database.

2. Microservices Architecture: Here, the app is split into smaller parts or services, each doing its job. It's like having several small boxes, each responsible for a specific task, and they all work together.

These patterns help decide how to build apps, and each has its strengths and weaknesses. Depending on what you need, you might choose one over the other. This blog will dive deeper into these two patterns to help you understand which one might work best for different situations.

Microservices Architecture

"Microservices" is a term buzzing around in the world of developers. But what do they mean? Let's break it down in easy terms.

Imagine building a blogging platform where people share their ideas. Now, instead of making it all in one piece, we split it into separate parts called services:

1. Auth Service : Takes care of logging in, passwords, and who's allowed to do what.

2. User Service : Handles creating accounts, profiles, and settings.

3. Content Service : Deals with writing, editing, and deleting blog posts.

4. Search Service : Helps users find posts by searching with words or tags.

5. Media Service : Stores, shows, and manages pictures or videos in the posts.

This list covers just a bit of what's needed. More services might be needed based on what the platform requires.

These separate services as a collection are called "Microservices." Each one is independent. But what's special about them being "independent"?

Independence here means:

1. Independent Development: Different teams can work on each service without waiting for others. This lets them work faster, try out new ideas and optionally, use a mix of different tools and frameworks.

2. Independent Deployment: Each service could be operated on separate servers. So, if one service has a problem, it doesn't mess up the others. This helps keep things running smoothly.

3. Independent Scaling: When lots of people use a service, you can make it bigger without affecting everything else. This helps the whole system handle lots of users without slowing down.

These things make Microservices strong. They can adapt and grow without causing trouble for the whole system. That's why they're powerful for making big and flexible applications.

While the Microservices architecture offers numerous advantages, it's important to note potential drawbacks:

1. Increased Maintenance Costs: Managing several independent services might require more effort and resources for maintenance. Each service needs regular updates, bug fixes, and continuous monitoring, leading to higher maintenance costs.

2. Organizational Complexity and Overhead: Coordinating among different teams, each responsible for specific services, can create organizational challenges.

3. Coordination Complexity: As multiple services work together to accomplish tasks, coordinating their interactions becomes crucial.

4. Risk of Failure Cascades: Since services are interconnected, a failure in one service could potentially affect other services, leading to a cascade of failures.

5. Performance and Reliability Issues: Integrating multiple services might introduce network latency or communication overhead, impacting overall system performance.

Understanding these potential drawbacks helps in making informed decisions and implementing strategies to mitigate these challenges while leveraging the benefits of a Microservices architecture.

Monolithic Architecture

Imagine the Monolithic Architecture as one big app that holds everything together. It's like having a single app where everything you need is inside.

Here's why it's handy:

1. Rapid Development: Since everything's in one place, building is fast. Talking between different services is easy because they're all together. Unlike in Microservices, where we need to plan how separate services talk because they're deployed on separate servers.

2. Rapid Deployment: When you finish, you just put out one big app. All the services come together at once. But with Microservices, you have to put out each service separately, which needs more planning and proper execution.

3. Cost Efficient: With Monolithic, you use fewer servers and databases. You put everything on one server, which makes things cheaper. Microservices usually need one server for each service, so more servers mean more money.

This Monolithic way helps grow things quickly and cheaper. It's great for startups to make things fast without spending a lot.

While the Monolithic approach aids rapid growth, it also carries its limitations:

1. Scalability: Individual parts cannot be scaled independently.

2. Reliability: Errors in one module might impact the entire application's availability.

3. Technology Adoption: Modifications in framework or language affect the entire application, making changes costly and time-consuming.

4. Lack of Flexibility: The Monolith is confined by the technologies it's built upon.

5. Deployment Hassles: Even minor changes necessitate redeploying the entire monolithic application.

Microservices Communication Patterns

Microservices use different ways to talk to each other and to the clients that use them. There are two key types of communication:

1. Client-to-Service Communication: This type helps clients (browsers) get data from microservices. It's like asking for information from the microservice.

2. Service-to-Service Communication: Here, one microservice talks to another one. It's like these services chatting amongst themselves to get things done.

These communication patterns are important because they decide how these microservices talk to each other. Let's take a closer look at both types to see how they work and why they matter.

Client-to-Service Communication

Imagine our blogging app using the Microservices pattern. This app's dashboard shows various info: blog feeds, searches, user profiles, etc. But because it uses Microservices, this data is split among different services:

• Content Service: Gives trending blog lists for feeds.

• User Service: Provides user details for profiles.

• Search Service: Offers blogs based on search terms.

• ... so on

So, when the code builds the dashboard, it needs info from all these services.

A common way to manage this is through an "API Gateway." This acts like a main door for all clients. Let's explore what an "API Gateway" is and another related idea called "Backends for Frontends (BFF)". This helps streamline how clients talk to these different services.

API Gateway

The API Gateway serves as a central server, the main entryway for all clients. It offers a common interface to a bunch of microservices. This makes things simpler for clients and hides the inside workings of the application.

Let's break down how the API Gateway functions using the diagram below:

From the diagram above, we see that when a client asks for something, the API Gateway handles a bunch of tasks and then sends the request to the right microservice.

The diagram also illustrates several tasks performed by the API Gateway, such as:

• Monitoring: API Gateway keeps an eye on the traffic and activities passing through it, observing performance, usage patterns, and potential issues.

• Security: It manages and enforces security measures, such as authentication, authorization and encryption.

• Throttling: Controls and regulates the rate of incoming requests.

• Aggregation: It involves merging or collecting data from various services into a unified response. This simplifies client interactions by integrating all necessary data into one request rather than making multiple separate calls.

• Manipulation: Modifies or transforms incoming or outgoing data payloads as needed.

• Filtering: Filters or screens incoming requests or outgoing responses based on predefined criteria.

These functionalities collectively help streamline communication between clients and microservices while providing essential services such as security, performance optimization, and data manipulation.

How does the API Gateway determine which request should be directed to which microservice?

API Gateway may simply maintain a static map of routes and hosts. However, what happens when multiple instances of a microservice are deployed having dynamic IP addresses due to scaling, downsizing, stopping, or starting?

Here's where "Service Registry & Discovery" steps in. It's like a service catalogue or directory where the API Gateway finds which service instance to send the request to. This Service Discovery acts as a source of truth, registering all services and their status, whether they're running or not. It's a bit like a map guiding the API Gateway to the right service instance.

Some of the popular open-source discovery tools:

1. Consul

2. Etcd

High Availability with API Gateway: Understanding Scalable Infrastructure

Generally, it's recommended to have a few containers or servers of "API Gateway" in production to have high availability. Let's examine the diagram below for a clearer insight:

The depicted diagram showcases a grouping of API Gateway instances and a grouping of Content service instances, along with the process of load balancing requests.

At the forefront is the external load balancer, responsible for receiving client requests and directing them to an API Gateway instance according to its balancing algorithm. Subsequently, the API Gateway might employ an internal load balancer to direct requests to a service instance. Alternatively, an external load balancer can be utilized to steer requests from the API Gateway to multiple instances of a service.

In conclusion, employing multiple API Gateway instances enhances system reliability and scalability. Through load balancing, both external and internal, this setup ensures efficient handling of client requests, contributing to a robust and highly available architecture.

Variation: Backends for Frontends(BFF)

A variation of this pattern is the Backends for frontends pattern. It defines a separate API gateway for each kind of client.

In the above diagram, there are three kinds of clients: web applications, mobile applications, and external third-party applications. There are three different API gateways. Each one provides an API for its client.

By implementing the Backends for Frontends pattern, tailored API gateways enhance client-specific experiences. However, managing client-specific gateways may introduce added complexity in configuration and maintenance, requiring careful consideration for effective implementation.

Service to Service Communication

Service-to-service communication involves services interacting and sharing data.

In a microservices setup, each service handles its specific tasks independently. But to accomplish more complex jobs, these services must talk to each other, share data, trigger actions, or coordinate their work.

Let's take an example of Search and Indexing where we would need service-to-service communication.

A search service would be responsible for indexing articles and providing search capabilities. It needs to communicate with the Content service to obtain the necessary data for indexing and updating the search index. The below diagram demonstrates how search services could communicate with content services via different methods of communication.

There are various ways these services can communicate, such as:

• RESTful APIs

• RPC(Remote Procedure Call)

• Event Streaming

• Message Brokers

These methods allow services to talk and exchange information, helping them collaborate and perform more complex tasks together.

When to Opt for Microservices?

For startups or smaller applications, starting with a Monolithic architecture is cost-effective and quicker for initial development. However, as an application grows and needs more scalability, flexibility, and independent service management, transitioning to Microservices becomes advantageous.

Microservices shine in larger, complex systems but bring challenges like increased complexity, communication management between services, and higher operational costs. Implementing Microservices should be based on the application's evolving needs, weighing the benefits against the added complexities.

In essence, Monoliths work well for simplicity in the beginning, while Microservices excel in scalability and modularity as applications mature and demand greater flexibility.

Summary

In this blog, we delve into the world of Microservices Architecture, covering a range of key topics:

1. Application Architecture Patterns: Understanding the fundamental structures and their relevance in designing applications.

2. Microservices Communication Patterns: Examining how Microservices communicate with clients and among themselves, highlighting Client-to-Service and Service-to-Service communication.

3. Determining When to Opt for Microservices: Considering scenarios where transitioning from Monolithic to Microservices architecture proves advantageous.

This article offers a basic understanding of Microservices Architecture patterns, yet deeper insights come with real implementation. New programmers entering distributed applications often make assumptions known as "Fallacies of distributed systems". It's crucial to consider these fallacies when designing such systems.

References to credible sources are provided for further exploration and a deeper understanding of Microservices Architecture patterns.

References

• Microservices architectures: https://microservices.io/

• ByteByteGo: https://blog.bytebytego.com/

• KrakenD API Gateway: https://www.krakend.io/

• Microservices Disadvantages: https://www.shopify.com/enterprise/disadvantages-microservices

• Microservices vs Monoliths: https://www.atlassian.com/microservices/microservices-architecture/microservices-vs-monolith