Doesn't Django already encourage this type of design? Each Django project is composed of several installed 'apps'. Each app should be portable enough that it could be the only app in any project.
Why we ditched Django for Microservices
11–20 of 85 posts
Re: Why we ditched Django for Microservices
#12Doesn't Django already encourage this type of design? Each Django project is composed of several installed 'apps'. Each app should be portable enough that it could be the only app in any project.
I have a large app in Django at my work. The thing is it doesn't make sense to split this into smaller apps (except for the shopping cart equivalent). It tracks the workflow of our organization, so all queries need to be related from the very start to the very end of the process. (Ok, not all queries, but a lot of them).
Re: Why we ditched Django for Microservices
#13> Having been a dev team of 1 for a long time I'd never experienced the headache of installing all the dependencies required by our Django system. It never really occurred to me that as I installed more packages, it was becoming incrementally larger and more complicated for new team members. Because of this, the monolithic Django system was already proving a headache to get quickly set up, running and understood by our new hires. Splitting it up into more digestible chunks (services) therefore should allow us to scale the team a lot quicker this year and beyond.
Yet, the dynamic language community constantly laughs at Java developers and their high overhead dependency management solutions, which just happen to have these kinds of problems solved since more than a decade.
Pathetic.
Re: Why we ditched Django for Microservices
#14Doesn't Django already encourage this type of design? Each Django project is composed of several installed 'apps'. Each app should be portable enough that it could be the only app in any project.
True, but all these installed apps still increase the size of your one project which becomes larger and larger. You can't install it in parts, you can't make any architectural or language changes as it requires a rewrite of the whole project and each new release/ deploy effects the entire codebase.
Microservices doesn't fix everything and you're right about Django encouraging this type of design. Each approach has it's pros and cons.
Re: Why we ditched Django for Microservices
#15> Having been a dev team of 1 for a long time I'd never experienced the headache of installing all the dependencies required by our Django system. It never really occurred to me that as I installed more packages, it was becoming incrementally larger and more complicated for new team members. Because of this, the monolithic Django system was already proving a headache to get quickly set up, running and understood by o…
I don't believe he's talking about code dependencies but rather things like LDAP, mySQL, MongoDB, etc which Java dependency management tools don't solve either. Managing code dependencies is solved in Python (as it is in most dynamic languages) using pip and virtual environments.
Re: Why we ditched Django for Microservices
#16> A microservices architecture is (fairly) new and it doesn't tie you to a particular language. If you want to build a service in Lisp, Go, Elixir, etc then you can (assuming it makes sense). Good devs love to learn, experiment and hate being bored. A microservices approach encourages all of that The developer in me kind of likes that - fun new toys! But from a business point of view, I'm not sure it sounds like such…
[deleted]
Re: Why we ditched Django for Microservices
#17> We don't worry too much about code quality as I believe that that is fixed at the recruitment level. Good people write good code and, more importantly, ship good products. Good people make mistakes too. Having good tools to ensure code quality doesn't make it impossible to ship bad products, but it's definitely important.
Not worrying too much doesn't mean not worrying at all! We still have tools in place to ensure silly mistakes aren't made or are at least rectified quickly. Just we don't expect 100% test coverage on every single feature or fix we ship.
This approach will probably change as we get larger but being a small development team means that it is fine for now.
Re: Why we ditched Django for Microservices
#18make sure to document well. When you're scaling up a team and moving from a coupled code base to independent codebases a good amount of assumption happens, especially around how mature each codebase is.
Re: Why we ditched Django for Microservices
#19> A microservices architecture is (fairly) new and it doesn't tie you to a particular language. If you want to build a service in Lisp, Go, Elixir, etc then you can (assuming it makes sense). Good devs love to learn, experiment and hate being bored. A microservices approach encourages all of that The developer in me kind of likes that - fun new toys! But from a business point of view, I'm not sure it sounds like such…
And of course, ignoring the problem of duct-taping all the services together. "Oh we'll just RabbitMQ everything together", sure, great, until you discovered certain services needed a smaller latency, more bandwidth, etc And RabbitMQ libraries are a pain and are not smart
Upvoted.
Tried RabbitMQ, had huge issues that standard library barely functioning. Running direct code samples from support failed, finally supporting dev confessed, "I don't know java and the java guy is busy."
I was forced to move on.
Re: Why we ditched Django for Microservices
#20> A microservices architecture is (fairly) new and it doesn't tie you to a particular language. If you want to build a service in Lisp, Go, Elixir, etc then you can (assuming it makes sense). Good devs love to learn, experiment and hate being bored. A microservices approach encourages all of that The developer in me kind of likes that - fun new toys! But from a business point of view, I'm not sure it sounds like such…
[deleted]
Correct, writing code does not make money. However this change is a little bit like starting a blog... You don't see the immediate benefits straight out but you'll realise them over time. You can put it off and put it off but the longer you do the harder it gets, especially in this scenario.
This architecture doesn't make sense for everyone and we could have continued with Django. But making these changes now mean that we will be able to fix all the above a lot quicker going forward.