A presentation on micro service, basic introduction, its treadeoffs and sharing the experience and discussion with the team.

1. Microservice
Intro and Experience Sharing

2. Microservice

3. Intro
In this presentation I will be providing a basic introduction to microservice and
we will be sharing our experience on microservice.
A microservice is a software architectural style in which a large application is
broken down into smaller, independent services that communicate with each
other through APIs.

4. Why Microservice
Monolithic architecture is a traditional software
architecture style where an application is
developed as a single, unified codebase that
contains all the features and functionalities of
the application. In a monolithic architecture, the
application is deployed as a single unit, and all
the services within the application are tightly
coupled together, making it difficult to modify or
scale individual components without affecting
the entire application.
Multi-tier architecture, on the other hand, is an
architecture style that separates the application
into different layers, each responsible for a
specific functionality of the application.
The most common layers in a multi-tier
architecture are the presentation layer,
application layer, and data storage layer.

5. Why Microservice
Limited scalability: difficult to scale horizontally
Limited fault tolerance: A failure in one
component can cause the entire application to
fail
Tightly coupled: difficult to modify or extend and
work on a team.
Technology stack inflexibility: use a single
technology stack for the entire application
Deployment complexity: Deploying updates or
new features
Testing complexity: Test the entire applications
Codebase complexity: complex codebase with
high coupling

6. Microservice
Microservices is a software design
approach that structures an
application as a collection of small,
independent services.
These services are loosely coupled
and communicate with each other via
well-defined APIs.
Microservices are often developed and
deployed independently, which can
make them more agile and scalable

7. API Gateway
Identity Provider:
An identity provider (IdP) is a server that
authenticates users and provides them with
access to resources. It is responsible for
verifying the identity of users and issuing them
tokens that can be used to access resources.
- Access Control
- Security
Service Registry and discovery:
A service registry is a database that stores
information about microservices, such as their
endpoints, health, and version. It is used by the
API gateway to route requests to the appropriate
microservices.
Service discovery is a process of finding the
location of a service. It is used by clients to find
the address of a service so that they can make
requests to it.

8. Microservice
Containerization: Each service are containerized,
and can be deployed independently. Get own
hostname to access it with in the network.
Docker
Containers Orchestration: Run the container,
maintain the state. Prepare a state and the
service will make sure, It stay such. Kuberneties
Pipeline Automation: CI/CD github actions,
Jenkins
Asynchronous Messaging: For communication
among Services. kafka, rabbitmq
Performance Monitoring: Monitor state of the
services, its performance and identify
bottleneck. Prometheus
Logging and Audit: for identifying the issues
when encountered, analysing the data. Datadog

9. Microservice
Scalability: independent scaling of individual
services
Fault tolerance: Only a components go down
Technology stack flexibility: We can use
different tech stack for different services
Simplified maintenance and development: Easy
to maintain, as a service is specific and simple
Agility: faster deployment of updates and new
features
Team autonomy: allows development teams to
work independently on different services

10. My experience with Microservice
At Sahara, a ride sharing company.
- Actively Under Development as well as on
production
- Small Team
- Event Driven Application flow
- Dependencies on other System, Map,
Notifications, SMS
A personal project, TSH
- A basic application
- Multiple services from different domains
- Limited target group

11. Experience
Sharing

12. A possible approach for starting
Start Small and Manageable architecture
Develope highly cohesive and low coupled
modules
Build stateless system
Access Other Modules through API, not directly
Keep scalability in mind
Create a separate process (microservice) for
supporting system, that can exist independently.
(Its okay to manually configure different
process)
Document your architecture and how each
components communicate.
KISS
YAGNI

13. Final point
We can use some form of
Microservice.

14. “The goal of software engineering is to
control complexity, not to create it.”
- Dr. Pamela Zave

15. It is important to carefully
consider the trade-offs and
challenges before deciding
to adopt microservices.