《激進市場》:雲端運算最重要的應用,就是「市場經濟」本身

《激進市場》:雲端運算最重要的應用,就是「市場經濟」本身
Photo Credit: Shutterstock / 達志影像

我們想讓你知道的是

我們倡議「激進市場」,原因在於我們相信,以現階段的科技與經濟發展,由於合作規模太過龐大,無法以道德經濟來管理,而市場正是適合為最多數人達成最高福祉的電腦。從這樣的觀點來看,我們可以修正市場編碼的瑕疵,讓市場能夠產生更多分配更公平的財富。

文:格倫・韋爾(E. Glen Weyl)、艾瑞克・波斯納(Eric A. Posner)

尾聲:後市場時代?

市場程序⋯⋯可視為電子時代之前的運算裝置。

——奧斯卡.蘭格(Oskar Lange),〈電腦與市場〉(The Computer And The Market),1967年

我們在全書中申張激進市場的轉化力量。但是市場究竟為什麼如此強而有力?在本書尾聲中,我們要反過來問這個問題。我們要問;市場的限制何在?這個問題能讓我們揣想,一個市場可能被某種更有效率的經濟籌畫方法所取代的時代。

市場就是奇蹟

我們曾在第1章述及,有許多忠於市場經濟的經濟學家也自認是「社會主義者」。然而在二十世紀初期,由於馬克思主義與法國大革命在蘇聯的經濟政策發揮了啟發與辯護之效,社會主義與中央計畫制度就變得如影隨形。第一次世界大戰也拉抬了中央計畫制度的聲勢,為了戰時的生產活動而將經濟交由國家控管,成效好得超乎倡議自由放任者的想像。中央計畫制度是否應該也用於和平時期的熱烈辯論於是點燃。

在世人的想像裡,中央計畫制度之所以無法成功,是因為它沒有賦予個人工作的誘因。讓大家早起的動力是致富(或至少是領到薪水)。然而在蘇聯,誘因卻相當強烈,而且在許多方面都勝過在資本主義國家。雖然在共產主義下,致富的機會渺茫,但隨便哪個古拉格的囚犯都知道「裝病」的人會有什麼樣的命運。

另一個反對中央計畫的普遍主張,是諾貝爾桂冠經濟學家海耶克在1945年所宣揚的論點。海耶克主張,沒有一個中央計畫者能取得關於大眾品味和生產力的資訊,而這些是達成資源配置效率的必要條件。市場的高明之處,就是價格制度能夠以分散的方式向所有人搜集這項資訊,並提供給需要知道的人,不必政府計畫委員會插手。

幾十年前,出現這個主張的一個相關版本,雖然知名度不如海耶克的主張,但其實更有說服力。聰慧的經濟學家米塞斯認為,社會主義面臨的根本問題,不在於抽象的誘因或知識,而在於溝通和運算。要明白米塞斯的意思,我們可以思索一下倫納德.里德(Leonard Read)在1958年的文章〈我這枝鉛筆〉(I, Pencil)提出的生動寓言。

里德講述了一枝鉛筆「一生的故事」。這麼簡單的東西,有人起初會這麼想。然而,如果你開始深思,你會發現要從無到有製造一枝鉛筆,需要層層疊疊、極其繁複的思考和規畫。木頭要經過砍伐、切割、成形、拋光和磨細。石墨要經過開採、挖鑿和塑形。連接筆身和橡皮擦的接環是數十種金屬的合金,這些金屬也都必須經過開探、熔化、化合和改良。諸如此類。

然而,鉛筆最了不起的不是它的複雜,而是每一個參與鉛筆製造的人,對於過程中的這些步驟都沒有通盤的理解。伐木工只知道他的木材有市場,得知價格後願意去購買所需的工具,砍伐樹木,並把木材賣到生產線。伐木工可能連木材是用於鉛筆都不知道。鉛筆工廠老闆只知道要去哪裡買所需的中間原物料,以及如何操作組裝原物料的生產線。製造鉛筆的知識和規畫,是在市場關係形成的過程中自然而然出現。

現在假設我們想要以中央計畫委員會複製市場關係。委員會要決定木材的砍伐量以及砍伐時機、各個生產階段的工人雇用量,以及生產、出貨與建置正確的地點及時間。然而,要有效地做到這些,委員會必須了解許多事情。它必須向這一群個個術有專精的生產者請教,學習他們得以在自身專業領域維生所憑恃的獨特知識,例如木材用於其他經濟部門,例如建造房屋、船隻或兒童玩具,價值是否會勝過做為鉛筆的一種原物料。要吸收所有這些資訊,還要不斷接收、消化必要的最新訊息,以掌握過程中各步驟的狀況變化,即使是最能幹的管理者,可能都會吃不消。

