AWS 的產品邏輯：組合

OOP編程中有一個經驗：prefer composition to inheritance. 組合優於繼承。在工作的幾年裡一直接觸AWS的雲服務，涉及了很多AWS的服務產品。在歐美，Amazon Web Service(AWS)是雲服務提供商三巨頭之一，每當有新產品發布的時候，筆者注意到一個新產品的發布和迭代，都是建立在先前產品的基礎上，初看一下，覺得這個產品和以前某個服務很相似，比如，SQS和Kinesis，都是關於Messaging的產品，但是細分的功能不同，用例也不同。今天梳理一下AWS的發布產品時間線（不完全統計）：

2006: 發布Simple Queue Service。消息隊列服務。

2006: 發布EC2。這是整個AWS計算能力的硬體基礎。

---- 2006 是AWS雲服務打下基礎的元年 ---

2007: 發布SimpleDB： 在EC2和S3的基礎上。提供NoSQL的數據查詢，簡單索引查詢。由於S3的產品定位是對象存儲，而SimpleDB則是提供了更加細緻的存儲粒度，可以對一個對象的任何一個attribute建立索引。在官方的文檔中，其指明了SimpleDB就是為了充分結合EC2的計算能力和S3的存儲基礎，來提供更加方便，快速的存儲方式。

2008: 發布EBS： 基於EC2，提供彈性塊存儲，SSD或HHD。提供多樣的存儲物理方式。更加強調了IO性能。

2009: 發布Elasic MapReduce: 在EC2的基礎上，提供MR的框架，數據可以直接存儲在S3或其他AWS的資料庫服務里。

2009: 發布Auto-Scaling: 動態的調節EC2的數量

2009: 發布RDS: 架設Full featured關係型數據產品，在EC2的基礎上

2010: 發布SNS: SMS，Email等通知的推送，訂閱。推送的本質就是消息的傳遞，有什麼現成的消息傳遞工具？就是SQS。

2011: 發布Elastic Beanstalk: 使得在AWS部署代碼更加方便

2011: 發布SES：Simple Email Service，注意和SNS的區別。

2012: 發布DynamoDB

2012: 發布Glacier：用於文件的長期存儲，更加廉價。

2013: 發布Kinesis：實時數據流的處理。

2014: 發布EC2 Container Service

2014: 發布Lambda：

2015: 發布IoT

2016: 發布Elastic File System: 企業級的文件系統，為EC2提供另一種存儲服務。

閱讀AWS的產品手冊，通篇出現最多的字眼就是：Availability，Durability，Maintainability，Scalable，Managed。這些特點（也是賣點）是每一個AWS服務所具備的，這跟AWS底層的架構有關，AWS也正是將這些特點充分發揮，組合出了許多產品線。

從這條時間線上來看，AWS雲服務的三大基石：「存儲，計算，消息傳遞」在2006就已經確立，隨後發布的大多數產品，都是在這三大基礎的組合之後的擴展，細分和差異化。

有時候我甚至在想，產品經理覺得開始想一個新產品的概念：然後Brainstorm：

• 如何讓用戶部署？我有Beanstalk。
• 如果用戶壓根兒就不想部署嘞？我有Lambda。
• 用戶在哪裡跑代碼？我有EC2。不想用？我有Container Service.
• 用戶在哪裡存結果？我有S3，EBS，Glacier, RDS
• 如何監控？我有Cloudwatch
• 如何傳遞連接其他內部AWS的服務？我有SQS，Kinesis

如此看來，Amazon的產品經理們，還是很懂得1+1>2的玩法。更何況自家的現有的N個產品，內部拿來就用。在早年的一篇文章STEVEY對AMAZON和GOOGLE平台的吐槽中，可以看出早在2002年，service orientated這個概念就已經在其內部各個部門開始協作。

看起來很熟悉？嗯，最近Microservice的架構很火。

PS: Amazon從未透露出任何服務的底層實現細節，以上所說都是基於我個人使用經驗的推測.