I'm researching about Microservices Architecture and I concern about shared data between services as master data of the system. Example, in my system I have 2
business contexts "Import Booking" and "Import Invoice".
Import Booking uses Company information to validate and create new Company if not exists.
Import Invoice uses Company information to validate.
So, the system will have 3 services "Import Booking", "Import Invoice", "Company Service" and "Company Service" will expose an API for another services to CRUD or the system only have 2 services "Import Booking" and "Import Service" and CRUD Company will implement in each service.
I think you have your bounded context and service boundaries a bit off, look at this talk: https://vimeo.com/284707733 "Finding your service boundaries - a practical guide - Adam Ralph".
I'd recommend learning more about distributed systems also, you can't really lift a monolith into a Microservice architecture without doing a big paradigm shift...
Related
I started reading microservices architecture and got confused with one below point.
Each service should have a separate database.
Does each service mean a single web(rest) api having its own database?
For example if I take motor insurance claim operation as a business scenario where I modelled business domain services in 3 part Insurance claim services , partner (automobile service providers) services and customer services.
Insurance claim settlement operation in claim api will require other information like incident , survey done by an inspector, policy detail , documents etc.
Now I can create 5 web(rest) api in Insurance claim services and will store its data in common db and other services like partner and customer service will have their own web apis and db
What is correct ?
All web api (claimAPI, PolicyAPI, IncidentAPI, SurveyAPI and DocumentAPI) in claim insurance services should have their own db or they can keep data in single data base ?
Thanks.
To follow microservice best practice, it is correct that they should each have their own database and be exposed solely by APIs. This is because every service in your architecture should be independent and de-coupled from other services. If 2+ services share a database, then there may arise problems in operation or upgrade.
One big issue with a shared database is each service would need to trust that another service doesn't modify it's information. But since they all have access to the same database, one of the others could in fact modify the underlying data and make things unstable or insecure.
Further, with 2+ services relying on a shared database, then you're forced to use the exact same database/version with all. You lose the freedom to independently use MySQL for one and MongoDB for another. Even if the same tool is used for all, when you do maintenance or migration on one you're forced to do it for the rest. All this adds up to some coupled services that make them harder to maintain and scale.
you can have common database for all microservices, it is one of the microservices patterns:
https://microservices.io/patterns/data/shared-database.html
https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-data-persistence/shared-database.html
check those links to see advantages and disadvantages of this approach.
I am new to microservices and trying to break up a big monolithic application into microservices. While scoping the microservice I am unable to decide whether I should go for a data duplication between services or ignore SRP by clubbing all requiring the same data into 1 service. Following is the scenario.
I have a service which receives Customer order say build a car with these parts and features. Now I have other 2 functionalities which uses the Parts and features to derive some runtime value say ;
If the order contains part A and Feature A then perform X operation. As each of these functionalities have there respective UI for configuration and runtime engine to derive the output and most of the time changes only comes in these respective function blocks, I thought of creating the separate microservices.
Creating the separate microservice would need data(Parts and Features) to be duplicated. Another option could be given each of these service uses the same data is clubbing all of them into 1, but with that I again create a big service which if goes down will stop all 3 functionalities and is against SRP. Another option could be when the data is required by the other 2 services make a call and get it from Order Service, but that is making it highly dependent and getting the data over network for each operation.
Can anyone suggest what would be ideal to do in such case.
Microservice should communicate via events using publisher/subscriber model and topics. See the tri-lateral design pattern. In a pub/sub system the producer writes the event to the topic and a broker makes it available to each subscriber, aka microservice. This is one advantage of eventing, one producer, and many consumers.
Order A has a BOM that expresses parts and features an order represents. When the order is placed, other services need that information such as the feature/part microservice and UI components and their respective datastores. For example, define two topics parts-ordered and features-ordered.
The order microservice writes to the parts and features topics respectively. The feature, parts, and UX microservices read and act upon those events.
You need to make a choice about your system of record. You can write to an orders DB before publishing the events, or let the pub/sub it. In your example, it sounds like you are talking about three different tables; order, parts, and events. That decomposes cleaning into the microservices you describe where each maintains the data it is responsible for. I'd be inclined to just use the pub/sub as your audit trail.
If you are writing in Go we have blueprints for the most common design patterns.
First, you mentioned that you are trying to convert the monolithic application into microservices. You can create/caters the microservices on basis of domain data, we can be called it domain-driven architecture.
Suppose you have the business functionality for customer data, customer order, customer order handling, and customer payment. And currently, it's part of a monolithic application. So you can create the subdomain for each functionality like Customer domain, Order domain, order handle domain, and payment domain respectively. Each domain contains several microservices depends on the business requirement.
For e.g you can check the Amazon website, In personal/customer data, you see the customer name, phone number, address, billing account information, delivery address type(office/home). In this case the under customer domain, there will be 3 microservices required(It totally depends on your domain design). One for customer(handles customer name, phone number, reference of Billing account id, reference of address id), second for Billing account(Billing account number, billing account information, reference if customer id), third for Address data(customer office address, preferable address). And for each microservice, there will be a dedicated database/buckets, Only that microservice can change/add the data. If any other microservice wants to add/update/get data, it needs to be get by calling that microservices HTTP endpoint over the network.
Updating the data in other microservice::
Now coming to your question about data duplication, Let's consider the above example.
If Customer microservice wants to store/ cache the billing account data for some purpose, that microservice can store that data in the database but again Customer microservice needs to make sure that, the current data of the billing account is always real one and not the old one. For this customer, microservice needs to listen to the event whenever there is update in billing account data, so old data in billing account gets purged and customer microservice always has the latest data of billing.
you can read here about event driven architecture.
https://en.wikipedia.org/wiki/Event-driven_architecture#:~:text=Event%2Ddriven%20architecture%20(EDA),sale%22%20to%20%22sold%22.
You can read more about this at the below links about Domain driven design.
https://www.thoughtworks.com/insights/blog/domain-driven-design-services-architecture
https://en.wikipedia.org/wiki/Domain-driven_design
This is my free book :)
https://github.com/vaquarkhan/microservices-recipes-a-free-gitbook
If you want to create microservice then need to follow microservice guideline.
Now come to real world :) really difficult to meet all microservice requirements as database has own licensing cost etc. so you can choose pragmatic microservices. You can get started with them faster and pick and choose the pieces that make sense for your team.
Design Domain driven design oriented microservice : DDD talks about problems as domains. It describes independent problem areas as Bounded Contexts and each Bounded Context correlates to a microservice.
Where to draw the boundaries is the key task when designing and defining a microservice.
DDD patterns help you understand the complexity in the domain, the domain model for each Bounded Context, you identify and define the entities, value objects, and aggregates that model your domain. You build and refine a domain model that is contained within a boundary that defines your context. And that is explicit in the form of a microservice. The components within those boundaries end up being your microservices.
https://martinfowler.com/bliki/AnemicDomainModel.html
https://github.com/vaquarkhan/Domain-driven-design
https://github.com/vaquarkhan/ddd-by-examples.github.io/blob/master/ddd-factory.pdf
Now you can create layers on top of you microservice and build complex logic using orchestration and choreography.
Example :
Gateway Customer order Application layer microservice --domain model layer microservice infrastructure layer
There are various ways to decompose an application into services.
1.Decompose by business capability
2.Decompose by subdomain
And there are various ways for data management also
SAGA
API Composition
Database per service
Please go through with the link for more details click
we have a big distributed and multitenant system with all sorts of accounts :
- admin and backoffice users account
- customer account
- cashier account (tenant : there is one or many more cashier for each client tenant)
All this account are sharing more or less the same lifecycle (account created, grant on some ressources, deny account, password reminder...)
But they are not used in all applications of the system : some account would be used on specific or just two application for example.
Furthermore our system should have the possibility to have a bridge with a CMS for the customer management, or the backoffice users account could be authorized one day against a ldap...
So the question : we are searching for the best way to model our right and authorization service(s).
One idea is to create one service in order to manage all types of accounts of any kind : that is a SOA way to modularize our system
And one idea is to create different services : perhaps much more a micro-service oriented way of thinking...
What are your opinion ? I am searching some advices and feedback on this two different approach or perhaps an alternative that we habve not thought about...
If you are looking for any open-source solution for your problem, you can have a look into keyclaok.
Keycloak also got place in Thoughtworks Technology RADAR.
It is very promising solution and has LDAP, Multi Tenancy support also. checkout keycloak features.
There is paid solution like ForgeRock is also avaible.
Coming to feedback which you have asked about SOA or microservice way of implementation here (You will get different feedback/advice on this)
It will be better if you have a service to take care of access and authorization management and other to look into user details. If you meant that having different services for different account then note that Having one service for taking care account is still considered as Microservice approach as there is one dedicated service to perform single set of tasks.
You can have User-Service for user information management and a authService to handle access and authorization of users. check.
I'm managing a very large enterprise application in that I've implemented microservice architecture. Standalone microservices have been created based on business entities & operations.
For example,
User Operations Service
Product Operations Service
Finance Operations Service
Please note that each service implemented using an n-tier architecture with WCF. i.e have separate tiers(which is independently deployable to separate server) for business and data access.
There is a centralized database which is accessed by all the microservices. There are a couple of common entities like 'user' accessed by all the services, so we have redundant database calls in multiple services. More efforts required due to database access from many places(i.e a column rename requires deployment of all the apps)
To reduce & optimize code, I'm planning to create separate microservice and move all the database operations into it. i.e services can call "Database Operations Service" for any database operations like add/update/select.
I want to know if there are any hidden challenges that I'm not aware of. Whether should I go with this thought? What can I consider as improvements in this concept?
I'm planning to create separate microservice and move all the database operations into it
That's how you will lose all benefits from microservice architecture. One service is down — the whole application is down. Unless you have replication on several nodes.
If your app does not work if one service went down(not implying that it's that service that connects to database), then it's still bad architecture and you are not using benefits of microservice architecture.
Correct for of communication would be if service would have their own databases. Or at least that every service that wants, for example, entity User, will not fetch it from DB, but will fetch it from appropriate service. And that appropriate service could fetch it from common DB at the beginning.
Next step (improvement) in the process of accommodation to microservice architecture would be creation of separate databases for each service. And by “separate” I mean that temporal fault of one service or temporal fault of one database will allow the rest of the app to be alive and functioning.
Generally, there are no hidden challenges in your approach. It just does not give any benefits, as an intermediate form between monolith application and microservice-based.
I've been triying to migrate part of our soa architecture (Mule ESB) to microservices (Spring Boot stack), but I'm facing a problem related to large flows where we have several orchestations.
Basically We a have a flow which has an user id as input and the response is compounded of user account, creditcards data, stocks and loans.
In this flow we have, at the beginning, a splitter (allows to send concurrent requests) and we send requests to account backend, 3 different credicard partners, stock partner and loans partner, at the end there is an agregattor (wait to all responses and merge all of them) and finally a node for prepare the response (apply business logic).
During the migration we have developed an account microservice, loan microservice, stock microservie and creditcard microservices (1 for each partner). The problem here is the orchestation, We can't use and event model approach because we need to get all responses in a certain point. We considered the choreography approach too, but we don't want to add logic related ot how orchestrate calls to our microservices because that would be a stepback to heavy coupled services (N*N connections).
We are thinking on make a new microservice that will be used as an orchestrator, but we don't know if this will be a good solution for microservices concepts.
Note: The front end can't make the orchestrations because it is a closed product and we can't touch it.
Thanks in advance.
We are thinking on make a new microservice that will be used as an orchestrator, but we don't know if this will be a good solution for microservices concepts.
From all you described that sounds like the most reasonable thing to do. You describe this service as having its own business purpose which indicates to me the potential need for a dedicated service. And the fact that it requires input from other (more basic) services would not be unusual for a complex domain service. Also you already listed the alternative of aggregating on the front end as something that doesn't work in your domain.
Something to consider is just making sure that the development teams for the basic services treat their APIs as customer facing (with the customer being your other services). That means they have to do clean work in terms of versioning/deprecating/etc.
And the downstream services need to treat the consumed APIs like they would a 3rd party API. For example Google went so far to allow internal service consumption be charged real money to incentivize optimizing the implementation of dependent services.