Unless you view systems that consist of microservices as "applications that are difficult to modify".
If anything, an obfuscated microservice-based application is easier to understand than a monolithic version: network data transfer is easier for observers to understand than memory modification.
This could be argued, but obfuscated apps are a land of their own.
(You could also argue that obfuscated monolithic programs are be easier to reverse engineer, breakpoint, replay, emulate, time-travel-debug, trace, etc because you can completely control them in your test bench and aren't then working against a hostile distributed system)
Re:The Ambassador Pattern
by xyzzy_plugh on Sunday November 26, 2023 @02:11AM
(#38419802)
It's similar to a thick client, what Google does by eschewing language agnosticism. It's a reasonable approach, really: thin clients of course work, and you have to provide them across popular languages, making them thicker adds value.
> This pattern can be useful for offloading common client connectivity tasks such as monitoring, logging, routing, security (such as TLS), and resiliency patterns in a language agnostic way. It is often used with legacy applications, or other applications that are difficult to modify, in order to extend their networking capabilities. It can also enable a specialized team to implement those features.
Not surprised this is a Microsoft page, given their legacy of long lifetime support for their software products.
It’s not for microservices, but rather for software maintenance of systems that other vendors would consider past EOL.