本文來自微信公眾號“開源云中文社區(qū)”。
不管你喜不喜歡，你已經(jīng)有了一個(gè)內(nèi)部開發(fā)人員平臺，即使你的組織從未建立過一個(gè)平臺，也沒有“平臺工程”人員。它可能不是正確的平臺，可能難以擴(kuò)展或使用，但它確實(shí)存在。
這意味著你可能不需要構(gòu)建平臺；你只需要讓它更好。你面臨的真正問題是，是否應(yīng)該在平臺之上使用內(nèi)部開發(fā)人員門戶，因?yàn)樗瞧脚_工程堆棧中最成熟的元素。
我們在這篇文章中要討論的是，門戶很重要，它們也會影響平臺工作的質(zhì)量和有用性，隨著它們和技術(shù)的發(fā)展，它們基本上會成為平臺的一部分。
但是等等！內(nèi)部開發(fā)者平臺？內(nèi)部開發(fā)者門戶？有什么區(qū)別？為什么要在另一個(gè)之上使用一個(gè)？讓我們首先定義兩者，并就這將帶我們走向何方提出一些大膽的論點(diǎn)。
什么是內(nèi)部開發(fā)人員平臺？
讓我們從基礎(chǔ)知識開始。平臺是幫助工程師完成工作的工具。它可以讓他們編碼，留在區(qū)域內(nèi)，不必太擔(dān)心他們無法控制或沒有專業(yè)知識的運(yùn)維問題。
現(xiàn)代架構(gòu)是復(fù)雜的，由許多底層技術(shù)和數(shù)百個(gè)微服務(wù)組成，軟件開發(fā)生命周期對于任何人來說都變得太長了，需要太多運(yùn)維和開發(fā)方面的專業(yè)知識。
解決方案是抽象掉一些復(fù)雜性，并創(chuàng)建一個(gè)統(tǒng)一的開發(fā)人員體驗(yàn)，這將減少開發(fā)人員和運(yùn)維人員的認(rèn)知負(fù)荷。這些更好的開發(fā)人員體驗(yàn)將提高生產(chǎn)力。這就是平臺的意義所在。
受Gartner啟發(fā)，分類的定義是，平臺是關(guān)于自助服務(wù)功能和具有自動(dòng)化基礎(chǔ)設(shè)施運(yùn)維的可重用工具。該平臺由平臺工程師構(gòu)建，使開發(fā)人員從“粘合工作”中解放出來，并為開發(fā)人員制定標(biāo)準(zhǔn)和黃金路徑。
所有這些都可以歸結(jié)為開發(fā)人員自助服務(wù)。你不必構(gòu)建自己的臨時(shí)云環(huán)境，也不必執(zhí)行第二天的運(yùn)維，不需要DevOps的人來做，只需訪問一個(gè)界面并獲得所需的內(nèi)容。想象一個(gè)Jenkins自助表單或Terraform無代碼。
當(dāng)然，這并不完美。例如，使用Jenkins進(jìn)行自助服務(wù)意味著缺乏上下文和狀態(tài)，用戶界面扁平，無法設(shè)置組織標(biāo)準(zhǔn)（工程質(zhì)量可以而且應(yīng)該是良好的門戶/平臺工作的結(jié)果）。它也沒有解耦。如果你改變了Jenkins，你也需要改變開發(fā)者的體驗(yàn)。這不太管用。
該平臺的另一部分是為開發(fā)人員提供底層基礎(chǔ)設(shè)施的某種程度的透明度，以便他們能夠做出明智的決定。為了提高生產(chǎn)力而將所有內(nèi)容都抽象出來在紙面上聽起來不錯(cuò)，但需要顯示一些數(shù)據(jù)，從依賴關(guān)系到Kubernetes設(shè)置、內(nèi)存或CPU使用情況等。
如果沒有一些數(shù)據(jù)，你就無法做到“建造它，擁有它”。一個(gè)很好的例子是GitOps（它可能構(gòu)成現(xiàn)有平臺的核心）。純粹的GitOps對開發(fā)人員來說不太好，因?yàn)樗颂嗟男畔?，并且為開發(fā)人員提供了太多自由漫游和犯錯(cuò)的空間。在這種情況下，用一個(gè)平臺替換GitOps或在其上添加一些平臺元素可能會奏效。
什么是內(nèi)部開發(fā)人員門戶？
門戶是平臺的界面，幫助用戶訪問底層的異構(gòu)軟件開發(fā)生命周期資源，并使用門戶中提供的自助服務(wù)。門戶為開發(fā)人員和運(yùn)維人員創(chuàng)造了類似的體驗(yàn)，因此每個(gè)人都可以自助服務(wù)，并獲得對基礎(chǔ)設(shè)施的適當(dāng)可見性，從而做出正確的決策。這些體驗(yàn)類似于產(chǎn)品，旨在提供簡單的黃金路徑自助服務(wù)，以及執(zhí)行質(zhì)量標(biāo)準(zhǔn)，提高工程質(zhì)量。否則，生產(chǎn)力就無法實(shí)現(xiàn)。
自助服務(wù)
開發(fā)人員在開發(fā)人員門戶中使用自助服務(wù)。行動(dòng)越多越好。首先，開發(fā)人員不僅需要構(gòu)建微服務(wù)；他們需要許多第二天的運(yùn)維，以及權(quán)限請求（TTL或生存時(shí)間）、設(shè)置臨時(shí)環(huán)境等。一個(gè)好的自助服務(wù)體驗(yàn)應(yīng)該盡可能像產(chǎn)品一樣，幫助開發(fā)人員輕松地工作，在黃金路徑內(nèi)，并盡可能少地出錯(cuò)。這樣做時(shí)，軟件目錄會通知開發(fā)人員，但自助服務(wù)操作本身需要立即反映在目錄中。
內(nèi)部開發(fā)人員門戶是否“只是開發(fā)人員自助服務(wù)的UI”？不是。為了理解原因，讓我們檢查一下軟件目錄，然后解釋它如何演變成平臺API。
軟件目錄是一切的中心
軟件目錄通常被描述為包含微服務(wù)、云資源和基礎(chǔ)設(shè)施的目錄，顯示上下文中的所有元素。它顯示并可以幫助管理權(quán)限、臨時(shí)環(huán)境和幾乎所有其他內(nèi)容。它包含了你可以驅(qū)動(dòng)到其中的所有元數(shù)據(jù)。它將被抽象出來供開發(fā)人員使用，只向他們顯示需要的內(nèi)容。
然而，即使你可能正在抽象其中的內(nèi)容，軟件目錄仍然充當(dāng)通用元數(shù)據(jù)存儲。因此，你可以對其運(yùn)行任何查詢并獲得所需的答案，即使是對于被認(rèn)為復(fù)雜的問題，如包漏洞計(jì)劃。這是運(yùn)維人員開始對軟件目錄感到興奮的地方。
軟件目錄需要在一開始就足夠中立，這樣你就可以構(gòu)建它以適合所擁有的任何數(shù)據(jù)模型，從而創(chuàng)建一個(gè)符合組織正在構(gòu)建的任何內(nèi)容的有見解的軟件目錄。
中央目錄不僅僅是關(guān)于其中的所有數(shù)據(jù)，或者它對開發(fā)人員和運(yùn)維人員都有什么用處。使用記分卡，目錄還反映了特定實(shí)體（例如在給定環(huán)境中運(yùn)行的特定服務(wù)）上下文中的質(zhì)量、健康狀況和其他度量。這有助于在有許多微服務(wù)、存儲庫和區(qū)域的環(huán)境中優(yōu)先采取行動(dòng)并提高質(zhì)量。它也有助于通過在一個(gè)中心位置確定質(zhì)量來改變組織行為。
軟件目錄也適用于機(jī)器和運(yùn)維
你可能已經(jīng)注意到，作為一個(gè)通用的元數(shù)據(jù)存儲，我們談?wù)摰氖且粋€(gè)超越開發(fā)人員體驗(yàn)的軟件目錄。換言之，盡管名稱如此，內(nèi)部開發(fā)人員門戶中的目錄也是為機(jī)器和管理機(jī)器的運(yùn)維人員創(chuàng)建的。
事實(shí)上，與我們交談的許多運(yùn)維人員都希望自己開始使用門戶，以管理軟件和系統(tǒng)的擴(kuò)展。他們抱怨混亂的微服務(wù)跟蹤和太多的DevOps工具，抱怨需要集中控制的復(fù)雜AppSec問題。然后他們明白了：他們想根據(jù)軟件目錄運(yùn)行工作流。
這是工作流自動(dòng)化，工作流檢查軟件目錄中所有內(nèi)容的狀態(tài)。我們經(jīng)常聽到這樣的消息，情況是這樣的：“如果軟件目錄包含有關(guān)服務(wù)鎖定/包/版本等的所有信息，我可以讓CI工作流作為工作流的一部分檢查軟件目錄嗎？”
如果服務(wù)被鎖定，工作流自動(dòng)化將在目錄中檢查它，并且不允許它部署。如果服務(wù)運(yùn)行狀況關(guān)閉，則將采取另一項(xiàng)操作。在這方面，前面提到的記分卡是有價(jià)值的，因?yàn)樽詣?dòng)化可以并且確實(shí)可以檢查記分卡信息，作為其流程的一部分。
門戶的核心原則
讓我們了解一下內(nèi)部開發(fā)人員門戶背后的核心思想：
——自帶數(shù)據(jù)模型。軟件目錄應(yīng)支持常見的數(shù)據(jù)模型（如后臺C4模型），以及唯一的數(shù)據(jù)模型。它應(yīng)該足夠中立，這樣你就可以在其中建立一個(gè)自己覺得好的數(shù)據(jù)模型。
——軟件目錄應(yīng)包含所需的所有數(shù)據(jù)，作為軟件和資源的通用元數(shù)據(jù)存儲。開發(fā)人員可以將數(shù)據(jù)抽象出來，但數(shù)據(jù)將保留在目錄中，供其他用戶使用，例如運(yùn)維團(tuán)隊(duì)或工作流自動(dòng)化。
——產(chǎn)品般的體驗(yàn)。UI應(yīng)該為開發(fā)人員提供黃金路徑體驗(yàn)。產(chǎn)品思維是內(nèi)部開發(fā)人員門戶的核心，UI應(yīng)該是可配置的，支持無代碼創(chuàng)建來支持這一點(diǎn)。
——與底層基礎(chǔ)設(shè)施和自動(dòng)化松散耦合。平臺一直在發(fā)展，無論它們是隨時(shí)間隨意構(gòu)建的還是新技術(shù)堆棧的結(jié)果。因此，內(nèi)部開發(fā)人員平臺（IDP）應(yīng)該與它們松散耦合。如果底層云資源、CI或CD系統(tǒng)被替換，開發(fā)人員應(yīng)該具有相同的體驗(yàn)。
——以最廣泛的方式允許開發(fā)人員自助服務(wù)。為了確保采用，開發(fā)人員需要在IDP中滿足他們的所有需求。只關(guān)注一個(gè)自助服務(wù)行動(dòng)，平臺進(jìn)度和IDP都不會增長。
——API優(yōu)先。
——設(shè)計(jì)符合要求且安全。
未來是平臺API
開發(fā)人員門戶的未來是成為一個(gè)平臺API，為與平臺交互提供統(tǒng)一的接口。開發(fā)者門戶還將托管軟件目錄，為平臺狀態(tài)提供上下文，并負(fù)責(zé)觸發(fā)平臺自動(dòng)化，作為其自助運(yùn)維的一部分。開發(fā)人員門戶將使用平臺API作為前端接口，平臺內(nèi)部組件將使用該API根據(jù)存儲在API中的上下文信息進(jìn)行自動(dòng)決策。
要進(jìn)行平臺工程，需要從門戶開始
無論你是否同意你已經(jīng)擁有一個(gè)平臺，內(nèi)部開發(fā)人員門戶可能是可以開始使用的加入平臺工程運(yùn)動(dòng)的最成熟和定義最明確的元素。內(nèi)部開發(fā)人員門戶非常有價(jià)值，足以推動(dòng)開發(fā)人員生產(chǎn)力的顯著提高，并為運(yùn)維人員帶來秩序。
