基礎(chǔ)設(shè)施即代碼（IaC）詳解

基礎(chǔ)設(shè)施即代碼（IaC）是軟件開發(fā)中的一個令人著迷的領(lǐng)域。雖然作為一門學(xué)科它還相對年輕，但在其短暫的發(fā)展歷程中，它已經(jīng)經(jīng)歷了幾次具有劃時代意義的變化。我認(rèn)為，它是當(dāng)今軟件開發(fā)創(chuàng)新中最熱門的領(lǐng)域之一，參與者很多，從大型科技公司到年輕的初創(chuàng)企業(yè)，都在創(chuàng)造新的方法，如果完全實(shí)現(xiàn)，有可能徹底改變我們編寫和部署軟件的方式。

在本篇文章中，我想對IaC這一主題進(jìn)行深入探討：它是什么，它能帶來什么好處，它已經(jīng)經(jīng)歷了哪些具有顛覆性的轉(zhuǎn)變，以及未來可能會發(fā)生什么樣的變化。

#01

什么是 IaC？

讓我們從解釋這個概念開始。基礎(chǔ)設(shè)施即代碼是一個涵蓋一系列實(shí)踐和工具的術(shù)語，旨在將應(yīng)用程序開發(fā)中的嚴(yán)謹(jǐn)性和經(jīng)驗(yàn)應(yīng)用到基礎(chǔ)設(shè)施供應(yīng)和維護(hù)的領(lǐng)域。

這里的“基礎(chǔ)設(shè)施”是故意模糊的，但我們可以把它定義為在環(huán)境中運(yùn)行一個特定的應(yīng)用程序所需要的一切，但這并不是應(yīng)用程序本身的一部分。一些常見的例子包括：服務(wù)器、配置、網(wǎng)絡(luò)、數(shù)據(jù)庫、存儲等等。在本文后面我們還會看到更多的例子。

IaC的實(shí)踐與運(yùn)行時代碼的實(shí)踐相呼應(yīng)。這些實(shí)踐包括：使用源代碼控制進(jìn)行版本管理、自動化測試、持續(xù)集成/持續(xù)交付（CI/CD）部署流程、快速反饋的本地開發(fā)等。

遵循IaC的實(shí)踐可以帶來以下好處：

性能：如果需要提供或更改大量基礎(chǔ)設(shè)施，IaC 將始終比人工手動執(zhí)行相同操作更快。

可重復(fù)性：人類在可靠地重復(fù)執(zhí)行相同任務(wù)方面往往表現(xiàn)不佳。如果我們需要重復(fù)進(jìn)行一百次相同的操作，很可能會分心并在過程中出錯。IaC 不會受到這個問題的影響。

文檔化：你的 IaC 可以作為你系統(tǒng)結(jié)構(gòu)的文檔。當(dāng)維護(hù)系統(tǒng)的團(tuán)隊(duì)規(guī)模擴(kuò)大時，這就變得至關(guān)重要了 —— 你不希望依賴于部落知識，或者只有少數(shù)幾個團(tuán)隊(duì)成員了解系統(tǒng)基礎(chǔ)設(shè)施的工作原理。最重要的是，與傳統(tǒng)文檔不同，這份文檔永遠(yuǎn)不會過時。

審計(jì)歷史：有了 IaC，由于你對IaC的版本控制與你的應(yīng)用代碼相同（有時被稱為 GitOps），它為你提供了歷史記錄，你可以查看你的基礎(chǔ)設(shè)施是如何隨時間變化的，如果任何變化導(dǎo)致問題，有辦法回滾到一個安全點(diǎn)。

可測試性：IaC 可以像應(yīng)用程序代碼一樣進(jìn)行測試。你可以對其進(jìn)行單元測試、集成測試和端到端測試。

接下來，讓我們談?wù)?IaC 工具在實(shí)踐開始以來所經(jīng)歷的主要階段。

#02

第一代：聲明式，主機(jī)配置

代表：Chef、Puppet、Ansible

第一代IaC工具都是關(guān)于主機(jī)配置的。這很有意義，因?yàn)檐浖到y(tǒng)的基礎(chǔ)設(shè)施，在其最低的抽象層次上，由單個機(jī)器組成。因此，這個領(lǐng)域的第一批工具集中在配置這些機(jī)器上。

