This document discusses microservices architecture. It describes microservices as loosely coupled services that communicate through well-defined APIs. Each service has a separate and focused business logic. The document outlines advantages like scalability, fault tolerance, and easier development. It also notes potential cons around increased complexity, testing challenges, and performance impacts from network latency.
Report
Share
Report
Share
1 of 14
Download to read offline
More Related Content
linkerd.pdf
1. By : Vishwas Narayan
@vishwasnarayan5 Vishwas N
https://hacksterdude.web.app
2. Microservices
● Microservice architecture is a type of service-oriented
architecture in which an application is organised as a series of
loosely connected services.
● Microservices architecture is characterised by fine-grained
services and lightweight protocols.
● Communication through the well defined API’s
● This is a separate Business logic instead of one Problem
statement
6. Advantages
● Greater agility
● Faster time to market
● Better scalability
● Faster development cycles (easier deployment and debugging)
● Easier to create a Cl/CD pipeline for single-responsibility
services
● Isolated services have better fault Tolerance
● Platform- and language agnostic services
● Cloud-readiness
7. In summary
● Microservices may be deployed individually, giving teams more
control.
● Microservices are scalable in their own right.
● Microservices decrease downtime by isolating faults.
● The smaller codebase allows teams to grasp the code more
quickly, making it easier to maintain.
8. Cons
● More collaboration is required (each team has to cover the
whole microservice lifecycle)
● Because of the architecture's complexity, it's more difficult to test
and monitor.
● Due to the requirement for microservices to communicate,
performance will suffer (network latency,message processing,
etc.)
● It's more difficult to keep the network up to date (has less fault
tolerance, needs more load balancing, etc.)
● Doesn't function until there's a strong company culture in place
(DevOps culture,automation practices,etc.)
● Concerns about security (harder to maintain transaction safety,
distributed communication goes wrong more likely,etc.)
10. Here is why I would love to use LinkerD
● Real-time platform health metrics
For any meshed task, instantly monitor
success rates, latencies, and request
volumes without making any configuration
changes.
● simpler than any mesh Minimalist design
that is inherent to Kubernetes. No hidden
magic, the least amount of YAML, and the
fewest CRDs.
● TLS with zero-config mutual
Any on-cluster TCP communication can
have mutual TLS added transparently and
without setup.
● Self-contained control plane, progressive data
deployment, and a tonne of diagnostic and
debugging tools—all designed by engineers,
for engineers.
● Drop-in features for dependability
To make your applications durable, add right
away latency-aware load balancing, request
retries, timeouts, and blue-green deployments.
● modern, lightweight Rust dataplane
Amazingly little and lightning quick Rust-based
Linkerd2-proxy micro-proxy for performance
and security.
12. ★ Just work : Don’t break apps and don’t require complex config.
★ Minimize resource requirements : Bare minimum perf (and resource!) hit.
★ Keep it simple : Operationally simple with low cognitive overhead. No magic.
Data plane: linkerd2-proxy. Written in Rust. <10ms RSS, < ims p99. (HEE!
Control plane: linkerd2. Written in Go. Includes small Prometheus (6 hour
window), Grafana, etc.
Has some Design Goals