I know I'm being snarky and I have used micro-services myself, but only when it was smacking me in the face as the best tool for the job. Is the fools-gold rush still on to do everything as a micro-service from the get-go?
Side note, I can't wait to hear my boss use "DOMA" in a meeting in the coming months. FML.
So yeah, we keep going at this, and then people discover that monoliths written in a correct modular way, with libraries, happen to be easier to debug and reason about without a network in the middle.
Main problem seems to be that not many developers bother to read about modular programming, large scale development (like Lakos books) and what features their language of choice offers for such endeavours.
"Large-Scale C++ Software Design"
https://www.amazon.com/Large-Scale-Software-Design-John-Lako...
Although oriented towards C++, many architecture tips apply to other languages as well.
John Lakos is in the process of writing updated versions of the book.
"Large-Scale C++ Volume I: Process and Architecture"
https://www.amazon.com/Large-Scale-Architecture-Addison-Wesl...
"Large-Scale C++ Volume II: Design and Implementation"
https://www.amazon.com/Large-Scale-Implementation-Addison-We...
Then going back into the old days, you have
"Software Engineering in Modula 2: An Object Oriented Approach"
https://www.amazon.de/-/en/Jill-Hewitt/dp/0333515188
"Data Structures and Program Design in Modula-2"
https://www.amazon.de/Larry-R-Nyhoff/dp/0023886218/ref=sr_1_...
"Code Complete: A Practical Handbook of Software Construction"
https://www.amazon.com/dp/0735619670/ref=sr_1_1
"AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis"
https://www.amazon.com/AntiPatterns-William-J-Brown/dp/04711...
"Component Software: Beyond Object-Oriented Programming"
https://www.amazon.com/Component-Software-Object-Oriented-Pr...
"Use Cases Combined With Booch/Omt/Uml: Process and Products"
https://www.amazon.com/Use-Cases-Combined-Booch-Omt/dp/01372...
Just some pointers to get you started.
I have posted some links to books on sibling comment.
IMO Micro-Services were addressing the skill gap in designing comprehensive schemas, not so much the object layer between user and data. So not modular "programming" but rather "modular design".
Yes.
For global-scale web applications? Obviously you won't. High-availability, low latency, resilience, scalability, performance. You don't get any of that by running your app on a single box. That ship has sailed two or three decades ago. Physics establishes all the limits, not software architects.
Distributed system critics, where they fixate on trendy microservices architectures or poopoo other suggestions like DOMA, should take a step back and look at themselves and what they are actually complaining about. Yes, a solution with no moving parts is simpler than a solution with some moving parts. But have you really noticed what problems are being solved by adding these pieces?
They are all, however, running exactly the same code, just in different configuration. I'd say it's roughly speaking 80% core libraries and the remaining 20% varies by role.
I have a command-line control & observation tool that comes in bin/ of the same repository, and it is again wrapped around the same code besides.
That's the modern monolith in production.
I mean, you yourself talk about "different instance roles".
You should pay attention to your own claims: if you have a distributed deployment comprised of different nodes, and you have specialized nodes that you yourself state that are ran to handle limited and very specific responsibilities, then just because you decided, for any reason that only you can think about, to bundle everything in a single project... That doesn't make it a monolith, does it?
Just to be absolutely clear, "monolith" is not a reference to how you chose to organize your source tree. Monolith is a software architecture concept that defines how your whole application is organized and deployed. A distributed system comprised of multiple specialized processeses running independently is not a monolith, even if you somehow believed it was a good idea to pick which role you run through configuration.
> you yourself
> You should pay attention
> you decided
> you yourself state
> even if you somehow believed it was a good idea
This isn't language anyone should respond to, and not merely because it's staking out a fine example of the No True Scotsman fallacy.
> you yourself state that are ran to handle limited and very specific responsibilities
I didn't.
> Just to be absolutely clear, "monolith" is not a reference to how you chose to organize your source tree
Again, that's a straw man - I never said it was. Although I can certainly see how someone who was absolutely determined to make an unnecessarily bitter remonstration as personal as possible might - through either branch of Hanlon's razor - misconstrue the words "the same repository" adversarially for the purposes of their ego trip.
It's a monolithic application because any of the instances could perform any of the roles, and they're all running exactly the same code. They're distinguished in production for the purposes of operational sanity, because only a flaming idiot would, say, run reporting workloads on the API host.
But when I stand up a demo / showcase environment, for example, it has exactly one instance that does everything, and we can (and do) develop with the whole thing running single process on our laptops.
I shouldn't need to clarify any of this, because the point being made was a rebuttal to the "single box" thesis, not whether I met some gatekeeper's opinion about my standing to discuss the topic.
The empirical example is that, say, Shopify and Basecamp both described their applications as monolithic.
However, there's a more comprehensive demonstration, in that we can't define "box" without contradiction. When you consider the many shells of virtualisation we use, the fact that any web application is by definition accessed over a network (and therefore distributed), and the internal architecture of a modern server, which is practically a distributed federation, or even the coordination between threads in a single process, it leads inevitably to contradiction (if you're careful) or just a messy quagmire of conflicting definitions.
The final nail in this dichotomous coffin is that the converse is also untrue, since any microservice-based application can be deployed on one box. Whichever way you look through the scope, deployment model turns out orthogonal to the taxonomy of software architecture.
Quite obviously the point is not whether a microservice-based app can be deployed on a single box. It obviously can.
The point is that you split your app in order to deploy different pieces to different boxes then you have a distributed system and no longer a monolith.
A monolith approach means a single program. This is a software architecture approach and implies by definition that the whole app runs as one in a single box.
I don't understand the point of arguing.
There is indeed no point in arguing about that.
And I’m not even sure about the calculator.
List of stacks I have used in some form since then, raw TCP/IP for in-house RPC protocol, SUN RPC, RMI, COM/DCOM, XML-RPC, SOAP, CORBA, REST, WCF and apparently gRPC is the new fashion.
At the same time, I also done modular development with teams responsible for modules, where the language features for creating modules, defining interfaces, and use binary dependencies are taken into use.
What I usually see with most "distributed systems" is that they are used as a physical solution for teams that never written a proper module in their life.
If monoliths with total lack of modularity are hard to debug, spaghetti network calls are even less fun.