我們與28位分別來自23家企業的高管人員進行了交流，希望了解這些負責立足于云環境進行應用程序開發與部署的技術領導者如何看待相關議題。

當被問及“開發人員需要在處理云應用時注意什么?”時，各位企業高管人員給出了以下意見與建議：

應用程序性能管理應該分為主動與被動兩類，特別是在面對開發與生產等不同場景的情況下。我們需要在開發階段獲取更多測試信息。APM工具將幫助我們在應用直接觸及生產環境前對其加以測試，并有效縮短產品進入生產環境并被交付至用戶手中的周期。

了解應用程序的十二因素。如何對應用程序中的服務進行遠程消費?了解其中的關聯性是解決問題的關鍵所在。

開發人員應當保持云中立性。所有應用程序都需要具備可移植能力。對于高級應用程序，我們需要將云因素排除在設計藍圖之外。在編寫應用時，保持其云中立特性、構建通用API并封裝特定的云依賴關系。大家不要假定使用某種特定虛擬機。為應用選定運行區域，這對安全性非常重要要。不過VCenter不具備分區特性，因為其主要面向私有云所構建。我們需要在設計之初考慮到這些前提。如果大家打算面向公有云進行應用開發，則需要利用微服務實現規模擴展——即考慮單一服務規模所帶來的多重影響。沙箱屬于Amazon以及V Container接口的縮影，大家可以借此了解二者之間的沖突點所在。

跳出固有思維，因為老派開發人員采用的方法往往無法適應當前需求。了解業務需求與客戶需求，并為問題提供最為簡單的解決方案。針對需求進行實現方法定制。保持統一的發展愿景，同時著眼于目標及需要解決的問題進行知識共享(使用JetBrains中的UTrack以及JIRA實現協作，盡可能提高社交水平)。大家需要通過添加簡化要素盡可能降低應用復雜度。

積極動手。選定一款簡單應用，然后立足于AWS進行構建——這也正是AWS的最大價值所在。API與使用指南都是學習云服務相關知識的絕佳途徑。

考慮應用何時需要進行規模擴展，應用中的哪些組件需要進行規模擴展。立足于容器架構實現諸如登錄等功能，從而建立共享式應用。必須保證自己具備按需擴展的能力。審視使用模式并考慮不同類型的用戶是否應當采用同樣的使用模式。了解我們不希望親手構建的部分——換言之，了解我們可以直接使用哪些后端即服務選項(例如API網關以及數據管理服務)。了解哪些元素可以具備云服務供應商鎖定特性在，則哪些能夠幫助我們在市場上獲取差異性優勢。

利用邏輯、數學與藝術手段構建用戶界面——同時使用各類更為先進的編程語言。利用自己的技能對應用做出轉型。尋找一位導師，在其幫助下打下堅實的專業知識基礎，這些都將在未來起到重要作用。另外，在工作中保持激情。

利用黑客馬拉松活動實現快速高效的應用開發。認真審視安全性。鼓勵開發人員與軟件團隊參與黑客馬拉松，從而快速構建應用程序并提供更出色的用戶體驗。部署前快速發現問題，而非完全依賴于測試部門。

考慮哪些組件可以發生故障，利用AWS與GCQ啟動對應實例，直接查看哪些組件正常起效而哪些遇到了問題。持續測試并了解開發成果的實際執行效果。

不要對應用程序的運行位置進行假設。保證所構建的應用能夠運行在任意環境當中。從起步階段將安全考量納入開發流程。構建抽象機制，從而保證應用可由一種云環境遷移至另一種當中。不要過度依賴于單一云環境或者技術方案。

安全性——關注最為重要的方面，特別是隔離各租戶的數據并保護敏感數據。

可擴展性——必須有能力在特定時間段內處理峰值資源需求。

成本控制——優化應用程序以實現成本效益，由于公有云資源在進行性能與擴展性優化時成本較高，這一點也變得愈發重要。基礎設施成本如今主要由軟件廠商而非客戶承擔。

