0
votes

I am a newbie to Docker & microservices, and trying to breakdown current monolithic services into smaller microservices using Docker containers. Idea is to logically divide monoliths into smaller independent modules as microservices and place each into separate Docker containers and manage it via Kubernetes for scaling.

Caveat is these services are either connected to third parties via REST or to mission critical voluminous databases. These dont have any local DB with them so i can't have any local microservice DB in bounded context.

I am trying to figure out best approach for refactoring

  • One approach i am thinking is to place DB connection code into separate container and call it from other containers.

  • Similarly place third party REST integration logic in a single container and call it from other containers.

Questions:

  1. Can i have a microservice without a database attached to it?
  2. Can i have containerized code as mentioned above and still be qualified for microservice?
  3. Can a microservice be used barely for integration?
  4. Does using docker containers qualify for this scenario?
2
In my opinion you should break down the voluminous database into logically separate parts and each part should have a rest service corresponding to it - Anuj Mehta
Not viable. Backend is enterprise data lake and any change is not plausible. - Finn

2 Answers

0
votes

It all depends what you are trying to achieve. Microservices is design constraint with no single right answer. The idea is to create loosely coupled services which can be updated , scaled and deployed independently without affecting any other services.

Now evaluate all the things above and see if you can do this all and achieve devops. yes you can have microservice without database and yes it can talk to external api as long as it's independent in its operations. in your case it's more of refactoring than microservices. e.g. integration microservices/container is not a good idea. All your services will be dependent on it and this is single point of failure.

If you really want to turn monolithic in microservices then do it right way from start. create individual services that can be operated separately, all dependencies, integration and external calls should only belong to individual service even if you have to duplicate same call in other services. Database is very important piece and since you may have central database means if it goes down your services are unavailable and again single point of failure. one approach is to create local database with each service and sync back with external database if your business operations allow it.

Just evaluate all the scenarios and see how can you make independent services. Hope that helps.

0
votes

when talking about architectures, there is not any one best solution, it always depends upon what you are doing or want to achieve. But i may be able to answer a few questions.

Microservice is a concept to divide services into small parts either horizontally or vertically so, Yes microservice can be without database attached to it.

You can have containerized code and qualified for microservices as it is good practice to containerize all micorservices.

  • I think you should split services logically and so database for each microservice should be with it, rather than calling other service for database as it will only increase cost nothing other benefit.
  • Connect microservices with each other either directly or by using RabbitMQ, it will be better i think.
  • Create one single extra service which will use third party REST services & also expose REST services if required.

Again, These are just suggestions, there is not perfect way to develop microservices so try what suits you best.