Microservices: Difference between revisions

From Devguid
No edit summary
No edit summary
Tag: visualeditor
 
(7 intermediate revisions by the same user not shown)
Line 1: Line 1:
== Microservice Manifesto ==
* A microservice must be able to be upgraded without the clients having a matching upgrade
* A microservice should have a clear and public interface / contract
* A microservice's public interface should only have additive changes
* A microservice's can add new properties to DTOs but they must not be required
* A microservice must support older version of interface
* A microservice can create new endpoints
* A microservice should be autonomous
== About ==
== About ==


* Autonomous
* Single responsibility principle
* Single responsibility principle
** Do one thing and do it well
** Do one thing and do it well
* Should be able to deploy on it's own
* Perform well
* Resilience to error
* Secure


* Should be able to deploy on it's own
* Own their own data
* Public interface should be defined clearly
* Independently deployable
* Within specific boundaries
 
=== When do you need one ===
 
* When scaling
 
=== Size of a microservice ===
 
== Resilience ==
 
== Securing ==
 
== Deploy ==
 
= How to =
 
== Avoid upgrade issues ==
 
* Split up team ownership of microservices
** First add new features
** Then deploy updated microservice
** Later update clients
* Automated tests
** Ensure that older clients are supported
** Run as part of CI build process
* Beware of shared code
** Can result in tight coupling


[[Category:Architecture]] [[Category:Designpatterns]]
[[Category:Architecture]] [[Category:Designpatterns]]

Latest revision as of 21:38, 26 April 2023

Microservice Manifesto

  • A microservice must be able to be upgraded without the clients having a matching upgrade
  • A microservice should have a clear and public interface / contract
  • A microservice's public interface should only have additive changes
  • A microservice's can add new properties to DTOs but they must not be required
  • A microservice must support older version of interface
  • A microservice can create new endpoints
  • A microservice should be autonomous

About

  • Autonomous
  • Single responsibility principle
    • Do one thing and do it well
  • Should be able to deploy on it's own
  • Perform well
  • Resilience to error
  • Secure
  • Own their own data
  • Independently deployable
  • Within specific boundaries

When do you need one

  • When scaling

Size of a microservice

Resilience

Securing

Deploy

How to

Avoid upgrade issues

  • Split up team ownership of microservices
    • First add new features
    • Then deploy updated microservice
    • Later update clients
  • Automated tests
    • Ensure that older clients are supported
    • Run as part of CI build process
  • Beware of shared code
    • Can result in tight coupling