Microservices: Difference between revisions
From Devguid
No edit summary |
No edit summary Tag: visualeditor |
||
| (One intermediate revision 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 14: | 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 28: | Line 28: | ||
=== Size of a microservice === | === Size of a microservice === | ||
== Resilience == | == Resilience == | ||
| Line 50: | Line 47: | ||
** Run as part of CI build process | ** Run as part of CI build process | ||
* Beware of shared code | * 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
