SOA learnings from Amazon and Facebook

I came across this interesting and very frank article written by Steve Yegge. You can read is here.

Having worked at Amazon for close to 4 years, I could not but agree with Steve's take on Amazon, Platform, SOA and 'Eat Your Own Dog food' concept. Thinking and designing in terms of services comes naturally to SDEs at Amazon.

It is interesting to understand what platform means. Platform is a term for technology that enables the creation of products and processes that support present or future development.

If we talk about software platform, it is a software program that makes services available to other software programs through Application Programming Interfaces (APIs).  e.g. the Java platform is a generic platform that runs programs written in the Java language.

Two notable characteristics about software platforms that I want to quote from the book "Invisible Engines":

Software platforms are at the heart of “ecosystems” that consist of mutually dependent communities of businesses and consumers that have a symbiotic relationship with the platform. 

"Software platform businesses have at least two sides. Software platforms consist of services that are often made available to developers through APIs. They are also made available to computer users, but those computer users typically avail themselves of API-based services by buying applications that in turn use APIs. It is only a slight exaggeration to say that all software platform makers all the time invest in getting both developers and users to use their platforms."

Look at the platform offerings from Amazon via Amazon Web Services(AWS) and Facebook. They provides developers with:

• Software services available through APIs

• Software development kits that facilitate writing applications

• A “developer zone” that provides, for example, access to tools, sample code, and technical support

• Member forums for online discussions with other developers

The AWS offerings now allows creating and hosting enterprise applications completely on the cloud.

Thinking in terms of platform and API allows great deal of innovation. In recent times with the advent of free web services, numerous mashups were created, which in turn created value for end users. Availability of Android OS and the 'apps' it can run has created a win-win situation for developers, hardware manufacturers and end-users.

A good indicator for creating a platform is when a big pieces of inter-dependent business functionalities needs to be realized and the future requirements are unknown or vague at best.

While deciding about creating a platform, it is important to have a clear vision. Some basic questions that needs to be answered are:

• What problem in the platform solving?
• Is the platform reusable? Can many clients benefit from it?
• Who will use it and how?

And then more specific questions like what APIs should be provided and many more. Infact, creating and externalizing a software platform is similar to writing a business plan and then launching a startup! It is learning all the way.

Often while interacting with other software engineers/architects, I find it very difficult to explain the need to go with SOA or think in terms of platform . Software engineers are inherently opposed to the idea. Mainly because they have not seen and experienced the architecture before or 'fear' the additional complexity that comes with it. The most common excuse for not using web services I hear is that SOAP is heavy weight, that web services add complexity and even phrases like "too many moving parts" and "we don't need SOA now"!

Indeed, these are valid statements but the benefits of SOA far exceed these short comings. Companies like Amazon has clearly demonstrated it. Not only does SOA solve business problems, it lowers costs and create values for end customers. With low margins in E-Retailing, Amazon had to adopt it.

The biggest hurdle software developers have to cross is the ability to 'think' in terms of platform and to realize it.

More interesting articles on SOA:
Software design at it's best
SOA @ Amazon

SOA Technology @Amazon

Amazon and Service Oriented Architecture (SOA)

The excerpt below comes from the 2010 Shareholder Letter by Amazon CEO Jeff Bezos. You can read more about other technologies at Amazon here.

"Our technologies are almost exclusively implemented as services: bits of logic that encapsulate the data they operate on and provide hardened interfaces as the only way to access their functionality. This approach reduces side effects and allows services to evolve at their own pace without impacting the other components of the overall system. Service-oriented architecture -- or SOA -- is the fundamental building abstraction for Amazon technologies. Thanks to a thoughtful and far-sighted team of engineers and architects, this approach was applied at Amazon long before SOA became a buzzword in the industry. Our e-commerce platform is composed of a federation of hundreds of software services that work in concert to deliver functionality ranging from recommendations to order fulfillment to inventory tracking. For example, to construct a product detail page for a customer visiting Amazon.com, our software calls on between 200 and 300 services to present a highly personalized experience for that customer."

Continuing from the excerpt above, of course there are challenges with the SOA approach. If 200+ services are called to render a single page, dependencies and handling failures becomes a critical aspect. A critical service failure can directly impact customer experience and revenue loss. Hence the need for software to monitor hardware and software in real time and  generate alerts. Processes need to be set to respond to such events.

Another important aspect is meeting the SLA (service level agreements) for a page. The slowest service will definitely impact the overall load time of the web page. But it also depends on the overall rendering framework. To keep the overall latency low, the services have to be categories based on customer impact, availability and bunch of other factors. Each service will have to meet the SLA defined for it's band.

Meeting SLA for critical services requires sound engineering. Right from understand the use cases, to designing a clean API, designing caching mechanism, using the right hardware and software for the job, handling peak traffic (throttling), capacity planning and monitoring are some of the things to consider even before starting on code.

Another point to consider is the impact of service upgrades on clients. Changing the service interface is not trivial and often requires coordination among multiple teams. More than 1 version of the service needs to be deployed to avoid breaking current systems.

With many services around, service discoverability is difficult. A centralized service registry can help here. To access sensitive data, authentication and authorization needs to be in place. Most of it should be transparent to a service developer.

In short, SOA has some great benefits but it comes with it's own set of baggages. SOA needs an ecosystem of software and processes to reap benefits from it.

You may also be interested in this article: SOA learnings from Amazon