利用無伺服器最佳化應用程式開發
最佳化應用程式開發的機會
虛擬機器 (VM)、容器和公有雲端等創新在許多方面改善了應用程式開發，但仍將數項設定、維護和最佳化決策放在開發人員身上，而不是技術本身。
開發人員承擔的這些責任越多，他們用於建置產品和內部應用程式的時間就越少。遺憾的是，許多廣泛採用的技術要求開發人員進行效能最佳化、應用程式擴展、安全修補程式、負載平衡等。這些職責帶來了可能會耗盡預算或導致漏洞和停機的次優選擇或錯誤的風險。
這種低效率會產生嚴重的後果。令人震驚的是，開發人員花在非編碼任務上的時間每年花費組織超過 850 億美元的支出。
因此，從應用程式開發中消除複雜性可以改善開發人員體驗，同時還可以幫助組織節省大量資金。
產業轉向無伺服器
無伺服器技術旨在解決這些問題，特別是透過減輕開發人員的負擔來改善應用程式開發。但是，並非所有的無伺服器平台都是一樣的。無伺服器平台的早期反覆運算繼承了許多與它們所基於的技術（容器、區域和公有雲端）相關的設定、可擴展性和效能問題。
因此，我們今天所知的「無伺服器」通常是舊模型之上一個有漏洞的抽象。
進階的無伺服器平台已經透過幾項重要的架構改進解決了這些問題。這些改進移除了開發過程中耗時的決策，因此團隊可以花更多時間建置出色的產品和應用程式。
以先前的開發方法為建置基礎
在無伺服器之前，有 VM 和容器。VM 是存在於其他電腦作業系統中的軟體型電腦，而容器則是標準軟體單位，可容納應用程式執行所需的所有元素。
這兩種技術都可以讓開發人員更專注於他們的應用程式，減少在管理硬體上花費的時間。但是，VM 和容器仍然會讓開發人員負責管理和設定職責，這些職責會拖慢整體開發過程。
在不同程度上，VM 和容器需要開發人員及其合作的 IT 和安全團隊執行以下工作：
管理安全性修補程式以及身分識別與存取管理 (IAM) 權限
設定負載平衡和網路
確保可用性並保留備援
像 Kubernetes 這樣的容器協調系統減輕了許多與容器相關的設定要求，包括管理規模和備援。但是，專注於解決內部開發問題而不是客戶面向問題的開發人員營運 (DevOps) 團隊需要 Kubernetes 專業知識才能有效地管理它。如果沒有 Kubernetes 和訓練有素的團隊，則仍會受限於容器限制。
VM 和容器只是更大圖景的一部分。這兩種技術都可以在公有雲端中使用，這帶來了自身的局限性。
公有雲端有助於簡化開發的各個方面，但仍將設定層留給客戶組織，例如選擇區域、管理安全性、設計網路解決方案和確保可用性。公有雲端還需要手動組合多個服務，如資料庫、訊息佇列和儲存。手動設定和連接這些服務非常耗時，增加了總體部署時間。
第一代無伺服器開發效率較低
無伺服器開發旨在克服與 VM、容器和公有雲端相關的挑戰。但是，早期的無伺服器方法只是部分成功。
第一代無伺服器開發的主要挑戰包括：
延遲和可擴展性。許多此類無伺服器平台都在公有雲端中運作，公有雲端依賴於集中式資料中心來降低管理成本。此模型要求客戶選擇其資源實際所在的部署區域。集中資料會引入延遲，因為程式碼在遠離終端使用者的地方執行。此外，可以在多個區域進行擴展和部署，但設定起來很複雜。
冷啟動和 CPU 節流。基於容器構建的無伺服器平台在和冷啟動與中央處理器 (CPU) 節流作鬥爭。冷啟動是無伺服器功能首次執行時發生的載入延遲。冷啟動的發生是因為容器可能需要幾秒鐘才能預熱。另一方面，當平台達到其指定的無伺服器執行個體限制並延遲請求時，就會發生 CPU 節流。
開發人員經驗不佳。開發人員通常必須管理耗時的工作，例如設定協調流程範本、調整應用程式大小，以及判斷記憶體層。這些任務有可能產生代價高昂的錯誤，並減少了開發人員花費在編碼上的時間，隨著時間的推移給組織帶來了成本。
有限的可觀察性。許多無伺服器開發平台難以監控，因為它們沒有提供足夠的可觀察性。可觀察性是指組織可以透過效能指標、事件記錄等，瞭解分散式系統中發生的事情的程度。如果沒有足夠的可觀察性，組織就無法在無伺服器應用程式中有效率地診斷和修正問題。
無狀態性質限制了應用程式功能。第一代無伺服器平台實際上是無狀態的。無狀態性質有助於可擴展性，但可能難以建置需要在多個用戶端之間保持強一致性或即時協調的應用程式，如互動式聊天、電玩遊戲或協作編輯工具。
成本。許多雲端無伺服器平台會承擔額外且通常隱藏的成本，例如 API 閘道費用或保持容器溫度的費用。因此，使用這些第一代平台建置應用程式可能會很昂貴，尤其是大規模建置時。
無伺服器運動的目的一直是讓應用程式開發程序更容易，但是在集中式公有雲端上執行的無伺服器平台並不能完全實現這一承諾。
重新思考無伺服器：無伺服器如何演進
新一代無伺服器開發平台已經克服了早期產品的許多缺點。透過不依賴容器和公有雲端等舊版基礎結構，這些解決方案提供了多項改進並將時間交還給開發人員。
這些改進包括：
在網路邊緣執行。最先進的無伺服器平台在「邊緣」上執行——也就是由許多資料中心組成的分散式網路。網路越大，就能越好地解決效能和擴展性問題。這是因為，在邊緣網路中，運算發生在最接近使用者的服務提供點。這種分散式方法可減少延遲，而且與公有雲端中的集中式區域完全不同。因此，將程式碼部署到由數百個資料中心組成的網路，比由 20 個資料中心所組成的網路能提供更好的效能。最進階的邊緣平台將提供較長的 CPU 執行時間來建置複雜的工作負載。
使用隔離而不是容器。這種方法移除了基於容器的架構問題（冷啟動和 CPU 節流，這些問題的緩解成本很高。與容器不同，隔離物不需要保溫，因此冷啟動不是問題。隔離還耗用更少的記憶體，減少開支和 CPU 節流問題。
更少的前期決策。一些較新的邊緣無伺服器平台會自動最佳化應用程式的效能和安全性。具有全球邊緣網路的解決方案也不需要開發人員選擇區域來託管他們的工作負載，因為他們將程式碼部署到他們網路上的所有資料中心。移除這些繁瑣的任務可以改善開發人員的體驗。
詳細的分析和記錄。先前的無伺服器平台並未提供太多的分析、偵錯或記錄功能，進階邊緣無伺服器平台可提供更高的可觀察性。詳細的分析和記錄可讓開發團隊更輕鬆地收集疑難排解問題所需的資訊。此外，某些平台還與更複雜的監控工具整合，這些工具可能需要更複雜的應用程式。
整合式協調與儲存。此功能可讓無伺服器成為具狀態架構。具狀態架構需要一致的資料儲存，這與無狀態應用程式不同，在後者中，資料是臨時的。如果沒有具狀態架構，就無法建立互動式即時應用程式。
成本效益。輕量型隔離式邊緣無伺服器平台的成本比基於容器的前代產品更低。隔離架構帶來了與雲端相關的所有可擴展性和靈活性優勢，但沒有隱藏的費用和成本高峰。
透過這些改良功能，新一代無伺服器平台可最佳化整體應用程式開發過程；消除繁瑣的工作，讓開發人員專注編碼，同時為組織節省成本。
利用 Workers 最佳化應用程式開發
正確的無伺服器平台移除了可擴展性限制，同時減輕了開發人員的負擔，並提高了應用程式開發過程的整體效率。Cloudflare Workers 是一個基於邊緣的無伺服器平台，它使用智慧型基礎結構，讓開發人員省去許多前期決策。得益於 Cloudflare 的基礎結構，基於 Workers 建置的應用程式始終針對安全性、效能和可靠性進行最佳化。
可擴展性從來都不是問題，因為 Workers 在跨越 125 多個國家/地區超過 330 座城市的全球 Cloudflare 網路上執行。程式碼自動部署到所有區域，無需額外成本或設定。開發團隊可以使用 Workers Unbound 在邊緣構建需要較長 CPU 執行階段的進階應用程式。因為 Workers 平台在隔離物而不是容器上執行，所以沒有冷啟動或 CPU 節流。除了透過 Workers 命令列介面 (CLI) 提供的偵錯和記錄工具外，Workers 還提供內建的可觀察性並與更先進的監控工具（如 New Relic 和 Sentry）整合。 Durable Objects 為 Workers 平台提供低延遲協調和一致儲存，使具狀態無伺服器應用程式成為現實。與此同時，Workers 透過移除隱藏費用和提供業界領先的定價，為客戶節省了資金。
Worker 讓開發團隊能夠專注於建置產品，而非維護和設定，改善了開發人員體驗，並隨著時間的推移使公司獲益。
Cloudflare 就影響當今技術決策者的最新趨勢和主題發表了一系列文章，本文為其一。
重點
閱讀本文後，您將能夠瞭解：
效率低下的開發架構中有什麼危險
開發方法的演變如何將我們帶入無伺服器時代
無伺服器的早期反覆為何未能簡化應用程式開發
新一代無伺服器的主要差異