It would be nice to see if there was a change at Google since then to orientate itself towards more of a SOA thing like Amazon? I don't know what state Google Cloud Platform was back in 2011 - I am guessing it is significantly more now than it was then, so would be curious to know if that has stemmed from a "transformation" internally, or if they just started from scratch for GCP?
I'm a newer employee, so I can't add color to the past several years of work, but my immediate reaction is Yes. Given the "We <3 APIs" slogan you can see around the MP campus (from public view of course) it's pretty apparent that there was a top down push towards improving the state of SOA and building platforms.
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.
>>You know how people are always saying Google is arrogant? I'm a Googler, so I get as irritated as you do when people say that. We're not arrogant, by and large. We're, like, 99% Arrogance-Free. I did start this post -- if you'll reach back into distant memory -- by describing Google as "doing everything right". We do mean well, and for the most part when people say we're arrogant it's because we didn't hire them, or they're unhappy with our policies, or something along those lines. They're inferring arrogance because it makes them feel better.
Given how Steve moved to Grab it's funny how his "they hate us cuz they ain't us" bit in itself comes off as arrogant.
The thing about API and platforms is, stability matters, and it matters a lot. Google can't stop fiddling with things, their products and their APIs and legal terms; they just keep changing things constantly. It makes it incredibly annoying to build anything on Google tech.
Things built on Microsoft tech still work decades later without any change. I have things built on AWS that's still running on 6 year old APIs and they still work. With Google, I'm lucky if it lasts 6 months.
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.
> head over to developers.google.com and browse a little. ... It's like what your fifth-grade nephew might mock up if he were doing an assignment to demonstrate what a big powerful platform company might be building if all they had, resource-wise, was one fifth grader.
Amazingly, this is now more true than when it was written.
Look at the top categories under the 'products' menu, compared with the same menu on aws.
I recently interviewed with Google and their recruiter's, presumably copy-and-pasted, spiel included the following footnote:
"Steve Yegge (former Googler) talks about his interview experience and "How to Get that Job at Google" in his blog post here[0]."
Which I found strange given that (A) Steve wrote it 10 years ago and (B) he's more recently written[1] that "The main reason [for leaving] Google is that they can no longer innovate."
It's funny how much he talked up Facebook's "platform", but all of their platform work has contributed very little to Facebook's bottom line, and has even caused them issues in the case of Cambridge Analytica.
My admiration for Steve Yegge plummeted after his article on why he moved from Google to Grab.
He was talking about how Grab had some sort of moral highground above Uber, but if he spent even 10 mins researching he would see that objectively they are worse in Southeast Asia. And their behavior after Grab bought Uber in Southeast Asia was nothing short of ruthless. I have family in the area so I have first hand accounts as to what happened, so him talking about how proud he is working at Grab because they are somehow moral really made my lose my respect for him.
Wow I remember when this was published and such a good rant. Had to read again for laughs. SOA is sort of the older term... a subset which is a better description of where platforms should be heading is microservices. Issues like rate limiting still exist but need to get away from things like api gateways as well as they are becoming a sort of antipattern for scaling massively. They're useful for certain problems but not necessarily as useful as lower level message queuing engines that need to handle high volumes of transactional throughput.
The biggest difference I’ve seen between SOA and microservives is that people have been able to explain to me what SOA means.
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.
I actually wrote an email similar to this recently (re: interfaces) to folks on a project I'm working on, though of course I didn't nor could I threaten to fire anyone :)
What's funny is I checked out https://developers.google.com/ and compared it to the others.....and 7 years later it is still accurate to describe it has "having been designed by a 5 year old". I'm a big fan of Google, it's too bad no one listened to this. Google Wave was amazing, I still to this day do not understand why it was shuttered before it even had a chance to get off the ground.
Speaking of eating their own dog food, still not sure why they are writing their own OS for Pixel. They have now shoved linux on top of it to make it useful to devs and I think that is akin to sprinkling people food around the bowl of dog food. The dog food was so bad your devs & community literally built around it.
And again, I'm a fan of Google. There are just some things they could do so much better.
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).
The thing about dogfooding is so accurate in Google. They don't like dogfooding here.
I work in Google cloud. And I want to host my personal website on the platform I'm working on.
People look at me funny when I bring up about free gcloud credit. My teammates don't seem enthusiastic about this idea. My manager don't seem to agree that it's important. So, I've never got the credit, and my personal site is still hosted on heroku for free.
And nobody on my team uses our own platform.
The culture is strange. Dogfooding our own product should be one of the top priorities.