日志記錄——最重要的是能夠調試問題并捕捉一切與故障相關的信息，從而在盡可能無需客戶協助的前提下實現問題修復。

可部署性——SaaS的一大重要優勢在于能夠隨時實現快速部署。我們的架構必須能夠處理實時部署，從而輕松應對客戶直接可見的零宕機時間效應。

多租戶——這一點對于內部環境開發人員而言最難解決，因為此類應用并非面向防火墻后的單一客戶所構建。

自動化——底層基礎設施必須以自動化方式實現設施部署與擴展性調整，且無需大量人為介入。

了解如何利用特定指南資料實現模式設計。云環境下的設計模式往往缺乏充足的說明素材，從業者對其亦理解不深。我們需要率先考量模式相關問題。對設計模式進行抽象化處理，從而確保我們始終參與其中并由此實現職業生涯積累。在了解到基礎模式之后，大家可以逐步體會更為復雜的執行模式。不要重復過去犯過的錯誤。很多人都從閱讀說明文檔開始學習。事實上，觀察他人的工作成果，掌握他人的工作經驗并閱讀博文以及在線資源等都是很好的學習方式。很多企業已經開始公開討論其云架構。大家不妨觀察十家不同企業所使用的架構與實現模式。這將幫助大家在構建自己的解決方案時擁有更為開闊的思路。

不要忘記，云環境是一套非常強大的開發平臺。充分利用云與其它各類資源。利用云服務實現快速迭代、頻繁部署并最終打造出高質量應用。

可擴展性與安全性。開發人員需要從起步階段認真思考安全性需求。將零宕機時間作為前提性目標。

性能與指令。盡可能在代碼中添加指令，從而簡化未來的故障排查工作。數小時的服務宕機有可能帶來數百萬美元損失。了解APM配置并構建修復指令。另外，在性能層面確定哪些狀況可以接受，而哪些絕對不能接受。

脫離應用本身從技術層面審視V5原則。服務器架構正是我們的指向目標(例如Amazon Lambda——其中包含一段代碼，在被調用時會運行Nano服務)。

目前已經有大量平臺開始引入眾多業務功能，這意味著我們可以借此創建預測模型，同時定義業務算法并為預測模型提供分析素材。立足于開發領域的知識，并將其與抽象思維結合起來。Google Tensor Flow、Google Now以及微軟目前都開始提供開源機器學習服務。大家可以考慮如何利用這些新成果解決問題。

考慮到越來越多的應用遭受黑客攻擊，我們需要始終將安全性作為關注重點。安全性與可靠性可謂相互依存。確保應用具備應對流量峰值以及長期發展所需要的擴展能力。盡快幫助客戶從應用中獲取價值。

了解當前可供使用的各類工具。著眼于規模化及性能水平進行應用設計。預測可能發生的變化。著眼于產品的當前作用，并預測其如何與企業環境下的其它產品進行集成。保證應用具備可擴展能力。將安全性引入其中，否則我們的應用將無法通過合規審查。將用戶體驗視為設計工作的核心。

自動化與驗證機制。如果大家在云應用中使用現代工具方案，但卻發現其并不適應當前實際需求，那么請果斷將目光轉回較為陳舊的實現模式。通過互聯網了解其它廠商的實際作法。盡可能利用開源工具實現大規模遷移(例如Netflix)。通過這種方式，大家將獲得出色的思維方式與解決方案。

安全性為先，保證應用中不存在可被利用的漏洞。堅持使用多租戶環境以實現規模化成本效益。

開發者與DevOps團隊需要以云原生角度理解應用程序，而非服務交付方式。很多工具內置有大量功能，但往往并不切合我們的實際需求。因此大家應當進一步學習與性能表現、用戶體驗以及面向最終用戶的應用服務效果相關的知識。了解應用是否可用且是否具備用戶友好特性。掌握應用依賴性與可擴展性。與DevOps及運維團隊交流，從而了解代碼成果的實際運行情況。

大家對于開發人員處理云應用的方式這一議題又有哪些觀點?請在評論中與我們分享。