Why our team cancelled our move to microservices

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.

I remember hearing a story (from a person inside said company) about a reasonably sized company with a 2 (really 1) man dev team (they contract for most of their needs) and how excited the company was to move their internal stuff to microservices and off a monolith.

He looked at me like i was insane when i said a monolith would work better for them.

> The term "Monolith" was devised by people who wanted to brand microservices as newer and superior. It's almost as if in order to succeed these days you need to discredit and disparage your competition rather than simply having a better product, and that's why I don't buy into buzz words at all.

But, my company split out a much older, larger monolith over many years into separate services with clear ownership across a variety of teams. This has been a huge benefit, coming from clear ownership, API boundaries, and separation of concerns.

So neither monolith or microservices are a clear winner. It depends on context. An easy litmus test, IMO, is that a single dev team will get little to no benefit from managing many microservices, but a company scale problem will get a lot of benefit from having each team manage and deal with an independent service.