當云計算技術最初出現時，一種很流行的觀點是它將包含所有計算。一種常見的類比是將其比作電網，可以在很大程度上取代本地的分布式發電設施。

　　但是，公有云不能總是替代內部部署硬件有著很多原因。特別是在采用邊緣計算的情況下，希望將計算推向更靠近數據收集和使用的地方。

　　隨著機器學習越來越多地用于在時間緊迫的情況下將內部部署操作實現自動化，這一點變得很重要。此外，與始終依賴中心站點相比，在本地采取行動通常不僅更快，而且在連接中斷時更有彈性。

　　然而，實現邊緣計算架構并不總是那么簡單。當企業將業務推向網絡邊緣時，需要考慮以下四個因素。

　　1.需要考慮自動化

　　自動化和管理很重要，邊緣計算設備的數量龐大以及可能沒有本地IT人員(甚至現場沒有固定員工)的事實意味著他們需要采用自動化和管理。

　　自動化使用軟件創建可重復的指令和流程，從而減少人員與IT系統的交互。這反過來又可以改進IT供應、配置管理、修補、應用編排、安全性和合規性。自動化通常是通過靠近邊緣端點和集中控制層的自動化工作流來實現的。本地化執行可以防止高延遲和連接中斷，集中控制則提供對邊緣環境的集成控制。

　　例如，零售連鎖店可能會自動化端點以簡化基礎設施操作、加強安全策略并標準化跨分支機構的設備配置。大規模配置、災難恢復、分支遷移和響應特定事件的操作都是自動化可以在邊緣環境中發揮作用的示例。

　　與之密切相關的是管理，其中包括創建標準的操作環境。這樣做是擴展的關鍵。在從開發到生產的整個環境中部署標準化映像時，還需要將這些系統注冊到邊緣管理控制臺。維護安全策略也是一項基本的管理功能。

　　2.不要隨意構建業務流程

　　如果沒有進行管理的話，邊緣計算可能會變得混亂不堪。即使有了自動化和管理系統，仍然需要架構承諾來保持跨邊緣和數據中心環境的高度一致性。

　　缺乏一致性的一個原因是外圍設備通常比數據中心的服務器更小，功能也更弱。因此，他們需要運行不同的軟件。

　　但情況不一定如此，或者至少不是全部。企業可以從在其他地方運行的小型核心Linux操作系統構建系統映像，并對其進行自定義，以準確添加在驅動程序、擴展和工作負載方面所需的內容。然后可以將映像作為一個單元進行版本控制、測試、簽名和部署，因此企業的運營團隊可以準確了解設備上運行的內容。

　　還可以將分階段和應用的映像更新配置為僅在下一次重新啟動時發生，以確保停機時間最小化。還可以通過智能回滾來減少停機時間，智能回滾可以逆轉更新以響應特定于應用程序的健康檢查。

　　雖然在包含邊緣設備的混合云中通常需要進行一些定制，但通常仍然可以在任何必要的定制下擁有一致的核心環境。

　　3.邊緣也需要Kubernetes

　　這種一致性甚至可以擴展到Kubernetes。

　　人們可能會想，“等一等……Kubernetes不只是用于云平臺和服務器集群嗎?”不一定。

　　一方面，邊緣設備不再那么小。例如在最近的一項研究中，企業內部的高級運營管理人員表示，允許在本地進行數據分析是一項重要的邊緣計算優勢。

　　雖然訓練機器學習模型通常仍然發生在集中位置，但模型推理越來越多地被推到邊緣。這可以顯著減少將所有數據發送回本地進行分析的高帶寬連接需求。這也意味著任何需要的本地操作(例如關閉或即將發生故障的機器)都不依賴于可靠且快速的網絡鏈接。

　　即使當今的工作量相對較輕，也可能希望保持選擇余地。也許工作量會增加，也許想添加一個高可用性選項，也許決定減少對可靠網絡鏈接的依賴。

　　但是，出于以上討論的相同原因，采用Kubernetes也是有意義的：一致性。如果企業在數據中心運行Kubernetes，在邊緣運行Kubernetes將幫助企業標準化軟件生命周期管理并在混合云環境中提供一致性。為此，正在進行各種項目，以針對具有不同足跡、可用性和網絡要求的各種用例優化Kubernetes。

　　4.提供幫助

　　如今有許多關于邊緣計算的信息來源。但是想了解一些開源工作，這些工作記錄了基于企業已經實施的模式的完整邊緣架構。

　　產品組合架構展示了開源軟件的成功部署，包括邊緣部署，并提供架構最佳實踐、工具和其他相關資源的鏈接。它們包括服務和平臺的高級抽象、描述主要節點和服務及其交互和網絡連接的模式，以及對特定服務的詳細介紹。

　　投資組合架構是使用通用的可重復流程、可視化語言和工具集、演示文稿和架構圖開發的。產品組合架構側重于在多種部署中有效的技術組合，并解決特定的常見問題(或問題集群)。

　　驗證模式是參考架構的自然發展。

　　它們包含幫助構建邊緣軟件堆棧所需的所有代碼，以便更快地獲得概念驗證。典型的模式包括數據中心和一個或多個基于邊緣Kubernetes的集群。所有步驟都通過GitOps完全自動化，以實現一致和大規模的自動化部署。然后，用戶可以修改特定應用程序的模式。

　　此外，相關用戶可以交流改進——提供開源開發模型的另一個示例，該模型應用于復雜的分布式軟件堆棧的初始部署和持續操作。

　　與靜態參考架構不同，經過驗證的模式會針對當前產品版本進行持續測試，以便企業的部署保持最新，并在使用最新功能的同時降低風險。

　　驗證模式還考慮了其​​他方面，例如安全性，這些方面本身可能不是架構的一部分，但作為軟件部署的一部分很重要。例如，機密和身份管理對于最復雜的部署至關重要。盡管如此，它們經常被排除在“市場結構”甚至參考架構之外，以專注于基本元素。

　　部分原因是，邊緣計算部署需要與雜亂無章的物理世界交互，它們總是有其復雜性和獨特性。但是，如果利用其他人學到的知識，并牢記自動化、管理和一致性等核心原則，就會獲得真正的業務價值。