5 ms·

But then why not just introduce a rule: Django ‘apps’ can only talk to each other via pure Python dicts like an interface? (rather than sharing models)? This s

But then why not just introduce a rule: Django ‘apps’ can only talk to each other via pure Python dicts like an interface? (rather than sharing models)? This situation is a necessary conceptual step before decoupled micro services and far far easier (because it introduces none of the ops problems of microservices). But that never seems to happen. I think it’s because codebase discipline rules are harder for management to ‘see’ than API rules.

yeswecatan 6y ago
I agree though I'd have to think a bit more about the exact way for apps to speak to each other. My guess would be each app could have an api file with a bunch of functions. I wonder how that would work in a situation where you have 3 apps, each with a single model, and the dependencies are A -> B -> C. You could still run into situations where B isn't supposed to know anything about A yet nothing stops B from importing A's api.
- aserafini 6y ago
  It’s still possible to have circular dependencies in microservices. There is normally nothing stopping service A calling B and B calling A except common sense and discipline. In fact I would say it’s MORE difficult to prevent circular microservice dependency programmatically than in code (where you can hook into module level imports).
vasco 6y ago
> But then why not just introduce a rule: Django ‘apps’ can only talk to each other via pure Python dicts like an interface? (rather than sharing models)? 1. One person or group needs to decide on what the rule should be, what the boundaries are and how to enforce those boundaries. This is usually not an easy process, ymmv. 2. After a decision is made, you'll have to decide on how to put the rule in place. Are you going to stop everything and make sure all code paths are working according to the new rule? Are you going to do it incrementally? New features = new rule, old features = common sense? Another variation? 3. You then start running your new rule and maybe you enforce it with some custom static checks, and when that fails you hope your code reviewers will always catch this every time. 4. You still need that one person or group to make sure this actually gets done and to assess if it actually has a positive impact on velocity and reliability. Or you can put in an implicit "rule" that new code happens in a separate repository, where you don't need to care. A developer that has to do an API call because they simply cannot "import" another module or "query" someone else's data has no choice but to do the right thing - though many opportunities to do a lot of other wrong things too, this is not a panacea. But when we're talking about more than ~5-6 teams, the coordination effort of making sure everyone is aligned on a monolith can be much tougher than to go to multiple services (hopefully not micro).
- playing_colours 6y ago
  I think your points are about lacking solid engineering leaders at an organisation that could provide guidance and manage execution of the "modular monolith" approach. If a company does not have leaders who can ensure consistency and discipline across a few team within a monolith, I am afraid of the mess they will run into with multiple services.
- nerdponx 6y ago
  None of these problems are solved by microservices. Now instead of undocumented unstructured interactions between modules, you have undocumented unstructured interactions between standalone applications. None of your problems are solved, except now you have a much bigger cloud hosting bill.
  - marshmellman 6y ago
    That’s not been my experience working with microservices for the past 5+ years. It’s in a team’s own interest to document their APIs and design them well, because if they don’t then it’s their own time sink when other teams integrate. Microservices have problems but the way they’re often portrayed doesn’t match my experience. I agree with the sibling commenter who said that a microservices architecture exchanges an organizational expense for a technical expense. For certain organizations, it can be the right call.

yeswecatan 6y ago

I agree though I'd have to think a bit more about the exact way for apps to speak to each other. My guess would be each app could have an api file with a bunch of functions. I wonder how that would work in a situation where you have 3 apps, each with a single model, and the dependencies are A -> B -> C. You could still run into situations where B isn't supposed to know anything about A yet nothing stops B from importing A's api.

aserafini 6y ago
It’s still possible to have circular dependencies in microservices. There is normally nothing stopping service A calling B and B calling A except common sense and discipline. In fact I would say it’s MORE difficult to prevent circular microservice dependency programmatically than in code (where you can hook into module level imports).

vasco 6y ago

> But then why not just introduce a rule: Django ‘apps’ can only talk to each other via pure Python dicts like an interface? (rather than sharing models)? 1. One person or group needs to decide on what the rule should be, what the boundaries are and how to enforce those boundaries. This is usually not an easy process, ymmv. 2. After a decision is made, you'll have to decide on how to put the rule in place. Are you going to stop everything and make sure all code paths are working according to the new rule? Are you going to do it incrementally? New features = new rule, old features = common sense? Another variation? 3. You then start running your new rule and maybe you enforce it with some custom static checks, and when that fails you hope your code reviewers will always catch this every time. 4. You still need that one person or group to make sure this actually gets done and to assess if it actually has a positive impact on velocity and reliability. Or you can put in an implicit "rule" that new code happens in a separate repository, where you don't need to care. A developer that has to do an API call because they simply cannot "import" another module or "query" someone else's data has no choice but to do the right thing - though many opportunities to do a lot of other wrong things too, this is not a panacea. But when we're talking about more than ~5-6 teams, the coordination effort of making sure everyone is aligned on a monolith can be much tougher than to go to multiple services (hopefully not micro).

playing_colours 6y ago
I think your points are about lacking solid engineering leaders at an organisation that could provide guidance and manage execution of the "modular monolith" approach. If a company does not have leaders who can ensure consistency and discipline across a few team within a monolith, I am afraid of the mess they will run into with multiple services.
nerdponx 6y ago
None of these problems are solved by microservices. Now instead of undocumented unstructured interactions between modules, you have undocumented unstructured interactions between standalone applications. None of your problems are solved, except now you have a much bigger cloud hosting bill.
- marshmellman 6y ago
  That’s not been my experience working with microservices for the past 5+ years. It’s in a team’s own interest to document their APIs and design them well, because if they don’t then it’s their own time sink when other teams integrate. Microservices have problems but the way they’re often portrayed doesn’t match my experience. I agree with the sibling commenter who said that a microservices architecture exchanges an organizational expense for a technical expense. For certain organizations, it can be the right call.