5 ms·

I'm looking forward to the article about the problems DOMA introduced for them and what they came up with next. Wonder if we will see a full circle back to mono

I'm looking forward to the article about the problems DOMA introduced for them and what they came up with next. Wonder if we will see a full circle back to monoliths. 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.

rumanator 6y ago
> Wonder if we will see a full circle back to monoliths. 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?
- inopinatus 6y ago
  Monoliths don't run on a single box. My entire current business runs on a single monolithic application, and it's running across multiple AZs with five different instance roles (consumer site, API endpoint, admin site, background jobs, and reporting), sized by memory demand and contention efficiency, then scaled horizontally according to workload demand. 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.
  - rumanator 6y ago
    It seems you should revise your concept of monolith because your description is anything but it. 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.
    - inopinatus 6y ago
      > you should > 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.
- pjmlp 6y ago
  Yes, doing distributed systems programming since around 1996. 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.
javajosh 6y ago
>Is the fools-gold rush still on to do everything as a micro-service from the get-go? Yes.
staticassertion 6y ago
I'm a fool who has done microservices first and is very happy about it. Just want to throw that out there into the sea of negativity I see towards microservices.
- random_kris 6y ago
  I was hired and was told I'll be building ONE of the microservises for their upcoming kubernetes platform. A year later I have written 5 microservises and I am responsible for managing all 5 of them. It is hell.
  - serhatozgel 6y ago
    We broke a monolith to mini-services 3 years ago. We went from 3 deployments (dev, stg, prod) to over 200. I think we've gone a bit too far and will cut down a bit but could not be happier overall. The move allowed the business to massively scale.
  - deleted 6y ago
    [deleted]
pjmlp 6y ago
Sun RPC marketing message, "The network is the computer". 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.
- yjftsjthsd-h 6y ago
  Alright, you've piqued my interest; any pointers for where to learn this stuff, or should I just Google all those terms?
  - pjmlp 6y ago
    Here are some pointers: "Large-Scale C++ Software Design" https://www.amazon.com/Large-Scale-Software-Design-John-Lakos/dp/0201633620/ref=sr_1_3 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-Wesley-Professional-Computing/dp/0201717069/ref=sr_1_1 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-Wesley-Professional-Computing/dp/0134694694/ref=sr_1_2 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 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_17 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 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/0471197130/ref=sr_1_2 https://www.amazon.com/AntiPatterns-William-J-Brown/dp/04711... "Component Software: Beyond Object-Oriented Programming" https://www.amazon.com/Component-Software-Object-Oriented-Programming-Szyperski/dp/B011DCDV40/ref=sr_1_4 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/013727405X/ref=sr_1_9 https://www.amazon.com/Use-Cases-Combined-Booch-Omt/dp/01372... Just some pointers to get you started.

rumanator 6y ago

> Wonder if we will see a full circle back to monoliths. 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?

inopinatus 6y ago
Monoliths don't run on a single box. My entire current business runs on a single monolithic application, and it's running across multiple AZs with five different instance roles (consumer site, API endpoint, admin site, background jobs, and reporting), sized by memory demand and contention efficiency, then scaled horizontally according to workload demand. 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.
- rumanator 6y ago
  It seems you should revise your concept of monolith because your description is anything but it. 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.
  - inopinatus 6y ago
    > you should > 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.
pjmlp 6y ago
Yes, doing distributed systems programming since around 1996. 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.

javajosh 6y ago

>Is the fools-gold rush still on to do everything as a micro-service from the get-go? Yes.

staticassertion 6y ago

I'm a fool who has done microservices first and is very happy about it. Just want to throw that out there into the sea of negativity I see towards microservices.

random_kris 6y ago
I was hired and was told I'll be building ONE of the microservises for their upcoming kubernetes platform. A year later I have written 5 microservises and I am responsible for managing all 5 of them. It is hell.
- serhatozgel 6y ago
  We broke a monolith to mini-services 3 years ago. We went from 3 deployments (dev, stg, prod) to over 200. I think we've gone a bit too far and will cut down a bit but could not be happier overall. The move allowed the business to massively scale.
- deleted 6y ago
  [deleted]

pjmlp 6y ago

Sun RPC marketing message, "The network is the computer". 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.

yjftsjthsd-h 6y ago
Alright, you've piqued my interest; any pointers for where to learn this stuff, or should I just Google all those terms?
- pjmlp 6y ago
  Here are some pointers: "Large-Scale C++ Software Design" https://www.amazon.com/Large-Scale-Software-Design-John-Lakos/dp/0201633620/ref=sr_1_3 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-Wesley-Professional-Computing/dp/0201717069/ref=sr_1_1 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-Wesley-Professional-Computing/dp/0134694694/ref=sr_1_2 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 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_17 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 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/0471197130/ref=sr_1_2 https://www.amazon.com/AntiPatterns-William-J-Brown/dp/04711... "Component Software: Beyond Object-Oriented Programming" https://www.amazon.com/Component-Software-Object-Oriented-Programming-Szyperski/dp/B011DCDV40/ref=sr_1_4 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/013727405X/ref=sr_1_9 https://www.amazon.com/Use-Cases-Combined-Booch-Omt/dp/01372... Just some pointers to get you started.