AWS的工程師如何開發(fā)和維護(hù)他們的內(nèi)部技術(shù),aws內(nèi)部如何研發(fā)AWS的工程師如何開發(fā)和維護(hù)他們的內(nèi)部技術(shù)如今硅谷內(nèi)外各大企業(yè)已經(jīng)尋找到了自己獨(dú)特的快速開發(fā)及部署功能特性的方式。而在云服務(wù)巨頭亞馬遜的體系中,擁有一個(gè)“Away Teams”的特殊處理機(jī)制,它的核心概念為:接受自身某些弱點(diǎn)以獲取最優(yōu)解。El Reg曾經(jīng)花了......
如今硅谷內(nèi)外各大企業(yè)已經(jīng)尋找到了自己獨(dú)特的快速開發(fā)及部署功能特性的方式。
而在云服務(wù)巨頭亞馬遜的體系中,擁有一個(gè)“Away Teams”的特殊處理機(jī)制,它的核心概念為:接受自身某些弱點(diǎn)以獲取最優(yōu)解。
El Reg曾經(jīng)花了數(shù)月的時(shí)間與該機(jī)制多位相關(guān)人員進(jìn)行探討,現(xiàn)在將正式與大家進(jìn)行分享。由于亞馬遜員工無(wú)權(quán)公開討論企業(yè)內(nèi)部事宜,我們的信息源還會(huì)保持匿名的形式。同時(shí)亞馬遜云服務(wù)(Amazon Web Services,下簡(jiǎn)稱為AWS)官方發(fā)言人拒絕對(duì)我們的調(diào)查結(jié)果發(fā)表評(píng)論。
亞馬遜從未像公開其領(lǐng)導(dǎo)力原則一樣支持公開編纂他們的管理體系,因此要捕捉亞馬遜這樣規(guī)模巨頭的方法機(jī)制總會(huì)是一個(gè)挑戰(zhàn)。但以下的描述或許可以為那些尋求大規(guī)模團(tuán)隊(duì)協(xié)作開發(fā)解決方案的人們提供一些新的思路。
當(dāng)前面臨的挑戰(zhàn)
一旦企業(yè)的工程師以及技術(shù)員工人數(shù)達(dá)到數(shù)百或數(shù)千時(shí),整個(gè)組織將會(huì)超出傳統(tǒng)團(tuán)隊(duì)協(xié)作的負(fù)荷。當(dāng)開發(fā)陷入混亂時(shí),就需要尋求某種可以支持20,50或者100個(gè)小團(tuán)隊(duì)互相協(xié)作的管理方式。
敏捷(Agile and Scrum)以及DevOps等方法可以支持特定項(xiàng)目從概念階段到交付階段中的持續(xù)演進(jìn),但這些方法并不會(huì)優(yōu)化現(xiàn)有各團(tuán)隊(duì)間的協(xié)作方式。
為平臺(tái)或者應(yīng)用程序創(chuàng)建完整且連貫的解決方案是較為基礎(chǔ)的需求,即便是組織一個(gè)專業(yè)團(tuán)隊(duì)來(lái)進(jìn)行實(shí)施也是如此。所以無(wú)論最初對(duì)團(tuán)隊(duì)協(xié)作考慮的多么全面,后期總會(huì)需要進(jìn)行一定程度的調(diào)整。
企業(yè)中各個(gè)團(tuán)隊(duì)都是為了某種特定目標(biāo)而設(shè)立的。甚至各團(tuán)隊(duì)還負(fù)責(zé)各自獨(dú)立的盈利或是虧損,獨(dú)立的目標(biāo)或是關(guān)鍵指標(biāo)(例如受到Intel企業(yè)使用經(jīng)歷的啟發(fā)而采用OKR模式的Google)。但在現(xiàn)今的企業(yè)平臺(tái)中,幾乎所有應(yīng)用于整個(gè)企業(yè)的服務(wù)相互間都有著密切關(guān)聯(lián)。
當(dāng)有人向你的團(tuán)隊(duì)提出挑戰(zhàn),需要在你的團(tuán)隊(duì)正在交付的服務(wù)中發(fā)起一個(gè)新的請(qǐng)求,例如新功能,修復(fù)錯(cuò)誤或是進(jìn)行優(yōu)化性能,你會(huì)怎么處理?你會(huì)給他們權(quán)限訪問(wèn)你的源代碼嗎?如果新功能能獲得用戶或是客戶的歡迎,你會(huì)將新功能的后期維護(hù)保留在你的團(tuán)隊(duì)內(nèi)部,或是將其交給負(fù)責(zé)交付的團(tuán)隊(duì)?如果你的團(tuán)隊(duì)可以添加一項(xiàng)能幫助其他團(tuán)隊(duì)增加收入的功能,那么你應(yīng)該在完成已規(guī)劃好的功能前添加這項(xiàng)功能嗎?
如果有任何人覺(jué)得以上問(wèn)題可以被輕松解決,并且企業(yè)內(nèi)部每人都可以完成對(duì)的事,那么他/她一定沒(méi)有在大型組織中真正工作過(guò)。
當(dāng)然,良好的管理層應(yīng)協(xié)調(diào)團(tuán)隊(duì),幫助他們更好地進(jìn)行協(xié)同工作。但尋求管理層的協(xié)助總會(huì)在某種程度上減慢工作效率。另外必須明確的是:管理層也并不總能做出正確的決定。
亞馬遜團(tuán)隊(duì)協(xié)作機(jī)制
亞馬遜自成立初期就面臨著以上提到的這些問(wèn)題。他們創(chuàng)建了一個(gè)基于面向服務(wù)架構(gòu)(SOA)的系統(tǒng)(增添了某些特有的創(chuàng)新點(diǎn)以適配亞馬遜這樣一個(gè)互聯(lián)網(wǎng)公司的管理模式)。
2017年在舊金山舉辦的全球人工智能大會(huì)中,Andrew Ng(斯坦福研究員,企業(yè)家以及AI專家)曾發(fā)表過(guò)一個(gè)演講,其中解釋道:真正的互聯(lián)網(wǎng)公司并不是一個(gè)擁有線上網(wǎng)站的購(gòu)物中心,而是一個(gè)能夠響應(yīng)快速迭代,擁有A/B測(cè)試以及自上而下設(shè)計(jì)方法的公司。
亞馬遜并沒(méi)有重新發(fā)明一個(gè)新的模式,它只是正在研究許多公司面臨的相同問(wèn)題,似乎也確實(shí)找到了解決問(wèn)題的方法。亞馬遜創(chuàng)建了一個(gè)優(yōu)化內(nèi)部團(tuán)隊(duì)協(xié)作的機(jī)制,并強(qiáng)制下達(dá)指令要求內(nèi)部團(tuán)隊(duì)構(gòu)建各自獨(dú)立服務(wù)接口,這些服務(wù)必須基于A/B測(cè)試以及自上而下的設(shè)計(jì)方法。這樣的機(jī)制促成了企業(yè)內(nèi)部團(tuán)隊(duì)協(xié)作的一個(gè)新概念:Away Teams。
事實(shí)證明亞馬遜體系,尤其是Away Teams,與技術(shù)哲學(xué)家的研究結(jié)果一致。例如Ray Kurzweill對(duì)近年來(lái)技術(shù)指數(shù)級(jí)發(fā)展的分析,以及麻省理工學(xué)院教授Eric Von Hippel關(guān)于用戶驅(qū)動(dòng)創(chuàng)新能力的文章。
來(lái)自Yegge的討論:亞馬遜面向服務(wù)架構(gòu)的轉(zhuǎn)變
根據(jù)我們的了解來(lái)看,亞馬遜的CEO杰夫貝索斯(Jeff Bezos)擁有著非常強(qiáng)勢(shì)的管理風(fēng)格。從公司執(zhí)行層面來(lái)探討的話,這樣的管理風(fēng)格的確是企業(yè)變革的必要因素之一。
Bezos使用了他的領(lǐng)袖魅力以及他作為CEO的權(quán)利要求亞馬遜改造自己,并要求https://Amazon.com必須使用自己生產(chǎn)的云服務(wù)。其中的改造可能是目前AWS的負(fù)責(zé)人Andy Jassy提到的全面移除Oracle技術(shù)(Amazon completely off Oracle)。但我最喜歡的改造是在“Yegge Rant”中敘述的亞馬遜向面向服務(wù)架構(gòu)的轉(zhuǎn)變。
Steve Yegge曾經(jīng)是亞馬遜的員工,工作了幾年后轉(zhuǎn)為替Google工作。2002年左右,Bezos要求亞馬遜所有的團(tuán)隊(duì)都要以公開服務(wù)接口的方式,提供數(shù)據(jù)和各種功能。Yegge在發(fā)布的相關(guān)討論帖(發(fā)布在現(xiàn)已棄用的Google+上)中解釋說(shuō),這個(gè)強(qiáng)制的命令引起了亞馬遜內(nèi)部的巨大波瀾。亞馬遜員工們需要學(xué)習(xí)以及探索各式技術(shù)以及操作問(wèn)題,例如面向服務(wù)架構(gòu)的錯(cuò)誤定位,服務(wù)性能控制(任意一個(gè)公司內(nèi)部團(tuán)隊(duì)都可能突然發(fā)起大量請(qǐng)求,成為一個(gè)潛在的DOS攻擊者),服務(wù)監(jiān)控,服務(wù)發(fā)現(xiàn)等等機(jī)制。另外,我們可以了解到這篇文章發(fā)布后,不久就被Yegge刪除并對(duì)文章的發(fā)表表示了懊悔。
這樣的強(qiáng)制命令就按照Bezos的計(jì)劃順利進(jìn)行下去了,并由此圍繞著服務(wù)架構(gòu)本身一些有趣的原則創(chuàng)建出了一種全新的技術(shù)文化。其中一個(gè)可能的(我們還沒(méi)有獲取到多個(gè)渠道信息可以支持交差驗(yàn)證)原則是:一旦某個(gè)團(tuán)隊(duì)成為了某個(gè)特定API唯一的用戶,他們就會(huì)成為該服務(wù)的所有者,即使他們并不是這個(gè)服務(wù)的開發(fā)者。
但是,對(duì)于一個(gè)成熟的面向服務(wù)的體系架構(gòu)而言,單獨(dú)的某個(gè)技術(shù),工具或者操作并不能解決內(nèi)部協(xié)作的問(wèn)題。這是亞馬遜開辟新天地的地方,尤其是Away Teams的概念。我們好像沒(méi)有聽過(guò)說(shuō)亞馬遜將其正式定義為該模式的名稱,但用它來(lái)解釋面向服務(wù)架構(gòu)似乎很合適。
亞馬遜面向服務(wù)架構(gòu)的協(xié)作機(jī)制
以下是我們對(duì)亞馬遜面向服務(wù)架構(gòu)的協(xié)作方式的研究:
團(tuán)隊(duì)結(jié)構(gòu)
·任何一個(gè)負(fù)責(zé)某項(xiàng)服務(wù)的團(tuán)隊(duì)都有一系列需要達(dá)成的目標(biāo)和衡量目標(biāo)達(dá)成的收支指標(biāo)。為了實(shí)現(xiàn)這些目標(biāo),團(tuán)隊(duì)通常會(huì)制定服務(wù)演進(jìn)圖。
·團(tuán)隊(duì)?wèi)?yīng)是自主的,可以做出實(shí)現(xiàn)目標(biāo)所需的任何重要決定。
·“對(duì)客戶的價(jià)值”是每個(gè)團(tuán)隊(duì)的使命的一部分。使用模擬發(fā)布方式(Mock)保證開發(fā)人員牢記最終用戶的需求。
·團(tuán)隊(duì)盡可能地保持小規(guī)模,堅(jiān)持兩個(gè)披薩原則,大約為六個(gè)人的團(tuán)隊(duì)。
·服務(wù)可以被重構(gòu),也可以將其拆分為新服務(wù)并分配給一個(gè)新的團(tuán)隊(duì)。沒(méi)有工作量的團(tuán)隊(duì)將被叫停,他們的技術(shù)產(chǎn)出將由其他團(tuán)隊(duì)接手或被廢棄。
·新團(tuán)隊(duì)通常會(huì)來(lái)處理緊急的端到端問(wèn)題。
開發(fā)流程
·團(tuán)隊(duì)使用一組共享的開發(fā)工具或共享服務(wù)進(jìn)行源代碼管理以及開發(fā)流水線管理。其中有許多常用的工具和服務(wù),每個(gè)團(tuán)隊(duì)都可以自主選擇來(lái)快速完成工作,不做硬性要求。盡管如此,在某些時(shí)候還是需要解釋團(tuán)隊(duì)選擇特殊工具的原因。
·DevOps模型完全被采用并接受,每個(gè)團(tuán)隊(duì)都會(huì)為其服務(wù)提供運(yùn)營(yíng)支持。
·訪問(wèn)大多數(shù)源代碼并不難,通常一團(tuán)隊(duì)在沒(méi)有事先約束的情況下,可以很容易地看到另一團(tuán)隊(duì)的源代碼。然而還是難免會(huì)有一些例外的情況。
·A/B測(cè)試和詳細(xì)監(jiān)控普遍用于站點(diǎn)和基礎(chǔ)設(shè)施的各個(gè)方面。測(cè)試由一個(gè)基于WebLab服務(wù)的團(tuán)隊(duì)提供支持,該團(tuán)隊(duì)負(fù)責(zé)培訓(xùn)員工如何使測(cè)試結(jié)果更易于統(tǒng)計(jì)。
·團(tuán)隊(duì)通常不必?fù)?dān)心內(nèi)部資源使用率。不會(huì)有單獨(dú)的內(nèi)部統(tǒng)計(jì)維度來(lái)跟蹤資源的使用情況。服務(wù)內(nèi)部使用率會(huì)作為預(yù)算流程的一部分進(jìn)行統(tǒng)計(jì),并由財(cái)務(wù)團(tuán)隊(duì)進(jìn)行監(jiān)控。他們會(huì)定期與團(tuán)隊(duì)會(huì)面,討論服務(wù)的任何異常增長(zhǎng)并鼓勵(lì)團(tuán)隊(duì)對(duì)其進(jìn)行優(yōu)化。
·減少技術(shù)債并不是做任何事情的好理由,除非它對(duì)實(shí)現(xiàn)團(tuán)隊(duì)目標(biāo)產(chǎn)生影響。
協(xié)作實(shí)踐
·對(duì)某團(tuán)隊(duì)所有服務(wù)的修改需求可能會(huì)由另一個(gè)團(tuán)隊(duì),也就是所謂的Away Team進(jìn)行實(shí)施。該團(tuán)隊(duì)會(huì)根據(jù)已建立的工程標(biāo)準(zhǔn)處理服務(wù)所有者的代碼,以便根據(jù)工程標(biāo)準(zhǔn)添加所需的代碼。接下來(lái)Away Team會(huì)將該代碼維持在良好可維護(hù)的狀態(tài),并由該服務(wù)所有者所在團(tuán)隊(duì)進(jìn)行后期維護(hù),并在需要時(shí)提供幫助。
·如果請(qǐng)求者沒(méi)有能力基于服務(wù)的演進(jìn)規(guī)劃來(lái)進(jìn)行服務(wù)修改需求的實(shí)施,而導(dǎo)致了無(wú)法采用Away Team這樣的模式。這通常是由于該服務(wù)的演進(jìn)規(guī)劃不夠全面,因此為了容納新的需求則需要重新調(diào)整現(xiàn)有的服務(wù)演進(jìn)規(guī)劃。
·如果使用Away Team模式對(duì)服務(wù)進(jìn)行擴(kuò)展時(shí),由于某種原因無(wú)法繼續(xù)往下進(jìn)行。那么此時(shí)可以進(jìn)行復(fù)制原有服務(wù)或創(chuàng)建一個(gè)新的服務(wù)等能夠推進(jìn)你的進(jìn)度所需的任何操作。只要能夠幫助進(jìn)度的推進(jìn),就不必?fù)?dān)心平臺(tái)內(nèi)部各服務(wù)間的重復(fù)。·創(chuàng)建服務(wù)的團(tuán)隊(duì)在做出對(duì)其他服務(wù)產(chǎn)生積極影響的事情時(shí)會(huì)獲得信譽(yù)以及管理層的認(rèn)可,這樣的影響通常是直接影響損益的。
·“Bar Raisers”是一種作為獨(dú)立專家角色的亞馬遜員工。他們?nèi)粘?huì)在其他團(tuán)隊(duì)進(jìn)行工作,但會(huì)對(duì)負(fù)責(zé)的服務(wù)站在相對(duì)獨(dú)立的角度上進(jìn)行關(guān)鍵決策,例如招聘,宣傳,設(shè)計(jì)、客戶體驗(yàn),架構(gòu),A/B測(cè)試等方面。這可能違背了對(duì)于Bar Raisers這個(gè)角色的初始定義,但在這樣的操作模式下,問(wèn)題會(huì)很容易被注意到并且易于更高級(jí)別的管理層進(jìn)行管理。
這些關(guān)鍵原則被運(yùn)用在了亞馬遜的各個(gè)不同階段:
亞馬遜最古老的原創(chuàng)技術(shù)通常被稱為L(zhǎng)egacy平臺(tái),之后誕生了有一個(gè)名為MAWS的非公開內(nèi)部服務(wù)平臺(tái),我們耳熟能詳?shù)腁WS是它最新的公開形式。但在這個(gè)演進(jìn)過(guò)程中也可能還有其他我們未曾聽說(shuō)過(guò)的平臺(tái)。
例如,https://Amazon.com或Kindle等舊產(chǎn)品可能會(huì)使用三個(gè)平臺(tái)中的服務(wù)。Alexa和Echo等新產(chǎn)品則可能更傾向于在AWS上使用更多公共服務(wù)。
從Legacy到MAWS甚至是到AWS的過(guò)程中,開發(fā)工具已進(jìn)行了多代演進(jìn),所有這些演進(jìn)都需要數(shù)年才能完成。
AWS以外的團(tuán)隊(duì)不太會(huì)在單個(gè)服務(wù)或是團(tuán)隊(duì)層面有直接的損益產(chǎn)生。所以一般而言,AWS團(tuán)隊(duì)對(duì)單個(gè)服務(wù),團(tuán)隊(duì)以及損益之間的邊界擁有著最多的經(jīng)驗(yàn)。
這是在與組織的不同層面和不同觀點(diǎn)的許多人訪談后得出的結(jié)論,可以讓我們理清自己的思路。但找到了解整個(gè)情況和詳細(xì)歷史的人并不是一件容易的事,就像亞馬遜的公關(guān)人員總是說(shuō):我們隨時(shí)準(zhǔn)備與亞馬遜首席技術(shù)官Werner Vogels坐下來(lái),詳細(xì)聊一聊。
Kurzweil和Von Hippel介紹面向服務(wù)架構(gòu)的協(xié)作
亞馬遜的模式鼓勵(lì)團(tuán)隊(duì)對(duì)接團(tuán)隊(duì),服務(wù)對(duì)接服務(wù)這樣直接的協(xié)作方式,以便在每個(gè)團(tuán)隊(duì)在需要對(duì)某個(gè)服務(wù)進(jìn)行優(yōu)化時(shí),盡可能多地取得進(jìn)展。
當(dāng)記者開始了解亞馬遜的模型時(shí),我意識(shí)到面向服務(wù)架構(gòu)的協(xié)作結(jié)構(gòu)使用了兩位著名研究人員記錄在冊(cè)的技術(shù)優(yōu)化方案。
麻省理工學(xué)院教授Eric Von Hippel對(duì)用戶驅(qū)動(dòng)創(chuàng)新的研究表明,當(dāng)用戶直接獲得創(chuàng)建解決方案的手段時(shí),跟高幾率會(huì)產(chǎn)生巨大的創(chuàng)新。否則必須將一系列需求相關(guān)的“粘性信息”呈現(xiàn)在需求文檔中或從用戶傳遞給開發(fā)者,這非常困難并很大幾率無(wú)法完成。但如果用戶和開發(fā)者是同一個(gè)人或處于同一個(gè)團(tuán)隊(duì)時(shí),就不必執(zhí)行此步驟,這樣的結(jié)果反而會(huì)更好。亞馬遜的Away Teams也秉持著這一概念,并允許團(tuán)隊(duì)創(chuàng)建具有高度適應(yīng)性的服務(wù)。
Ray Kurzweil在技術(shù)指數(shù)級(jí)發(fā)展的分析中提供了另一個(gè)思路,通過(guò)它可以解釋亞馬遜模型的內(nèi)涵。記者總結(jié)了Kurzweil在技術(shù)杠桿研究使命中的模型,他論文的觀點(diǎn)如下:
·起初,任何技術(shù)領(lǐng)域的進(jìn)展看似非常緩慢,這是由于當(dāng)時(shí)處在正在開發(fā)基本服務(wù)的階段
·但是接下來(lái)到了使用簡(jiǎn)單的服務(wù)構(gòu)建更復(fù)雜的服務(wù)。長(zhǎng)此以往推進(jìn)了開發(fā)的速度
·與此同時(shí),資金逐漸大量投入到了那些具有優(yōu)勢(shì)的服務(wù)
·隨著服務(wù)的使用越多,服務(wù)的目標(biāo)適應(yīng)性就越變?cè)胶?/p>
Kurzweil的研究表明,在許多不同的技術(shù)領(lǐng)域,這種模式總是貫穿整個(gè)技術(shù)發(fā)展史的。從我的角度上看,亞馬遜仍然處于這個(gè)模型指數(shù)曲線中的早期階段,這是由亞馬遜內(nèi)外部對(duì)服務(wù)的使用程度來(lái)決定的。
如果沒(méi)有足夠的服務(wù)數(shù)據(jù)來(lái)推動(dòng)資金和優(yōu)化,亞馬遜的模型將無(wú)法運(yùn)作,端到端的實(shí)施團(tuán)隊(duì)以及Away Team在識(shí)別新服務(wù)和改善現(xiàn)有服務(wù)的適應(yīng)性方面發(fā)揮著至關(guān)重要的作用。
目前,AWS專注于創(chuàng)建更高層次的通用型服務(wù),這些服務(wù)適合用于各類通用平臺(tái)的軟件開發(fā)。例如亞馬遜自身(Amazon.com,Alexa,Kindle等)以及正在構(gòu)建各種產(chǎn)品和IT基礎(chǔ)架構(gòu)的AWS客戶。
亞馬遜面向服務(wù)協(xié)作的特征
亞馬遜的協(xié)作原則與其他大型組織不同,因此避免了其他大型組織經(jīng)常出現(xiàn)的一些問(wèn)題,如:
·可能需要消耗幾個(gè)月請(qǐng)求訪問(wèn)另一個(gè)團(tuán)隊(duì)的源代碼
·直接產(chǎn)生收益的服務(wù)或服務(wù)的關(guān)鍵決策權(quán)僅由一個(gè)固定的團(tuán)隊(duì)負(fù)責(zé),而不會(huì)將其傳遞給服務(wù)所有者團(tuán)隊(duì)。
·讓管理層注意到重構(gòu)某些演進(jìn)需求可能需要耗費(fèi)數(shù)月時(shí)間。通常這樣的關(guān)注也不會(huì)促成有效的團(tuán)隊(duì)合作
·在調(diào)整激勵(lì)措施之前,團(tuán)隊(duì)可能會(huì)將對(duì)向他人提供幫助的優(yōu)先級(jí)降低
·團(tuán)隊(duì)內(nèi)部?jī)?yōu)化的優(yōu)先級(jí)很容易高于整體業(yè)務(wù)轉(zhuǎn)型
借助亞馬遜的面向服務(wù)的協(xié)作系統(tǒng),大部分問(wèn)題永遠(yuǎn)不會(huì)發(fā)生,有些問(wèn)題則會(huì)減小發(fā)生頻率。如果說(shuō)任何像亞馬遜一樣規(guī)模的組織都沒(méi)有政治因素的影響,那就太天真了。但這些原則鼓勵(lì)大家像這個(gè)最優(yōu)方案靠攏,就像鼓勵(lì)擁抱用戶價(jià)值一樣。
以下是亞馬遜體系內(nèi)的一些優(yōu)點(diǎn):
·Away Team模型以及訪問(wèn)源代碼的便捷性意味著可以輕松跨越服務(wù)邊界,以增強(qiáng)整個(gè)平臺(tái)中服務(wù)的易用性。團(tuán)隊(duì)可以輕易地完成通過(guò)改進(jìn)其他服務(wù)來(lái)完成自己團(tuán)隊(duì)服務(wù)的優(yōu)化
·解決協(xié)作問(wèn)題和重構(gòu)服務(wù)演進(jìn)方案所需的時(shí)間成本大大減少。在亞馬遜的模型中,演進(jìn)方案有時(shí)需要重新考慮,但由于有Away Team的協(xié)助,這些事件會(huì)被弱化
·團(tuán)隊(duì)自治過(guò)程中還減少了對(duì)管理輸入上下文的需要。這樣的政策是盡一切可能專注于為客戶提供價(jià)值,而不是擔(dān)心服務(wù)重復(fù)或偏離標(biāo)準(zhǔn)。在開發(fā)完美的共享服務(wù)時(shí)不需要等待,在使用完美的共享服務(wù)的時(shí)候不會(huì)有任何阻力。
·服務(wù)轉(zhuǎn)讓定價(jià)制度的剔除意味著團(tuán)隊(duì)更加致力于提供更好的服務(wù),而不是始終追求效益最大化。資源的使用情況由財(cái)務(wù)團(tuán)隊(duì)跟蹤,他們會(huì)分配請(qǐng)求并且對(duì)資源調(diào)配進(jìn)行優(yōu)化
·專注于數(shù)據(jù)減少了主觀判斷。我們不需要進(jìn)行爭(zhēng)論,任何一方都持有著各自的觀點(diǎn)。我們最終只需要關(guān)注數(shù)據(jù),因?yàn)閿?shù)據(jù)總是正確的
·凸顯了跨團(tuán)隊(duì)審查的優(yōu)點(diǎn)。團(tuán)隊(duì)的代碼將是可見(jiàn)的,所有的決定會(huì)受Bar Raisers監(jiān)督,而Away Team編寫的代碼必須被其他的團(tuán)隊(duì)接受。如果馬虎對(duì)待代碼,那么它將會(huì)被公開。
·隨著時(shí)間的推移,公開版本的AWS服務(wù)往往會(huì)成為首選。顧客們對(duì)亞馬遜產(chǎn)品的迷戀加速了亞馬遜持續(xù)的優(yōu)化自身內(nèi)部服務(wù),促使公開版本的AWS服務(wù)通常比內(nèi)部服務(wù)擁有更高的質(zhì)量和性能
亞馬遜模型的缺點(diǎn)是架構(gòu)可能包含重復(fù)的服務(wù)或是同一服務(wù)的多個(gè)版本。有這樣一個(gè)座右銘:“有兩個(gè)好過(guò)一個(gè)都沒(méi)有”,意思是做你需要做的事情,另一個(gè)平衡的座右銘是“一個(gè)都沒(méi)有好過(guò)有五個(gè)”,所以每當(dāng)發(fā)現(xiàn)有些服務(wù)并不是完全適合的時(shí)候,也不要忘掉它而去創(chuàng)造新的服務(wù)。
更大的一個(gè)擔(dān)憂是產(chǎn)品凝聚力和一致性可能會(huì)受到影響。這位作者還沒(méi)有花時(shí)間在AWS之間挖掘各API模式之間的差異,我也無(wú)法對(duì)內(nèi)部API進(jìn)行這樣的操作,但我們被告知這確實(shí)是存在的隱患。
當(dāng)然,我們提出的觀點(diǎn)代表了理論,而不是從實(shí)踐中獲取經(jīng)驗(yàn)教訓(xùn)。正如在亞馬遜體系中受挫并且在五個(gè)月后離開亞馬遜的人在本博客中所述,Away Team模型,Bar Raisers和標(biāo)準(zhǔn)開發(fā)環(huán)境都可能出錯(cuò)并導(dǎo)致問(wèn)題。亞馬遜是一個(gè)高壓且競(jìng)爭(zhēng)非常激烈的環(huán)境,這就導(dǎo)致了他們的員工和經(jīng)理都很難在像Glassdoor這樣的網(wǎng)站中公開發(fā)表自己的看法。
“商業(yè)總是在發(fā)展迅速,我們必須加快行動(dòng)”。這是Bezos一貫的口頭禪。面向服務(wù)架構(gòu)的協(xié)作模型基于Kurzweil指數(shù)理論以及減少Von Hippel提到的粘性信息進(jìn)行著短期以及長(zhǎng)期的優(yōu)化。最后,亞馬遜很樂(lè)意使用面向服務(wù)架構(gòu)的協(xié)作來(lái)確保AWS和內(nèi)部服務(wù)快速增長(zhǎng),但表面看起來(lái)確實(shí)是激進(jìn)了一些。
原作者:Dan Woods
原文鏈接:https://www.theregister.co.uk/2019/05/14/amazonsawayteams/
譯者:趙越 ThoughtWorks咨詢師,李之琳 ThoughtWorks業(yè)務(wù)分析師
點(diǎn)擊咨詢現(xiàn)在有哪些新興平臺(tái)值得關(guān)注 >>>
特別聲明:以上文章內(nèi)容僅代表作者本人觀點(diǎn),不代表ESG跨境電商觀點(diǎn)或立場(chǎng)。如有關(guān)于作品內(nèi)容、版權(quán)或其它問(wèn)題請(qǐng)于作品發(fā)表后的30日內(nèi)與ESG跨境電商聯(lián)系。
二維碼加載中...
使用微信掃一掃登錄
使用賬號(hào)密碼登錄
平臺(tái)顧問(wèn)
微信掃一掃
馬上聯(lián)系在線顧問(wèn)
小程序
ESG跨境小程序
手機(jī)入駐更便捷
返回頂部