這些工具管理的基礎(chǔ)設(shè)施資源是 Unix 中熟悉的概念：文件、來自 Apt 或 RPM 等軟件包管理器的 users、groups、permissions、init services 等等。

下面是一個創(chuàng)建 Java 服務(wù)的 Ansible playbook 例子：

-hosts:app tasks: -name:Updateapt-get apt:update_cache=yes -name:InstallApache apt:name=apache2state=present -name:InstallLibapache-mod-jk apt:name=libapache2-mod-jkstate=present -name:InstallJava apt:name=default-jdkstate=present -name:CreateTomcatnodedirectories file:path=/etc/tomcatstate=directorymode=0777 -file:path=/etc/tomcat/serverstate=directorymode=0775 -name:DownloadTomcat7package get_url:url=http://apache.mirror.digionline.de/tomcat/tomcat-7/v7.0.92/bin/apache-tomcat-7.0.92.tar.gzdest='/etc/tomcat' -unarchive:src=/etc/tomcat/apache-tomcat-7.0.92.tar.gzdest=/etc/tomcat/servercopy=no -name:ConfiguringMod-Jk&Apache replace:dest=/etc/apache2/sites-enabled/000-default.confregexp='^'replace="JkMount/statusstatus JkMount/*loadbalancer JkMountCopyOn " -name:DownloadsampleTomcatapplication get_url:url=https://tomcat.apache.org/tomcat-7.0-doc/appdev/sample/sample.wardest='/etc/tomcat/server/apache-tomcat-7.0.92/webapps'validate_certs=no -name:RestartApache service:name=apache2state=restarted -name:StartTomcatnodes command:nohup/etc/tomcat/server/apache-tomcat-7.0.92/bin/catalina.shstart

本操作手冊的抽象層次是一臺以 Linux 為操作系統(tǒng)的單一計(jì)算機(jī)。我們聲明我們想要安裝的 Apt 軟件包，我們想要創(chuàng)建的文件（創(chuàng)建它們的方式有多種：直接在給定的路徑下創(chuàng)建目錄，從給定的 URL 下載，從存檔中提取文件，或根據(jù)正則表達(dá)式替換編輯現(xiàn)有文件），我們想要運(yùn)行的系統(tǒng)服務(wù)或命令等等。 實(shí)際上，如果你稍微看一下，你會發(fā)現(xiàn)這個 playbook 與 Bash 腳本非常相似。主要的區(qū)別是，playbook 是聲明式的—— 它描述了它希望發(fā)生的事情，比如在機(jī)器上安裝給定的 Apt 軟件包。這與腳本不同，腳本包含要執(zhí)行的命令。 雖然這個區(qū)別很小，但它很重要；它使 playbook 具有冪等性，這意味著，即使它在中間某個地方失敗了（也許 tomcat。apache。org 有暫時的故障，導(dǎo)致從它那里的下載失?。?，你可以重新啟動它，之前成功執(zhí)行的步驟會識別到這一點(diǎn)，并在不做任何事情的情況下通過，這通常不是 Bash 腳本的情況。

現(xiàn)在，這些工具對于推進(jìn)軟件開發(fā)行業(yè)的發(fā)展起著至關(guān)重要的作用，不可忽視。但是，它們只能在單個主機(jī)層面上運(yùn)行，這有巨大的局限性。這就意味著你不得不手動管理這些主機(jī)，這在很大程度上抵消了IaC所帶來的好處，或者你需要將這些工具與能夠管理主機(jī)的其他工具結(jié)合使用，比如用于本地開發(fā)的 Vagrant，或者用于管理共享環(huán)境（如生產(chǎn)環(huán)境）的 OpenStack。

舉個例子，如果你想創(chuàng)建一個經(jīng)典的三層架構(gòu)，你需要創(chuàng)建三種類型的虛擬機(jī)，每種類型的虛擬機(jī)都有自己的 Ansible playbook，根據(jù)它們在架構(gòu)中的角色來配置這些主機(jī)。

IaC 工具的下一階段將擺脫這種限制。

#03

第二代：聲明式，云計(jì)算

代表：CloudFormation、Terraform、Azure Resource Manager

