| This is agreeably congruent with my original statement, The main problem I have with microservice marketing: It is often promoted to clients that do not have applications that are large or critical enough to warrant leveraging them. That buyers often are properly warned about their inability to easily migrate if they invest in platform-specific microservices too heavily. And clients are often not aware of the operational costs that can rise over time for each component of the distributed architecture. "Monolithic" solutions have also not stagnated... They can be run in distributed methods, they can leverage microservices in parts, they can also leverage containers, they are far from obsolescence because they are using the same languages that microservice architectures use, just with less distribution overall. The term monolithic is often used to indicate that less-distributed solutions are somehow "out of date", "obsolete" and "not innovating" inaccurately, when the real story is that the business case usually dictates which solution will fit best. |
Anyway, if you’re dealing with microservices “lock-in” isn’t a real problem—you just move one service over to your new platform at a time. Good luck doing that with your monolith without decomposing it into services (and frankly, if you can feasibly decompose your monolith into services, your architecture is probably cleaner than 95% of monoliths out there).