即使委員具備無極限的資訊吸收能力,在資料的汪洋裡,仍然無法克服行動困難的問題。價格、供給與需求、市場裡的生產關係,這些都衍生自個人之間的複雜互動,而這些個人分別都有助於廣大社會過程裡的一小部分達成最適化。如果以單一委員會取而代之,來規畫這一整支市場之舞,那麼這一小撮人就不得不深思這一連串無止境的選擇與規畫。這種精細繁複的計算,即使是一群最高超的工程師,都力有未逮。

在米塞斯著述的數十年前,電腦科學和資訊理論還沒有出現,他沒有任何方法可以把這些直覺構想付諸正式的表述。米塞斯的許多主張都受到主流經濟學家的排拒,而這些經濟學家用於這個領域愈見狹隘的數學方法,也為米塞斯所鄙視。米塞斯的批評者,包括蘭格、佛瑞德.泰勒(Fred Taylor)與阿巴.勒那(Abba Lerner),主張市場機制只不過是籌畫經濟的許多方法中的一個,而且遠遠稱不上是最有效率的一個。他們從純數學觀點來看經濟,而不是以運算觀點,而且認為那套與各種財貨、資源與服務供需相關的方程式系統(非常龐大),在原則上,解題沒有困難。

在簡化的經濟藍圖裡,一般人同時扮演生產者(勞動者、資本供應者等等)和消費者的角色。身為消費者,人們對各種財貨和服務有不同的偏好。有些人喜歡巧克力,有些人喜歡香草。身為生產者,他們具備不同的天賦與能力。有些人擅長數學,有些人對安撫顧客很有一套。原則上,我們唯一需要做的事,就是找出大家的偏好和能力,把工作指派給最能勝任的人,同時分配從生產大家真正想要的財貨與服務所創造出來的價值。我們也必須制定獎勵和懲罰,讓大家有顯現偏好和能力的誘因,並確保他們展現他們理應有的行為。所有這些都可以用數學呈現和解決。那就是為什麼社會主義經濟學家把經濟體看成一道數學題,只要一部電腦就可以解題。


猜你喜歡


挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

我們想讓你知道的是

企業如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署,減輕人力負擔,提升專案服務運作效率?

所謂現代化智慧 IT,所有工程師最希望的境界,莫過於只要輕鬆點幾下設定,系統就會自動跑起來,管理者再也不用隨時待命在機台旁邊,從此工作悠哉又快樂!儘管這樣情境還沒到來,但隨著敏捷式開發的流行,除了 DevOps 人員,有越來越多開發者將 CI/CD 概念融入到工作流程當中,例如從 build code、執行 unit test、到部署應用程式。

透過 AWS 增加雲端技能 在組織發揮影響力

上述種種反覆步驟自動化執行,也就能提昇服務品質、主動通知開發人員以減輕人力負擔,讓專案服務能持續運作。

其中,GitLab 是執行 CI/CD 常用的工具之一,也是開發者使用程式碼儲存庫的地方。為了讓 GitLab Runner 在雲端快速實踐 CI/CD,《AWS 開發者系列》透過影片分享,如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署。

以下節錄工作坊影音內容,幫助開發者快速理解如何運用 Amazon EKS 的高可用性且安全的叢集,將修補、部署節點、更新等關鍵任務,全部做到自動化設定。同時影片也會示範 Amazon EKS 搭配 GitLab 如何展開自動部署,幫助工程團隊實踐 CI/CD 價值。

Amazon EKS 對容器管理輕鬆簡單、維運省時省力

容器化服務越來越興盛,當容器(Container)越來越多,在複雜的微服務(Microservice)系統環境之下,運維團隊的管理成本可能相對會增加不少,為了有效調度容器部署, 導入Kubernetes 無疑是近年企業熱門的話題之一。

建構 Kubernetes Cluster 流主要可區分兩大塊,一是安排容器調度的Control Plane、另一則是容器運行時需要用到的 Worker Node。

Control Plane 裡面涵蓋有儲存狀態的 ETCD、CoController manager 、Scheduler 的調度管理、甚至是操作時進行互動的 APIServer,若是自己創建 的 Kubernetes Cluster ,需要自己安裝這些元件,後續仍需要對 Control Plane 進行相關管理、維護、升級工作。為了減少上述 Components 的繁複維護,在透過 AWS EKS 代管的 Kubernete Control Plane 部可以獲得以下三大好處。

Amazon EKS 一鍵式部署,展現三大優勢

第一,Amazon EKS代管的 Control Plane實踐了跨AZ的高可用部署,使用者不需要擔心單一節點故障的風險。

第二,Amazon EKS 支持至少四個 Kubernetes版本,持續跟進每季 CNCF 的發佈,同時 EKS 也完全符合上游 CNCF 規範。

第三,部署 Amazon EKS 之後,可直接使用 AWS 平台上現成的服務工具,在安全性管理、網路設定方面,可以做到無縫整合。

