Scribd
Upload
28 views1 page

Micro Services

Microservices architecture involves building large applications as a collection of small, maintainable modules that can be developed and deployed independently. Key components include RESTful web services for client-server separation, various design patterns for communication, and tools like API gateways and message brokers for managing interactions. Security, coupling, cohesion, and the 12-factor rules are essential considerations for effective microservices implementation.

Uploaded by

akshararoshan97
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
28 views1 page

Micro Services

Microservices architecture involves building large applications as a collection of small, maintainable modules that can be developed and deployed independently. Key components include RESTful web services for client-server separation, various design patterns for communication, and tools like API gateways and message brokers for managing interactions. Security, coupling, cohesion, and the 12-factor rules are essential considerations for effective microservices implementation.

Uploaded by

akshararoshan97
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 1

Microservices

10/04/24 2:23 PM

What do you mean by Microservice?


○ Microservices, also known as Microservices Architecture, is basically an SDLC approach in which large applications are built
as a collection of small functional modules.
○ In addition to helping in easy maintenance, this architecture also makes development faster.
○ Maintainable and testable,Loosely coupled,Independently deployable, Designed or organized around business capabilities
and Managed by a small team
What is a restful web service?
RESTful web services support total client-server separation. They simplify and
decouple various server components so that each part can evolve independently.
Platform or technology changes at the server application do not affect the client
application.

Design Patterns:
○ API gateway pattern
○ Service discovery pattern
○ Circuit breaker pattern
○ Blue-green deployment pattern

Communication between microservices:


In a microservices architecture, various tools and technologies are involved in facilitating communication between
microservices. These tools help manage the complexities of communication, improve reliability, ensure scalability, and
provide features such as service discovery, load balancing, fault tolerance, and observability. Here are some of the key tools
involved in microservices communication:
○ API Gateway: (Netflix Zuul, Kong, Apigee, and AWS API Gateway)
An API Gateway is a centralized entry point for managing and routing client requests to the appropriate microservices.
It provides features such as request routing, load balancing, authentication, authorization, rate limiting, and caching.

○ Message Brokers: (Apache Kafka, RabbitMQ, Apache Pulsar, and AWS SQS/SNS)
Message brokers facilitate asynchronous communication between microservices using messaging or event-driven
architecture.
They provide features such as pub/sub messaging, message queues, durability, fault tolerance, and scalability.

○ Service Discovery: (Consul, Eureka (part of Netflix OSS), ZooKeeper, and AWS Cloud Map)
Service discovery tools help microservices locate and communicate with each other dynamically without hardcoding
network addresses.
They provide features such as service registration, service lookup, health checks, and load balancing.

○ Load Balancers: (HAProxy, NGINX, AWS ELB (Elastic Load Balancer), and Kubernetes Ingress)
Load balancers distribute incoming client requests across multiple instances of microservices to improve scalability,
availability, and performance.
They provide features such as traffic distribution, health checks, and session persistence.

○ REST Clients and Libraries: (Spring RestTemplate, Feign, Retrofit, and Apache HttpClient)
REST clients and libraries help microservices communicate with each other over HTTP/RESTful APIs.
They provide features such as HTTP request/response handling, serialization/deserialization, and error handling.

○ Service Mesh: (Istio, Linkerd, Consul Connect, and AWS App Mesh)
A service mesh is a dedicated infrastructure layer that facilitates communication between microservices.
It provides features such as service discovery, load balancing, encryption, traffic routing, circuit breaking, and
observability.

How to secure Microservice:


○ Make your microservices architecture secure by design
○ Scan for dependencies
○ Use HTTPS over HTTP
○ Use access and identity tokens
○ Encrypt and protect secrets - developers should encrypt secrets using tools like Microsoft Azure Key Vault, or Amazon
KMS.

Coupling:
It is defined as a relationship between software modules A and B, and how much one module depends or interacts with
another one. Couplings fall into three major categories. Modules can be highly coupled (highly dependent), loosely coupled,
and uncoupled from each other. The best kind of coupling is loose coupling, which is achieved through interfaces.

Cohesion:
It is defined as a relationship between two or more parts/elements of a module that serves the same purpose. Generally, a
module with high cohesion can perform a specific function efficiently without needing communication with any other
modules. High cohesion enhances the functionality of the module.
Example: Suppose we have a class that multiplies two numbers, but the same class creates a pop-up window
displaying the result. This is an example of a low cohesive class because the window and the multiplication operation don’t
have much in common. To make it high cohesive, we would have to create a class Display and a class Multiply. The Display
will call Multiply’s method to get the result and display it. This way to develop a high cohesive solution.

12 Factor rules:
○ Codebase (One codebase tracked in revision control, many deploys)
In Microservices, every service should have its own codebase. Having an independent codebase helps you to easy
CI/CD process for your applications.
○ Dependencies (Explicitly declare and isolate the dependencies)
All the application packages will be managed through package managers like sbt, maven.
▪ In non-containerized environments, you can go for configuration management tools like chef, ansible, etc. to
install system-level dependencies.
▪ For a containerized environment, you can go for Dockerfile.

○ Config (Store configurations in an environment)


○ Backing Services (treat backing resources as attached resources)
Database, Message Brokers, any other external systems that the app communicates is treated as Backing service.
Anything external to service is treated as an attached resource. The resource can be swapped at any given point in
time without impacting the service.
○ Build, release, and Run (Strictly separate build and run stages)
○ Processes (execute the app as one or more stateless processes)
○ Port Binding (Export services via port binding)
○ Concurrency (Scale out via the process model)
○ Disposability (maximize the robustness with fast startup and graceful shutdown)
By adopting containerization into the deployment process of microservices, your application implicitly follows this
principle to a maximum extent. Docker containers can be started or stopped instantly. Storing requests, state, or
session data in queues or other backing services ensures that a request is handled seamlessly in the event of a
container crash.
○ Dev/prod parity (Keep development, staging, and production as similar as possible)
○ Logs (Treat logs as event streams)
○ Admin processes (Run admin/management tasks as one-off processes)

Idempotence:
The term 'idempotence' refers to the repeated performance of a task despite the same outcome. In other words, it is a
situation in which a task is performed repeatedly with the end result remaining the same.

When an HTTP method is idempotent in a REST API, this means that if you send multiple identical requests, only the
initial request would cause a change. Therefore, the results returned to the user will not depend on how many times the
method has been called.

Usage: When the remote service or data source receives instructions more than once, Idempotence ensures that it will
process each request once.

Mike Cohn’s Test Pyramid:


Mike Cohn's Test Pyramid explains the different types of
automated tests needed for software development. The test
pyramid is basically used to maximize automation at all
levels of testing, including unit testing, service level testing,
UI testing, etc. The pyramid also states that unit tests are
faster and more isolated, while UI tests, which are at the top,
are more time-consuming and are centered around
integration.

In accordance with the pyramid, the number of tests should


be highest at the first layer. At the service layer, fewer tests
should be performed than at the unit test level, but greater
than that at the end-to-end level.

You might also like