2000 年代中期，云計(jì)算的引入是軟件開發(fā)史上的一個里程碑事件。在許多方面，我認(rèn)為我們?nèi)栽谏疃认鶐淼母锩杂绊憽?/p>

突然間，主機(jī)管理的諸多問題得到了解決。你不需要運(yùn)行和操作你自己的 OpenStack 集群來自動管理虛擬機(jī)；云供應(yīng)商將為你處理這一切。

但更重要的是，云計(jì)算立即提高了我們設(shè)計(jì)系統(tǒng)的抽象水平。不再只是給主機(jī)分配不同的角色那么簡單。

如果你需要發(fā)布 - 訂閱資源，那么就沒有必要去配置一臺虛擬機(jī)，并在其上安裝 Apt 的 ZeroMQ 包；相反，你可以直接使用 Amazon SNS。如果你想存儲一些文件，你也不需要指定一堆主機(jī)作為你的存儲層；相反，你可以創(chuàng)建一個 S3 存儲桶。諸如此類，不一而足。

我們進(jìn)入了配置管理服務(wù)的階段，而不再是將主機(jī)配置置于首要位置。由于上一代的工具被設(shè)計(jì)成只在單個主機(jī)的層面上工作，因此我們需要一種全新的方法。

為了解決這個問題，像 CloudFormation 和 Terraform 這樣的工具應(yīng)運(yùn)而生。它們和第一代工具一樣，都采用聲明式設(shè)計(jì)；但不同之處在于，它們操作的抽象層級不再是單一機(jī)器上的文件和軟件包，而是各種屬于不同托管服務(wù)的獨(dú)立資源，以及這些資源的屬性和它們之間的相互關(guān)系。

例如，這里有一個 CloudFormation 模板，定義了一個由 SQS 隊(duì)列觸發(fā)的 AWS Lambda 函數(shù)：

AWSTemplateFormatVersion:2010-09-09 Resources: LambdaFunction: Type:AWS::Function Properties: Code: S3Bucket:my-source-bucket S3Key:lambda/my-java-app.zip Handler:example.Handler Role:!GetAttLambdaExecutionRole.Arn Runtime:java17 Timeout:60 MemorySize:512 MyQueue: Type:AWS::Queue Properties: VisibilityTimeout:120 LambdaFunctionEventSourceMapping: Type:AWS::EventSourceMapping Properties: BatchSize:10 Enabled:true EventSourceArn:!GetAttMyQueue.Arn FunctionName:!GetAttLambdaFunction.Arn LambdaExecutionRole: Type:AWS::Role Properties: AssumeRolePolicyDocument: Version:'2012-10-17' Statement: -Effect:Allow Principal: Service: -lambda.amazonaws.com Action: -sts:AssumeRole Policies: -PolicyName:allowLambdaLogs PolicyDocument: Version:'2012-10-17' Statement: -Effect:Allow Action: -logs:* Resource:arnlogs*:* -PolicyName:allowSqs PolicyDocument: Version:'2012-10-17' Statement: -Effect:Allow Action: -sqs:ReceiveMessage -sqs:DeleteMessage -sqs:GetQueueAttributes -sqs:ChangeMessageVisibility Resource:!GetAttMyQueue.Arn

這個 CloudFormation 模板與我們之前看到的 Ansible playbook 差別很大。它并未提及任何文件、程序包或初始化服務(wù)；而是使用了托管服務(wù)的語言。我們配置的資源類型是AWS::Function和AWS::Queue。我們并未定義這些服務(wù)將在何處運(yùn)行，也未定義如何配置這些主機(jī) ——我們所關(guān)心的是，云供應(yīng)商所提供的托管服務(wù)能否被正確使用。

然而，它與 Ansible 的共同點(diǎn)在于其聲明性質(zhì)。我們不需要編寫對 SQS API 的調(diào)用來創(chuàng)建一個隊(duì)列 —— 我們只需要聲明我們需要一個隊(duì)列，并將 VisibilityTimeout 屬性設(shè)置為 120，部署引擎（在這個例子中是 CloudFormation）會負(fù)責(zé)確定需要調(diào)用哪些 AWS API 來實(shí)現(xiàn)這個目標(biāo)。如果我們后來決定修改隊(duì)列（比如我們想將超時時間設(shè)為 240，而不是 120），或者完全刪除它，我們只需修改模板，引擎便會自動找出需要的 API 調(diào)用來更新或者刪除隊(duì)列。

