Skip to main content

MicroServices Notes

What is a Service​

Clients(Website, mobile and desktop) send req and receive data over some kind of network i.e., INTERNET

Backend systems will provide the functionality and data to the client side applications. Backend system will consistes of some kind of service or multiple services which basically encapsulate functionality and data we need to request.

Normally client use API to make request.

Example:

http://myapi.com/products

API – Application Programming Interface - It’s a way of making request into a component. Here the component means Model, Views, Controllers, Services, Plugins and Data Access Objects …etc. So a component that can be reused across multiple systems and applications can be packaged and distributed as an API.

API

Client applications can do different operations(GET,POST,PUT,DELETE etc) with API support and backend system will provide that functionality and data.

info

Micro services architecture can actually takes different form in terms of scope and communication style when compared to client-server architecture.

Actually most micro services architecture desing principles actually inherits from service oriendted architecture(SOA). SOA is adopted enterprise level.SOA usually communicates with multiple services using messaging technique called Event Service Bus (ESB). Service ===== Service Service Service

Monolith​

  • No restriction on size
  • Longer development and deployment
  • Inaccessible features
  • Fixed technology stack
  • High levels of coupling
  • Failure could effect the whole system
  • Inefficient scaling
  • Minor change results in entire system deployment
  • Easy to replicate environment
  • Quick solution for startup and prototyping
  • Monolithic is an alternative

Microservices Design Principles​

Service

Technologies for Microservices​

Service

- Load balancers and Service registry​

Service Service

- API Gateways and BFF APIs​

Service

- Synchronous Communication​

Service

- API Style for micro services​

Service

- Resiliency Patterns​

Service

- Open API and API Catalogues​

Service

- Asynchronous Communication​

Service Service

- Transaction Manager​

- Horizantal and Verical Scaling​

Scalability is simply measured by the number of requests an application can handle successfully. It can be measured by the number of requests and it can effectively support simultaneously. Once the application can no longer handle any more simultaneous requests, it has reached its scalability limit.

When your business to grow, in order to prevent downtime, and reduce latency, you must scale your resources accordingly. You can scale these resources through a combination of the network bandwidth, CPU and physical memory requirements, and hard disk adjustments.

Horizontal scaling and Vertical scaling both involve adding resources to your computing infrastructure, you must decide which is right for your application. Scaling horizontally and scaling vertically are similar in that they both involve adding computing resources to your infrastructure.

Horizontal scaling means scaling by adding more machines to your pool of resources (also described as “scaling out”), whereas Vertical scaling refers to scaling by adding more power (e.g. CPU, RAM) to an existing machine (also described as “scaling up”).

Service

Distributed transaction​

Transactions that span over multiple physical systems or computers over the network, are simply termed Distributed Transactions.

In the world of microservices a transaction is now distributed to multiple services that are called in a sequence to complete the entire transaction.