Bezos比軟體工程師更理解API
這篇看過的人不多，而且我也有新的消化輸出，所以分享給大家囉！😉
The Bezos API Mandate: Amazon’s Manifesto For Externalization | Nordic APIs |
關於Bezos的「API命令」，這可說是科技史中堪稱是教科書等級的一個大事件。雖然這當然不是新聞，會看科技媒體的應該都有瀏覽過，但我想以自己的角度也深入去思考一輪，輸出跟大家分享。
這是在2002年的事，當時還是Amazon的CEO的Bezos，為了徹底強化在AWS的骨幹系統，不論是在效能上還是在思維上，他下達了這個重要的命令。遵循著Amazon一貫的簡潔明瞭的文件作風，內文很簡單就7點而已：
- All teams will henceforth expose their data and functionality through service interfaces(所有的團隊，從此只能透過介面，來提供資料及服務).
- Teams must communicate with each other through these interfaces(團隊間的溝通，也只能透過介面來進行).
- There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network(工具間的溝通實作，不能以下列方式處理：直連存取，透過團隊資料存儲區，共享記憶體模式，或是任何類似的「後門」。這些工具唯一的通訊方式，就是透過網路的服務介面進行).
- It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter(上述的通訊協定，用HTTP, Corba, Pubsub，甚至是自訂協定都可以，不重要).
- All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions(所有的服務介面，沒有例外，必須從骨子裡就被設計成可以對外服務。也就是說，設計介面的團隊，就是要設計成要給公司外的開發者使用，沒有例外).
- Anyone who doesn’t do this will be fired(不照做的就會被解僱).
- Thank you; have a nice day(謝謝大家，祝你們有美好的一天)!
雖然說是舊文，這次我就認真的把它們給翻譯一輪。這七點其實都指向同一個重點，Bezos想從骨子裡來改造Amazon的服務「體質」。
去除「窗口」，打破孤島，強迫協作
API是一種具「疊加性」的溝通方式，和我們認為方便的「一站式」服務有很大的不同，也就是所謂的「窗口」。我們要取得其他單位的服務，若只是找到窗口，簡單說一聲要什麼資料或服務，剩下的”運算”就都得由這個窗口執行。
但API通常都只是提供一些基礎的功能而已，用戶想要什麼資料，想要什麼服務，就得靠這些基礎的「零件」自己打造。雖然對不習慣，沒經驗的用戶，會需要一段時間學習及開發，但一回生二回熟，其實學習曲線也不算高，很快就能串起自己要的”功能”。
由於不能再透過其他的方式交換資料及服務，所有單位就必須提供出足夠的API介面。不管是工程單位，財會單位還是業務單位，沒有一個單位可以置身事外，可以要求別人follow他們的規矩。因為規矩只有一條 - 你得把你的介面貼出來。這不但打破了孤島效應，也間接的強迫協作，沒有什麼東西可以被「人」藏起來。
文中提到說，有人質疑這樣的作法不合理。讓窗口為需要服務的單位，提供”最佳化”的服務不是應該比較好嗎？但Bezos想的事情肯定和我們不同：他要的是「規模化(Scalibility)」。窗口的服務再怎麼好，也就只是一個人或一個團隊。可一但我們把資料及服務的存取變得像24小時全年無休的自動販賣機一樣時，這才真正把”最佳化”這件事給規模化了：每一個用戶都可以決定，怎麼樣最佳化的解決他們的需求。
溝通的「效率」來自於介面的一致性
由於API天生的特性，就是將實作細節給封裝起來，這無疑就打破了低效溝通的最大元兇 - 介面的不一致性。
當你向業務部門要資料，它只能給你Word檔；向財會部門要資料，它給你的是Excel；你問了下後台的數據如何，它用SQL查給你；要查一下產品的規格的話，可能是一個網頁或是PDF等等。這是不同的資料介面，拿到資料後你得自己整理成需要的樣子。
同樣的，要求不同的部門服務時，有的人處理完是回電給你，有的人是用LINE通知，有的人會走過來直接跟你說一聲等等。這是不同的功能介面，你得瞭解每個人或每個部門的「眉角」，排出一個合理的工作流，才能比較順暢的把事情處理好。
這一些若是有了新的部門，新的資料，新的執行窗口，就會讓執行的效率再有新的變數。
一但所有的協作都”只”用API進行，不管API後面是哪種資料庫或函式庫處理的，用戶只在乎API是否有在預期的時間，得到他想要的回答。這全程沒有「人」的問題，就沒有所謂的「眉角」。協作的過程，只要有「人」進來成為存取資料及服務的節點，那通常就是效率最差的弱點。
另一個API帶來的優勢是「相容性」。資訊技術日新月異，永遠都會有更好的新工具，新軟體，新服務，新技術等等。而許多需求可能根本就和實作技術無關，若取得資料及服務的介面，是完全依賴在特定的工具或服務上(就像之前提到的Word/Excel/DB/PDF…)的，這就意味著有朝一日必然會遭遇”改版”的需求。
相反的，若一開始就訂好了API這種存取資料或服務的方式，那這API的底下是怎麼運作的，就是一個可以與時俱進的實作。反正用戶也不在乎你是怎麼提供服務或資料的，他只在乎同樣的方法，有沒有辦法拿到資料。
從骨子裡就開始面對客戶，在血液中就流著用戶思維
Bezos要求所有的API，都要設計成可以直接提供外部用戶使用，而且沒有例外。以工程師的角度來說，這意謂著他們不能隨便亂加一些無謂的全域變數，無用的類別，也不能為了趕時間貪方便，就以破框的方式來開發系統；即便是非工程單位，他們的API除了要想怎麼跟內部團隊協作，也要去思考「真正的用戶」會需要什麼介面。沒經過大腦思考就亂訂一通，開出來的API，就像沒睡飽亂講話一樣。
API代表的，就是最終的商業邏輯，不論它是不是真的純商業行為。「只能用API交換資料，存取服務」，「API都必須能直接提供外部用戶使用」，「API才能保持其一致性」這些讓人很頭皮發麻，很”麻煩”的事情，才真的能促使整個團隊在面對自己的產品，都是從骨子裡就開始面對客戶，在血液中隨時流著的都是用戶思維。
沒照做的就請離開
不管Bezos的這個指令有多傳奇，多有真知灼見，但最重要的可能是第6點：Anyone who doesn’t do this will be fired。可想而知對非軟體工程團隊的人來說，這是一個多”不合理”，多勞師動眾的一個要求。但若不是Bezos的這道指令，若不是這麼強悍的執行力，Amazon就不是今天這個樣子了。