這些工具是 IaC 發(fā)展過程中的一個巨大的里程碑，這大大提升了前一代的抽象水平。然而，它們也存在一些缺陷。

第一個問題是，為了實(shí)現(xiàn)其聲明性質(zhì)，這些工具使用了自定義的 DSL（領(lǐng)域特定語言），例如，在 CloudFormation 中，這種語言可能是 JSON 或 YAML 格式。這就意味著所有的通用編程語言功能，比如變量、函數(shù)、循環(huán)、if 語句、類等，在這種 DSL 中都無法使用。因此，沒有簡單的辦法來減少重復(fù)代碼。

舉個例子，如果我們想要在我們的應(yīng)用中配置不止一個，而是三個具有相同設(shè)置的隊(duì)列，我們無法簡單地編寫一個循環(huán)來執(zhí)行三次；我們必須把相同的定義復(fù)制和粘貼三次，這并不理想。同時，這也意味著我們無法將模板劃分為邏輯單元；我們無法將一部分資源指定為存儲層，另一部分資源指定為前端層等。所有的資源都屬于一個扁平的命名空間。

這些工具的另一個問題是，雖然它們肯定比第一代的主機(jī)配置更高級，但它們?nèi)匀恍枰阍敿?xì)指定在系統(tǒng)中使用的所有資源的所有細(xì)節(jié)。例如，你可能已經(jīng)注意到，在上面的模板示例中，除了我們主要關(guān)注的 Lambda 和 SQS 資源，我們還有事件映射和 IAM 資源。這是連接 SQS 和 Lambda 所需的 “粘合劑”，而正確配置這些“粘合劑”資源并非易事。

舉例來說，你需要向執(zhí)行函數(shù)的 IAM 角色授予一組非常特定的權(quán)限（sqs:ReceiveMessage、sqs:DeleteMessage、sqs:GetQueueAttributes 和 sqs:ChangeMessageVisibility），才能成功地從特定隊(duì)列觸發(fā)它。

從某種程度上來說，這是一個非常低級的問題；然而，由于 DSL 中缺乏抽象工具，我們實(shí)際上沒有任何工具可以隱藏這些實(shí)現(xiàn)細(xì)節(jié)。所以，每次你需要創(chuàng)建一個由 SQS 隊(duì)列觸發(fā)的新 Lambda 函數(shù)，你別無選擇，只能復(fù)制包含這四個權(quán)限的代碼段。因此，這些模板往往會很快變得冗長，并包含大量重復(fù)內(nèi)容。

#04

第三代：命令式，云計(jì)算

代表：AWS CDK、Pulumi、SST

例如，讓我們看看相當(dāng)于上述 CloudFormation 模板的云開發(fā)工具包程序（在這個例子中我將使用 TypeScript，但任何其他 CDK 支持的語言看起來都非常相似）：

第二代工具的所有缺陷都可以追溯到它們使用了一種自定義的 DSL，這種語言缺乏我們在使用通用編程語言時習(xí)慣的抽象工具，如變量、函數(shù)、循環(huán)、類、方法等。

因此，第三代IaC工具的主要思想非常簡單：如果通用編程語言已經(jīng)具備了這些功能，那么我們?yōu)槭裁床皇褂盟鼈儊矶x基礎(chǔ)設(shè)施，而要使用自定義的 JSON 或 YAML DSL？

例如，讓我們看看相當(dāng)于上述 CloudFormation 模板的云開發(fā)工具包程序（在這個例子中我將使用 TypeScript，但任何其他 CDK 支持的語言看起來都非常相似）：

classLambdaStackextendscdk.Stack{ constructor(scope:cdk.Construct,id:string,props?:cdk.StackProps){ super(scope,id,props); constfunc=newlambda.Function(this,'Function',{ code:lambda.Code.fromBucket( s3.Bucket.fromBucketName(this,'CodeBucket','my-source-bucket'), 'lambda/my-java-app.zip'), handler:'example.Handler', runtime:lambda.Runtime.JAVA_17, }); constqueue=newsqs.Queue(this,'Queue',{ visibilityTimeout:cdk.Duration.minutes(2), }); func.addEventSource(newlambda_events.SqsEventSource(queue)); } } constapp=newcdk.App(); newLambdaStack(app,'LambdaStack');

