Suggestion to clarify or avoid the term 'microservices'

[Joel Lim]

A core tenet of microservices is independent deployability. As the tag line says, this cool approach is very good for 'writing distributed applications', but with a monolithic code boundary. The framework is a reminder that process and boundaries don't need the same. If the components in a monolithic codebase are not independently deployable, they are not micro-services. Sometimes words don't really matter, but there are enough people cargo-culting microservices and doing distributed monoliths that costs them all the complexity of process segregation but none of the benefits, it's my opinion it's better off avoiding this term. 

[Srdjan Petrovic]

Yeah, I agree, the word microservice is overloaded, at least for us internally at Google. We'll try to fix it in our documentation.

Interestingly, we found that vast majority of "services that run as independent binaries" at Google are distributed application artifacts, i.e., not "real" microservices by definition. I wish there was a better name for it. Let us know if there is an industry-standard term for it (distributed processes?).

Thanks!

-Srdjan

[Joel Lim]

Just pasting the conversation because I unintentionally replied privately

------------------------------------------------------------------------------------------------------------------------------------------------

Thanks for your suggestions!

On Sat, Mar 4, 2023 at 8:06 PM Joel Lim <103...@gmail.com> wrote:

Thanks for replying.

I think distributed applications / binaries / workloads / processes are ok, just definitely not microservices. This tool was built internally, perhaps the best people to decide this would be those who work on / with the product. I would also suggest including two sections in the documentation or website

1. an example usecase of why such a trade-off would be made

Good point.

 

2. Trade-offs: explicitly mention components that have changes always going at the same time are not independently deployable. Also even when using something like Service Weaver, from a release POV subcomponents are released together, but there's no guarantee that cross-process calls are compatible at any single point of time. evolutionary mindset when modifying contracts is still needed for zero downtime developments.

For point (2), we do guarantee that cross-process calls are compatible. We do blue/green deployment, and processes only communicate with other processes at the same version.

Regards,

Joel