halkyonio / operator

Kubernetes Operator simplifying the development of microservices on k8s !
Apache License 2.0
41 stars 14 forks source link

Shared capability #74

Open cmoulliard opened 5 years ago

cmoulliard commented 5 years ago

Use case - shared capability

A use case that we haven't yet discussed and that we must consider is about "shared database, capability" where one or several microservices will use the same DB's instance (= capability), JMS/AMQP Broker, ....

If we use what we have designed for the moment, then that will fail or could create conflicts as each module (e.g fruit-backend-1, fruit-backend-2, ....) will contain a capability generated by ap4k to use/the same database and when the operator will get it, then it will try to create another PostgresDB instance.

We could enhance the logic of the operator to avoid to create again a database if by example the Capability CRD use the same name but I think that it could better when such a situation exists that we document/tell to the developer that a separate maven/gradle project should be created and includes a configuration property file to describe such needed capabilities. See this example [1]

Of course, this logic could become the standard too for microservices consuming only one DB, one broker, ... without shared database.

The "configuration property file" could be generated/managed by the kreate tool, ap4k,....

WDYT ? @aureamunoz @metacosm @iocanel @geoand @gytis @nainaz @tqvarnst

[1] https://github.com/snowdrop/component-operator-demo/blob/master/fruit-configuration/application.yml

geoand commented 5 years ago

I don't think that the use case for a shared database would come up too often in a microservices world, however the use case for a shared mesage broker is certainly very very common

cmoulliard commented 5 years ago

I don't think that the use case for a shared database would come up too often in a microservices world

I don't think so. Even if we want to promote the idea of the pattern CQRS and the Debezium project, a shared database where each microservices will manage perhaps different tables or use records published by other microservices is completely relevant till solutions have evolved to adopt an event streamed database and kafka topology

geoand commented 5 years ago

Not saying that the pattern doesn't exist, but what I have seen sharing a database is rather uncommon. All microserves however will share Kafka or RabbitMQ :)

nainaz commented 5 years ago

On Fri, Jun 28, 2019 at 11:45 AM Georgios Andrianakis < notifications@github.com> wrote:

Not saying that the pattern doesn't exist, but what I have seen sharing a database is rather uncommon. All microserves however will share Kafka or RabbitMQ :)

This use case is still worth exploring though. Shared Database, All micro-services are not micro-services in the strickt sense of separate DB. it is modular monolith :)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/snowdrop/component-operator/issues/74?email_source=notifications&email_token=AISZCFEDC5Y766XQYW3MICDP4YWXFA5CNFSM4H4F4PDKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY2N6LY#issuecomment-506781487, or mute the thread https://github.com/notifications/unsubscribe-auth/AISZCFCVTTX2BHQN5LCKCVLP4YWXFANCNFSM4H4F4PDA .

--

Best,

Naina Singh

Senior Product Manager

naina.s@redhat.com +19194506323

@madhatter_ns https://www.redhat.com/