這個 CDK 代碼的第一個有趣之處在于，它比其對應(yīng)的 CloudFormation 模板要短得多 —— 大約 20 行 TypeScript，而 YAML 大約有 60 行，所以大概是 3 比 1 的比例。這是一個非常簡單的例子；當(dāng)你的基礎(chǔ)設(shè)施越來越復(fù)雜時，這個比例就會越來越大 —— 我見過有些情況下比例高達(dá) 30 比 1。

其次，CDK 代碼的級別比 CloudFormation 模板要高得多。請注意，如何從隊(duì)列中觸發(fā)函數(shù)的細(xì)節(jié)被 addEventSource() 方法和 SqsEventSource 類優(yōu)雅地封裝了起來。這兩個 API 都是類型安全的 —— 你不能錯誤地將一個 SNS 主題傳遞給 SqsEventSource，因?yàn)榫幾g器不允許這樣。

還請注意，我們不必在代碼中的任何地方提到 IAM —— CDK 為我們處理了所有這些細(xì)節(jié)，所以我們不必知道需要哪 4 個確切的權(quán)限來允許一個函數(shù)被隊(duì)列觸發(fā)。

所有這些都是因?yàn)?strong>高級編程語言允許我們構(gòu)建抽象概念。我可以把一段重復(fù)的或復(fù)雜的代碼，放在一個類或函數(shù)中，并為我的項(xiàng)目提供一個干凈、簡單的 API，這個 API 巧妙地封裝了所有混亂的實(shí)現(xiàn)細(xì)節(jié)，就像 CDK 團(tuán)隊(duì)創(chuàng)建和維護(hù)的 SqsEventSource 類那樣。

如果這是其他項(xiàng)目可能受益的東西，我可以把我的抽象概念打包成它所使用的編程語言的庫，并通過我的語言的包管理器分發(fā)出去，比如 JavaScript/TypeScript 的 npmjs.com，或 Java 的 Maven Central，這樣其他人就可以依賴它，就像我們分發(fā)應(yīng)用程序代碼的庫一樣。我甚至可以把它添加到 constructs.dev 的可用開源 CDK 庫目錄中，這樣就更容易找到它。

#05

第四代：Infrastructure from Code

代表：Wing、Dark、Eventual、Ampt、Klotho

雖然第三代 IaC 工具是一個巨大的飛躍，使云計(jì)算更容易被使用（我在這里可能有偏見，因?yàn)槲沂?AWS 的 CDK 團(tuán)隊(duì)的前成員，但我認(rèn)為這種說法很接近事實(shí)），但它們?nèi)匀挥懈倪M(jìn)的空間。

他們的第一個缺點(diǎn)是，它們在很大程度上是在單個云服務(wù)的層面上運(yùn)作的。因此，雖然他們使使用 Lambda 或 SQS 變得很容易，但你仍然需要知道這些服務(wù)是什么，以及為什么你會考慮使用它們。

現(xiàn)在是云計(jì)算時代，我們已經(jīng)看到每個供應(yīng)商提供的服務(wù)數(shù)量激增。僅 AWS 就有 200 多種。在如此多樣化的選擇中，選擇適合自己要求的服務(wù)變得越來越難。我應(yīng)該在 AWS Lambda、AWS EKS 或 AWS AppRunner 上運(yùn)行我的容器嗎？我應(yīng)該使用 Google Cloud Functions 還是 Google Cloud Run？在什么情況下，這一個比那一個更適合？

大多數(shù)開發(fā)人員對每個云計(jì)算供應(yīng)商的產(chǎn)品沒有特別詳細(xì)的了解，特別是由于這些產(chǎn)品往往經(jīng)常變化，新的服務(wù)（或現(xiàn)有服務(wù)的新功能）不斷推出，舊的服務(wù)被淘汰。但他們確實(shí)對系統(tǒng)設(shè)計(jì)的基本原理有很好的理解。

