Microservices: Difference between revisions
From Devguid
No edit summary |
No edit summary Tag: visualeditor |
||
(3 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 == | ||
Line 5: | Line 15: | ||
** Do one thing and do it well | ** Do one thing and do it well | ||
* Should be able to deploy on it's own | * Should be able to deploy on it's own | ||
* Perform well | * Perform well | ||
* Resilience to error | * Resilience to error | ||
Line 20: | Line 29: | ||
=== Size of a microservice === | === 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