Microservices: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
 
(53 intermediate revisions by the same user not shown)
Line 2: Line 2:


* [[Software Development#Microservices|Software Development]]
* [[Software Development#Microservices|Software Development]]
* [[Software Architecture#Microservices|Software Architecture]]
* [[Serverless Computing]]
* [[Serverless Computing]]
* [[Microservices in Go]]


=External=
=Learning=
{{Internal|Microservices Learning|Microservices Learning}}


* Martin Fowler's Microservices Resource Guide http://martinfowler.com/microservices/ https://martinfowler.com/articles/microservices.html
=Overview=
* Adrian Cockcroft on Microservices, Terraservices and Serverless Computing https://www.infoq.com/articles/podcast-adrian-cockcroft
* https://access.redhat.com/documentation/en-us/reference_architectures/2017/html/microservice_architecture/
* Anil's:
** https://hackernoon.com/development-of-microservices-problems-and-solutions-b3ce8f1f7ff1#.h88lojeqh
** https://medium.com/@anil789/micro-applications-and-decomposition-of-ui-1062e3b1a345#.b3rid28v8
** https://medium.com/@anil789/micro-applications-and-microservices-together-b1d0460916d3#.dzosqc17v


* https://livebook.manning.com/#!/book/microservices-in-net-core/chapter-1/7
An application based on microservices is composed of small, highly decoupled, mostly autonomous components, that are built to offer a specific (mostly business) functionality. A cloud-native application is composed of multiple microservices that communicated through shared infrastructure, in most cases over HTTP/REST. The microservices architecture provides two major advantages: various components can be developed, deployed, monitored, and troubleshot independently, on a service-by-service basis, rather than dealing with the entire application. The second advantage is that a specific layer can be scaled independently by other layers. The underlying infrastructure can also be provisioned and changed [[Infrastructure_as_Code_Concepts#Build_Small.2C_Simple.2C_Loosely_Coupled_Pieces_that_Can_Be_Changed_Independently|independently and faster]].


=Overview=
James Lewis and Martin Fowler definition: Microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.
 
=Use Cases=
 
A situation when we may benefit from splitting an application into separate services is when:
* Logic is loosely coupled
* Data models are different
* Data is generally independent
 
=<span id='Discovery'></span>Service Discovery=
Service discovery is letting microservices know about each other in a dynamic environment. Service discovery addresses discovering the instances of a particular service, adding and removing service instances and handling the situation when a service instance becomes unresponsive, as indicated by a [[#Service_Heath_Monitoring|service health monitoring feature]]. The list of discrete features we would expect from a service discovery provider implementation is:
* The ability to register a service on service startup.
* The ability to deregister a service on shutdown.
* The ability to get a list of services, per type.
* Service health monitoring and automatic removal of inactive services.
 
In most cases, the service discovery function is implemented with a '''service registry'''.
 
Each service can either register itself, or use some library or tool to automatically register on startup. Once the service is registered, it is being monitored via health checks to ensure that is available.
 
==Service Discovery Patterns==
===Client-Side Service Discovery===
For client-side service discovery, the dependent service connects to the registry and pulls targets. The downside is that this makes the service logic more complex, and also burdens it with load balancing duties.
===Server-Side Service Discovery===
{{External|https://microservices.io/patterns/server-side-discovery.html}}
 
For server-side service discovery, the dependent service sends requests into a '''load balancer'''. The load balancer interacts with the registry and becomes informed on possible targets. The load balancer does the load balancing.
 
==Service Discovery Solutions==
* [[HashiCorp Consul]]
* [[Kubernetes]]
 
Also see: {{Internal|Infrastructure_Concepts#Service_Discovery|Infrastructure Concepts &#124; Service Discovery}}
 
=Service Heath Monitoring=
 
A registry keeps up to date with the health of the registered services via a '''pull model''' (the registry polls) or '''push model''' (the service pushes health information).
=Serialization=
{{Internal|Serialization#Overview|Serialization}}
 
=Synchronous Communication=
 
Synchronous communication is a way of interaction between network applications, in which applications exchange data using a request-response model. The client, which sent the request, blocks the invoking thread until a response is available, or an error or timeout occur. [[HTTP]] is one of many protocols that allow synchronous communication. [[Grpc|gRPC]] is an alternative.


An application based on micro services is composed of small, mostly autonomous components, that are built to offer a specific functionality. A cloud-native application is composed of multiple microservices that communicated through shared infrastructure, in most cases over HTTP/REST. The microservices architecture provides two major advantages: various components can be developed, deployed, monitored, and troubleshot independently, on a service-by-service basis, rather than dealing with the entire application. The second advantage is that a specific layer can be scaled independently by other layers.
=Asynchronous Communication=
{{Internal|Asynchronous Communication|Asynchronous Communication}}


James Lewis and Martin Fowler definition: Microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.
=Data Storage=
{{Internal|Databases|Databases}}


=To Process=
=Deployment=
In most cases, Kubernetes is a good option.
==Deployment Best Practices==
===Automated Rollbacks===
===Canary Deployments===
A canary deployment is a special type of deployment where only a small fraction of the instances is updated. This allows testing the new version on a subset a production instances and quickly roll back if there are problems, without affecting a large user population.
===Continuous Deployment (CD)===


* http://basho.com/posts/technical/microservices-please-dont/
=Unit and Integration Testing=
* https://content.pivotal.io/blog/should-that-be-a-microservice-keep-these-six-factors-in-mind
=Observability=
* Chris Richardson's https://www.infoq.com/articles/microservices-intro
{{Internal|Observability|Observability}}
* The Hidden Dividends of Microservices https://queue.acm.org/detail.cfm?id=2956643
=Patterns=
* https://opensource.com/article/18/11/revisiting-unix-philosophy-2018
{{Internal|Microservices_Patterns#Overview|Microservices Patterns}}

Latest revision as of 21:37, 16 February 2024

Internal

Learning

Microservices Learning

Overview

An application based on microservices is composed of small, highly decoupled, mostly autonomous components, that are built to offer a specific (mostly business) functionality. A cloud-native application is composed of multiple microservices that communicated through shared infrastructure, in most cases over HTTP/REST. The microservices architecture provides two major advantages: various components can be developed, deployed, monitored, and troubleshot independently, on a service-by-service basis, rather than dealing with the entire application. The second advantage is that a specific layer can be scaled independently by other layers. The underlying infrastructure can also be provisioned and changed independently and faster.

James Lewis and Martin Fowler definition: Microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.

Use Cases

A situation when we may benefit from splitting an application into separate services is when:

  • Logic is loosely coupled
  • Data models are different
  • Data is generally independent

Service Discovery

Service discovery is letting microservices know about each other in a dynamic environment. Service discovery addresses discovering the instances of a particular service, adding and removing service instances and handling the situation when a service instance becomes unresponsive, as indicated by a service health monitoring feature. The list of discrete features we would expect from a service discovery provider implementation is:

  • The ability to register a service on service startup.
  • The ability to deregister a service on shutdown.
  • The ability to get a list of services, per type.
  • Service health monitoring and automatic removal of inactive services.

In most cases, the service discovery function is implemented with a service registry.

Each service can either register itself, or use some library or tool to automatically register on startup. Once the service is registered, it is being monitored via health checks to ensure that is available.

Service Discovery Patterns

Client-Side Service Discovery

For client-side service discovery, the dependent service connects to the registry and pulls targets. The downside is that this makes the service logic more complex, and also burdens it with load balancing duties.

Server-Side Service Discovery

https://microservices.io/patterns/server-side-discovery.html

For server-side service discovery, the dependent service sends requests into a load balancer. The load balancer interacts with the registry and becomes informed on possible targets. The load balancer does the load balancing.

Service Discovery Solutions

Also see:

Infrastructure Concepts | Service Discovery

Service Heath Monitoring

A registry keeps up to date with the health of the registered services via a pull model (the registry polls) or push model (the service pushes health information).

Serialization

Serialization

Synchronous Communication

Synchronous communication is a way of interaction between network applications, in which applications exchange data using a request-response model. The client, which sent the request, blocks the invoking thread until a response is available, or an error or timeout occur. HTTP is one of many protocols that allow synchronous communication. gRPC is an alternative.

Asynchronous Communication

Asynchronous Communication

Data Storage

Databases

Deployment

In most cases, Kubernetes is a good option.

Deployment Best Practices

Automated Rollbacks

Canary Deployments

A canary deployment is a special type of deployment where only a small fraction of the instances is updated. This allows testing the new version on a subset a production instances and quickly roll back if there are problems, without affecting a large user population.

Continuous Deployment (CD)

Unit and Integration Testing

Observability

Observability

Patterns

Microservices Patterns