因此，他們知道他們需要一個無狀態(tài)的 HTTP 服務(wù)，在負(fù)載均衡器后面進(jìn)行水平擴(kuò)展，一個 NoSQL 文檔存儲，一個緩存層，一個靜態(tài)網(wǎng)站前端，等等。第三代的工具對他們來說太低級了；理想情況下，他們希望用這些高級別的系統(tǒng)架構(gòu)術(shù)語來描述他們的基礎(chǔ)設(shè)施，然后將如何在給定的云供應(yīng)商上最好地實(shí)現(xiàn)這種架構(gòu)的細(xì)節(jié)委托給他們的 IaC 工具。

第三代工具的第二個缺點(diǎn)是，它們將IaC與應(yīng)用程序代碼完全分開。例如，在上面的 CDK 的例子中，Lambda 函數(shù)的代碼與它的基礎(chǔ)設(shè)施定義完全脫節(jié)。而且，雖然 CDK 有資產(chǎn)的概念，允許這兩種類型的代碼在同一個版本控制倉庫中存在，但它們?nèi)匀徊荒芟嗷?。從某種意義上說，這就是重復(fù) —— 我的應(yīng)用程序代碼使用了 SQS 隊(duì)列，這對我的IaC提出了一個隱含的要求，即正確配置該隊(duì)列。

但是，就像所有的重復(fù)和隱含要求一樣，當(dāng)雙方意外地不同步時（例如，如果我從我的基礎(chǔ)設(shè)施代碼中刪除了隊(duì)列，但忘記更新我的應(yīng)用程序代碼以不再使用它），這可能會導(dǎo)致問題，而且在我部署我的更改之前，我的語言的編譯器并不能幫助我捕獲這些錯誤，可能會引發(fā)問題。

第四代 IaC 工具的目標(biāo)是解決上述兩個問題。它們的主要理念是，在云計(jì)算時代，基礎(chǔ)設(shè)施代碼和應(yīng)用程序代碼之間的區(qū)別已經(jīng)變得沒有太大意義。因?yàn)閮烧叨荚谑褂猛泄芊?wù)的語言，我在應(yīng)用程序代碼中想使用的任何資源，都需要在我的基礎(chǔ)設(shè)施代碼中存在，就像我們在 Lambda 和 SQS 的例子中看到的一樣。

因此，這些工具將兩者統(tǒng)一起來。它們不再是獨(dú)立的基礎(chǔ)設(shè)施和應(yīng)用程序代碼，而是消除了前者，只保留了應(yīng)用程序代碼，而基礎(chǔ)設(shè)施則完全來自應(yīng)用程序代碼。由于這個原因，這種方法被稱為 Infrastructure from Code，而不是 Infrastructure as Code。

讓我們來看看 IfC 工具的兩個例子。

Eventual

第一個是 Eventual，一個 TypeScript 庫，它定義了現(xiàn)代云應(yīng)用的幾個通用構(gòu)建模塊：Service、API、Workflow、Task、Event 以及其他一些東西。你可以從這些通用構(gòu)件中創(chuàng)建一個任意復(fù)雜的應(yīng)用程序，把它們組合在一起，就像樂高積木一樣。

Eventual 部署引擎知道如何將這些構(gòu)建模塊轉(zhuǎn)換為 AWS 資源，如 Lambda 函數(shù)、API 網(wǎng)關(guān)、StepFunction 狀態(tài)機(jī)、EventBridge 規(guī)則等。這種轉(zhuǎn)換的細(xì)節(jié)被庫的抽象所隱藏，因此，作為它的用戶，你無需關(guān)心這些細(xì)節(jié) —— 你只需使用所提供的構(gòu)件模塊，部署由庫處理。

下面是一個簡單的例子，顯示 Event、Subscription、Task、Workflow 和 API：

import{event,subscription,task,workflow,command}from"@eventual/core"; //defineanEvent exportinterfaceHelloEvent{ message:string; } exportconsthelloEvent=event("HelloEvent"); //getnotifiedeachtimetheeventisemitted exportconstonHelloEvent=subscription("onHelloEvent",{ events:[helloEvent], },async(event)=>{ console.log("receivedevent:",event); }); //aTaskthatformatsthereceivedmessage exportconsthelloTask=task("helloTask",async(name:string)=>{ return`hello${name}`; }); //anexampleWorkflowthatusestheaboveTask exportconsthelloWorkflow=workflow("helloWorkflow",async(name:string)=>{ //calltheTasktoformatthemessage constmessage=awaithelloTask(name); //emitanEvent,passingitsomedata awaithelloEvent.emit({ message, }); returnmessage; }); //createaRESTAPIforPOST/hello exportconsthello=command("hello",async(name:string)=>{ //triggertheaboveWorkflow const{executionId}=awaithelloWorkflow.startExecution({ input:name, }); return{executionId}; });

