Thank Tom for sharing your views on microservices. I started writing some comments but they got a bit too long, so I’ll go ahead and share my thoughts in here ☺.

First of all, I’m still waiting for Amazon to deliver this book, so right now I really don’t know anything about microservices.

I think your approach sounds like it could have lots of benefits. Django projects indeed get quite large most of the time and it can be hard to wrap your head across the entire project. It also sounds like you could indeed build a great team where different people focus on different aspects of your business and can use their preferred tools for doing just that.

I do have some reservations as well, especially from a start-up point of view. Here we go:

As a start-up you don’t have enough engineers to form several distinct teams. It’s going to be a bunch of people for now and they’ll have to be aware of what everyone else is doing.

Also I think it’s very important that everyone agrees on the ‘culture’ of the team, in terms of tools and framework as well as processes. I think this could be made more difficult if you had different microservices using different technologies. ‘Writing tests’ can be mean very different things to different people, especially when different languages or frameworks are involved.

Besides the culture problem, I can also see a communication problem.

When people work on the same monolithic Django project, at least it comes with shared conventions. Still there’s a big chance of misunderstanding ‘some other part’ of the project, just because of a lack of communication(lack of code review, test coverage and so on).

If this happens when using the same programming language and the same framework, how bad can it get if you have people working on separate services written in different languages and frameworks?

How will you avoid silos(maybe those are good in your code, not in your team however)?

I can imagine a large company(say 50 to 100 engineers) where distinct teams of 3–5 people build their own microservice and offer those to their colleagues via ‘public’ API’s. No one has to know much about the internals of services they’re not directly working on. Teams will have their own culture(at least when it comes to the tech) and they’ll see to their own recruiting needs.

For a start-up, where there is really just one team, I think splitting your app across languages and frameworks really risks undermining mutual understanding between your engineers.

I’m interested in reading more about how you will, or already have, address(ed) such challenges, or perhaps why you think these are non-issues.