這篇文章是Serverless系列的第二篇文章，這一系列文章是為了探索Serverless的本質。
越來越多的企業與創業公司選擇Serverless技術，並且Serverless技術發展速度遠遠快於之前的Container技術，而Container技術則是最近一次被行業廣泛採用的新技術。
不論從何種維度分析，都可以看到Serverless這項技術正引起人們的興趣。
-
ServerlessConf以及ServerlssDays這兩個活動的參與人和演講人數量和範圍一直在增長擴大。
-
Developer Economics最新的季度調查[1]表明，19%的後臺人員正在使用Serverless平臺，這個資料已經接近於使用虛擬機器的人數了。而在6個月前，這個數字還只是16%。
-
Cloudability的2018年度雲狀態報告（State of the Cloud 2018 Report[2]）中分析了1500個組織的IT支出，結果顯示Serverless的環比增長率為 667%。
-
TweetReach 估計每小時都有100條左右的推文被標記成serverless
-
谷歌搜尋顯示serverless的搜尋量在最近12月內穩步增長。
目前只有一些創業公司會在全面使用Serverless，大部分的企業只會在一些特定的專案中採用Serverless技術來測試基礎架構的方案，以及測試團隊文化是否適合實施Serverless。
儘管Serverless技術只被用於一些獨立的專案上進行測試，它們仍引起了多米諾骨牌效應，以一種意想不到的方式影響了公司業務。Serverless縮短了生產時間，引入了cost-for-usage（根據使用量付費）模型並鼓勵團隊成員更加自主。這些改變影響了企業的運作方式，包括如何選擇需要在Serverless上執行的功能，企業研發新產品新功能的意願，以及如何管理預算，程式員與產品經理如何履行職責等等。
O’Reilly系列的Microservices Architecture（微服務架構）書中提到 “微服務架構使Serverless更加快速，微服務使一個單體應用程式碼被拆分成小型的自治服務。因此，企業可以大規模的快速安全的構建解決方案”。
今年年初的一篇部落格中[3]，機器學習平臺Algorithmia的Mike Anderson演示了一個典型的高科技公司透過微服務將標準釋出週期從65天縮短至16天。他寫道“微服務幫助他們解耦了開發流程中的阻塞部分，縷清以及隔離了問題，使他們只關註元件級別的變化。”
當一個組織的程式碼是以微服務而不是單體應用的形式組織的時候，才可能使用Serverless技術。現在，企業可以識別出適合在Serverless架構執行的任務，這些任務是一些特定的，無狀態的任務。雲平臺會透過分配計算資源來解決問題，執行伺服器來做計算，在資料轉換完成後將這些操作任務關閉。
Red Hat產品管理部門的高階主管Rich Sharples 說道，該公司在過去兩三年一直關註Serverless技術並且正在開發一個開源的，企業級別的Serverless產品，這個產品可以與Kubernetes一起使用。Red Hat希望今年能夠釋出整個產品。
Sharples說道“透過客戶，我們發現技術的技術成熟度曲線（ The Hyper Curve）飆升的十分迅速，例如微服務，而Serverless攀升的速度更快”
因為微服務的增量交付，靈活，快速交付的特點，微服務收到越來越多企業的歡迎，Sharples說道“但是在我看來，這些使用者在疲於應對分散式系統管理和監控的運維複雜性，這也是為什麼Serverless會引起他們的興趣，透過Serverless，你可以獲得微服務的好處，從開發人員角度來看，這也非常簡單——僅僅只用修改一些程式碼。在運維人員看來，Serverless是一種非常適合建立自動化運維繫統的模型，例如將回覆一個日誌事件實現成Serverless方法呼叫將會非常方便“。Sharples說道從他與企業級使用者的日常對話中，可以感受到他們對Serverless的興趣。
Sharples說道“任何短時間執行的，無狀態的，可以獨立執行的任務都適用於Serverless”。
開源軟體API Gateway Kong的高階解決方案工程師Aaron Miler說道，大部分開始設計Serverless架構的客戶基本都採用了自下而上，或者自上而下的方案。使用自下而上方案的客戶已經將他們的傳統架構轉換成微服務架構，並且正在尋找一種方案可以讓他們在整個企業以不同方式使用Kong。他們傾向於選擇開源技術公司的企業級方案，並且希望透過發掘Serverless方向的工作機會來進入一個新的領域。
Miller說道：“在Kong，的確有一些優秀的Serverless專案引起了那些想要快速跟進新技術的CTO的關註。Expedia的Serverless專案就採用了Kong的技術，Expedia是Serverless的深度使用者，這家公司在他們所有日常的API閘道器都使用了Kong，因為Kong提供了AWS Lamda外掛，透過外掛，Expedia可以很方便的使用AWS Lamda，例如，每當使用者在Expedia上訂了一間房或是一張機票時，Expedia都會為客戶提供一個可以用於下次消費的折扣券。Serverless技術非常適用於這種場景。”
Miller談到，雖然減少成本是Serverless的一大優勢，但是它更大的優勢在於加快了開發速度。“如果團隊只用專註於寫程式碼，只用關心函式功能的質量，不用擔心這些程式碼是在Linux哪個版本上執行，這些問題將由別人解決，而團隊只用關心如何用Node、Python或是其他Serverless語言寫程式碼，這樣一來，每個人都從中收益。它可以讓人更加專註於自己的事情同時交付更多的功能。”
許多企業和創業公司都找一個簡單的例子來測試Serverless的潛力。The New Stack會定期列舉一些簡單事件作為Serverless用例（ a number of the low-hanging fruit use cases for serverless[4]）。
Steve Faulkner曾經幫助媒體公司Bustle公司構建Serverless基礎架構，該公司現在所有的運維都在Serverless的架構上執行，只有一個兼職的運維員工， Steve有一個簡單的經驗法則來幫助企業找到從哪可以開始他們的Serverless旅程。
他問到 “你的CI/CD流水線有哪些缺陷？一個測試你的CI/CD流水線的簡單方法：一個非技術人員是否可以對您的網站或檔案中的文字或副本進行更改？將更改部署到生產的速度有多快？大多數公司甚至不能這樣做。”
Faulkner說道，他見過有個CEO看到網站上有個錯別字，改正後透過Git中提交，一小時內更改就在生產中生效了。“這是一個很高的標準，但是這對於找到你的CI/CD的缺陷是一個很好的測試，並且這也是一個Serverless解決問題的案例”。
Kong公司的Miller提出了一種適合使用Serverless的場景，當某個處理任務所需的資源是不可預估的時候，這個任務就很適合使用Serverless。“在任何你不確定計算容量的地方：比如你不確定使用1還是100臺伺服器，如果沒有方式可以預估，那麼這個任務就很適合用Serverless處理”。另一種情況則是當你有很高很多的需求，但是預算又非常緊張的時候，Serverless可以幫助你很好的控製成本。
就像是Expedia的用例一樣，他也建議技術領導與產品經理以及銷售和營銷團隊一起討論企業當前如何提高使用者的粘性，在此之中或許可以發現一些合適的用例。
這通常是James Beswick的起點，該公司的Indevelo開發商店為使用者建立網頁和移動應用程式，他們的企業和B2B客戶端都是Serverless架構。最初，Beswick在所有標準影象大小調整型別任務中使用Serverless，但在紐約最近一個ServerlessConf中，“我突然意識到我可以將所有的工作都放在無伺服器上，”他說。
Beswick說，每次跟新客戶討論時，他通常不會從一開始就討論Serverless，而是把低廉的使用成本作為他的主要賣點。
“我們必須解釋整個事情，”Beswick說。 “首先我們談論軟體需求是什麼，然後談論架構。在架構方面，我們從財務方面入手。我們解釋了為什麼Serverless更便宜，更易用。”
Beswick說，因為Serverless價格“非常難以估計”，他傾向於給潛在客戶一個估價範圍。 “網路規模的應用程式非常昂貴，但是你得執行它們”Beswick說。我傾向於表明，如果某個應用程式正在進行10,000次交易，那麼每月帳戶看起來如何？如果一個事件每個月花費500美元，那麼什麼可能會導致它突然每月花費5000美元？”
從成本的角度出發，促使企業思考Serverless架構可能會對他們未來執行公司的方式產生巨大的影響。
例如，在美國，IT專案可能會根據人力資源和資本支出（capX）進行預算，而不是純粹的成本分配和運營支出（opX）。許多企業將其IT視為capX，因此獲得特定的稅收折扣。但是對於雲環境，對於Serverless的情況更是如此，其中定價是基於實際使用情況，它全部是opX。這讓一些首席財務官感到擔憂，他們害怕失去IT專案的稅務減免。在進行專案預算時，其他的專案並沒有設定成可以降低現有員工的工資成本。
“你可能會為一名資料庫員工每年支付12萬美元，”Beswick解釋說。 “如果您正在執行AWS Aurora，那可能會花費500美元一個月，這要便宜得多，但人們並沒有考慮到人員成本，因為它被分成了多個部分。“Beswick說，企業將不得不推出新的會計方法，這不是尋求CapX稅務減免，而是一種純粹的成本分配，人力資源預算將會採用新的方式，而將運維成本劃分到專案成本之中。
Serverless的引入也帶來了其他的影響。其中一些影響在雲技術和SaaS技術中產生，但隨著Sevrerless應用的發展，它影響的速度和範圍也在增加。
Beswick指出，他的設計店經常被IT以外的業務部門僱用，例如企業的營銷和銷售團隊。例如，SaaS工具只被一個部門使用，但隨後資料整合和移動裝置整合則意味著跨越多個業務線，應用程式開發必須找到解決方法來限制傳統IT部門的參與。 “當你與IT部門合作時，有一系列因素在起作用：他們不在權威，他們對發生的事故感到不滿，並且懷疑它是否應該在Serverless中執行。 IT團隊在這方面如此落後，“Beswick警告說。
“IT部門正在變懶，他們掉入了不想改變任何事物的陷阱之中。但大多數企業都看到自身行業發生的巨大變化，所以他們不想再依賴IT部門，而是從外部尋求問題的解決方案，”Beswick認為，大多數企業都在處於一個中間過渡時期，新的組織架構會代替傳統IT部門的組織結構和作用，而Serverless正在加速這個過程。
Faulkner說道：“我確實看到了Serverless帶來的業務流程的變化。 我認為Serverless不僅僅提高了軟體開發的速度，還幫助你模組化你的應用程式。 我們透過Serverless的方式重新構建了Bustle。 Serverless架構是模組化的，並且具有許多功能，因此更容易與其他的應用適配。 在去年，我們開始建立可以搭載事件的架構並提供新價值的業務系統。”
Beswick也同意這個觀點。 “想想以前的世界，MVP（Minimum Viable products 最小可行性產品）是不可擴充套件的，它們並不可靠。 如果想法真正被採用併進入生產階段，那麼MVP的大部分工作將被丟棄。 但是現在有了Serverless之後，我們可以輕易的將MVP投入生產來構建高階應用程式，從而解決問題，它變得更靈活。 以前當一個功能或應用規模擴大時，你只能默默祈禱不要發生問題，而現在Serverless使規模縮放變得更穩定。”
Beswick說，透過微服務和Functions，構建MVP所需的很多程式碼塊都已經實現。 透過Serverless（根據使用量付費），企業可以加快開發速度，快速向客戶群體釋出原型以獲得反饋，從而降低風險。 如果他們成功了，他們可以更快地轉向生產，而無需重建整個應用。
保險科技創業公司Fabric的聯合創始人兼技術長Steven Surgnier表示，在他們的業務中使用Serverless架構的確為該公司帶來了的業務流程的優勢，正如Faulkner和Beswick之前所提到的一樣。
“最終都歸結於執行力，”Surgnier說。 “作為一家早期的創業公司，我們希望迅速執行並最大限度地降低整體技術的複雜性。 我們使用Serverless技術來減少從我們的想法到客戶手中的最終產品的時間。”
Miller和Surgnier都贊同一種觀點，即Serverless技術幫助企業留住關鍵開發人員。 Miller說，企業內部的開發團隊通常對測試新技術感興趣，他們會找到一個專案，分配一個小團隊，並給他們幾個星期來建立一個原型。 “這些企業透過為開發人員提供有趣的工作來吸引和留住優秀的人才，”Miller解釋說。 Surgnier說Serverless對公司和工程師都有好處：“工程師喜歡創造。 因此，透過為他們提供Serverless基礎架構和專註於產品的機會，可以讓工程師在其職業生涯中創造出更多的產品。”
Steve Faulkner說Serverless改變了軟體開發的基本流程，在這個過程中培養企業內部的開發人員自主性。
作為Bustle的Serverless的冠軍，他花費大部分時間來維護第一批bash指令碼，併在之後構建了一個十分成熟的框架。 “我希望人們瞭解它是如何工作的，但我也堅信任何人都可以隨時用一個命令部署生產環境，”他說。
Serverless鼓勵這種程式員自主開發的文化。 “如果有的話，一切都會更快，”福克納說。 “一個完全部署的Lambda的更改可以在30秒內完成。 如果你知道部署到生產需要一些過程，那麼它會成為一種精神障礙，並會引入惰性，就像是我現在應該做麼？還是我應該等待別人去做這件事？Serverless幫助開發者解除了這種精神障礙。 現在任何人都可以隨時部署到任何生產端點，這就會給賦予人們自主權和能力。”
Faulkner說，在Bustle，這已經是文化的一部分，而大公司可能有一種根深蒂固的文化和觀念，即鼓勵開發者們在簽字（上級認可）後才開始做事。 “我想如果你在大企業中使用Serverless，如果文化已經很糟糕，Serverless也無法幫助到你。”
Faulkner表示，Serverless也加速改變了另一種文化，即對輕量級架構決策記錄的需求。 “人們需要記錄他們正在做的事情，”他急忙說道。 “如果我們的標的是任何時候任何人都可以部署到生產，我們必然會有很多短暫存在的feature branch（Git的功能分支）。那麼你需要一個功能標記系統，這樣生產中的東西就不會完全暴露給外界。“儘管Faulkner表示這還不是規範，並且是分散式軟體應用有著更廣泛的趨勢，這種議程和需求是由影響無伺服器的採用創造了速度和釋出生產級變更的能力。
“我最近的觀點是，隨著應用規模不斷擴大，功能標誌（feature flag）可能是改善軟體開發過程最有用的方法。”Faulkner建議道。
Indevelo的Beswick認為，在許多企業，IT主管和業務部門經理會對未來的發展存在分歧。 雲技術已經引入了新的領域，但Serverless的出現則向前推進了更大的一步。
“我從未像現在這樣對一項技術感到如此興奮，”Beswick說道，Faulkner，Surgnier，Miller和Sharples都表達了同樣的觀點。 “Serverless使所有事物彙集於一處，”Beswick繼續說道。 “Serverless能交付的遠超想象， 以後可以將它新增到機器學習，也可以被應用於移動方向。 你需要以一種全新的思維方式去思考，而不是繼續維持老舊的思想，這才是Serverless令人興奮的地方。 我們可以更好地去詢問客戶的問題，以及如何讓每個人更容易解決這些問題。”
-
https://www.developereconomics.com/reports/developer-economics-state-of-the-developer-nation-14th-edition
-
http://get.cloudability.com/ebook-state-of-cloud-2018-thank-you.html?aliId=3136040
-
https://blog.algorithmia.com/introduction-to-serverless-microservices/
-
https://thenewstack.io/serverless-architecture-five-design-patterns/
原文連結：https://thenewstack.io/serverless-impacts-on-business-process-and-culture/
本次培訓包括：Docker介紹、Docker映象、網路、儲存、容器安全；Kubernetes架構、設計理念、常用物件、網路、儲存、網路隔離、服務發現與負載均衡；Kubernetes核心元件、Pod、外掛、微服務、雲原生、Kubernetes Operator、叢集災備等，點選瞭解具體培訓內容。
長按二維碼向我轉賬
受蘋果公司新規定影響，微信 iOS 版的贊賞功能被關閉，可透過二維碼轉賬支援公眾號。
![]()
微信掃一掃
使用小程式
知識星球