Wing

另一種方法是創(chuàng)建一個全新的通用編程語言，該語言不僅僅在單臺機(jī)器上執(zhí)行，而是從一開始就設(shè)計(jì)成在云上分布式運(yùn)行。Wing 就是由 Monada 公司創(chuàng)建的一種這樣的語言，該公司的聯(lián)合創(chuàng)始人是 AWS CDK 的創(chuàng)建者 Elad Ben-Israel。

Wing 通過引入執(zhí)行階段的概念成功地將基礎(chǔ)設(shè)施代碼和應(yīng)用程序代碼合并在一起。默認(rèn)情況下，Preflight 對應(yīng)于 “構(gòu)建時間”，在這個階段執(zhí)行基礎(chǔ)設(shè)施代碼；Inflight 對應(yīng)于“運(yùn)行時間”，應(yīng)用程序代碼在云上運(yùn)行。

通過 Wing 編譯器實(shí)現(xiàn)的復(fù)雜的引用機(jī)制，Inflight 代碼可以使用 Preflight 代碼中定義的對象。然而，Inflight 階段不能創(chuàng)建新的 Preflight 對象，只能使用這些對象明確標(biāo)有修飾符的特定 API Inflight。Wing 編譯器會確保你的程序遵守這些規(guī)則，所以如果你試圖破壞這些規(guī)則，它就會編譯失敗，并為你快速提供關(guān)于應(yīng)用程序正確性的反饋。

因此，我們上面看到的那個由隊(duì)列觸發(fā)的無服務(wù)器函數(shù)的例子，在 Wing 中看起來會是下面這樣的：

bringcloud; letqueue=newcloud.Queue(timeout:2m); letbucket=newcloud.Bucket(); queue.addConsumer(inflight(item:str):str=>{ //getanitemfromthebucketwiththenameequaltothemessage letobject=bucket.get(item); //dosomethingwith'object'... });

這段代碼相當(dāng)高級 —— 我們甚至沒有在任何地方明確提到無服務(wù)器函數(shù)資源，我們只是在一個匿名函數(shù)中寫了我們的應(yīng)用代碼，用 Inflight 修改器進(jìn)行了注釋。該匿名函數(shù)被部署在無服務(wù)器函數(shù)中，并在云上執(zhí)行（或在 Wing 附帶的本地模擬器中執(zhí)行，以提供快速開發(fā)體驗(yàn)）。

還要注意的是，我們不能在應(yīng)用代碼中錯誤地使用錯誤的資源。例如，錯誤地使用 SNS 主題而不是 SQS 隊(duì)列，因?yàn)樵?Preflight 的代碼中沒有定義 Topic 對象，所以我們沒有辦法在 Inflight 的代碼中引用它。同樣，你也不能在 Preflight 的代碼中使用 bucket.get() 方法，因?yàn)槟鞘且粋€ Inflight 的專用 API。這樣一來，語言本身就可以防止我們犯很多錯誤，如果基礎(chǔ)設(shè)施和應(yīng)用代碼是分開的，這些錯誤就不會被發(fā)現(xiàn)。

如果你想了解更多關(guān)于 Infrastructure from Code 的新趨勢，我推薦這篇來自 Ala Shiban 的文章，他是這個領(lǐng)域另一個工具 Klotho 的聯(lián)合創(chuàng)始人。

https://klo.dev/state-of-infrastructure-from-code-2023

#06

總結(jié)

這就是 IaC 領(lǐng)域的歷史和最新發(fā)展。我認(rèn)為這值得密切關(guān)注，因?yàn)樗钱?dāng)今軟件工程中最熱門的領(lǐng)域之一，甚至在一些產(chǎn)品中還將最新的人工智能進(jìn)展納入其中，比如 EventualAI 和 Pulumi Insights。

我相信，在不久的將來，這個領(lǐng)域?qū)楷F(xiàn)出許多新的方法，這些方法將對我們編寫和發(fā)布軟件的方式產(chǎn)生深遠(yuǎn)的影響。