It actually sounds more like what I'd expect: microservices don't scale.
I've never been a fan of microservices for this simple reason: every boundary, every interface, every connection is friction and a potential source of bugs, performance issues and problems.
It's now been several years since I worked at Google so I can't speak to the current state of things but when I was there, monoliths ruled the roost.
It seems possible there was some experimentation with microservices given the rise of Docker and Kubernetes in the last few years. I'd be surprised if this made serious inroads into high-traffic core services.
It's also worth mentioning that generally Google has (had?) SRE teams rather than SREs embedded on SWE teams. You'd never have one SRE supporting a service as there'd have to be enough to maintain a healthy oncall rotation (typically 8-12).
I can't help but feel like the author is projecting his own experiences onto what Google has said here.
I previously worked in a BigCo that did microservices and currently work at BigCo that leans towards monoliths.
It's completely true that microservices makes development _very_ hard. Just being able to run things locally was very hard since instead of understanding how to build/run one service, you had to figure our how to build/run N services. Testing was another major headache.
Monoliths help with technical aspects but organizationally they make your life hell and can severely limit your ability to move fast.
I've never been a fan of microservices for this simple reason: every boundary, every interface, every connection is friction and a potential source of bugs, performance issues and problems.
It's now been several years since I worked at Google so I can't speak to the current state of things but when I was there, monoliths ruled the roost.
It seems possible there was some experimentation with microservices given the rise of Docker and Kubernetes in the last few years. I'd be surprised if this made serious inroads into high-traffic core services.
It's also worth mentioning that generally Google has (had?) SRE teams rather than SREs embedded on SWE teams. You'd never have one SRE supporting a service as there'd have to be enough to maintain a healthy oncall rotation (typically 8-12).
I can't help but feel like the author is projecting his own experiences onto what Google has said here.