Amazon的架構經歷了巨大的變化，從一開始時的兩層架構，轉向了分散式的、去中心化的服務平臺，提供許多種不同的應用。
最開始只有一個應用來和後端互動，是用C++來完成的。
架構會隨著時間而演進。多年來，Amazon將增容的主要精力放在後端的資料庫上，試圖讓其容納更多的商品資料，更多的客戶資料，更多的訂單資料，並讓其支援多個國際站點。到2001年，前端應用很明顯不能再做任何增容方面的努力了。資料庫被分為很多個小部分，圍繞每個部分會建立一個服務介面，並且該介面是訪問資料的唯一途徑。
資料庫逐漸演變成共享資源，這樣就很難再在全部業務的基礎之上進行增容操作了。前端與後端處理的演進受到很大限制，因為他們被太多不同的團隊和流程所共享了。
他們的架構是鬆散耦合的的，並且圍繞著服務進行構建。面向服務的架構提供給他們的隔離特性，讓他們能夠快速、獨立地完成許多軟體元件的開發。
逐漸地，Amazon擁有了數百個服務，並有若干應用伺服器，從服務中聚合資訊。生成http://Amazon.com站點頁面的應用就位於這樣的一臺應用伺服器之上。提供web服務介面、顧客服務應用以及賣家介面的應用也都是類似的情況。
許多第三方的技術難以適用Amazon這種網站的規模，特別是通訊基礎架構技術。它們在一定範圍內工作的很好，但是如果範圍再擴大的話，它們就不適用了。因此，Amazon只好自己開發相應的基礎技術。
不在一種技術上"吊死"。Amazon在有的地方使用jboss/java,不過只是使用servets，並沒有完全使用j2ee中所涉及到的技術。
C++開發的程式被用來處理請求。Per/Mason開發的程式用來生成頁面中的內容。
Amazon不喜歡採用中介軟體技術，因為它看起來更像一種框架而不是一個工具。如果採用了某種中介軟體，那麼就會被那種中介軟體所採用的軟體模式所困擾。你也就只能選用他們的軟體。如果你想採用不同的軟體幾乎是不可能的。你被困住了！經常發生的情況就是訊息中介軟體，資料持久層中介軟體，Ajax等等。它們都太複雜了。如果中介軟體能夠以更小的元件的方式提供，更像一個工具而不是框架，或許對我們的吸引力會更大一些。
SOAP 相關的web解決方案看起來想再次解決所有分散式系統的問題。
Amazon提供SOAP和REST這兩種Web 服務。大概有30%的使用者採用SOAP這種Web Services。他們看起來似乎是Java和.NET的使用者，而且使用WSD來生成遠端物件介面。大概有70%的使用者使用REST。他們看起來似乎是PHP和PER的使用者。
無論採用SOAP還是REST，開發人員都可以得到訪問Amazon的物件介面。開發人員想要的是把工作完成，而不需要關心網線上傳輸的是什麼東西。
Amazon想要圍繞他們的服務構建一個開放的社群。他們之所以選擇Web Services是因為它的簡單。事實上它是一個面向服務的體系架構。簡單來說，你只有透過接口才能訪問到需要的資料，這些介面是用WSD描述的，不過它們採用自己的封裝和傳輸機制。
Amazon的架構經歷了巨大的變化，從一開始時的兩層架構，轉向了分散式的、去中心化的服務平臺，提供許多種不同的應用。
最開始只有一個應用來和後端互動，是用C++來完成的。
架構會隨著時間而演進。多年來，Amazon將增容的主要精力放在後端的資料庫上，試圖讓其容納更多的商品資料，更多的客戶資料，更多的訂單資料，並讓其支援多個國際站點。到2001年，前端應用很明顯不能再做任何增容方面的努力了。資料庫被分為很多個小部分，圍繞每個部分會建立一個服務介面，並且該介面是訪問資料的唯一途徑。
資料庫逐漸演變成共享資源，這樣就很難再在全部業務的基礎之上進行增容操作了。前端與後端處理的演進受到很大限制，因為他們被太多不同的團隊和流程所共享了。
他們的架構是鬆散耦合的的，並且圍繞著服務進行構建。面向服務的架構提供給他們的隔離特性，讓他們能夠快速、獨立地完成許多軟體元件的開發。
逐漸地，Amazon擁有了數百個服務，並有若干應用伺服器，從服務中聚合資訊。生成http://Amazon.com站點頁面的應用就位於這樣的一臺應用伺服器之上。提供web服務介面、顧客服務應用以及賣家介面的應用也都是類似的情況。
許多第三方的技術難以適用Amazon這種網站的規模，特別是通訊基礎架構技術。它們在一定範圍內工作的很好，但是如果範圍再擴大的話，它們就不適用了。因此，Amazon只好自己開發相應的基礎技術。
不在一種技術上"吊死"。Amazon在有的地方使用jboss/java,不過只是使用servets，並沒有完全使用j2ee中所涉及到的技術。
C++開發的程式被用來處理請求。Per/Mason開發的程式用來生成頁面中的內容。
Amazon不喜歡採用中介軟體技術，因為它看起來更像一種框架而不是一個工具。如果採用了某種中介軟體，那麼就會被那種中介軟體所採用的軟體模式所困擾。你也就只能選用他們的軟體。如果你想採用不同的軟體幾乎是不可能的。你被困住了！經常發生的情況就是訊息中介軟體，資料持久層中介軟體，Ajax等等。它們都太複雜了。如果中介軟體能夠以更小的元件的方式提供，更像一個工具而不是框架，或許對我們的吸引力會更大一些。
SOAP 相關的web解決方案看起來想再次解決所有分散式系統的問題。
Amazon提供SOAP和REST這兩種Web 服務。大概有30%的使用者採用SOAP這種Web Services。他們看起來似乎是Java和.NET的使用者，而且使用WSD來生成遠端物件介面。大概有70%的使用者使用REST。他們看起來似乎是PHP和PER的使用者。
無論採用SOAP還是REST，開發人員都可以得到訪問Amazon的物件介面。開發人員想要的是把工作完成，而不需要關心網線上傳輸的是什麼東西。
Amazon想要圍繞他們的服務構建一個開放的社群。他們之所以選擇Web Services是因為它的簡單。事實上它是一個面向服務的體系架構。簡單來說，你只有透過接口才能訪問到需要的資料，這些介面是用WSD描述的，不過它們採用自己的封裝和傳輸機制。