最後 AWS 台灣解決方案架構師也提到,若想在容器環境進行 CI/CD 及應用程式的管理,可以進一步透過 IaC 整合部署 Amazon EKS 叢集,透過使用 Console、把 EKS 變成 Cloudformation 的模板、使用 AWS 所開發出來的 eksctl.io、或指令是採用 AWS CDK 可以讓開發者用自身熟悉的語言,在 AWS 平台整合 CI/CD 工具進行維運及部署 EKS。

打造第一個在 AWS 上的應用程式

了解 Amazon EKS 整合 GitLab ,獲得三面向價值

對開發者而言,想把 Amazon EKS 整合到 CI/CD 工具之一的 GitLab 平台上,可以看到那些實際的優勢?

在 DevOps 開發者示範工作坊當中,GitLab 資深解決方案架構師指出,GitLab 使用到 Kubernetes 技術,主要有三種搭配方法,包含 GitLab Server、GitLab Runner、以及創建 Deployment Environment。

本次示範教學會主要聚焦在 GitLab Runner 如何採取 Auto-scaled 方式進行 Build、Test、Package Apps;以及在 Deployment Environment 運用 Kubernetes 技術,做到 Auto Deploy、Review App。

正因為 Amazon EKS 能夠在 DevOps 過程提供所需要的彈性計算資源,幫助開發者在 GitLab 平台上面獲得以下三個層次的優勢:

  • 在 GitLab 內建的部署工作流程當中,自動生成整套 CI/CD 最佳實踐腳本。
  • Review App 過程,從 Merge Request 中可直接訪問應用程式 /App 的 UI 介面,並且根據 Git branch 名稱、專案名稱,自動生成 Review App 的 URL,以及在 Merge 前的最後防線進行 Approval 檢查。
  • 加速 CI/CD 流水線,GitLab Runner 運行時候還可藉由 Amazon EKS Cluster 進行 Auto-scaled 的支援。

Amazon EKS 整合 GitLab ,需要兩大流程

影片最後,GitLab 資深解決方案架構師示範如何把 Amazon EKS 整合至 GitLab 執行 Auto Deploy,主要可分為兩大區塊流程,第一部分聚焦在 Amazon EKS cluster 的設置,第二部分則執行 Auto Deploy 設置。

第一塊可拆分為四個階段,首先教學怎麼創建 EC2 節點的 EKS cluster,第二階段示範把 EKS Cluster 連接到開發者的 GitLab Instance、Group 或 Project,下一步則使用 Cluster Management Project Template 創建一個 Cluster Management Project,以及最後一階段透過 Cluster Management Project 自帶的 Helm Chart,安裝在 Cluster 所需要的內建 App。

第二塊執行 Auto Deploy 設置,針對需要部署的 App 創建一個 GitLab Project,接著再把 gitlab-ci.yml 添加到 Project,並從 Web IDE 選擇及導入 Auto Deploy 的 CI 模版,讓 GitLab 自動生成最佳實踐的整套流水線。

幫助開發者更了解 Amazon EKS 整合 GitLab 的 QA 系列

Q:使用 Amazon EKS 之後,如何更有效率或優化資源去配置 Worker Node 的機器數量,以及如何有效空管開發維運的成本?

A:Kubernetes 除了本身有 HPA(Horizontal Pod Autoscaling)可根據使用程度自動調整資源流量,另外也能延伸使用 AWS Auto Scaling 方案,針對可擴展資源去設定自動擴展管理。另外在成本管控,雖然 Amazon EKS 會收取額外管理費用,但可透過 AWS 平台的 Calculato r計算每個 EKS 的價格,你會發現自動化部署及管理的費用,相對工程師人力的成本更加便宜。

Q:越來越多客戶考慮把現有 Application 變成容器部署,大多是爲了加快部署的效率,那麼變成容器模式之後,對 CI/CD 的工作流程有什麽影響嗎?

A:運用容器技術最直接的效果,可以讓應用程式的環境更一致化,例如 testing 環節、stage production,讓容器避開一些差異問題。至於 CD 部分要 delivery 一些 usage 不太一樣的時候,容器會幫忙做配置,所以 CI/CD 對容器的效益是相輔相成的。

Q: 客戶在開發流程漸漸會把 Infrastructure 變成代碼或文檔,是不是可以把程式碼跟現有的應用程式的 CI/CD 流水線整合在一起,達到一套完整的 CI/CD 部署流程?

A:觀察目前市場作法,主要分成兩個階段去做整體部署。如果規模比較小的團隊,會把 Infrastructure 代碼跟 App 代碼分開,在管理上會比較靈活;如果企業規模比較大,會有另外一個 Infrastructure 團隊來控制部署事情,這種情况之下,APP 的項目會生成一個 APP package,主要做到 delivery 這個階段爲止。而 Infrastructure 的項目會指定把需要版本的文檔,部署到他們的 Kubernetes Cluster。

填寫表單 找到適合的快速上雲服務與工具!


猜你喜歡