3 ms·

I still don’t fully understand what makes something a monolith. For example, I have a big app which is serving 90% of the API traffic. I also have three separa

I still don’t fully understand what makes something a monolith. For example, I have a big app which is serving 90% of the API traffic. I also have three separate services, one for a camera, one to run ML inference, and one to drive a laser welding process. They are split up because they all need specific hardware and preferably a separate process (one per gpu for example). Is this a monolothic app or a micro service architecture?

flakes 3y ago
I would call that a micro-service architecture using a mono-repo. I think a lot of people here are conflating mono-repo/poly-repo with a mono-deployment. You can easily add in extra entrypoint executables to a single mono-repo. That allows initiating parts of the system on different machines, allowing scaling for skewed API rates across your different request handlers. Similarly, you can create a monolith application building from a poly-repo set of dependencies. This can be easier depending on you version control system, as I find git starts to perform really poorly when you enter multi-million SLOC. At my job we have a custom build system for poly-repos that analyzes dependencies and rebuilds higher level leaf packages for lower level changes. Failing a dependency rebuild gets your version rejected, keeping the overall set of packages green.
stavros 3y ago
> Is this a monolothic app or a micro service architecture? Yes. To be less facetious, the continuum goes from "all the code in a single process" to "every line of code is a separate service". It's not either-or.
SanderNL 3y ago
I tend to call these things “distributed monoliths” assuming the camera, ML and laser driver are integral to the functionality of the system. There is no hard rule that I know of but my heuristic is something like “can I bring instances up and down randomly without affecting operations (too much)”. If so, I’d call that a microservice(ish) architecture. The waters have been muddied though. Microservices were IMO once associated with Netflix-like scalability, bringing up and down bunches up “instances” without trouble. But nowadays what used to be good old service-oriented architecture (SOA) tend to be also called microservices. SOA can also be about scalability, but it tended to focus more on how to partition the system on (business) boundaries. I guess like you did. It’s all a bit muddy in my experience.

flakes 3y ago

I would call that a micro-service architecture using a mono-repo. I think a lot of people here are conflating mono-repo/poly-repo with a mono-deployment. You can easily add in extra entrypoint executables to a single mono-repo. That allows initiating parts of the system on different machines, allowing scaling for skewed API rates across your different request handlers. Similarly, you can create a monolith application building from a poly-repo set of dependencies. This can be easier depending on you version control system, as I find git starts to perform really poorly when you enter multi-million SLOC. At my job we have a custom build system for poly-repos that analyzes dependencies and rebuilds higher level leaf packages for lower level changes. Failing a dependency rebuild gets your version rejected, keeping the overall set of packages green.

stavros 3y ago

> Is this a monolothic app or a micro service architecture? Yes. To be less facetious, the continuum goes from "all the code in a single process" to "every line of code is a separate service". It's not either-or.

SanderNL 3y ago

I tend to call these things “distributed monoliths” assuming the camera, ML and laser driver are integral to the functionality of the system. There is no hard rule that I know of but my heuristic is something like “can I bring instances up and down randomly without affecting operations (too much)”. If so, I’d call that a microservice(ish) architecture. The waters have been muddied though. Microservices were IMO once associated with Netflix-like scalability, bringing up and down bunches up “instances” without trouble. But nowadays what used to be good old service-oriented architecture (SOA) tend to be also called microservices. SOA can also be about scalability, but it tended to focus more on how to partition the system on (business) boundaries. I guess like you did. It’s all a bit muddy in my experience.