[ryan_j_naughton]

> Microservice architecture is also inherently designed to lock a customer into very specific tools that make future migration to any other platform a very costly decision in most cases... Thereby locking a customer into platform-specific dependency

Can you elaborate on this? Examples? Thanks!!

[fendy3002]

Looks like OP talked about serverless / google cloud run, where rather than traditional server deployment, it use specific provider's implementation. Additionally it may also means CI/CD pipeline where usually it's different between provider.

[winternett]

I'd need days to detail it all specifically enough, but I'll give you a simple example...

A "monolithic" solution usually relies on a basic (e.g. LAMP) stack that can all be run on one server if the need arises... Your web and database server can be migrated from AWS to Azure much easier if pretty much all of the functionality relies on a close-knit local server architecture that can have a less complicated security, code, and endpoint design as well.

If you create an app that works based on a highly distributed architecture, suddenly, migrating a solution is far more complex - Platforms like AWS and Azure do not run all of the same services, and those services often require lots of refactoring to work properly with your prior data, you'll also need to do many test cycles after migrating to ensure that solution integrity is maintained.... At that point, a simple migration might as well be a total refactor.

After implementing policies like zero trust and working out whitelisting, if your solution is complicated or large-scale, you also have to deal with service-specific nuances in your code and in your architecture design that don't translate well to the completely different tools available on an alternate cloud hosting platform, because usually they have completely different nuances and conventions on their service architectures.

To put it simply, it's like buying a ford pickup truck and installing an aftermarket 6.34 x 9.85ft camper top (and other ford-specific aftermarket parts) on it, and then trying to install that custom Ford camper top and the other Ford aftermarket parts onto a Toyota which only fits a 5.77 x 8.34ft camper later on... It usually doesn't work out well, and usually provides very unexpected results and more financial loss than using a universally sized 5.55 x 8.20ft camper (The monolithic option that fits in both trucks, albeit not perfectly).

Each platform is very specialized in their own way... Just as with Ford any Toyota pick up trucks, they have completely different build dimensions, and that's why the parts aren't interchangeable between the two trucks.

Monolithic solutions were originally designed to work agnostic of platforms, so they can work on either provided that they are implemented correctly...

Ultimately, the business need should be carefully evaluated by an experienced architect to determine which architecture fits the need best, and then other factors should be reviewed (like if you'll need to migrate any time in the future for example) to make the final call.

[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!