2

Today I come with this question probably to someone who has large experience in this.

Basically what the title indicates. We have that app and we have to migrate it to microservices.

We didn't find any solid approach (or we felt it like that) about this. What we ended up doing is creating 1 project per microservice (a single functionality related to a module app, in general) but then we had some problems because we already had a database to work with since this is already a functioning app. We had problems communicating with the existing models, so basically what we did was to point in every settings.py of the projects to the existing DB, and with python3 manage.py inspectdb, we grabbed the existing models. This approach ended up working, but we feel that is not the best approach. We had a lot of problems with circular imports and more.

Is out there good practices about microservices with Django, and how to properly do it, like in most of the cases that we want to create something with the framework?

If someone knows or has something we would really appreciate it!

elece
  • 21
  • 1
  • 1

1 Answers1

0

you can use Django for Microservices. in this case you have only one few apps, and you start every service on own port:

first Django project

pdf generator + views generate small pdf

second Django project.

pdf generator + views generate big pdf (code can inherit other project)

orchestra:

third Django project: Autorization + call big or small pdf generator service

settings

settings.py for first and second is very easy and allows only call from internal ip's. here we don't need middleaware, template, cache, admin and other settings.

settings.py for orchestra is also very easy and used only auth and made call by internal ip ant send response to user. Here we don't need much middlaware, and don't need many other settings.

gains:

  1. All is independent. if one server fall, other can work.
  2. Updates are easy. One small server update is always easy than monolith update.
  3. development is easy: three small teams works on own small projects.
  4. Units testing is easy and fast
  5. For complex business goals the whole system is faster.

pains:

  1. after 100 micro-services it is completely complex to work with that all.
  2. code style from many teams is always different. Don't matter how strict you define styleguide or settings for black-linter.
  3. integrate Testing is difficult - If something not work, it is hard to find where.
  4. Ecosystem Auth/services/messaging is really complex
  5. For easy business goals the whole system is overcomplicated.

summary

Don't matter how much DB you want to use. it can be monolith or many services.

i don't see any problem to import in one Microservice something from other project: it can be model / admin or other staff. it works. probably you need to smart split monolith, but it also easy, for that we have a many experience (my own and in internet or books)

Maxim Danilov
  • 2,472
  • 1
  • 3
  • 8