Microservices: Difference between revisions
From Devguid
No edit summary |
No edit summary |
||
| Line 37: | Line 37: | ||
== Deploy == | == 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 | |||
[[Category:Architecture]] [[Category:Designpatterns]] | [[Category:Architecture]] [[Category:Designpatterns]] | ||
Revision as of 19:15, 25 April 2023
Rules
- Can be upgraded without clients need to be upgraded
- Define a clear public interface/contract
- Make additivie changes
- Create new endpoints
- New properties on DTOs
- Publish new version of it, previous version must still be supported
About
- Autonomous
- Single responsibility principle
- Do one thing and do it well
- Should be able to deploy on it's own
- Public interface should be defined clearly
- 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
