In this article I'd like to collect some ideas connected with Microservice Architecture.
1. Bounded context and organisational aspect.
In many sources there is recommendation to create small teams dedicated to one or a few microservices. One microservice should resolve a problem of one bounded context. A small team should well understand implemented part of domain (bounded domain) and should gather maximum "two-pizza team".
2. Possibility to scaling every service of application.
Microservice architecture requires usage of many servers, that's why they have to be monitored and managed centrally. On each server works one instance of service but if we need more instances it is very easy to install it on more servers. This way it is possible to start new instance of service and shut down it if it is needless. Another advantage of Microservice is that small application boot faster than big monolith and it is easy to deploy new code without outage.In many sources there is recommendation to create small teams dedicated to one or a few microservices. One microservice should resolve a problem of one bounded context. A small team should well understand implemented part of domain (bounded domain) and should gather maximum "two-pizza team".
2. Possibility to scaling every service of application.
3. Duplication of code
There is common opinion that much easier is to control monolith than Microservices. Martin Fowler recommends to try resolve business problem in monolith architecture and then eventually move into microservices. However this style have become fashionable and everyone tries his hands at it and it has nothing common to do with business needs... During migration process there is a lot of duplicated code between services. It could be also big problem. However my idea is to move shared parts of code into small utils jars.
4. Latency time & lack of consistent = additional complexity
Common question is how to get consistency and availability concurrently? Answer is sad but it is impossible. Consistency requires to have shared database where every business operation locks updated or removed record.
However, firstly we have to remember that coding, transmitting and decoding message takes time, especially if services are situated in worldwide locations, transmission has significant influence.
Secondly, fault tolerant services move task to available instance of service.
Then, to have hight performance every service has its own database or even every instance of service. That's why in most cases there is used optimistic locking, data partitioning or CQRS and Event Sourcing. Sometimes it is not enough and some business decisions are required to be ready for border conditionals, ex. hotel's room reservation problem.
However, firstly we have to remember that coding, transmitting and decoding message takes time, especially if services are situated in worldwide locations, transmission has significant influence.
Secondly, fault tolerant services move task to available instance of service.
Then, to have hight performance every service has its own database or even every instance of service. That's why in most cases there is used optimistic locking, data partitioning or CQRS and Event Sourcing. Sometimes it is not enough and some business decisions are required to be ready for border conditionals, ex. hotel's room reservation problem.
5. Interface development - contract problem
This subject is good known for SOA and Microservices as well. The common solution for SOA is to use the same wsdl file for producer and consumer but what if we have many different consumers and we need to extend our interface without engaging teams responsible for immutable services?
There is one way to do that - Consumer-Driven Contract. This approach requires to use only needed fields and inform producer about customer schema.
Resources:
This subject is good known for SOA and Microservices as well. The common solution for SOA is to use the same wsdl file for producer and consumer but what if we have many different consumers and we need to extend our interface without engaging teams responsible for immutable services?
There is one way to do that - Consumer-Driven Contract. This approach requires to use only needed fields and inform producer about customer schema.
Resources:
- https://martinfowler.com/articles/microservices.html
- https://martinfowler.com/articles/consumerDrivenContracts.html
- https://www.infoq.com/news/2015/12/soa-v-microservices
- http://blog.arungupta.me/microservice-design-patterns/
- https://dzone.com/articles/application-pattern-consumer
- https://www.martinfowler.com/microservices/
- http://microservices.io/patterns/microservices.html
- https://docs.pact.io/
No comments:
Post a Comment