Comment by Jun8 | Hacker News Reader

Comment by Jun8 | Hacker News Reader

Parent Full thread

Although the etiquette of posting it here is debatable this post is gold, it is not (totally) an ordinary disgruntled coder rant. It's worth reading even for the small list of problems that he gives that Amazon faced when trying to go to an all-services architecture.

But if I had to summarize the main point, I would choose: "The Golden Rule of Platforms, "Eat Your Own Dogfood", can be rephrased as "Start with a Platform, and Then Use it for Everything." You can't just bolt it on later." Start with the platform. This is so obvious, yet a lot of middle and higher managers ignore this either because (i) they are totally ignorant (see Peter's Principle), sadly the case that I usually face, (ii) they pragmatically ignore it, because they are doing greedy optimization for the next 6mos-year and developing the platform is just a "waste of time", or (iii) they ignore developing and making available the platforms they already have because they think it's their "competitive advantage".

The way I read his post, Google's case seems to be (iii). They have great internal tools and platforms for many years now, why they wouldn't develop good APIs around these and make them available is a mystery to me. Wouldn't they have eaten AWS for lunch if they platform-atized their Map-Reduce tools, say around 2004?

It's not that. The procedure for open-sourcing Google-owned code is very easy: you e-mail Chris DiBona and he almost always says yes. There've been a bunch of major pieces of the Google infrastructure open-sourced (eg. cTemplate, Closure, Protocol Buffers, Guice).

The problem is really technical. Because of the open codebase and "edit anything" culture, basically every piece of infrastructure at Google, unless it was designed at the start for open-sourcing, has dependencies on every other piece of infrastructure. Untangling them takes far more time than you could 20% on. That's why you don't see more open-source platforms from Google.

Ugh, I think you are mistaking between open source and being a platform here. A platform need not to be open source.

But all the same issues apply, i.e. if you can't disentangle your code from proprietary interfaces enough to open-source it, you probably will not be able to put a service API on it that third-party programmers will be able to use without a lot of handholding. (And Google doesn't do handholding, as just about everyone knows by now.)

No, it's not the same issues. I'm not a programmer, but I know that offering a well designed API to a service has nothing to do with its code being closed or not.

When I was learning to program, I was very interested in 3 Google's core products API: Search, Adsense and Adwords but got turned off because their APIs are very crippled. I understand that Google do not want to expose their core products (cash cows) to abuse, however that's exactly what Steve argued in parent's quote. If the closeness (nothing to do with code) is already in Google's mindset, how do they become a "platform oriented company"? Steve says that it will take a dramatic cultural change to catch up. Steve also chooses Amazon's example to prove: when the years of explosive growth were over, Jeff Bezos had to think of some new expansion strategies. He was betting on the cloud, whatever that means, or on being a platform, and he implemented his vision with an iron fist, because paradigm shift is hard, you have to consistently push people into doing it.

But ... in the one case we are aware of, of a whole company, Amazon, using a service oriented architecture, they did it after the fact. The did bolt it on later, or rather, they (according to Steve) ripped everything up and re-did it in this way. I'm sure it was absolute hell to do this, but that is what they apparently did. So it isn't a requirement to build a platform first, then build everything else. It might be nicer to do it that way, if it's the best prioritization of resources at the time, but that's not what happened in the case being discussed.

I would call that very dangerous and very likely a premature optimization. Nobody cares you are a platform until they use your product, and if you spend all your time building a platform, there will be no product to use.

The path requires far more finese than "always create a platform". You need to balance over-engineering with the ability to re-evaluate previous decisions.

I agree Google has wandered far off this path, but imnot sure they are on any more well defined path than Yahoo. They just happen to be earlier.

This applies to startups, less so to more mature companies who can and will throw more resources behind a project. After the prototyping phase, once you're reasonably sure of the direction you're going to go in, it isn't a bad idea to keep extensibility in mind from the start. It's more like premature architecting, if anything, than premature optimization, which is much less offensive (and not even necessarily bad).

I agree with you in principal but I think practically this isn't always possible.

Sometimes you don't know if a product is worth being an entire platform until it's been thoroughly field tested. It's too expensive to assume that everything is.

Perhaps in Google's case there could have been more foresight, though.

Isn't it the same with scalability? You won't know if you need a product to be scalable until you have actually launched it and seen its success.

Yet, every product developed at Google seems to be developed with absolute scalability in mind from the get-go, wasting lots of effort invested into scalability in the case of the product failing to get significant customer adoption.

But Google will only consider a product a success if it achieves sufficient scale, while it would (apparently) be happy to have a successful product that is not a platform.

Since 100% of successful Google products will be large, it makes sense to design for scale from the get-go. But if some of Google's products won't end up being platforms, it might make more sense to bolt that on later.

Reply on news.ycombinator.com