Should Each Microservice Have Its Own Database? by Dmitry Belyaev

[@glebbondarenko67]

I won't say that I disagree with the idea. Then we should think about how to deploy 2 services that share a database layer. Having monorepo with shareable code can give you a false sense that all services already applied a new schema, but it's not true, and it becomes dangerous if you make breaking changes. So the next statement that I can challenge is `model duplication is always bad` :)

[@upgradeplans777]

The summarizing point "Database belongs to a business domain (bounded context) not to a microservice" is the one point that I think is not good advice, while I agree with the rest. The problem is that a bounded context is a logical construct ( @1:45 ), but a database necessarily needs to be physically deployed. This means that a database can never span more than one microservice. Otherwise, multiple database-using-microservices are no longer independently deployable from each other. It is of course possible to promote the database to be its own microservice. Microservices don't imply anything about the technical protocol used for communication between them, so the database protocol plus the data definition can itself be a perfectly sensible boundary-protocol between the services. If this is handled correctly, then the database becomes independently deployable, and guarantees backwards compatability with all currently deployed clients. This brings technical chalenges of its own, depending on the technologies used and the structures of teams, but it can indeed also solve some technical chalenges, which I think was the main point of the talk.

[@dmitrybelyaev4244]

Thanks for a good comment. It touches on an aspect which I unfortunately didn't manage to cover in the talk due to limited time. If we use a mono repo per bounded context and this repo follows the App Continuum project structure we'll most probably end up deploying all microservices of this bounded context together. An alternative is to build a pretty complex build and deployment script which will analyze what shared components are used by what microservices (applications in the App Continuum terminology) and build/deploy only ones which are affected by committed changes. As I mentioned close to the end of the talk, the proposed solution is similar to the straightforward one in which we put all logic of one bounded context in one microservice connected to one database. The difference is that following some technical reasons we split one bounded context into multiple microservices and convert a single-module project into a multi-module project which provides better support for our use case. Straightforward solution: bounded context BC implemented as microservice MS connected to database DB Proposed solution: bounded context BC implemented as microservices MS1, MS2, ..., MSN connected to database DB

[@upgradeplans777]

​@@dmitrybelyaev4244 This confuses me a bit about the definition of a microservice. To me, independent deployability is the core of what makes any piece of code a microservice. The way you described it @2:30 with "multiple deployable units" seemingly refers to the same thing, but not entirely? That said, I see nothing wrong with deploying multiple executables together, that can be a technical solution for specific technical reasons. Just that I would consider the executables that are deployed together to form one (possibly distributed) microservice, not multiple. Which has a number of implications, for example, that deployed together means integration-tested together. (Ideally with CI/CD.) If the database does not guarantee backwards compatibility to its clients, then the interaction between those clients must be validated as a whole. On the other hand, independently deployable microservices can be tested for their adherence to a backwards compatible API, which also guarantees a validated state of the project as a whole, but in a different way.

[@dmitrybelyaev4244]

@@upgradeplans777 I think I understood the reason for the confusion, it's my wording. Certainly all these microservices will be separated executables and they will be deployed separately and can be scaled separately. But, because they all live in the same mono repo, a trigger for a new build/deployment (think CI/CD) is a commit in this repository. And, because any of shared components potentially can be used by multiple microservices, it is difficult to say which microservice(s) exactly should be built and deployed. That is the reason why the whole mono repo is built and deployed in this case. All microservices are deployed, not at exactly the same time but very close in time. This is actually one of the downsides of this approach. Even if a certain change touches only one microservice all of them are built and deployed. But, keep in mind, I'm talking about a set of microservices covering exactly one bounded context (business domain). You can think about it as the whole bounded context is built and deployed, even though it results in building and deploying multiple microservices. Now about a database: the database is a part of the mono repo and is deployed/upgraded together with all microservices. My recommendation is to use a blue-green or a canary or any other type of deployment which supports uninterruptible operation of the software. In this case any changes in the database must be backward compatible because for some time old and new versions of your components will access the same database. Another decision to make is whether database migration is a part of a start-up procedure of a microservice or a process on its own. In short, the former is good for a quick start but error-prone, the latter requires some effort but is more robust. This is a completely different topic though. Might be a good one for a quickie talk at the next year's Devoxx. 😀

[@semenivanoff8615]

It is the case when DBs created and maintained with ORM. When DDL is used there are no such issues. Well no coding sugar in this case, but that is a minor loss

[@andyvandenberghe6364]

that is a good point. a database should be bound to its context, the technical interpretation can be divided into several micro services.

[@RonaldTetsuoMiura]

They're not multiple microservices, it's a micro-distributed-monolith. And that's ok. Microservice != container.

[@RiccardoPasquini]

The difference between bounded context and microservice pushes me behind several years... Sort of SOA

[@sergeykichuk2586]

In first example the job “microservice” it is not microservice it is just a service, first because it is not independent and the second is not a separate from the bounded context! Author forgot that the main idea of microservice is to be independently deployable units!

[@tobyzieglerrr]

That was a very good talk, enjoyed it very much and a crucial point was very well presented (use APIs to access the "db owning" service). I have mixed feelings and experience with the monorepo approach. It sounds good, it has some benefits. But still, in reality it mixes concerns (deployment and code sharing) imho. I have seen it being misused to "share" common configurations of services and a lot of other weird stuff. Then the discussion about build times and instant feedback which leads to a lot of effort going into differential build complexity. There is no such thing as a free lunch... or: it depends 🙂

[@shailabsingh7612]

awesome i feel blessed with this channel and this is a perfect use case of all i needed.

[@minor12828]

Micros34vic3s is about teams not about deplorable units. It was said by himself who coined the term. Individual operable teams even in budget terms.

[@matheusmarabesi]

to the point scenarios and examples, thanks for that! I just found out that usually developers push back when monorepo is suggested, any recommendations to improve that?

[@balazsklezli5702]

Interesting talk, thanks for sharing it!

[@dmitrybelyaev4244]

A slightly extended version of this talk is available on Medium

[@berndeckenfels]

Same project suture works for single- and distributed moduliths as well.

[@mohammedabulsoud1819]

Gracias 🙏

[@asebeshuk]

I know him 😁