My cousin recently appeared for her BBA interview. The interviewer asked her "Do you read the newspaper?". "Yes", my cousin replied. The interviewer asked an expected follow up question "Which sections of the newspaper do you read?" to which my cousin candidly replied "Actually my father once told me that if the Sensex reaches 20,000 points, he will buy me a laptop. So I check the business Sensex section daily!"
Sunday, August 21, 2011
Friday, August 19, 2011
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
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
Subscribe to:
Posts (Atom)