Deviant Abstraction

ACM Queue has just released an interview of Amazon’s CTO Werner Vogels. He is an ancient from Cornell University and is specialised on HA and scalable system (see his thesis work for more information) I read his blog regularly since he addresses themes I work on.

He speaks on various subjects. It seems great to work for Amazon. Should I send them my resume?

My favorite points (I defend them too through this blog and I might have over-interpreted some of his quotes)

• Growth The goal of a new company is to grow (Amazon is still a new company). You will eventually scale up or you will look for another job.
• Operations vs. development In our fast-paced world, those two worlds should be the same. There should be no operations service whose job is to finish “manually” the applications developed in house. Most operations team exist only because the executives are afraid of code and they are bound to disappear.
• Amazon is a technology company The last generation of companies rely heavily on technology. They sell their technology as a service (Google, Amazon, eBay,…) and not as a shrink wrapped software. They tend to see processes everywhere. After defining a process, they automate it. Human work comes into play only when a process fails. The responsible process is then updated. We are in vertuous circle. An employee manages some processes instead of having a job. (Here a process = a service or a composition of service)
• Distributed system is the new norm. Distributed systems are emerging from research and are more and more used. A lot of companies do not know still how to use them efficiently. SOA can help them improve this. Actually SOA is distribution. Where is fault-tolerance and replication? Can we manage them as services?
• REST vs SOAP. No one cares. SOAP and the WS stack is used with IDE (they consume the WSDL file to generate the proxy automatically). REST is used by small libraries (PHP, Python). To create an open Web service you need to support both. They will appeal to two different (and complementary) market segments.
• Scaling need careful planning. When scaling, you are less efficient as when not scaling. This is a general idea valid both in computer science and in life. For instance, you can both work and manage five persons. When managing two hundred persons, most of your time will be spent managing them and not working. You need to delegate. Since scaling takes resources, you need to plan it in time and know it will be resource consuming.
• Cost of messages. This is something quite obvious. SOA creates a network intensive computing environment: you will send a lot more messages to create a page but on your LAN. This is a fine practice since message are costly on WAN/Internet, not on LAN. (To be exact, they both are costly but the differential costs make the LAN negligible.)
• Use SLA. One question has always been: how to measure performance? Actually it depends on your goals. SLA is a good way to formalize your goals in technical terms. It is how carriers are working with their suppliers.

Link to his blog
Link to his interview

This entry was posted on Tuesday, May 16th, 2006 at 5:09 pm and is filed under distributed systems, software, paradigm, web. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.