[throwaway894345]

You’re confusing “microservices” and “distributed architecture” with “depending on specific cloud provider services”. Microservices don’t have to depend on any cloud services at all and monoliths can (and often do!) use cloud services.

[winternett]

Many "Monoliths" can be run on something as simple as a desktop emulator. They don't generally rely on cloud either.

Microservices are "distributed" across a cloud host platform because they are each updated and maintained by different teams. My use of the term "distributed means that if AWS East has your DB instance and your web server is stored in an entirely different region, you app goes down anyway, but your front-end team can maybe still deploy updates... Which is not really a dramatically productive gain for a customer running a restaurant web site.... On the other hand, if you're running a massive video streaming site, it might be a good thing to base it on micro service architecture. Each use case is different.

I'm resisting the pressure to be drawn into a debate about which one is better, that's not what I'm out to do... What determines which solution is better is the business case it seeks to resolve. Neither is inferior or more obsolete, the two ideals both can and often do run on identical/similar code bases... It's the configuration and potential uses/application/benefits that differ.

[throwaway894345]

> Many "Monoliths" can be run on something as simple as a desktop emulator.

I'm not sure what a "desktop emulator" is, but a lot of micro services can run as native processes or in a VM. There's nothing about micro services that fundamentally restrict where they run--they're just application processes at the end of the day.

> my use of the term "distributed means that if AWS East has your DB instance and your web server is stored in an entirely different region, you app goes down anyway, but your front-end team can maybe still deploy updates... Which is not really a dramatically productive gain for a customer running a restaurant web site.... On the other hand, if you're running a massive video streaming site, it might be a good thing to base it on micro service architecture. Each use case is different.

I mean, that's one scenario but the inverse could be true--your custom emoji service could go down but everything else--your payment service, etc could stay up. More than that, you can play it fast and loose with deploying to your emoji service while your important core services get more scrutiny. With monoliths, any change could take down core services so you have to use the same scrutiny when deploying changes to the emoji features. Moreover, you don't need to coordinate with a bunch of other teams to deploy--your team can deploy its own service whenever it needs to. You can use whichever language is best for your component. Etc, etc. But we are agreed that micro services aren't fit for every use case--if you only have a few teams then you probably won't benefit much from micro services.

> I'm resisting the pressure to be drawn into a debate about which one is better, that's not what I'm out to do... What determines which solution is better is the business case it seeks to resolve. Neither is inferior or more obsolete, the two ideals both can and often do run on identical/similar code bases... It's the configuration and potential uses/application/benefits that differ.

You're back pedaling pretty quickly from the tone and claims of your original comment, but I accept all of this--neither is a silver bullet. :)

[winternett]

FTR... A desktop emulator was a reference to something like WAMP or XAMPP... On which a monolith can be run, developed upon, and even tested entirely independent of any host or VM infrastructure.

I'm not back pedaling, you're reading too closely and judging instead of looking at the discussion from an objective standpoint and simply seeking clarity and working towards truth. Here's what I posted in this same thread even before my post in this branch -

+++

by winternett 6 hours ago | parent | context | prev | next [–] | on: Why our team cancelled our move to microservices

A size 20 shoe is better for a large foot... But not better for a size 15 or size 10 foot. Saying Microservices are better is the same as me saying "a size 20 shoe is better than any other shoe"... for everyone.

It's not a viable statement in any use case, except for people with size 20 feet.

The business need is what determines the solution necessary.

[throwaway894345]

> you're reading too closely and judging instead of looking at the discussion from an objective standpoint and simply seeking clarity and working towards truth

I think you're projecting here. Perhaps we can stick to the actual discussion instead of speculating on my motivations--as though you can understand someone's inner workings from half a dozen Internet comments :).

Anyway, we're no longer talking about microservices or monoliths so it would seem this thread has run its course. Enjoy your day!