Stevey's Google Platforms Rant (2011)

Whether that applies to non-Cloud Google I don't know. But I don't even think GCE existed in 2011. A lot has changed.

And the post starts with "Amazon does everything wrong, and Google does everything right".

I think "changing" also means "killing".

A quip from someone on HN from earlier this year, I didn't save the URL:

It’s not as though Google, to pick one example from your list, is some kind of techno-prophet; they’ve killed more projects than asteroids did dinosaurs.

If nothing else, the recommended book "Steven Skiena's The Algorithm Design Manual" is very good to prepare for the Google interview.

Aside from that, the term “microservices” implies a bunch of anti patterns in itself, and brings to mind horror stories of startups with three times as many microservices as engineers that invested multiple man-years in setting up Kubernetes to do something that could have been accomplished with a fraction of the cost in 2005 with ASP.NET and Microsoft SQL Server.

Service boundaries are significantly more expensive than people assume. A monolithic web application, or even a “macroservice”, can still be scaled horizontally with network dependencies on a shared database and can call any code or access any local data with the same basic guarantees of any other computer program. Your procedure calls are normal procedure calls, whose contracts and interfaces are as efficient and safe as your language’s type system allows. You can have unit and functional test coverage that exercises virtually all of your feature or application without needing to deploy and integrate multiple services. You can achieve better focus and deeper investments in infrastructure when there are fewer services to deploy and support. The only issues with concurrency and distribution you have to worry about are whether you are writing threadsafe code in the first place, your connection to your database, and perhaps cache invalidation.

The minute you introduce a service boundary, you throw all of that away. API calls have to be documented, versioned, and validated on both sides. Tooling exists for this (Swagger, gRPC, GraphQL), but the complexity is much higher. Testing requires deploying interdependent services in a shared test environment. Your service interfaces have to be built with some well-considered strategy around resiliency and consistency because you might (and, with enough services, statistically will) have to keep running with some unavailable dependencies. Even dependency management, which is already a hell in itself, becomes combinatorially harder when you have to design around the requirement that your service dependencies (and the services that depend on yours) can change at runtime with you being none the wiser.

Now, at times, you don’t have to incur all these costs. Some services are inherently independent. Some behaviors can and should happen e.g. on a message queue or on a schedule rather than in response to live traffic. And, at a certain scale, you need to separate your data stores, decouple your feature deployments from each other, or reap many of the other benefits of SOA. But those benefits aren’t free; they’re extremely expensive, and companies on the scale of Amazon or Google reap those benefits not because they are inherently wonderful, but because despite the costs, they are the only way certain things are possible in the first place.

If monoliths are the communist planned economy of web applications, SOA are the market economies. They can scale a lot, lot more, but at the added overhead of everyone having to squint at each other suspiciously and distrustfully.

Would be the equivalent to the links this person blogged. And they offer a ton now, including Turing GPU cloud computing for AI, which I have seen host chess AI and destroy the world's best chess engine (Stockfish).