1

Topic: Microservices and databases.

Hello. A question: whether correctly I understand that in case of microservices it is desirable, or even it is necessary, that each service had a database. Or it is possible to have a heap of services which will rummage any one , demarcation under circuits or tables? It seemed to me that microservices are an insulation on a functional, instead of by data. In advance I thank.

2

Re: Microservices and databases.

Hello, Sharov, you wrote: S> Hello. S> a question: whether correctly I understand that in case of microservices it is desirable, or even it is necessary, that each service had a database. S> or it is possible to have a heap of services which will rummage any one , demarcation under circuits or tables? S> it seemed to me that microservices are an insulation on a functional, instead of by data. S> in advance I thank. Microservices are ESPECIALLY insulation by data. About the general basis still Fowler wrote: https://martinfowler.com/bliki/IntegrationDatabase.html the Sense of microservice is the insulated essence bringing business favor in itself. With the general basis there are dependences, single point of failure, God forbid  between the data of different microservices and put out the light. It is possible to use the general physical DB, why is not present. The main thing - that microservices had no data access each other.

3

Re: Microservices and databases.

Hello, scf, you wrote: scf> it is possible to use the General physical DB, why is not present. The main thing - that microservices had no data access each other. Here it here the extremely interesting piece if it is fair. Because here interests of productivity and consistency are included into the explicit contradiction with interests of independent development. I met such systems, but there it is amusing that frequently their development encounters exactly the same restrictions. Roughly speaking, the information on submission is stored in basis Human Resources, and the information on sales - in basis Sales. When the manual suddenly wants to compare performance of the same manager on sales by its operation under the direction of different principals we come across that the data cannot be pulled out in any way. Server-side join it is impracticable, since microservices, and client-side join occupies all time before galaxy cooling. But, if we once want, we can easily replace HR-system. Instead of PeopleSoft at us becomes Workday, and all integrations will be saved. Aha-aha. Therefore, to solve this fundamental problem, we offer.... Data Warehouse!! ! That is we reversely collect now all data in separate expensive service, and but we have an opportunity to derive them on the move.

4

Re: Microservices and databases.

Hello, Sinclair, you wrote: S> Hello, scf, you wrote: S> Therefore to solve this fundamental problem, we offer.... Data Warehouse!! ! S> That is we reversely collect now all data in separate expensive service, and but we have an opportunity to derive them on the move. Well so that yes. Current operation and formation of reports is 2 different tasks. Even in classical RDBMS is OLTP, and is OLAP and there was this sharing for long before microservices.

5

Re: Microservices and databases.

Hello, Sinclair, you wrote: S> Hello, scf, you wrote: scf>> it is possible to use the General physical DB, why is not present. The main thing - that microservices had no data access each other. S> here it here the extremely interesting piece if it is fair. S> because here interests of productivity and consistency are included into the explicit contradiction with interests of independent development. S> I met such systems, but there it is amusing that frequently their development encounters exactly the same restrictions. S> roughly speaking, the information on submission is stored in basis Human Resources, and the information on sales - in basis Sales. S> When the manual suddenly wants to compare performance of the same manager on sales by its operation under the direction of different principals we come across that the data cannot be pulled out in any way. Server-side join it is impracticable, since microservices, and client-side join occupies all time before galaxy cooling. S> But if we once want we can easily replace HR-system. Instead of PeopleSoft at us becomes Workday, and all integrations will be saved. Aha-aha. S> Therefore to solve this fundamental problem, we offer.... Data Warehouse!! ! S> That is we reversely collect now all data in separate expensive service, and but we have an opportunity to derive them on the move. There is one basic difference - DWH is principal data source (source of truth), and in the environment of microservices by a principal source microservices are. I.e. historicity is not necessary,  is not necessary, reliability is not necessary. Therefore it is possible to use alternative methods - qlikview or  a DBMS with  (Kassandra, ES, solr)

6

Re: Microservices and databases.

Hello, Sharov, you wrote: S> Hello. S> a question: whether correctly I understand that in case of microservices it is desirable, or even it is necessary, that each service had a database. S> or it is possible to have a heap of services which will rummage any one , demarcation under circuits or tables? S> it seemed to me that microservices are an insulation on a functional, instead of by data. Microservices are a restriction first of all on . And from this logically follows that if microservices rummage basis independent  microservice it it turns out basically. But whether it is exact to you microservices are necessary?

7

Re: Microservices and databases.

Hello, Sinclair, you wrote: S> Because here interests of productivity and consistency are included into the explicit contradiction with interests of independent development. Indeed, with it it is necessary to live, if went towards microservices. S> I met such systems, but there it is amusing that frequently their development encounters exactly the same restrictions. S> roughly speaking, the information on submission is stored in basis Human Resources, and the information on sales - in basis Sales. S> When the manual suddenly wants to compare performance of the same manager on sales by its operation under the direction of different principals we come across that the data cannot be pulled out in any way. Server-side join it is impracticable, since microservices, and client-side join occupies all time before galaxy cooling. Therefore the competent partition of system on microservices uneasy also demands experience and deep understanding of data domain, including understanding where the system will develop throughout many years. Was specific in this case, here so to unwinding, it is possible to get one more microservice which will store history and to be used only for this request. And the data yes to double. There you still eventual consistency expects, prepare, any ACID

8

Re: Microservices and databases.

Hello, itslave, you wrote: I> Microservices are a restriction first of all on . And from this logically follows that if microservices rummage basis independent  microservice it it turns out basically. What restrictions on , all the I carry with myself? At first, obviously,  basis, further services. What not so? I> But whether it is exact to you microservices are necessary? Services where everyone is engaged in any functionality are necessary, thus, probably, there will be a general basis. Always it seemed to me (I this question never explicitly studied) that microservices are an insulation on functionality, i.e. each service does something one. Above prompted that it is insulation by data that in effect same.

9

Re: Microservices and databases.

Hello, Sharov, you wrote: S> Hello, itslave, you wrote: I>> Microservices are a restriction first of all on . And from this logically follows that if microservices rummage basis independent  microservice it it turns out basically. S> what restrictions on , all the I carry with myself? At first, obviously,  basis, further services. What not so? Microservice is the full separate project, with the command, the  and .  - it is true, all the I carry with myself. 2 microservices cannot rummage basis because one of them can roll an update of the circuit and break operation of another.  bases,  etc. Completely breaks the concept.

10

Re: Microservices and databases.

Hello, itslave, you wrote: I> Microservice is the full separate project, with the command, the  and .  - it is true, all the I carry with myself. 2 microservices cannot rummage basis because one of them can roll an update of the circuit and break operation of another.  bases,  etc. Completely breaks the concept. In what a problem to have physically one , and different circuits, with the access rights for each service?

11

Re: Microservices and databases.

Hello, Sharov, you wrote: S> In what a problem to have physically one , and different circuits, with the access rights for each service? So it is possible, but in this case the data model that is rummaged will not be and consequently from the logical point of view is 2 different bases