[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.