[jeffbee]

It is perhaps unfair to compare with Google, since the question of "how will we store the web" clearly calls for a distributed system, whereas the microservice haters are often speaking of systems with an ultimate user base in the low single digits. It _is_ true that with modern hardware you can monolith your way to serving thousands of users at 1 query per second. It is not true that you can incrementally modify that architecture to handle more users and traffic. One must carefully judge such things before committing to either the costs of a distributed system or the limitations of a monolithic system.

A reason this succeeds at Google is that many of the microservice counter-arguments boil down to "yes, but what if I am a jackass?" If you are afraid of having to reimplement your structured logging framework for 11 different languages, I suggest you simply do not do that. Initially everything at Google was in C++ alone, then python, Java, and Go[†] were slowly added. Even after 25+ years of being Google they are not out there trying to diversify languages. You don't need to be Google to exercise good taste and restraint.

†: You needn't correct me regarding the niche languages that popped up here and there because I am aware.

[d_watt]

> It is not true that you can incrementally modify that architecture to handle more users and traffic. One must carefully judge such things before committing to either the costs of a distributed system or the limitations of a monolithic system.

I'm a little confused by this, microservices or monoliths can both be distributed systems. A monolithic architecture (eg a Rails app) still usually has a separate database. You can even deploy that monoloth in different configurations (Web vs Worker).

You can then deploy many nodes of that same monolith, pointed at many different shards of a database to handle huge scaling needs. This is especially easy to do if the problem domain lends itself to horizontal scaling, like B2B saas.

I feel like the definition of microservices has gotten a bit murky here.

[jeffbee]

Well, if you use a scalable SaaS like Cloud Spanner, do you then comfort yourself with the idea that you avoided microservices? Because that seems a little hard to defend on the facts.

[candybar]

Not sure what you're trying to get at here - from the standpoint of developers, Cloud Spanner is the opposite of a microservice.

https://en.wikipedia.org/wiki/Microservices

> A microservice architecture – a variant of the service-oriented architecture structural style – is an architectural pattern that arranges an application as a collection of loosely-coupled, fine-grained services, communicating through lightweight protocols

> A microservice is not a layer within a monolithic application (example, the web controller, or the backend-for-frontend).[8] Rather, it is a self-contained piece of business functionality with clear interfaces, and may, through its own internal components, implement a layered architecture. From a strategical perspective, microservice architecture essentially follows the Unix philosophy of "Do one thing and do it well".[9] Martin Fowler describes a microservices-based architecture as having the following properties:[2]

A typical monolith would use Cloud Spanner as a layer, not as a microservice.

Most people's criticism of microservices isn't about never having independently deployable services, but rather the service boundary being based on business domain decomposition, rather than essential technical characteristics. In other words, different types of storage (due to their technical characteristics, i.e. blob storage for photos vs relational database for transactional entities) being served by different services for technical reasons is eminently sensible and not something most people would have issues with and has been around for much longer than microservices. The problem is more around people deciding that for a hypothetical financial website backend that "bonds" and "stocks" should be two separate microservices, rather than just two endpoints served by the same monolith, even though they differ merely in terms of business logic and do not require any special handling from a technical perspective.