雲端運算的成本建模
本文將討論通過評估雲端資源的配置來研究各種雲端平台中的成本是如何產生的。同時我們必須確保在正確的組織層級中以正確的成本方式分配。
同時也將討論到如何開發和實施一個成本模型，使我們能夠識別雲端成本（showback）並將成本分配（chargeback）到部門或團隊的預算中。 在此之前，我們必須了解成本覆蓋的原則、雲端中的成本類型以及雲端提供商(以下簡稱CSP)是如何設定它們的費率。
本文討論的重點如下:
- 雲端成本的類型評估
- 建立成本模型
- Showback 與Chargeback的作業原理
雲端成本的類型評估
在建立模型之前，我們需要理解雲端中的成本類型有哪些。這樣才可以理解如何分配成本，並制定一個"集中的、受控的且有一致性"的成本分配策略。
成本覆蓋
PAYG(pay-as-you-go)是一般人所熟知的雲端付費方式，這通常是有限度的使用方式。但通常大型企業運作在雲端中的環境都是巨大的，有時雲端運作成熟企業也會將重要系統搬遷到雲端中。企業希望這些重要的系統都是持續而穩定的，並且依需求是有足夠的量能的。為此，企業都會與CSP簽訂一個長約來確保資源是穩定可用的(像企業租車一樣)。
另一個好處是，長租會有則扣。因為對CSP而言這就是一個長期而穩定的現金流。不過有一好沒有兩好，這種長約的資源預定，就算企業沒有用到還是要付錢，狀況與地端機房是一樣的。所以事實上在雲端中，CAPE與OPEX是同時存在的。
所以本質上，企業會有長租(CPAEX)與短租(OEPX)兩種的雲端資源可以使用。差別在與長租的量能是保證的，但短租不是(就像你在UBIKE單車站租車一樣，不是每個站永遠都是單車可租)。
另外，我們必須確保未充分利用的雲端資源成本不會超過當初談判之後的折扣金額。FinOps將這一件事標示為"浪費的資源"。
所以針對企業付的每一塊錢都能充分利用到其雲端資源。我們將盡力了解所覆蓋的使用情況，因為這將提供最佳的見解並實現準確的預測。 覆蓋使用(Covered usage)是指長租的資源，會有較低費率。 現在，我們來談談費率。
雲端費率
每家CSP計費的方式都不盡相同。但是還是有一些基本性原則可以讓企業理解其雲端計費的模式。
第一個原則是 — 雲端資源用得越多或用得越久，其費率就會變得不一樣(就跟台電夏季電費的概念一樣，只是再複雜得多)。例如，使用量。像是CDN服務，傳輸總量越大，每單位成本就越小。FinOps稱這種案例為”非混和費率(unblended rate)”。
有非混和費率，當然也有混和費率(blended rate)。混和費率是指將成本平均分配到每個雲端資源，所以每個雲端資源的費率是相同的。這起來很容易處理也很簡單的概念，不過這是不對的。因為企業無法知道每項資源投資的貢獻度與成本的比較。就像員工一樣，總經理的成本跟櫃台妹妹的成本其貢獻度不是同一個檔次吧。
最終顯示在發票中的費率幾乎肯定會與CSP的Billing portal不一樣。 企業通常都會用on-demand價格來當作初始的雲端費用。 只有當用量大的企業才會有批發折扣、特別計劃(例如有潛力的新創)的折扣，才能把費率降低。 這可以節省成本。 節省的金額將可以在發票中看到，然後我們還可以通過將商業協議應用於我們現有和計劃的雲端環境來計算節省的可能性，因為環境可能會越長越大。
三大公有雲通常都依些批發折扣方案或企業方案。例如微軟的EA或是Azure Hybrid Benefit(可以將之前購買Windows/SQL server等licnese用到Azure中)。AWS的EDP(Enterprise Discount Program)。GCP則是Enterprise Agreement。而軟體授權費用則影響雲端費率最深也最複雜。
攤銷(Amortized)成本與全額成本
上述提到的雲端資源的長租跟帶來的折扣。哪這些是如何呈現在成本中的呢?這裡會呈現兩種不同類型的成本:攤銷成本與全額成本。
在長租合約中，通常企業需要先預付一定百分比的金額，我們可以把它看成是CAPEX(就是買機器一樣)。在這種成本模式中，這類的成本需要攤銷到雲端資源的使用。
而全額成本 = 攤銷成本 + 當月實際資源用量成本(有時會包含折扣)。為了計算出全額成本，我們必須完整的解構所有的雲端組件。
建立成本模型
建立成本模型有以下三個步驟:
- 辨識成本製造者 —
成本的產生通常與企業的業務流程相關。所以辨識成本製造者也等同於辨識了企業在雲端中的企業流程，以便設立雲端環境。這個環境搭配雲端環境可能是自動資源縮放或是evnet-driven架構。重點還是對資源的自動化與優化使用，因為這會影響成本。
因為成本將在很大程度上決定公司對產品或服務的客戶的價格。 產品的價格基本上是成本和利潤。 只搞定了成本，公司不會獲利。 但公司也不能為其產品定價：它需要對客戶“有意義(就是CP值夠高)”。 - 定義所有雲端組件的完整解構 —
我們只需要知道企業會在雲端中使用的所有元素即可。 但與此同時，必須以易於理解的方式呈現。 這就是成本模型的作用。 必須確定所有費用：基礎設施、軟體、開發、資安等。 - 組件的數量 —
雲端的計費有兩種屬性或其兩種的混和，哪就是時間維度與量能(規格大小)維度。基本上大多數都是兩種的混和 — 如VM。我們必須考慮攤銷成本和各種折扣，以獲得正確的成本水準。 在這個階段，我們還應該考慮可以使用哪些雲端服務來共享。 共享服務會降低成本，但請注意，在合規性方面可能需要權衡。
接下來我們開始解構。一個好的實踐是應用程式的角度來解構，前提是每個應用程式都有其負責人。從應用程式開始，我們就可以定義這個應用程式要運作需要那些資源。這些資源可能有專用與共享的。事實上，管理雲端的Landing zone是有成本的。 我們可以對成本進行基本劃分：
- 消耗式— 每個應用程式會消耗到的。例如使用CDN資源
- 固定成本 — 沒用也需要付錢的。例如一些共享服務 — 如file server.
再來是託管與非託管服務:
- 託管 — CSP提供服務。客戶在執行作業時沒有額外的成本。
- 非託管 — CSP一樣提供服務。但客戶執行其作業會有額外成本。像是管理成本或軟體授權成本。
不管是哪一種服務，它需要被解構。以下我們將使用AWS EC2為範例來解構其EC2中的每項組件。相同的原理也套用到其他CSP。
- EC2
- General
- Operating Systems
- Licenses
- Extensions
- RDP setting
- Serial Console
- Availability
- Virtual Machine SLAs
- VM Type
- Auto-Shutdown
- Just-In-Time Access
- Boot Diagnostic
- Virtual Server Templates and IaC
- VM Sizes and Tiers
- VM Naming Convention
- VM Deployment and Image Management
- Gold Image
- Post_deployment Configuration
- Monitoring
- AWS EBS
- Disk Caching
- Drive Type
- Drive Performance
- EC2 Instance Additional Storage
- Managed Drives Reserved Instance
- Disk Bursting
- Ephemeral OS Disks
- Shared Disks
- Network Connectivity
- Disk Naming Convention
- Disk Encryption
以上僅僅只有VM本身這個Workload，還要有運作這個workload還需要有storage與網路。還有資安也是不可少的。以下是關於網路與資安的元素。
- Network
- Private IP
- Public IP
- Accelerated Network
- Proximity Placement group
- Security
- VM Encryption
- Virus Scanning and Anti-Malware
- OS Update Management
- Software Inventory
- Host Firewall
- OS Editions
- OS Hardening
- Storage Accounts
- Storage Account Security
- Authorization
- Encryption
- Recovery
- Tracking
- Backup and Recovery
- Cloud-Native Backup
- AWS Backups
- Windows and Linux Server Backup
- RDS Backup
- File-Based Restore
- Backup Monitoring
所有這些組件都有與之相關的成本。 所有這些成本都必須進行追踪和管理。 因此，我們還需要明定成本管理設定。以下清單活動是關於成本管理。
- Cost Management
- Cost Visibility
- Cost Reporting and Analysis
- Management of Invoice and Payments
- Setting and Management of Budgets
- Control Usage via Policy
- Cost Optimization
- Reserved Instance
- Spot Instance
- Serverless
- Trusted Advisor
這是一項廣泛的作業，但需要建立具有成本意識的設計。 我們必須對雲端環境中的每個工件、我們使用的每個雲端平台執行此操作。
最後是成本的分配。企業中的部門/單位/團隊需要他們運作在雲端中服務(不管對內還是對外)付費。成本分配將會顯示出成本效益並讓管理層做出決定。決定。 因此，我們必須定義一種邏輯方法來進行成本分配，這在雲端環境中並不容易，尤其是在多雲環境。 我們必須將所使用的雲端服務對應到業務功能，以便清楚地了解哪些服務由誰使用、用於什麼目的以及支出是什麼。 實現此目的的一種方法是從應用程式或一套系統的角度來考量。
當準備好成本模型之後，就可以開始監控企業的雲端費用。成本必需被正確分配到我們先前定義好的單位中。這會用showback與chargeback的方式來完成。
Showback 與Chargeback的作業原理
在多雲中，應用程序或一套系統通常使用雲上的多個服務。 通過應用程式或系統的角度，所有雲端服務都將被辨識。 如果我們正確地進行了成本建模，我們將準確地知道哪些資源連接到程式或系統，以及其運作成本。 然後還有最後一件事要做，即，將程式或系統與其負責人還有團隊、部門或業務部門結合起來。
在開始進行chargeback流程之前，我們需要了解系統、雲端中使用的資源和服務以及與這些資源和服務相關的相應成本。 此過程在 FinOps 中稱為showback：分析有關雲端中使用情況的所有資料，以便向相關利害關係人報告。 這個資料必須涵蓋我們在前面幾節中討論的所有面向：
- 使用情況
- 成本要素
- 費率
- 適用於費率的折扣
這些資料必須能夠被系統識別，進而被系統負責人、團隊或業務部門識別。
接下來是chargeback步驟，這是將費用歸到真正要付費的團隊成本中心（就是該部門的預算）。這裡的困難在於將共同成本(共享服務上的)以及在各種資源上分配折扣的方式。 這將需要財務工程，這是我們在多雲的FinOps成熟度中FinOps 團隊的主要任務之一。 第一步是能夠將成本分配到正確的預算中。 在真正成熟的FinOps組織中，chargeback是自動化的並整合到企業的財務系統(通常是ERP)中，並且共同成本根據共享資源的實際使用情況進行分配。
