Learned from "A Conversation with Werner Vogels"

What I learn from:
http://queue.acm.org/detail.cfm?id=1142065

Growth impact:
  Larger data sets, faster update rates, more requests, more services, tighter SLAs (service-level agreements), more failures, more latency challenges, more service interdependenceies, more developers, more documentation, more programs, more servers, more networks, more data centers.

Progress:
  There were many complex pieces of software combined into a single system. It could not evolve anymore. The parts that needed to scale independently were tied into sharing resources with other unknown code path. There was no isolation and, as a result, no clear ownership.
  Service orientation becomes encapsulating the data with the business logic and operates on the data, with the only access through a published service interface.
  Grew into hundreds of services and a number of application servers that aggregate the information from the services.
  Move from a two-tier monolith to a fully distributed, decentralized, services platform serving many different applications.

Outcomes:
  Strict service orientation is an excellent technique to achieve isolation; you come to a level of ownership and control that was not seen before.
  By prohibiting direct database access by clients, you can make scaling and reliability improvements to your service state without involving your clients.
  If you want to insert advanced infrastructure techniques such as decentralized request routing or distributed request tracking, you need a single unified service-access mechanism.
  The developement and operational process has greatly benefited from using services.
  Giving developers operational responsibilities has greatly enhanced the quality of the services.

Headaches:
  How do you make sure that developers are productive?
  How can you make sure that all the pieces work together as intended, now and in the future?
  How do you test in this environment?

How to make decision:
  Scope and prototype the idea quickly. New ideas are enabled through the loosely coupled services model.

How to measure:
  Have good understanding of how customers interact with the site.
  Most of our developers are in the loop with customers.

Integrated with partners:
  Provide branded web sites for the general retail partners.

Fallacies of distributed computing

Good reading materials about common problems of the distributed computing.

http://en.wikipedia.org/wiki/Fallacies_of_distributed_computing

1. The network is reliable
2. Latency is zero
3. Bandwidth is infinite
4. The network is secure
5. Topology does not change
6. There is one administrator
7. Transport cost is zero
8. The network is homogeneous

http://www.somethingsimilar.com/2013/01/14/notes-on-distributed-systems-for-young-bloods/

• Distributed systems are different because they fail often.
• Writing robust distributed systems costs more than writing robust single-machine systems.
• Robust, open source distributed systems are much less common than robust, single-machine systems.
• Coordination is very hard.
• If you can fit your problem in memory, it’s probably trivial.
• “It’s slow” is the hardest problem you’ll ever debug.
• Implement backpressure throughout your system.
• Find ways to be partially available. 
• Metrics are the only way to get your job done.
• Use percentiles, not averages.
• Learn to estimate your capacity.
• Feature flags are how infrastructure is rolled out.
• Choose id spaces wisely.
• Exploit data-locality ?
• Writing cached data back to persistent storage is bad. 
• Computers can do more than you think they can ?
• Use the CAP theorem to critique systems.
• Extract services.