毫無疑問IT技術和基礎架構在過年幾年當中實現了快速發展。而網站系統也已經從最初的“腳本和文件的簡單組合”發展成為“由可重用代碼組件構成的復雜模塊化應用系統”——所有網站都在使用HTTP，其已經成為互聯網通信的主要協議。各種各樣的Web應用已經完全融入到人們的生活當中。用戶期望獲得響應速度快、性能良好并且能夠在所有設備上流暢運行的應用程序。
盡管我知道很多工程師都認為這是一件令人興奮的事情，但是同時我也知道很多技術經理敏銳地意識到技術的快速發展以及用戶不斷提升的期望值所帶來的全新挑戰。而在所有這些挑戰當中，管理權限是一個非常突出的問題。我們在將傳統基礎架構遷移到更加流暢的web架構方面已經取得了很大進步，但是仍然在使用傳統方式來分配控制權限。這就能夠解釋為什么現在很多公司當中，網絡團隊依然控制著應用程序交付流程——而不是那些負責開發應用程序、并且加速其性能的DevOps工程師。顯而易見，這種權限分配方式并不合理。
下面的情況是否聽起來十分熟悉？也許你也曾經在自己的企業當中遇到過類似的問題。如果真的是這樣，那么是時候思考應該如何避免這些由控制和問責機制失衡所導致的矛盾和沖突了。
也許你是一位開發人員，現在想要為某個應用程序添加或者修改訪問控制列表（ACL）以提升系統安全性；或者想要臨時將流量重定向到另外一臺備份服務器。現在你需要做的不是思考應該如何自己完成這項任務，而是認真地準備一份相關申請，之后提交給網絡運維團隊。（由于他們很有可能需要處理企業當中的所有請求）因此你必須等待他們找到合適的時間來處理你的請求。
當然，如果你總是向他們提交申請，那么最終他們可能會為你分配一些簡單的控制權限，因為他們需要處理其他（通常是更加重要的）任務。但是如果在你操作過程當中系統出現故障導致無法訪問，那么無疑你將會成為那個被責備的對象。導致系統故障的原因很多，可能只是由于某個廠商設備的ACL具有默認的“隱式拒絕”規則，而你忘記顯式放行特定流量，也或者你沒有搞清楚“反向掩碼”，還或者將ACL錯誤地應用到其他接口上了。因此，不論對于開發人員還是網絡團隊來說，這種方式都不是一種好的解決方案。
大部分情況下，網絡團隊掌握應用程序交付控制權是因為當前環境使用了基于硬件的應用程序交付控制器。但是這些集中式應用程序交付解決方案由于潛在的單點故障問題而變得非常脆弱。除了脆弱性之外，還需要思考被分配過多任務的網絡團隊如何快速構建和部署應用程序，這無疑是一種并不穩妥的做法。
企業當中的開發人員數量通常大大超過網絡工程師的數量。我們經常能夠聽到一家擁有數百個虛擬化服務器實例、數十種應用程序的企業擁有100個人的DevOps團隊——但是同時也許只有兩個網絡工程師在管理多個部署在私有云當中的應用程序交付控制器。顯而易見，網絡團隊很難同時處理多項web加速任務，而且他們同樣擔心將過多的應用程序邏輯引入到網絡環境當中。
此外需要記住的是，高速網絡并不一定總是意味著應用程序的良好表現。配置命令當中的潛在沖突或者網絡設備當中的錯誤腳本都有可能導致問題的發生。事實上，向網絡團隊不停發送配置變更請求所能夠得到的唯一結果就是抱怨的逐漸加深。
另外一種不和諧因素的來源是應用程序系統工程師使用的現代敏捷開發過程。使用這種方式之后，開發人員不能在開發完一款產品之后將其交付給其他人進行部署和維護；敏捷開發過程需要創建迭代，之后部署，一直重復這個循環。而這個循環要求開發人員擁有全部、端到端的控制權限，這樣才能夠避免大量http傳輸可能產生的系統性能和可擴展性問題。然而協商各個部門任務分工的過程無疑會延緩開發人員的工作進度，并且開發人員難以更改系統配置以提升系統性能。
軟件解決方案：新的希望那么DevOps工程師應該如何解決這些問題呢？其應該想辦法獲得web加速和應用程序性能方面關鍵功能的管理權限，同時仍然滿足企業對于性能和安全方面的需求。
而壞消息是，你不能使用任何10或15年之前推出的工具，這些工具針對大型、古老的獨立應用程序（同時對于消費者和企業來說）而開發，因此并不適用于現代的分布式、松耦合以及組件化的應用程序。而網絡工程師也不能幫助開發人員解決HTTP的復雜性問題，他們的注意力仍然在網絡設備硬件方面，主要關注數據包，而不是應用程序。
等一下，也許你會想使用NFV（Network Function Virtualization）來解決這個問題怎么樣？這是一種可行——但是只適用于部分情況——的解決方案。首先，其主要提供2層、有時是3/4層的功能，而和第7層相關的功能還沒有被完全開發。NFV和SDN的另外一個問題是，目前為止，其只解決了商業網絡基礎架構的問題，而無法應對如何在DevOps環境當中如何管理完整第7層環境的挑戰。企業需要尋找一種解決方案，合理地對層級權限進行管理。網絡團隊需要控制3和4層，而DevOps工程師需要第7層的控制權。
最后同樣重要的是，大多數應用程序框架都沒有提供良好的方式來快速和輕松解決HTTP的固有復雜性問題——比如并發處理、安全、訪問控制等——以及應用層流量管理。
那么究竟應該如何解決這種問題呢？網絡或者應用程序框架都不能在端到端web加速方面起到真正的幫助作用，是否存在相關軟件能夠解決這種矛盾關系，完全滿足DevOps的全部需求？
幸運的是，答案是肯定的。現在有很多非常有用的工具，能夠提供HAProxy、負載均衡或 SSL termination等功能，而另外一些產品（比如我們自己的NGINX Plus）能夠提供所有主要功能，比如應用層負載均衡、請求路由、應用程序內容交付、web緩存、SSL termination、即時壓縮、協議優化等。
這些DevOps工具的配置方式遵循“應用程序風格”，能夠很好地兼容Puppet或Docker等其他工具所提供的自動化功能。此外，其還能夠被輕松部署到云環境當中，在虛擬化環境當中高效運行，并且和應用程序協同工作，最終成為應用程序的一部分。同時，這些產品擁有和網絡硬件設備相同、甚至更好的性能表現，在低成本投入的情況下擁有無限制的吞吐量。
最后，也許是最重要的一點，其還能夠為DevOps團隊提供期望已久的針對HTTP性能和可擴展性的端到端控制權限。
使用DevOps工具合理控制權限決定使用DevOps工具之后，下一步就是思考如何使用其滿足當前需求了。DevOps和網絡基礎架構團隊可以融洽相處，并且更加高效地合作，如果應用層功能由基于軟件的可擴展層實現——完全由DevOps團隊進行創建和管理——而像數據包傳輸、QoS以及其他傳統網絡功能仍然交給網絡基礎架構團隊進行管理。
誰能夠從中受益？所有人。開發團隊可以從順利運營、快速配置和部署以及更加簡化的應用程序開發流程當中受益。而網絡團隊的負擔減少，能夠更好地控制其所需要管理的領域，同時將集中精力于自身工作。用戶受益于更好的應用程序使用體驗。最終，公司也能夠從高效交付高性能應用程序以及滿足市場預期等方面獲益。
我們推薦用戶嘗試使用這種基于軟件的解決方案，查看應用程序速度和效率的提升情況以及團隊成員是否對其感到滿意。企業現在可以免費試用NGINX Plus以替換現有的基于硬件的應用程序交付控制器，或者聯系我們，更好地了解NGINX如何幫助企業以一種DevOps友好的方式交付高性能、安全、可靠和可擴展的應用程序。
京公網安備 11010502049343號