4 ms·

I've joined a company with a silent majority monolith, and joined at the inflection point where they realise their monolith is strangling them... If your dev g

I've joined a company with a silent majority monolith, and joined at the inflection point where they realise their monolith is strangling them... If your dev guide in the wiki says "to run unit tests, use docker-compose exec monolith test some.package.test_class", you're in danger. This company needs to start breaking the monolith down into, well maybe not microservices, but at least smaller monoliths, if they want to achieve what they want to achieve.

Tainnor 4y ago
No, you just need a sane test architecture. I've worked on monoliths, and none of them required docker compose for unit tests. Now, you may need some extra infrastructure for integration tests, depending on how you architect them, but that's also not a requirement. You could also use mock services, test containers, ... - essentially there's enough ways to make this sane. It's annoying that people take badly written monoliths as an excuse to proceed to write badly written microservices.
- EdwardDiego 4y ago
  Let me just say, Django was designed to be a monolith. Also, people who put code that reaches out to external systems in __init__.py are the devil, but the people who decided "sure, let's execute code when we import a module or package, even if we're just importing it to use a class, that sounds reasonable" are the super-devil.
lytefm 4y ago
The hard part is to recognize when to start moving towards microservices. As long as the team is small enough and the core product is still undergoing rapid development, I think it's premature to use microservices. Too much overhead without any tangible benefit. But with multiple teams working on different parts of a profit-generating system, it makes sense to the transition - ideally, having a relatively stable core monolith and developing new services around it, occasionally extracting some core functionality as needed.
snovv_crash 4y ago
That's a deployment and dependencies issue, not a monolith issue. The microservices equivalent needs Kubernetes to run your tests.
- remram 4y ago
  Usually not for unit tests.
  - snovv_crash 4y ago
    Well you can do the same with a monolith too right, just pull some random code out of the codebase and compile it without anything else, plus the tests for it. It gives the same guarantees as the microservices unit tests.
    - EdwardDiego 4y ago
      Not when it's Django, sadly.
treis 4y ago
Can you explain what is wrong with the test command?
- kaashif 4y ago
  I don't know what _they_ think is wrong with it, but if you need docker-compose to run unit tests, they're not unit tests. Unit tests really shouldn't have external dependencies of the kind docker-compose helps to provide. That's more of a terminology point IMO, and probably not what they were talking about.
  - snovv_crash 4y ago
    I'm guessing it is something like "works with version X of dependency Y which is only available on Linux distro Z" and distro Z is only available with an ancient kernel which makes it a pain to run on modern laptops so everyone just develops in Docker.
zaphar 4y ago
I have no particular dog I wish to back in the Microservice vs Monolith debate. But I think since you joined at the inflection point it's probably worth it to take a good look at why their monolith landed them in such a poor place and so that no matter what direction you go for the future you can at least make different mistakes. Microservices won't magically fix issues with tightly coupled components or poor achitecture. Those problems can and do still happen with them.
deleted 4y ago
[deleted]

Tainnor 4y ago

No, you just need a sane test architecture. I've worked on monoliths, and none of them required docker compose for unit tests. Now, you may need some extra infrastructure for integration tests, depending on how you architect them, but that's also not a requirement. You could also use mock services, test containers, ... - essentially there's enough ways to make this sane. It's annoying that people take badly written monoliths as an excuse to proceed to write badly written microservices.

EdwardDiego 4y ago
Let me just say, Django was designed to be a monolith. Also, people who put code that reaches out to external systems in __init__.py are the devil, but the people who decided "sure, let's execute code when we import a module or package, even if we're just importing it to use a class, that sounds reasonable" are the super-devil.

lytefm 4y ago

The hard part is to recognize when to start moving towards microservices. As long as the team is small enough and the core product is still undergoing rapid development, I think it's premature to use microservices. Too much overhead without any tangible benefit. But with multiple teams working on different parts of a profit-generating system, it makes sense to the transition - ideally, having a relatively stable core monolith and developing new services around it, occasionally extracting some core functionality as needed.

snovv_crash 4y ago

That's a deployment and dependencies issue, not a monolith issue. The microservices equivalent needs Kubernetes to run your tests.

remram 4y ago
Usually not for unit tests.
- snovv_crash 4y ago
  Well you can do the same with a monolith too right, just pull some random code out of the codebase and compile it without anything else, plus the tests for it. It gives the same guarantees as the microservices unit tests.
  - EdwardDiego 4y ago
    Not when it's Django, sadly.

treis 4y ago

Can you explain what is wrong with the test command?

kaashif 4y ago
I don't know what _they_ think is wrong with it, but if you need docker-compose to run unit tests, they're not unit tests. Unit tests really shouldn't have external dependencies of the kind docker-compose helps to provide. That's more of a terminology point IMO, and probably not what they were talking about.
- snovv_crash 4y ago
  I'm guessing it is something like "works with version X of dependency Y which is only available on Linux distro Z" and distro Z is only available with an ancient kernel which makes it a pain to run on modern laptops so everyone just develops in Docker.

zaphar 4y ago

I have no particular dog I wish to back in the Microservice vs Monolith debate. But I think since you joined at the inflection point it's probably worth it to take a good look at why their monolith landed them in such a poor place and so that no matter what direction you go for the future you can at least make different mistakes. Microservices won't magically fix issues with tightly coupled components or poor achitecture. Those problems can and do still happen with them.

deleted 4y ago

[deleted]