Re: Django + microservices: What's correct approach?

Hi Crohn.

You're asking a lot of related but very general questions here. I know
you are looking for someone who has "had the same problem" but we
don't know what your problem is. The whole point of any architecture
is that it's supposed to be a solution to your problems, not a problem
in itself :) If you tell us what you are trying to create (roughly
from the perspective of your users) and why you want to solve that
problem with microservices and Django, there may be sensible advice
people on the list can offer. Anyone who offers you architectural
advice before knowing what your system actually does is usually
selling something.

Many of the resources you'll need to learn about architecture and
about Django implementations will have been published before 2014, and
hence won't contain the word "microservices".

To address specific things you've asked (none of which are specific to
microservice architectures):

1. REST
Django is a HTTP application framework, and you can obviously use any
approach that HTTP supports, including REST. RESTful or RPC-like
services using JSON as a serialisation format are common.
Django-rest-framework is obviously geared towards REST :)

2. Deployment
The built-in runserver is only appropriate for development, and
certainly not for a services based approach. The normal way to deploy
django applications is with a WSGI server such as uwsgi or gunicorn.
These are typically run behind a reverse proxy or load balancer. If
you are planning to deploy many services, it's worth automating this
process as much as possible. There's good recommendations on how to
deploy Django for production in the docs:
https://docs.djangoproject.com/en/1.8/howto/deployment/

3. Performance analysis
Performance analysis of communicating services can be tricky. To
master it you'll need a grasp of distributed systems and queuing
theory and this will take a lot of reading, maths and experimentation.
There are books and software that can help you with this such as PPA:
http://www.perfdynamics.com/iBook/ppa.html

4. Async
Django is not designed to be an asynchronous server. Async webapps are
usually more complex than synchronous ones. You may be better off
either:
a) using one of the queueing systems for Django
https://www.djangopackages.com/grids/g/workers-queues-tasks/
b) using things like asyncio, gevent or twisted if you are *sure*
you need them.

I hope this is a helpful response, and good luck with your project!


On 25 August 2015 at 08:42, cr0hn <cr0hn@cr0hn.com> wrote:
> Thank you for your responses.
>
> I try to find some guide to create micro-services architecture using Django.
> I know that micro-service is a design paradigm, so I'm looking for the best
> way to implement it using Django (+ django-rest-framework).
>
> I also know that there're not a unique response, but I would like to answer
> questions like that:
> Create a Django project for each micro-service or all using the same
> project?
>
> Micro-services must communicate themselves using the same REST API, some way
> for better approach?
> How to deploy the project: Running "python manage.py runserver" or something
> like "python manage.py start MY_MICROSERVICE"?
> How to communicate the services for reduce response time and using async
> way?
>
> I know how to implement all of things above, but I'm looking for some
> recommendation of someone who have had the same problem or who has created
> micro-services with django.
>
> I hope I explained better now :)
>
> Regards.
>
>
> El lunes, 24 de agosto de 2015, 17:59:01 (UTC+2), Tom Christie escribió:
>>
>> Django REST framework is a general purpose API toolkit, and more than
>> capable of building microservice-type services. Likewise there are plenty of
>> frameworks in alternative languages that are also suitable for building APIs
>> that could be characterized as 'microservice'.
>>
>> The reason you're finding it hard to discover much on the subject is
>> probably due to microservices being an architectural style, rather than a
>> framework choice.
>>
>> Are there any *specific* technical issues that you're looking for help
>> with? What sort of service are you building, and is this for a Web App
>> frontend, a native client, both or something else?
>>
>> Aside: Unless you've got automated deployments nailed, great monitoring, a
>> heavily used service with a really nicely designed separation of concerns,
>> and a culture of personal responsibility for the engineers taking
>> code-to-deployment then the microservices probably (as a super-rough rule of
>> thumb) isn't worth the extra up-front infrastructure it requires.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscribe@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/ceefe6b9-ab71-405c-abae-dc09ed3f695f%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



--
steve
http://stevemcconville.com/

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAOoCU%3DTR0T3_toYVRkocWgBCTp5mQqGrYr-z-76Bv6ujxByMZA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.