為什麼我們轉向無服務器計算來部署自定義構建
已發表: 2018-11-22
Pexels 上的 panumas nikhomkhai 拍攝的照片
作為我們致力於讓績效營銷人員做到事半功倍、事半功倍、無憂的承諾的一部分，TUNE 的團隊一直在尋找新的方式來服務我們的客戶。 在這種情況下，我們的解決方案工程團隊發現了一種技術，可以簡化他們在我們平台上部署和支持自定義構建的方式。 因此，他們現在可以花更多的時間（和更少的錢）與更多的客戶合作來構建他們需要的解決方案。
在 TUNE，我們以提供靈活、全面的績效營銷平台而自豪，該平台允許網絡和廣告商管理他們的數字營銷活動、出版商關係、支出等——直接開箱即用，無需編寫一行代碼. 但有時，與其他完全託管的 SaaS 系統一樣，我們的客戶需要自定義配置、功能或集成，而這只能通過捲起袖子並啟動舊代碼編輯器來實現。 最近，我們轉向了一種新技術，它改變了我們構建這些解決方案的方式：無服務器計算。
在這篇文章中，我將介紹我們在自定義開發中遇到的問題，我們為設置無服務器構建過程所採取的步驟，以及這種新方法如何解決成本和規模方面的挑戰。
挑戰：跟上定制解決方案的需求
當我們第一次在 TUNE 啟動解決方案工程團隊時，我們將每個自定義客戶構建視為一個單獨的構建。 這些構建中的大多數都有一個前端組件，通常部署為我們平台上的自定義頁面，以及一個由服務器、數據庫和保持服務器最新所需的任何其他基礎設施組成的後端組件-日期和操作。
起初，這種方法對我們有用。 通過擁有一個包含一些複雜自定義構建的小型精益團隊，我們為每個構建配置和配置不同服務器的方法對我們很有效。 它使我們能夠為我們的客戶創造驚人的體驗。
但是隨著構建數量的增加，我們開始遇到問題：
- 服務器太多了！ 可以想像，每次構建至少配置兩個盒子會導致我們擁有過多的服務器。 龐大的服務器數量以及隨之而來的所有麻煩（例如安全更新和備份）讓我們花費的時間比我們願意承認的要多。
- 保持這些服務器正常運行。 由於每台服務器都是自己的實體，我們負責確保每台服務器始終正常運行。
- PHP 不適合我。 我們的大部分構建都是從一個基本的 Docker PHP 鏡像中衍生出來的。 但是隨著我們團隊的壯大，我們知道強迫人們在他們還是 Python 嚮導的時候用 PHP 5.0 編寫他們的客戶構建是沒有任何意義的。
- 這越來越貴了。 由於我們所有的服務器都部署在 ec2/RDS 上，我們開始看到每月的成本很高。
- 安全第一。 由於這些服務處理敏感的客戶數據，我們必須為我們的公共 URL 提供一種身份驗證方法，以確保該數據的安全性。
- Cron 很難。 許多後端服務由 cron 腳本組成，我們沒有有效的方法來管理它們。
隨著這些挑戰的出現，我們知道我們必須找到一種更簡單、更具成本效益的方法來為我們的客戶構建提供後端功能。 但是經過多次辯論並且沒有明確的解決方案領先者，我們開始沒有想法了。 （此外，隨著對新定制構建的需求瘋狂增長，時間肯定不在我們這邊。）
解決方案：拯救無服務器計算
如果您還沒有聽說過無服務器計算，您可能想知道我們第一次聽說它時的情況。 如何在沒有服務器的情況下執行代碼？ （別擔心；您對編程的基本理解仍然是正確的，不，我們在寫這篇文章之前並沒有濫用歡樂時光特別節目。）
“無服務器”對於一項新技術來說是一個非常令人困惑的術語，因為——別傻了——肯定還有一個服務器在執行代碼。 那麼究竟什麼是無服務器？
無服務器計算是一種雲計算執行模型，其中云提供商充當服務器，動態管理機器資源的分配。 –維基百科
無服務器雲解決方案允許您構建和運行應用程序和服務，而無需考慮與服務器相關的麻煩。 從本質上講，無服務器計算允許您做自己最擅長的事情：編寫代碼。
無服務器設置過程
為了向您展示無服務器技術如何工作的要點，我將介紹我們用於設置此功能的步驟。
注意：有許多具有無服務器功能的雲提供商。 在此示例中，我們使用AWS Lambda 。
- 首先，創建一個新的 Lambda 函數並選擇“ Blueprints ”。 然後，在關鍵字字段中輸入“ http ”，然後選擇 Python 或 Node microservice-http-endpoint。 （藍圖是預先製作的代碼塊，旨在加快開發速度。這有多棒？）一旦你做出選擇，點擊“配置”。
如何在 AWS Lambda 上配置函數。
- 添加函數名稱和角色。 然後選擇一個帶有安全選項“ Open with API Key ”的API Gateway觸發器。 此 API 網關將提供一個公共 URL，該 URL 將觸發您的 Lambda 函數。 添加 API 密鑰提供了一種身份驗證方法，強烈推薦。
在 AWS Lambda 中設置開放 API 網關密鑰。
- 創建函數後，您現在可以對代碼進行配置。 如您所見，藍圖已經為您提供了一個很酷的入口點掛鉤，允許您與Dynamo 表進行交互（如果您正在尋找添加數據庫）。 加載公共 URL 時，將執行lambda_handler下的任何內容。 由於我們還添加了一個數據庫，讓我們去 Dynamo 並創建一個。
在 AWS Lambda 中創建 Dynamo 數據庫表。
- 創建 Dynamo 表後，讓我們從公共 URL 調用此 Lambda 函數。 返回您的函數並單擊頂部的“ API Gateway ”圖標。 您應該看到已經為您創建了端點和 API 密鑰。
在 AWS Lambda 函數中哪裡可以找到 API Gateway 圖標。
- 現在打開終端並在“ x-api-key”標題下添加 API 密鑰，然後在TableName查詢字符串參數下添加您創建的表名。
在終端中輸入您的密鑰和數據庫名稱以完成。
- 首先，創建一個新的 Lambda 函數並選擇“ Blueprints ”。 然後，在關鍵字字段中輸入“ http ”，然後選擇 Python 或 Node microservice-http-endpoint。 （藍圖是預先製作的代碼塊，旨在加快開發速度。這有多棒？）一旦你做出選擇，點擊“配置”。
而已！ 您現在有一個連接到數據庫的工作、安全的後端。 只需要五個簡單的步驟。
無服務器計算如何應對我們的挑戰
現在我們已經向您展示瞭如何設置無服務器構建，讓我們來看看這個基於雲的模型如何與我們的問題清單相匹配。
- 服務器太多了！ 無服務器……意味著不再有服務器，對吧？
- 保持這些服務器正常運行。 由於無服務器計算由雲提供商管理，因此您可以從這些提供商（以及他們久經考驗、久經考驗的方法）監控您的服務器中獲益。 對於那些想玩福爾摩斯的人，您還可以在Cloudwatch上查看您的函數輸出的所有服務器日誌。
- PHP 不適合我。 無服務器模型允許您使用 C#、Python、NodeJS、Go 甚至 Java 進行編寫。
- 這越來越貴了。 使用無服務器解決方案，成本是根據執行時間（每 100 毫秒）和傳輸的數據量來計量的。 與每月付費（包括服務器閒置時間）不同，您只需為使用的內容付費。 每 100 毫秒執行的成本低至 0.000000208 美元，無服務器計算可以為您節省大量現金。
- 安全第一。 無服務器安全嗎？ 借助內置的 API 密鑰身份驗證系統，您敢打賭。
- Cron 很難。 使用原生構建在 Cloudwatch 上的 cron 管理系統，只需設置一個時間窗口，然後忘記它。 Cloudwatch 處理所有日誌記錄和執行。
最後的想法
對於 TUNE 的解決方案工程團隊來說，轉向無服務器計算已經改變了遊戲規則。 它的易用性、成本節約和敏捷友好的特性改變了我們處理所有新客戶構建的方式。 基於雲的無服務器解決方案將改變服務器端計算的世界。 我不了解您，但可以肯定的是：TUNE 解決方案工程團隊已準備就緒。
要了解有關TUNE 平台和我們提供的定制開發服務的更多信息，請訪問我們的專業服務頁面。