雲計算與移動性這兩大技術的交叉必然是炙熱異常的，而這也是應用程式開發人員和規劃人員所面臨的一大挑戰。因為移動應用程式更具自發性和個性化，是以它們成為了雲計算支援的最合适候選者，但是讓移動雲應用從一開始就在正确的方向上發展是非常重要的。為了做到這一點，就要從基于工作流的應用程式深度管理開始，以系統的方法引入byod支援，使用應用程式生命周期管理(alm)來統一應用程式的釋出。
移動使用者是所有使用者最具地域多元化的使用者，而這一多樣性也同時為雲計算帶來了機會和挑戰。雲計算允許開發人員把應用程式支援部署在與移動使用者相同的廣泛地域中，但是如果缺乏正确的管理，這也會為成本和性能帶來不利的影響。
移動雲應用開發中最顯著的問題是如何把握将應用程式擴充至所謂的“自然分布”。就如同有着一定靜态資料内容的網站主機一樣，它們可以被很容易且低價地複制以提高性能。在雲計算中，可以在使用者較為集中的位置部署站點以供本地應用程式通路。但是，如果應用程式是依賴于托管在企業資料中心中的資料(有可能是出于安全性或成本管理方面的考慮)的，那麼所有的應用程式最終将不得不傳回資料中心以擷取資訊。
為了平衡成本性能與集中化資料存儲處理兩方面的關系，應試圖抽取應用程式工作流程以說明使用者是如何與應用程式進行互動并通路集中處理存儲的企業資訊的。一般而言，應用程式與使用者的互動分為包含選擇表現形式的一系列階段，如收集資訊、處理資訊和傳回結果。在雲計算中的關鍵階段是“處理”階段，因為這是雲計算外包最難以為應用程式進行定價、提升性能和遵守合規性的所在。應用程式設計的第一目标應當是確定處理階段是工作流中的一個單一環節，這樣就可確定應用程式的其他階段可以被雲計算外包、複制和分發。
應用程式階段的概念引入了移動雲計算的第二個問題，即如何支援byod。解決byod問題的一個常見方法是為應用程式開發多個前端以支援各種移動平台。這樣做是與分布性原則相違背的，因為把每一個前端應用程式元件的副本分發至每一位移動使用者可能出現的區域是一件相當不經濟的做法。
為了更高效地在雲計算中支援byod，可以有兩個方法：把特定裝置格式移至移動裝置或者為使用者的應用程式開發多個裝置前端元件。如果前端處理是由集中化 “顯示面闆”回報的，那麼前者是有效的，因為這個“顯示面闆”是專為輕松實作目标裝置重新格式化而設計的;而如果“裝置-應用程式”的互動被限制于支援所有byod目标的歸一化形式(以特定裝置的方式)，那麼後一個方法也是有效的。實際上，開發一個具有基本功能的“虛拟移動裝置”就可以在之後為每一個 byod目标進行定制。
為每一個裝置進行格式轉換的缺點在于，如果為應用程式開發了更多的功能就會造成對新裝置支援工作的複雜化。使用者可能可以通過一些“移動後端即服務”的工具來管理這一複雜性，是以在對虛拟移動裝置進行架構設計之前審查工具的具體功能是非常明智的一件事。
移動雲應用的最後一個問題就是應用程式管理流程。應用程式管理通常被視為移動應用程式本身的版本控制和根據使用者需求和意願向使用者釋出應用程式的組合。移動雲應用由于其中的雲計算元件而必須被更廣泛地考慮，而更為複雜的結構讓應用程式管理變得更像是alm，在很多情況下這是最好的入手點。從某種意義上來說，移動雲應用管理就是雲應用生命周期管理和移動應用程式釋出控制的組合。
由于變更因素的多樣性，移動雲應用産生了管理方面的問題。業務變更總是會造成應用程式的變更，是以作業系統和中間件元素也需實作有序更新。傳統的alm是通過為開發人員和操作人員制定“變更-測試-部署”的标準化程式來解決這一問題的。移動雲計算不僅引入了另一類的變更(即移動平台的組合集)，而且還至少帶來了新版本交錯部署的潛在問題，這是以往alm實踐所沒有考慮過的問題。
因為大多數精心設計的移動雲應用是多元件和分布式的，其獨特前端處理集是随着移動裝置的改變而變化的，是以是有可能把移動雲應用的前端和後端當作兩個獨立應用程式來對待的。這一方法的風險取決于使用者的“虛拟裝置”是否真正地實作了兩個應用程式元件的各自獨立。
移動應用程式釋出要求将版本控制納入alm流程中。如果使用者對應用程式或移動裝置進行了修改，其影響可能會跨越虛拟裝置的邊界，使用者可能不得不更新應用程式元件的裝置副本。請確定您的移動應用程式管理工具具有軟體版本控制功能，并對按需更新裝置元件有一個科學有效的更新機制。一般來說，您的應用程式管理軟體應當能夠驗證任意被用于運作應用程式的新移動裝置的裝置型号和軟體版本。
從開發的角度來看，移動雲計算是兩個互相依存的事物。至少在某種程度上保持兩者的獨立性将有助于使用者實作移動性和雲計算使用的優化，但是也應至少在alm層面上把兩者連接配接在一起也是實作應用程式長期穩定性的關鍵所在。小心行事，您是可以做到這兩點的。
本文作者：佚名
來源：51cto