Thoughts on software, running and other things

Platforms and Services: why you(r company) need(s) them

This is a gist of the Steve Yegge‘s phenomenal(ly long) Google Platforms Rant, which lists the only three things he thinks were done well by his former company and are the only things his current company hasn’t got right. The most important of these was Platforms. The hows & whys are a fascinating and a long read and the discourse is much posted on the internet. Steve has since offered his apology/follow up to the accidental disclosure of what was supposed to be a private memo. At least that’s my understanding of the story, as are the following lessons from the post, laid out for those short of time.

Platforms are needed since no one can always build the right thing for everyone. Anything that a company can build, if it’s extensible – like a platform, can be used by others to build the right thing for themselves. Which is what all the big companies, are trying to achieve. Amazon, Microsoft and Facebook have had a lot/some success with this model and are constantly enhancing it.

Interwoven with the importance of Platforms are Services and SOA, which enable Platforms. This is what Amazon have done supremely well. All their teams expose data/functionality via service interfaces, which are built to be externalisable from the start. No other form of interaction is allowed – definitely no back-doors. This was done under the pain of being fired initially, but later became a culture because it was self-apparently the right thing to do.

The path to such a nirvana-esque state of affairs is littered with hardship and lessons. A very small sample: every service has to be on guard against all others and the developer has to be on guard for the service to be actually up and running, which means monitoring becomes same as demanding automated QA. Debugging is only possible if it’s each service can run in a debuggable sandbox. And Accessibility or discoverability becomes paramount – the Most Important Thing, as per Steve, cue the universal service registry.

Any product without a platform will be replaced by something similar with one. It’s no use trying to build a product – you should allow others to build a range of products by providing a platform, which makes the product, or it’s future incarnations, accessible to others. A well defined API will enable the fulfillment of the Golden Rule of platforms: Eat Your Own Dogfood (basically using the software you build to work out it’s kinks), making the product better as development continues.

Steve’s take on the Golden Rule: “Start with a Platform, and Then Use it for Everything“. The longer the delay in starting with platforms/services, the more the work needed, the closer you get to Too Late. And don’t cheat along the way – no back doors for internal apps, for ANY reason. Solve the hard problems up front. That is the only way for a company to stay competitive in today’s market.

I’ve left out a lot of specifics Steve went into, please do read them when you get the time. The idea of Platforms / hardcore SOA was quite outlandish when it was first imposed on Amazon, but is now an integral part of their’s and a lot of other biggies’ growth, usually in areas that didn’t exist when the process started. To me that offers the blue sky portion of the reasoning behind this whole concept. Some of the benefits of this may be outside the scope of a company’s current strategy. But there are other tangible benefits like quicker turnaround, easier scalability and neat, easily deployable chunks of applications in place of monoliths, to name a few. The work needed to get through the first few stages is not easy, but now we have sufficient examples, some included in Steve’s discourse, to prove that Services are the future, at least for now.