由某公司云服務到對移動端開發和運維思考
之前hobo在36ker上了解到一家提供云服務的公司AVOS Cloud，他們對外提供了提供一站式app后端云服務，可以大大提升app應用的開發效率。
下面先對他們提供的服務和工作機制做一個簡單介紹：
1. 數據存儲服務
對外提供的數據存儲服務，可以讓你用 RESTful API 和各種 SDK 增刪改查任意數據。基于文檔類型的 schema-free 的對象級別存儲，幫助您存儲各類應用信息。我們還提供包括圖片、視頻等多媒體文件在內的分布式存儲服務。
2. 消息服務
支持一對一，群聊，只需幾行代碼，就可以給你的應用插上移動 IM 的翅膀;IM 系統與當前用戶系統完全解耦，無需同步或修改現有用戶體系，即可使用;除移動開發的原生 SDK 之外，我們也支持網頁內聊天。
3. 消息PUSH服務
iOS、Android、Window Phone，每個平臺都各有特色，技術方案各不相同，該怎么辦?我們提供了一套簡單、高效的解決方案。你可以通過 Web 控制臺、也可以通過 Restful API 以及原生 SDK來發送通知。
4. 數據分析服務
AVOS Cloud 提供實時、免費、專業的移動應用統計分析服務，幫助你了解運營概況、應用趨勢分析、用戶行為分析等關鍵指標，也可以追蹤不同渠道的推廣效果。
5.社交網絡服務
一行代碼實現第三方登錄，體驗差的注冊流程會帶來三成以上的用戶流失。想簡化流程，直接使用微博、微信、Twitter、Facebook 一鍵登錄?沒有問題，使用我們的 Social 組件，最少只需一行代碼，輕松搞定第三方賬戶登錄!
如果基于AVOS Cloud開發普通的app應用的話，我想基本可以省去大部分后臺服務了，而且可以大大節省開發時間，對于分秒必爭的移動互聯網來說，節省開發時間就意味著你可以比競爭對手提前發布應用，占領市場。
反觀我們SNG目前的應用開發和部署流程，要開發一款app的話，可能先是客戶端的同學和后臺開發同學一起，商量好接口，后臺的同學開始開發，然后開始使用各種前端的接入框架(wns,msf)等，聯調各種接口(cmem,L5,各種權限),上線部署的時候又開始找運維申請機器，申請tgw,cmem，L5，各種權限等等，而且移動端很多都是直連ip的私有協議，這樣又要自己去實現一套調度的接口，用來保證用戶能夠接入到最優的服務ip，而這時候客戶端的同學可能又要去折騰公司各種平臺登錄問題了。
對比上面的兩種開發方式，我想我們在移動端上開發效率可能還真沒有使用AVOS Cloud的創業公司的效率高了，之前PC端的運維方式，開發完成cgi和邏輯server的開發和聯調，找到運維去申請tgw，部署qzhttp，部署spp，申請cmem，雖說有很多自動化的工具，但畢竟要走這么長的一個流程才能上線。
其實AVOS對外提供的服務，我們公司內部都是可以支持，比如存儲服務我們cmem這樣支持海量高并發的內存數據庫，對外接入我們tgw，消息推送和數據分析我們有信鴿和TA等等，但問題就在于我們沒有把這么整合起來，對開發以云服務的方式提供出來，還是由運維和開發來一步一步去對接和實施，鑒于此hobo大膽設想下，我們應該怎么去改進我們目前開發運維方式：
1.整合公司現有的服務，對外提供一個操作界面，開發的同學直接可以在同一個站點完成關于app開發需要所有的操作，不需要來回去公司各種系統去申請權限，聯調接口等等。
2.針對接入，把tgw和接入調度封裝成服務，對外提供sdk，開發只需要自助申請一個接入ID，然后把SDK集成app就可以實現與服務端交互以及獲取到最優的接入ip。由運維后臺自動化去申請后端接入機器，部署接入框架。
3.關于存儲，最好能直接對外提供存儲的服務，支持restful api 和 sdk的方式，把cmem和tfs的接口封裝對外的服務，讓app直接在客戶端操作存儲。
4.數據分析服務和消息推送，可以直接和公司現有信鴿，TA對接下即可，因為他們已經有現成的sdk和服務了。
總之就是把我們目前的系統、接口、服務進行封裝和優化，以云服務的方式提供出來，節省app開發時間，提升開發效率。
最后套用一個大神說過的一句話結尾：
如果一個公司內的運維團隊開發出一堆工具，讓做應用開發團隊可以很容易地申請機器、存儲、網絡、中間件、安全等資源，并很容易管理、監控和部署應用，并提供運維資詢。而不是幫應用開發團隊干活擦屁股當保姆。那么，這個公司就會不經意地做出一個云計算平臺來了。
