Microservices

What are the main components of microservices architecture

Microservices pattern in simple terms is where you would create a separate component for each of the logical components in the system. For a e-commerce platform as an example you can take the products, cart, checkout as three different logical components that can be written as separate services. In microservices, each component needs to have a separate data store (database) that the service would query to provide its services.

But microservices aren't just about have a separate code base and a database for each component. While each microservice can be explained in that form, the collection a microservice would need more components.

Microservices are a structural design pattern that divides an application into a collection of loosely coupled services, each responsible for a specific business capability. These services are independently developed using different languages, frameworks, independently deployable, communicate through well-defined interfaces or APIs.

Key Concepts

Decoupled: Microservices are decoupled from each other, which makes it easy to develop, deploy and scale independent of each other. Enables faster design, develop, test cycles.

Independent: Each service is a contained unit of its own. No other service can block its progress.

Containerized: Each srevice may be packaged with its own requirements, such as dependencies and can be kept consistent across different environments such as dev, staging and production.

Communication: Services talk to each other through well defined interfaces reducing complexities in RPC.

API Gateway

This is the entry point for requests to the service. API Gateway routes the requests to the appropriate microservice. API Gateways also are capable of other tasks as follows.

API Gateways are capable of validating parameters when an OpenAPI specification is provided. If you are wondering how this is possible with encrypted traffic (HTTPS with SSL/TLS), this is doable as the https or SSL/TLS termination (decryting the encrypted data) happens mostly on the API gateway (also can happen on a load balancer) and the API Gateway passes this information forward to a given load balancer or a service in unencrypted form.

API Gateways can also provide allow-lists and deny-lists. You can provide IP addresses, ranges or geographical ranges for the for allowing the traffic through or denying.

Authentication and Authorization is a bigger part of the microservices where each request has to be authenticated regardless of what authentication method is used. While authenticating can be tiny bit computationally expensive, API Gateways can cache authentication requests for shorter periods of time in instances such as when using JWT with expiry timestamps. That way it can authenticate the requests faster.

Rate limiting can also be performed at the API Gateway level where limits based on IP, devices or API Key can be provided thus reducing the load on the servers.

Dynamic Routing, routing requests dynamically based on paths, goregraphies etc can be facilitated using API Gateways.

Protocol conversion where the API Gateway can convert the request protocol (like TCP) to a different protocol requested by the downstream services.

Load balancer

A load balancer as the word means is a component that distributes the incoming requests for a service across similar instances of a given service. The load balancer comes in handy when there are multiple instances of the same microservice that is ready to accept requests. Load balancer then sends the requests balanced between the instances resulting in faster responses. Load balancers utilize different algorithms to do this such as round robin, sticky round robin (consistent hashing). Nginx patterns

AWS Elastic Load Balancer, GCP, AZURE, Nginx, Big-IP

Service Instances

This is the core of the microservice architecture. These are the individual services that form up the entire architecture. Each microservice caters to different components of the system. Each microservice can have more than one instace of the same service depending on the SLA (service level agreements) and the demand. Instances can be created as the demand increases automatically (horizontal scaling).

Database per Service

Each service would maintain its own database to provide its services. This database would not be accessed by other services and any transactions would be routed through the relevant microservice.

Service Registry

As we discussed under Service Instances, each service might spin up multiple instances of the same. But in order to fulfill concurrent requests received at the load balancer, the load balancer itself should know that there are multiple instances running and it can pass these requests to them. So every new instance spawn should register themselves in a service registry so that the load balancer can keep track of the available instances and route requests to them. Service registry is a simple database of services, their instances and the locations. Service instances register with the registry on startup and deregister when being shutdown. In case of services dying without graceful deregistration, the service regsitry might invoke the healthcheck API of the instance for confirmation and on a given number of failed retries, deregsiter the service instance.

Other examples of service registries (or technologies that are commonly used as service registries) include:

Apache Zookeeper
Consul
Etcd
Netflix Eureka

Some systems such as Kubernetes, Marathon and AWS ELB have an implicit service registry.

Service Discovery

When microservices need to talk to each other to get stuff done, how would each service know where to reach? That's when service discovery comes in. This goes hand in hand with the service registry as the service discovery is done via a service registry.

Advantages of Microservice Architecture

Scalability: Not all services need same level fos scaling, a checkout service would need less scaling compared toa product catalog service. Microservices can be scaled individually, allowing for efficient resource utilization and improved performance.

Flexibility: Some languages/frameworks may suit some services more than that of others. Developers can choose the best technology stack for each microservice, making it easier to adopt new technologies or languages as needed.

Rapid Development: Microservices can be allocated to smaller size teams, who can then develop and deploy microservices quickly, enabling faster time-to-market for new features.

Fault Isolation: While debugging issues on microservices can be a nightmare, it would still help to isolate the faults. Issues in one microservice don’t necessarily affect others, enhancing system robustness and fault tolerance.

Disadvantages of Microservice Architecture

Complexity: Managing a large number of microservices can be complex, requiring robust orchestration and monitoring tools.

Increased Operational Overhead: Running multiple microservices and containers necessitates additional operational effort and infrastructure.

Communication Overhead: Inter-service communication can introduce latency and complexity, especially in distributed systems.

Data Consistency: Maintaining data consistency across microservices can be challenging, requiring careful planning and synchronization mechanisms.