Why we ditched Django for Microservices
blog.hubblehq.com
Why we ditched Django for Microservices
1–10 of 85 posts
Re: Why we ditched Django for Microservices
#2> 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 a good idea: lots of weird, unmaintainable stuff.
Re: Why we ditched Django for Microservices
#3More often than not, I start my projects thinking that they would be small and don't need a comprehensive framework like Django. Then I figure I need an authentication mechanism, SQL abstraction, an admin site, a pipeline to handle, verify the requests and so on. Then I switch back to Django mostly because I don't want to rediscover the world again. Surely given enough time I could rediscover, but why would one bother?
As per staying lean as stated in the article. I don't think that's staying lean at all. I must mention that I have no knowledge of the framework or codebase of the company in question, although rewriting a codebase is almost never a good idea. Well, it will require a lot of rewriting which is redundant, you would be ditching a lot of testing and bug fixing you have done ever since, and you will probably create a space a lot of new bugs.
I believe a better approach would be componentize your structure in a way that's still governed by django, every component split into apps. And if there are outlier apps that do not need to be within Django at all could be used by redirecting the requests to those services on the load balancer / reverse proxy level.
Re: Why we ditched Django for Microservices
#4> 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…
This is not as terrifying as you might think. You can use this well for prototyping. You can make a simple endpoint fairly quickly in Go, Erlang, Clojure, Ruby. It could do some small task and pop out an answer. You can deploy this behind the wall of an named service.
If the service proves useful, you can migrate it to a more appropriate language. By appropriate, I mean a language that fits your companies culture. Java Shoppe? Java. C# Shoppe? F#.
You can also get a better match for the domain. For example Python has some great math libraries. They are easy to pickup, pleasant to use and reasonably performant. Say you need such features. Boom! Python service doing what it does best while the rest of your shop can use the tools that work well for the domain.
Re: Why we ditched Django for Microservices
#5> 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…
Micro-services force separation of concerns, theoretically making a system more maintainable. Micro-services do little for complexity though - they simply move complexity from a monolithic app to somewhere else and spread it out.
Re: Why we ditched Django for Microservices
#6> 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…
what happens when those devs who chose some new language leave? Who gets stuck with all that code?
Re: Why we ditched Django for Microservices
#7More often than not, I start my projects thinking that they would be small and don't need a comprehensive framework like Django. Then I figure I need an authentication mechanism, SQL abstraction, an admin site, a pipeline to handle, verify the requests and so on. Then I switch back to Django mostly because I don't want to rediscover the world again. Surely given enough time I could rediscover, but why would one bothe…
We're lucky enough that we decided early enough for it not to be too big an issue.
Also we split up the re-write over stages and haven't done it all in one go. I'm gonna write more about it in another blog post but essentially we still have our monolithic Django system.
It currently powers the majority of the services except we have changed the architecture so we can split things out overtime. This allowed us to achieve what we wanted to in 4 weeks yet lay the groundwork for the future.
Re: Why we ditched Django for Microservices
#8> 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.
Re: Why we ditched Django for Microservices
#9> 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
Re: Why we ditched Django for Microservices
#10> 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…
what happens when those devs who chose some new language leave? Who gets stuck with all that code?
That's a good reason to have shared responsibility of code. There is no one owner of a codebase, an entire team should own the code. An entire team leaving at once seems highly unlikely.