論平臺(tái)工程的價(jià)值
我已經(jīng)當(dāng)了幾年的平臺(tái)工程師。我喜歡這份工作，對(duì)此充滿了激情。
在本文中，我將討論我的專業(yè)知識(shí)所帶來的好處。由于平臺(tái)工程師的角色還比較新，所以對(duì)于這個(gè)角色的需求和所提供的價(jià)值還沒有形成廣泛的共識(shí)。假如你找三個(gè)人詢問他們對(duì)這個(gè)問題的意見，你會(huì)得到四個(gè)答案——至少在細(xì)節(jié)方面，我不會(huì)感到奇怪。另外，由于平臺(tái)工程與基礎(chǔ)設(shè)施非常接近，不存在直接和明顯的價(jià)值可見性，想想前端工程，它就可以顯示所提供的價(jià)值。
不管怎么說，我真正的動(dòng)機(jī)是要清楚自己對(duì)這個(gè)問題的看法，而在這個(gè)過程中，寫作幫助了我。
因?yàn)槲椰F(xiàn)在只研究云基礎(chǔ)設(shè)施，因此我所有的論點(diǎn)，以及對(duì)基礎(chǔ)設(shè)施資源的提及，都應(yīng)該放在這個(gè)背景下來看；不過我猜測，很多論斷在更傳統(tǒng)的數(shù)據(jù)中心，甚至更寬泛的范圍應(yīng)該都可以成立。
在我提出有價(jià)值的論點(diǎn)之前，我認(rèn)為明智的做法是先簡單回顧一下互聯(lián)網(wǎng)歷史。我所許諾的價(jià)值將會(huì)得到體現(xiàn)，這不僅是為了好玩，而且是為了描繪一幅圖景。我當(dāng)然是基于自己的個(gè)人經(jīng)歷，所以你的情況可能會(huì)不一樣。
云計(jì)算簡史
云計(jì)算是指計(jì)算機(jī)系統(tǒng)資源的按需可用性，尤其是數(shù)據(jù)存儲(chǔ)（云存儲(chǔ)）和計(jì)算能力，而用戶無需直接主動(dòng)管理。
——維基百科：云計(jì)算詞條
隨著現(xiàn)代云計(jì)算的出現(xiàn)，計(jì)算環(huán)境發(fā)生了一個(gè)重大變化：硬件現(xiàn)在有了一個(gè)按需的 API。實(shí)際上，并不是硬件，而是資源之前只能通過硬件來表達(dá)。這種情況不是一朝一夕就能發(fā)生的，沒有第一家廠商使用“云”這個(gè)詞，并且為所有人都指定了新的標(biāo)準(zhǔn)（即使有人可能會(huì)這樣說）。這曾經(jīng)是，現(xiàn)在依然是，一個(gè)由必要性和需求驅(qū)動(dòng)的過程。這也不是一個(gè)進(jìn)程，而是多個(gè)進(jìn)程同時(shí)運(yùn)行，并且以某種程度向同一方向發(fā)展。
對(duì)于平臺(tái)工程，我認(rèn)為兩個(gè)因果概念或技術(shù)尤其重要，它們是：
虛擬化。盡管這一概念本身已經(jīng)存在了幾十年，而且很久以前就被用來處理邊緣案例和大型企業(yè)解決方案，但是在我看來，第一個(gè)對(duì)更大的市場產(chǎn)生重大影響的實(shí)施是虛擬服務(wù)器。虛擬服務(wù)器允許數(shù)據(jù)中心的所有者將其昂貴的硬件分割為更小的塊，以供自己使用，并使之更容易銷售給他人。對(duì)現(xiàn)有資源的有效利用更為有效。但更重要的是，如果能夠在一個(gè)物理服務(wù)器中創(chuàng)建多個(gè)虛擬服務(wù)器，那么下一個(gè)邏輯步驟當(dāng)然是自動(dòng)執(zhí)行這個(gè)過程，然后再進(jìn)一步：自動(dòng)化的工具?；A(chǔ)設(shè)施 API 應(yīng)運(yùn)而生。不只是簡單地管理虛擬服務(wù)器，還包括網(wǎng)絡(luò)防火墻、CDN、數(shù)據(jù)庫等等，這些都是虛擬的，可以通過 API 來實(shí)現(xiàn)。
容器化（與編排）：從嚴(yán)格意義上說，容器化是虛擬化的一個(gè)具體實(shí)現(xiàn)。但我仍然認(rèn)為它應(yīng)該有介紹自己的一段內(nèi)容，因?yàn)闆]有技術(shù)能像容器化一樣，在基礎(chǔ)設(shè)施提供商和基礎(chǔ)設(shè)施用戶之間架起橋梁。封裝在容器內(nèi)的應(yīng)用使雙方在共同點(diǎn)上達(dá)成一致。只有適合于容器，我們才能運(yùn)行它。而且，從容器化基礎(chǔ)設(shè)施的角度來看，也需要編排：在隔離的環(huán)境下，大規(guī)模地運(yùn)行標(biāo)準(zhǔn)化容器。
新范式
以上所提到的技術(shù)的廣泛應(yīng)用（我相信還有其他因素）引起了許多思考，并導(dǎo)致了一系列新的觀點(diǎn)和后續(xù)業(yè)務(wù)的出現(xiàn)。在此，我要再次強(qiáng)調(diào)一些我認(rèn)為特別具有影響力并與背景相關(guān)的因素：
微服務(wù)：微服務(wù)是對(duì)應(yīng)用設(shè)計(jì)和實(shí)現(xiàn)的一種完全不同的觀點(diǎn)。這使你可以將最復(fù)雜的應(yīng)用視為一組不同的、潛在的、相互連接的功能。這一思路不僅適用于實(shí)現(xiàn)（構(gòu)建“簡化”的微服務(wù)），還適用于組織（擁有整體中定義良好的部分），當(dāng)然，對(duì)部署和執(zhí)行也有直接的影響：單體設(shè)計(jì)通常具有對(duì)操作系統(tǒng)和硬件（資源）的大量高度特定需求，而封裝在容器中的微服務(wù)可以在更相同的基礎(chǔ)設(shè)施中工作，不是作為一個(gè)整體，而是按照服務(wù)（部分）來擴(kuò)展，以更小的爆炸半徑單獨(dú)失敗，等等。這并不意味著每個(gè)應(yīng)用都是（或者應(yīng)該是）從一開始就被設(shè)計(jì)成微服務(wù)，但它仍然創(chuàng)造了思維方式，推動(dòng)了組織，并促進(jìn)了標(biāo)準(zhǔn)化。
寵物與牛：以前的服務(wù)器都是有名字的，并且都是單獨(dú)配置的。我曾經(jīng)在裸機(jī)上工作過，在將它們放進(jìn)機(jī)架之前，我親手貼上一張帶有名字的貼紙，我很清楚我可以創(chuàng)造的“寵物”。由于能夠訪問提供虛擬服務(wù)器或任何其他資源的 API，因此沒有辦法，也沒有必要跟上?，F(xiàn)在，基礎(chǔ)設(shè)施用戶可以購買完全脫離物理的資源，根據(jù)需要自動(dòng)擴(kuò)展。結(jié)果，資源的可得性就不那么重要了（它們只是可得的）；我們考慮的是堆棧（資源），而非單個(gè)機(jī)器。資源就是數(shù)字。牛，不是寵物。請(qǐng)參閱 Randy Bias 寫的內(nèi)容，他將這一類比總結(jié)得很完美。
基礎(chǔ)設(shè)施即代碼：應(yīng)用很復(fù)雜。操作系統(tǒng)也很復(fù)雜。如果兩者都是相關(guān)的，那就會(huì)變得更復(fù)雜。過去，大多數(shù)人，包括我在內(nèi)，都是手動(dòng)配置系統(tǒng)的。這樣就得到了系統(tǒng)的深刻理解，并且常常是獨(dú)特的理解。這里所謂的獨(dú)特，如在：低巴士因子（bus factor）；又如在：除了一個(gè)人外，沒有人知道這個(gè)系統(tǒng)的情況。這個(gè)問題的解決方案是配置管理，它允許維護(hù)人員以可復(fù)制、可測試、版本控制和標(biāo)準(zhǔn)化的文檔方式來描述整個(gè)設(shè)置。通過這個(gè)系統(tǒng)，配置可以很容易地重建（相對(duì)而言），人為錯(cuò)誤因素大大減少，任何設(shè)置都可以在較短時(shí)間內(nèi)被他人理解（相對(duì)而言）?；A(chǔ)設(shè)施即代碼（Infrastructure as Code，IaC）在基礎(chǔ)設(shè)施資源方面也是如此。不再需要手動(dòng)提供 / 配置 / 訂購特定服務(wù)或應(yīng)用所需的資源，而是使用標(biāo)準(zhǔn)化、文檔化、簽入版本控制、代碼可查看、可測試和可復(fù)制的代碼來描述。
平臺(tái)即服務(wù)：隨著基礎(chǔ)設(shè)施資源自動(dòng)化日益普及，在上述基礎(chǔ)設(shè)施上運(yùn)行的東西也可以輕松地獲得超級(jí)能力：可擴(kuò)展性。也就是說，你只需為所需資源付費(fèi)。或者從商業(yè)角度來看，你只需為你實(shí)際賣出的東西付費(fèi)（粗略地說）。牢記這一點(diǎn)，我們就不難理解為什么如今幾乎所有的功能都可以作為服務(wù)來購買。我們可以把它想象成一種由基礎(chǔ)設(shè)施即服務(wù)（Infrastructure as a Service，IaaS）提供基礎(chǔ)的供應(yīng)鏈。這樣，平臺(tái)即服務(wù)（Platform as a Service，PaaS）就可以構(gòu)建自己的服務(wù)，這些服務(wù)包括計(jì)算運(yùn)行時(shí)、數(shù)據(jù)庫、CDN 等等。通過這種方式，軟件即服務(wù)（Software as a Service，SaaS）的構(gòu)建者可以將注意力集中在他們自己的領(lǐng)域：軟件構(gòu)建，而不是深入到基礎(chǔ)設(shè)施層。而且人們還可以根據(jù)需要增加或減少需求。請(qǐng)注意，在撰寫本文時(shí)，維基百科上列出的“即服務(wù)”類型有 75 種，因此我略去了一些。但重點(diǎn)是，市場已經(jīng)改變。諸如硬件、操作系統(tǒng)、服務(wù)操作之類的問題現(xiàn)在可以外包，按需購買。
所有這些范式深深地糾纏在一起。你可以認(rèn)為“平臺(tái)即服務(wù)”是“微服務(wù)”的結(jié)果，反之亦然。另外，如果沒有“基礎(chǔ)設(shè)施即代碼”，寵物與牛是幾乎不可能的，而后者是前者所需要的。
什么是平臺(tái)工程？
在討論平臺(tái)工程帶來的價(jià)值之前，我需要先說明我所說的是什么意思（或者不是什么意思）。也要記得，我的觀點(diǎn)是，角色就像一頂帽子：你可以根據(jù)需要戴帽子。有些帽子是你經(jīng)常戴的，有些帽子是你比別人更喜歡的，而有些帽子你會(huì)藏起來，希望以后不要把它拿出來。角色沒有明確的界限，也不與職位掛鉤。
平臺(tái)化
我認(rèn)為可以肯定地說，平臺(tái)工程師參與平臺(tái)的建設(shè)。由于平臺(tái)這一術(shù)語相當(dāng)模糊，所以我將試著在本文的范圍內(nèi)解釋我的意思。讓我們從以下幾個(gè)方面開始：平臺(tái)是一個(gè)定義良好的接口，它簡化了對(duì)資源的處理和訪問。
當(dāng)然，在平臺(tái)工程領(lǐng)域中，這些資源都是某種基礎(chǔ)設(shè)施資源。從軟件開發(fā)人員的角度來說，門面設(shè)計(jì)模式是我所能想到的最接近平臺(tái)關(guān)鍵屬性的。在我看來，平臺(tái)是由一個(gè)或多個(gè)“服務(wù)門面（facade）”機(jī)器接口規(guī)范和文檔組成的。這一切都是必要的，因?yàn)槠脚_(tái)的目的就是自動(dòng)化通用用例。
對(duì)于用戶來說，平臺(tái)基本上是透明的（比如，你不知道里面發(fā)生了什么），但我不確定這是否一個(gè)要求——盡管在大多數(shù)情況下這肯定是個(gè)好主意。
根據(jù)這一定義，GitHub 就是一個(gè)平臺(tái)。AWS 也是一個(gè)平臺(tái)，更確切地說，它是一個(gè)平臺(tái)中的平臺(tái)。但任何單獨(dú)的、內(nèi)部創(chuàng)建的解決方案都是一個(gè)平臺(tái)，它為管理你的用例使用所需的基礎(chǔ)設(shè)施資源提供了簡化的接口。
平臺(tái)化就是要確定常見的用例（或模式），為描述這些用例的接口進(jìn)行建模，提供實(shí)現(xiàn)這些用例的自動(dòng)化解決方案，并將其文檔化，這樣過程就可以以最小的人工交互進(jìn)行使用。
平臺(tái)工程就是與平臺(tái)化相關(guān)的學(xué)科。
與其他角色相比
盡管平臺(tái)工程是一個(gè)新的角色，但它并非憑空而來，而是對(duì)現(xiàn)有的其他角色和職責(zé)進(jìn)行了專門劃分——與所有角色一樣。在我看來，以下幾點(diǎn)對(duì)平臺(tái)工程有重大影響：
我認(rèn)為DevOps 工程師最接近平臺(tái)工程的角色，他們專注于為特定應(yīng)用（基于云基礎(chǔ)設(shè)施）提供解決方案?；蛘哒f我這樣認(rèn)為：畢竟 DevOps 是一種生活方式。這是一個(gè)非常接近于平臺(tái)工程的東西。在我看來，主要的區(qū)別應(yīng)該是視角和所得到的的規(guī)模。DevOps 工程師提倡“他們”的應(yīng)用，而平臺(tái)工程則關(guān)注大量或全部應(yīng)用。DevOps 工程師處理特殊用例（構(gòu)建一組特定應(yīng)用運(yùn)行的基礎(chǔ)設(shè)施），而平臺(tái)工程處理普通用例（構(gòu)建所有 / 大多數(shù)應(yīng)用運(yùn)行的平臺(tái)）。DevOps 工程師對(duì)細(xì)節(jié)更感興趣，而平臺(tái)工程則更關(guān)注共性。根據(jù)我的經(jīng)驗(yàn)，這兩者通常都有需要，邊界非常模糊，而且經(jīng)常是同一個(gè)人“戴著兩頂帽子”。
平臺(tái)工程師角色的起源可能涉及到基礎(chǔ)設(shè)施工程師的角色，其重點(diǎn)是構(gòu)建、部署和維護(hù)基礎(chǔ)設(shè)施。這個(gè)角色接近于系統(tǒng)管理員、網(wǎng)絡(luò)工程師以及可能還有 DevOps。這超出了云的范疇，因?yàn)樗€涉及到數(shù)據(jù)中心。本文只涉及云相關(guān)的范圍。在這個(gè)術(shù)語中，我認(rèn)為是“云（基礎(chǔ)設(shè)施）工程師”，所以我就是這個(gè)意思。自然的，平臺(tái)工程師從這里開始，使用（云) 基礎(chǔ)設(shè)施，并對(duì)基礎(chǔ)設(shè)施進(jìn)行全面的思考。最大的不同在于，基礎(chǔ)設(shè)施工程師非常注重可操作性和可靠性，而平臺(tái)工程則是注重可訪問性。
另外，后端工程師也發(fā)揮了作用，他們專注于應(yīng)用的數(shù)據(jù)訪問層。它的范圍很廣，有許多子專業(yè)，而且肯定接近 DevOps。其中一個(gè)核心問題是 API 的設(shè)計(jì)和實(shí)現(xiàn)，包括處理數(shù)據(jù)源、隊(duì)列等等。平臺(tái)工程也做這些，不過目的不同。后端工程師是由平臺(tái)工程創(chuàng)建的平臺(tái)的“客戶”（公司內(nèi)部），并在平臺(tái)上構(gòu)建自己的應(yīng)用。
我曾說過，邊界很難畫出來，可能會(huì)有更多的角色（比如網(wǎng)站可靠性工程），我想和他們比較一下，但是有時(shí)候我不得不停下來，希望這個(gè)描繪的更清晰一些。
價(jià)值主張
最后，我要談一下我的論點(diǎn)：平臺(tái)工程的價(jià)值。
鑒于技術(shù)領(lǐng)域的變化，以及由此產(chǎn)生的新范式，我們可以清楚地看到：應(yīng)用生態(tài)圈的復(fù)雜性正在增加。但這并非因?yàn)槭褂没A(chǔ)設(shè)施或應(yīng)用開發(fā)方面的復(fù)雜性增加所致。事實(shí)上，基礎(chǔ)設(shè)施的事情已經(jīng)變得非常簡單了，有了基礎(chǔ)設(shè)施即代碼等，從我的角度來看，應(yīng)用開發(fā)也在易用性方面取得了長足的進(jìn)步。
那是什么呢？嗯，這是巨大成功的錯(cuò)誤所在：我所強(qiáng)調(diào)的變化（以及其他變化）帶來了更多的可能性和機(jī)會(huì)?，F(xiàn)在人人都能很容易獲得可擴(kuò)展性嗎？好吧，這也意味著現(xiàn)在每個(gè)人都在關(guān)注這個(gè)問題。正因?yàn)槿绱?，平臺(tái)工程才起到關(guān)鍵作用：它通過降低用戶和應(yīng)用開發(fā)者的復(fù)雜性，幫助使這些機(jī)會(huì)更容易獲得。
具體而言：
標(biāo)準(zhǔn) PaaS 推銷方式
PaaS（Platform as a Service，平臺(tái)即服務(wù)）的優(yōu)勢主要在于它可以進(jìn)行更高級(jí)別的編程，而復(fù)雜性則大大降低。
——維基百科：平臺(tái)即服務(wù)詞條
首先：我認(rèn)為這應(yīng)該是一般的作為服務(wù)的推銷，而不是專門針對(duì) PaaS 的。比如?！捌脚_(tái)即服務(wù)”的優(yōu)勢主要在于，它可以在更高的級(jí)別上進(jìn)行使用，而復(fù)雜性則大大降低：你知道，發(fā)送電子郵件、流媒體電影。如果有其他選擇，所有更好的接口都會(huì)大幅降低復(fù)雜性。
這就是平臺(tái)工程可以完成的工作：為基礎(chǔ)設(shè)施資源創(chuàng)建更高級(jí)別的接口，這些接口的設(shè)計(jì)是為了使它們適合用例，然后實(shí)現(xiàn)它們。只不過不是為任何終端用戶，就像上面一般的服務(wù)推銷所暗示的那樣，而是為應(yīng)用開發(fā)者服務(wù)。標(biāo)準(zhǔn)化是免費(fèi)的回報(bào)。
當(dāng)然，平臺(tái)工程師并非專為 PaaS 提供商工作的（周圍沒有那么多），他們?cè)诟鞯卮罱ㄆ脚_(tái)。大多數(shù) PaaS 提供商面向的是大眾市場。有很多公司因?yàn)橐?guī)模、安全、法律、遺留系統(tǒng)或者其他的原因不適合這個(gè)產(chǎn)品。他們?nèi)孕枰褂糜砷_發(fā)人員創(chuàng)建的基礎(chǔ)設(shè)施來運(yùn)行服務(wù)。
DevOps 工程和平臺(tái)工程在專注于應(yīng)用層的開發(fā)人員和提供用于運(yùn)行應(yīng)用的資源的基礎(chǔ)設(shè)施提供商之間架起了一座橋梁。DevOps 工程提供了一個(gè)解決方案，可以在云基礎(chǔ)設(shè)施中運(yùn)行一組小型、專業(yè)化的服務(wù)。平臺(tái)工程以平臺(tái)的形式提供解決方案，在云基礎(chǔ)設(shè)施中運(yùn)行更通用的服務(wù)。二者之間的邊界非常模糊，主要是規(guī)模和增長的問題。
無論哪種方式：這使開發(fā)人員能夠集中精力開發(fā)應(yīng)用，他們?cè)谶@方面非常出色。依我看，你當(dāng)然應(yīng)該盡早開始平臺(tái)化，除非你不期待基礎(chǔ)設(shè)施的發(fā)展或變化。
價(jià)值：持久、高節(jié)奏的開發(fā)進(jìn)度。
抵消技術(shù)債務(wù)
隨著事情的改變或發(fā)展，技術(shù)債務(wù)也隨之增加。一直如此，除非你停滯不前。問題不在于如何完全阻止它，而在于如何減緩它，讓它變得可控，在你被迫停止之前不會(huì)增加。
許多因素導(dǎo)致了技術(shù)債務(wù)的增加。當(dāng)然，也有業(yè)務(wù)方面的原因，因?yàn)樗鼈冋紦?jù)了優(yōu)先地位，使人們幾乎沒有或根本沒有時(shí)間去調(diào)整基礎(chǔ)設(shè)施或軟件設(shè)計(jì)來抵消累積的技術(shù)債務(wù)。此外，還存在結(jié)構(gòu)或架構(gòu)方面的原因。類似微服務(wù)這樣的模式也是為了從架構(gòu)方面解決這個(gè)問題而產(chǎn)生的。
造成技術(shù)債務(wù)快速增長的一個(gè)主要因素是，同一問題有太多的解決方案。就像其他的應(yīng)用一樣，它們也有自己獨(dú)特的部署管道、服務(wù)運(yùn)行時(shí)、數(shù)據(jù)庫設(shè)置或者是所有你能想到的東西。一座正在發(fā)展中的解決方案和模式的“動(dòng)物園”，在此刻聽起來也許是不錯(cuò)的主意，因?yàn)樗鼈兘鉀Q了眼前的問題，但在未來卻會(huì)變成一片難以處理的混亂，非常脆弱，在這里危險(xiǎn)，不可觸碰，否則風(fēng)險(xiǎn)很大。
平臺(tái)工程至少通過提供一個(gè)標(biāo)準(zhǔn)化的框架（服務(wù)的共同標(biāo)準(zhǔn)），在不同程度上抵消了這最后一個(gè)因素，以及其他因素。它還強(qiáng)制執(zhí)行明確的邊界和接口，使你可以更容易地理解、發(fā)展和改變應(yīng)用的前景，無論是現(xiàn)在還是將來。
與此密切相關(guān)的是，久而久之，遺留問題也在不斷積累。它還會(huì)轉(zhuǎn)化成要求在某個(gè)時(shí)間償還的技術(shù)債務(wù)。盡管平臺(tái)工程并不直接解決遺留問題，但它將這些問題限定于組成服務(wù)或應(yīng)用的商定邊界之內(nèi)。
最后，平臺(tái)工程孕育了像前面提到的微服務(wù)這樣的現(xiàn)代范式，它本身可以抵消技術(shù)債務(wù)。平臺(tái)在這方面起到了支持和推動(dòng)的作用。
價(jià)值：變革的敏捷性 / 不間斷的增長。
為變化做好準(zhǔn)備
唯一不變的就是變化。早在 2500 年前，人們就已經(jīng)知道了這一點(diǎn)，甚至對(duì)于現(xiàn)代的應(yīng)用基礎(chǔ)設(shè)施而言，它仍然適用。然而，當(dāng)變化到來的時(shí)候，我們?nèi)匀粫?huì)感到驚奇。我在這個(gè)生態(tài)圈工作了 20 年，從來沒有遇到過一個(gè)系統(tǒng)不會(huì)隨時(shí)間而改變的情況。變化有許多形式。你可以做一些小事情，比如增加應(yīng)用價(jià)值的新功能，也可以做一些根本性的改變，比如從物理數(shù)據(jù)中心遷移到云基礎(chǔ)設(shè)施，或者重新構(gòu)建整個(gè)應(yīng)用。不管怎么說：事情會(huì)發(fā)生變化，你需要做好準(zhǔn)備，或者在變化來臨時(shí)支付高額的賬單。這是必然的。
你猜對(duì)了，這里有一個(gè)共同的主題：平臺(tái)工程是為了拯救。怎么說呢？它為部署和運(yùn)行你的應(yīng)用提供了一個(gè)標(biāo)準(zhǔn)化的環(huán)境。重點(diǎn)在于“標(biāo)準(zhǔn)化”一詞?？梢赃@樣想，移動(dòng)一百個(gè)應(yīng)用，每一個(gè)都有各自的部署和運(yùn)行服務(wù)的方式，這是非常困難的，甚至是可怕的。而移動(dòng)一百個(gè)具有共同部署和運(yùn)行服務(wù)方式的應(yīng)用就容易得多。毫無疑問，一個(gè)平臺(tái)可以提供這些共享的共性。
這也意味著：平臺(tái)的早期。也許不是在打造 MVP 的時(shí)候，即使是我也不會(huì)提倡這樣做，但是要確保時(shí)間足夠早，以使標(biāo)準(zhǔn)化工作不會(huì)太過痛苦，讓你對(duì)其視而不見。找出合適的時(shí)機(jī)并非易事，所以，要盡早進(jìn)入平臺(tái)。
價(jià)值：靈活性（應(yīng)用基礎(chǔ)設(shè)施中的靈活性轉(zhuǎn)化為業(yè)務(wù)中的靈活性）。
作者介紹：
Ulrich Kautz，居住德國柏林，高級(jí)平臺(tái)工程師，供職于 Scout24 Group。
原文鏈接：
https://ulrichkautz.com/posts/2021-03-11_value-of-platforming-engineering/