作者 Richard Seroter ，譯者 王靈軍
開發者正在不斷體驗多種不同的云環境。當在云中工作時，開發者應如何改變他們的思考方式？是否有某些云環境更適合于剛準備入門的開發者？而那些目前尚未涉及云開發的開發者們又如何在此領域獲得相應技能呢？
為了回答這些問題，InfoQ就云開發的現狀、推薦工具和反面模式與三位意見領袖進行了交流。我們的專家組成員是：
??[Adron Hall](http://adron.me)，通曉多種語言的碼農和開發人員布道師。
??[Magnus M?rtensson](http://magnusmartensson.com)，微軟MVP，擔任瑞典Active Solution顧問公司的云架構師。
??[Andy Piper](http://andypiper.co.uk/about)，熱衷于推動Cloud Foundry的開發人員。
InfoQ：是不是一位云開發人員的工具箱相比于普通開發者會有很大不同？如果是這樣的話，那么在你們看來，云開發者更依賴于哪些傳統的web開發者不會使用的工具呢？
**Hall：**首先我會定義當聽到“云開發人員”這個詞時會想到什么。一名云開發人員就是負責這樣的代碼解決方案的人，解決方案是基于水平擴展的、分布式的、冪等的和異步處理，同時具有可伸縮、高度可用和彈性存儲的特點。
我說在回答這個問題時當然應完全根據這個定義。一名普通的開發人員經常是在某個傳統的RDBMS數據庫的基礎之上構建應用，在此過程中他會使用某個框架或是其它基于此框架之上的工具，并受到垂直擴展的限制。這并不是不好的開發方式，但是對于云或其它任何可水平擴展的環境來說，以這種方式來構建應用或服務效率會非常低。一旦達到最大物理擴展極限，開發者就完全無能為力了，因為他再也沒有辦法使用任何合理的方式來提升性能。
一位云開發人員會橫跨廣闊的資源范圍來構建應用，他經常將某個應用的功能拆分成更為具體的服務或模塊。云開發人員也常需要涉足于某些含有更多語言的工具包，這些語言包括從JavaScript到C#、Ruby或其它語言等。這樣做的原因固然經常是出于必要，但在很大程度上也是為了在每個特定工作最適合使用的工具之間提供匹配。
所以，簡而言之，云開發人員的工具絕對是不同的。
**M?rtensson：**云開發人員需要用很多與非云開發環境不同的思考方法來武裝自己。較之于其他寄宿（host）選項而言，當處于云部署平臺時，你可以很容易地獲取到很多東西。良好的云平臺會提供一個工具集，這個工具集與你可能使用過的相比顯得非常不同。它可擁有“無限的”存儲空間，該空間同時具有自動備份、內建的緩存功能、強有力的服務總線和其他特性。
公平來說，你完全沒有必要僅為了獲得此工具箱而去100%買入云計算。如果需要的話，你完全可以只是使用來自云平臺的如服務總線這樣的某一項服務。與任何非云環境的寄宿類型不同的是，工具箱中擁有更多“工具”，比如快速彈性、內建容錯、故障轉移，以及你可以在任何時候按需優化費用的完全可度量的服務等。這些云特點常被引為NIST云計算定義。我認為，云開發人員有非常多的工具待去了解和運用。合適地運用這些工具可以助你構建那些以前看起來近乎不可能的、或者即使可能但也是代價昂貴的解決方案。如果這些特性被濫用的話，那么云開發人員則會冒著失去獲得強大力量的希望的風險，甚至于冒著構建了更為昂貴的解決方案的風險。因為能力越強大，責任也越多。
最后，如果我們再多談論點傳統開發人員工具，其實對于云開發人員和其他類型的開發人員來說，這些工具都是極其一致的。按照我的經驗，雖然在Windows Azure平臺上使用PowerShell可以在云環境中獲得很多收益，并且也自動化了構建和部署。但對于大多數其他寄宿情形來說，這種做法也可以獲得同樣的效果。我只是覺得在一個像云這樣的內在的分布式環境中這樣做是很自然的。對于任何一個想使用云來讓自己能力更強大的開發人員，我的建議是去學習和了解云計算的真正力量。它們是你的新工具，將會助力你實現從一名傳統開發者成為云開發人員的目標，你曾經為此有過一段痛苦的時光甚至于以前這只能是一種奢望！
**Piper：**好問題，這也是我一直仔細考慮的問題之一。Adron在一件事上絕對正確，就是云帶來的是規模——無論是就數據本身而言（同時到達的數據量，或存儲的數據量）還是就你如何在云環境中為了獲得可用性而擴展你的應用至跨地理位置的多個實例而言。也就是說，雖然很多專為這個新時代而創建的工具和技術（如Riak和其他的分布式數據庫）紛紛出現，并且與以前比工具箱中出現了很多不同的工具，我總是傾向于認為，開發者使用新的云平臺的最重要的一件事，就是忘掉他們過去的假設——換種方式來思考如何部署應用。
給開發人員提供一致的體驗是構建能支持云應用的操作系統的目標之一。我們寧愿如此簡單：用Ruby或node.js或隨便某個工具來編寫一個簡單web應用，然后本地運行，或者運行在自己的單一服務器上，亦或運行在一個可縮放的彈性的云環境中。所以我們構建一個抽象層來隱藏不同的云基礎設施（AWS、OpenStack或無論什么）之間的差異，讓開發人員能夠很輕松地部署應用。這確實意味著他們需要意識到不能依賴于自己應用的位置、硬編碼的IP地址或其他配置，這些都是不好的做法，而應是在編碼時應盡可能將代碼與數據庫（它們有可能會改變）之間解耦。所以思考方式和架構都是不同的，不過最起碼很多工具和代碼都可以保持不變。
InfoQ：你們認為哪些IDE最適合于云開發？開發者應為些IDE添加哪些東西來增強其云開發的能力？你們對基于云的IDE有興趣嗎？
**Piper：**很個人的說我是有潛在偏見的（作為一個Eclipse提交者），我很喜歡Eclipse，也是IntelliJ和RubyMine的粉絲。現在大部分成熟的IDE都擁有非常好的插件與云服務進行交互，比如有低級別的AWS Explorer，也有提供了平滑的構建/測試/部署體驗Eclipse的Cloud Foundty集成插件。
我曾使用過像Eclipse Orin和Cloud9這樣的基于云的IDE和編輯器，它們都非常方便。我很高興地看到它們演進得也很快，從而可以利用最新的web特性。
當然很可能具有諷刺意味的是，我自己的開發者工具集根本不是以IDE為中心的。我將一天的大部分時間都花在Sublime Text以及命令行上，并且我也是Ubuntu的包管理和OS X的自制軟件開源包管理器的大粉絲 :-)。
**M?rtensson：**聽到Andy這么說很有趣，因為我有類似的背景，不過剛好相反。我是一個Microsoft/C#/Windows Azure的開發人員，這使得我在面對IDE環境和開發體驗上極具偏見。最近Microsoft在Visual Studio中實現無縫的云開發體驗上投入的努力是無與倫比的，而這是我在Visual Studio身上前所未見。它們確實做出了巨大的努力來支持快速和強有力的云開發。Visual Studio中的Server Explorer能夠踏足任何云賬戶并和運行其上的任何服務進行交互。你可以管理它們，監控它們，并可以在云上運行類似于IntelliTrace和性能監視器這樣的工具。然后你可以下載結果并在Visual Studio中進行分析。很自然地，你能在本地構建和測試任何云應用，包括最近加入的非超級管理員模式的計算模擬器（Express版本）。隨后你可以將應用作為一個單元推送到位于Windows Azure上的自己的網站和云服務中。我在Visual Studio IDE所見到的用于云開發的（讀作：Windows Azure開發）部分在Visual Studio歷史上是無與倫比的。干了這杯Kool-Aid？是啊！大口地享受它吧！
**Hall：**很明顯有至上之選：Cloud9IDE。
雖然如此，在現在很多情況下IDE看起來有所妨礙。當某個人需要在具有很多種語言和工具的不同環境之間切換時，最容易的就是抓到Sublime或類似的某個東西并運行。
在重量級有像Visual Studio、Eclipse、IntelliJ、WebStorm和其他應用工具等這樣的IDE。這些都很好，并且為一種或某幾種語言提供了鉤子以方便日常的運維編碼工作。但是有可能當某一天快要結束時，某個不在那個IDE范圍之內的語言突然冒出來，那就毀了你這一天。
另外一方面，如果一個團隊能夠專注于某個特定IDE，使用它來加載任何開發所需要的一切，并且IDE能夠和首選的云環境協同工作，那么Visual Studio和其他幾個IDE就會脫穎而出。一個很好的例子就是用于Visual Studio的AWS的.NET插件。這個特殊的插件是我所見過的僅有的沒有將開發者綁定于實際云的工具集。它只是極大地簡化了部署和查看云服務，這些都不用離開Visual Studio。對于.NET開發者來說，這是極大的好處，因為他們總是被鼓勵并習慣于在云開發過程中一直呆在一種IDE中。
然而，在大多數web開發和云環境中，你會推送一些東西并使用像SSH這樣的工具。在這種情形中Visual Studio和Windows通常都不是首選者（non-starter：比賽中不是首發的隊員）。讓Windows和Visual Studio與SSH和其他Linux或相關環境一起工作所花費的時間會非常讓人沮喪。此時，非常戲劇性的是，像下面這樣做反而容易得多，抓到一個終端，學會如何擺弄它，然后SSH連接到在這些終端，實際上就可以工作了。即使在使用Windows Azure，如果你并不打算在Windows上寄宿或也不想使用Visual Studio的至Azure的私有鉤子，那么完全可以甩開基于Windows的開發工具轉而使用運行于Linux或OS-X之上的來自于JetBrains的工具。從這些工具上獲取好處，你的開發團隊最終會感謝你。云畢竟是源自于Unix并將在多年來已成為Unix技術世界一部分的很多理念的基礎上繼續演化著。
InfoQ：當開發者在構建云規模的應用時，應避免哪些反面模式呢？云提供商又如何避免你們犯這些錯誤，或反過來說，讓你們做些錯誤的事情？
**Hall：**在開發云分布式應用時，開發者會掉入很多巨大的陷阱之中。
我曾一次又一次看到的最大問題是，他們更愿意搭建單一的數據中心（比如AWS，一個區域等）。使用局限于某個數據中心的框架棧和故障轉移所構建的某個應用仍然趨向于引起很多停機情況，比如“East 1 AWS Failure”，綽號為復活節故障。
另外一個很大的問題就是很多提供商——好吧，也許是所有的提供商——仍然還有很多SPOFs（單點故障）。Windows Azure在幾個月前由于其證書問題而打破了大數據中心的故障記錄。AWS也出現過由于數據中心的某個網絡設備而導致的故障。Rackspace同樣也有類似的問題，也鼓勵了人們使用機架設備，這又在已有的其他故障點之上生成了更多的SPOFs。整個想法是想讓云架構具有彈性，而這些情況適得其反。
從純粹的開發者角度來看，最大的錯誤在于很容易在云的計算和存儲環境中只是簡單地構建一個傳統的垂直堆疊在一起的應用。在云環境中使用按照傳統架構信條所構建的應用會付出高昂的代價昂貴，并且效率很低。然而一次又一次，我看到人們只是重新實現某個垂直設計的應用；Sharepoint，WebSphere和其他所能想到的。他們通常只有單一的RDBMS，在此之上有個數據層，以及一個或者可能是幾個應用節點，而這幾個應用節點卻位于某個有著SPOF的緩存層之上。
總的來看，云開發中有很多反面模式，而運維和開發總是很容易實現它們。
**M?rtensson：**一個真正而又常見的反面模式就是將老的思考方式應用到新的范式上。比如認證；“我們想讓顧客能夠使用他們自己已有的Google，Yahoo！，Facebook和Microsoft帳號來認證我們的服務。當然我們也需要標準的用戶名/密碼登錄方式。”你來找出其中的缺陷！基本上就是他們說想要設法變得很時髦，然后又想通過將自己的祖母帶到聚會上來回歸保守。如果這確實是你的開發和維護工作所要關注的，當然你可以運行并處理自己的用戶名/密碼認證服務。但如果你正在采用所有的方式來外部化自己的應用的認證，那么就需要通過將自己寄宿的認證服務（術語也稱為安全令牌服務STS）從你的應用中分離出來，然后才能真正實現這些方式。簡而言之，你的應用不應關心任何認證。然而它應擁有一個可信任的、為你處理這個單獨的關注點的標識符提供者。如果你不保存密碼，則你根本不用保留此職責。最開初的表述是害怕由于不提供的標準的用戶名/密碼認證選項從而失去顧客。但這只會增加你的工作負荷，并且你將會失去使用云服務進行外部化認證的好處。如果你不能公正地對待這種新的模式，除了在開始就以完全錯誤的方式來使用它這種壞處之外，你最終還將會損害自己的業務。
**Piper：**好吧，說到現在我已經很難在Adron和Magnus所闡述的常見反面模式之外再添加其他內容了——這些我都見到過。有個很明確的傾向就是以傳統的方式思考并構建垂直而不是水平擴展的應用。在這樣的情況下，當一個開發者“發現”像RabbitMQ這樣的異步消息傳遞和像Redis這樣的內存中的數據結構，然后想到，哦，這是一種“全新”的做事方法時，我總是很吃驚。不，完全不是，這些概念已經出現了很長一段時間，而云平臺比曾經任何時候都提供了一個冪等的、最終一致的服務模式。
在云提供商如何幫助你避免失誤方面，就我自己來說，Cloud Foundry盡了其最大努力盡可能地來提供作為其環境一部分的有用配置信息，所以你可以編碼來從配置信息中去查找值而不用硬編碼端口、數據庫設置等。這并不妨礙你硬編碼，但是這樣做確實不是一件好想法。
InfoQ：Redmonk的Stephen O'Grady曾經說過“云計算的最重要特征：進入的低門檻。”你們認為哪些云對于開發人員來說學習會更容易一些？不僅只是讓開發者注冊，而且還向開發者展示了該如何開始部署應用這些方面，誰工作做得好？對于開發人員仍然還存在哪些進入門檻？
**M?rtensson：**在瑞典我們說“'tala i egen sak”，意思就是說你是偏頗地來表達自己關于事情的看法。再次說明，我是一名虔誠的.NET/Visual Studio/C#開發人員。當然就會偏向Windows Azure云。仍然……哦！不用暴露我的年紀，我在這個持續的消防比賽中已經有很好的數十年的經歷，而且我還從來沒有在Microsoft看見過像這樣的事情。也許巧合的是，微軟的云的氣息到來適逢其時？也許只是因為這就是應當做的？但我還從來沒有在Microsoft身上見過如此致力于推動技術變遷的情況。并不僅是VB和C#，還有很多。Microsoft為現在的Windows Azure的多種平臺和IDE構建和維護了工具集和SDK。PHP、Java、Node.js、Ruby、Python & Visual Studio、Eclipse和開發一次并可給很多不同類型設備發送消息的能力；這些設備有iOS、Android、Window Phone和Windows 8。挑選你的毒藥吧！今天誰是對Linux最大的開源貢獻者？是的，這就對了，但是誰又曾知道這些呢？對于那些泡在這個空間的人以及那些知道Microsoft的人來說，這是一筆非常大交易！這是一個擁抱多元化的全新的Microsoft，并且它意識到許多公司為了日常運營將會使用很多服務和平臺來構建自己的現實世界。這就是我們現在所處的情形，而Microsoft就在這兒。有哪個其他的棧/平臺能匹配這個呢？
**Hall：**對于任何PaaS（平臺即服務），進入門檻都盡可能如你所能達到的一樣低。當我們深入探討這些時，這會得到一些奇怪的比較結果。Window Azure據稱首先是PaaS，然后才是IaaS（基礎設施即服務），它以這種方式開始，然后努力推廣它。AWS甚至都沒有提到過PaaS這個詞，即使他們擁有很多提供了PaaS風格的單一命令行（某些時候要點擊）部署方式的服務和特征。而對于其他那些沒有一個明確的PaaS說法的環境，門檻過多，而且很笨重，并且我覺得不太值得提及。所以對于那些沒有一個合理的PaaS說法的我將會在其他時候再討論。
這帶來了另外一個關鍵之處，在AWS上實際運行的所有PaaS服務都是怎么樣的。Heroku、EngineYard、AppHarbor、AppFpg和幾乎每個Cloud Foundry或OpenShift PaaS服務都安裝在AWS上。所以很明顯，如果某個應用包含了AWS的服務和AWS提供了PaaS服務的客戶，那么它在可用性方面就大幅領先于其他人。即使我們回溯并只是看看首批AWS客戶的安裝和使用，這些客戶在使用Beanstalk、EC2或S3，其安裝和使用都極其簡單。簽約、檢查認證機制或類似于通過郵件發送的編碼令牌，然后安裝好上面所提到的項目之一并啟動，你就已經在運行一個應用了。
可以說最嚴重的障礙都在基于Heroku、EngineYard、Cloud Foundry和OpenShift的PaaS中被移除了。在上面這樣PaaS環境中可以很容易地安裝、使用和部署應用，這些恰好都是位于AWS中。
但是對于Windows Azure，Windows Azure團隊和努力將這些云選項從一個“絕對不”移動到“嘿，這是非常容易的且功能豐富的”。 Windows Azure，我不會再為回答這個問題而談論其過去，它已經戲劇性地重新定義了如何更貼近部署，并積極地比幾乎其他每一個PaaS或IaaS服務提供商提供了更多的部署選項和部署能力。另外其已轉變為多語言的，在這場由AWS扮演兔子的龜兔賽跑中獲勝。比如AWS節點Beanstalk功能。在Windows Azure能夠極為容易地、優雅地和極好地在AWS上部署基于Node.js的應用差不多一年之后，AWS才實現。加上它可以圍繞Node.js來定價，對于小型的共享的云寄宿模型來說，.NET、PHP和其他的應用已經為零。這對于開發者來說當然非常棒，他們可以在運營之前測試、調試大多數的應用。
總的來說，上面幾乎涵蓋了我個人所使用和一直關注的主要提供商的基本內容。Windows Azure、AWS、Cloud Foundry、OpenShlft、Heroku、EngineYard都是現在值得關注的主要公司，它們正在這個空間內做著繁重的創新工作，并正在逐漸地前進以移除更多的進入門檻。
**Piper：**我喜歡Redmonk的這些家伙！他們都是非常聰明的人，并且我推薦那些任何不熟悉他們意見的人去尋找他們。開發者都是新的擁護者。
所以，是的，我完全同意進入的低門檻對于開發人員快速采用我們所討論的云技術來說非常重要。實際上，這就是某個“啊哈時刻”，這可以讓我從自己以前在IBM的角色轉換到VMware的Cloud Foundry上來——本地編碼應用的能力，無需任何改變地將其推送至云上，然后在幾秒鐘內將其擴展。鑒于我的角色，不用想就我可以說，很明顯，Cloud Foundry進入門檻很低……但就如Adron所說，我想很多相似的PaaS提供商都是這樣，如Heroku。我同樣對為所見過的在Visual Studio和Azure環境中開發者所展示的工具集成所驚嘆，在這個環境中開發者會覺得走向云的旅程十分愉快。我應該指出的是，很多云提供商，特別是PaaS提供商也擁有工作得很好的IDE插件。然而對于真正地低進入門檻，我仍然喜歡源自于Github命令行方式的克隆，本地構建和測試，然后從命令行推送至云的體驗，Cloud Foundry和幾個其他云提供商都提供了這種——這比需要一個IDE更輕量級。
InfoQ：對于開發者來說哪些事情在過去曾經是很難的，而現在由于云變得簡單多了？而且，有沒有某些事情在過去是簡單地忽略掉或者根本不做，而現在變得簡單明了的？
**M?rtensson：**這是一個大局觀的問題。當我們開發時什么是重要的？我們會在某一天回憶起云之前的“黑暗時代”并問自己在那個時代我們是曾經如何讓一切運轉起來的嗎？構建一個全球可伸縮的供幾十萬甚至上億用戶使用的解決方案確實不是我們大部分人都曾經做過的。但是我們確實可以做到這一點。如果我們業務比像Facebook那樣構建自己的數據中心要小得多的話，那么能有機會看到過自己能做到哪一步嗎？如果有一個了解了云平臺的力量的像樣的架構師的話，我就敢說再開發這樣的解決方案甚至都不再是什么難事了。現在沒有新成立的公司會說“好吧，我們現在獲得一筆風險投資，讓我們出去采購一些服務器回來。”如果我們展望未來并設想我們開發將會所使用的環境，我確信CPU的能力、內存的大小、存儲容量、甚至互聯網的速度對于我們構建應用的方式的重要性會越來越小。相反我們會開始依賴于總會有足夠的容量給我們正在做的無論什么東西，以及能滿足我們的服務所要求的無論什么樣的使用模式的需要。當然事情在未來仍然會出現中斷，并且某些時候服務會出現故障。但不應會出現這樣的情形，即我們不得不恐慌地沖到市中心去買一個全新的硬盤驅動器。我們的服務將會是自愈的。在這個大局觀中我們會使用新的模式來開發，這些模式從開始就會把所有這些問題都考慮進來，而且我們從來也不會再關心是否擁有足夠的計算能力。
**Hall：**我將建議的是排在前三名的事物：
??已經影響到開發人員能如何來開發的最大的影響是能力，即僅需在這兒或那兒點擊一些選項或某個腳本就可以讓整個運行開發環境跑起來。服務器、測試服務器、UAT服務器等。在以前，即使在簡單的虛擬化下這些在很多方式上都會受到限制。但是現在，在擁有AWS、Azure以及其他類似云環境所提供的云計算能力的情形下前面那些都完全不再是問題。以前需要耗時幾小時或幾天甚至幾個月的事情現在幾分鐘之內就可以完成，并且以一種能向前移動并保留全部努力的方式工作，而這種方式在6-7年前完全無法想象可以這樣做的。
??跨地理邊界的分發系統的能力，這在6-7年前，即便不用花費數百萬美元資本投資，也會需要數十萬。現在每個月僅只需要幾百或幾千美元，一個龐大的、跨越廣為分散的多個國家的分布式系統在幾分鐘之內就可以安裝并運轉起來，并準備好投入使用。
??與垂直疊高的方法相比，分布式系統正在成為普遍的做法。隨著這種改變，隱藏在冪等、彈性、自愈、異步、可伸縮、高度可用性系統背后的思想在大大小小公司的絕大多數程序員中出現。隨著越來越多的開發者轉向水平擴展的做法，垂直擴展背后的極端受限的設計逐漸地被扔到路旁。隨后一系列很多用來增強利用這些功能的能力的語言和框架應運而生。這種觀念模式和方法的變化一直在持續進行著，并日益增強著云計算的能力。
……這就是在我腦袋中立刻能想到的排在前三的最重要的事物。現在已經發生那么多的變化，獲得了很多的進展，以至于關于這個話題有人能寫一本書了。
**Piper：**對于開發人員來說，云讓哪些變得容易呢？
??按需的、潛在的可自由支配的環境。實際上，像Vagrant這樣的本地工具還一如既往是開發者的朋友，但是能快速提供和千篇一律的克隆環境以及能以通常很小的代價運行這些環境的能力也極具價值。這對于開發和運維活動一直是巨大的推動力——開發者不用再面對運營維護者的突發奇想，開發者曾經得去為他們提供新的環境。這并不是為了敲打運營團隊——新的云工具和環境也為他們提供更多的敏捷性。“作為服務”是*aaS縮寫的關鍵部分。
??可伸縮性、可用性、彈性。我想Magnus和Adron對這部分已經說得很好。在這里除了將它們歸結為這三原則之一之外，我無法再補充什么了。
??我認為有兩件事——“大數據”和“物聯網”——因為云的可用性在很大程度上變得更有能力。垂直擴展的大數據庫這許多年來已經成為可能，但是具有海量存儲容量、復制、MapReduce等特性的分布式數據庫更傾向于與云聯系在一起。傳感器的連通性、數據的采集和對數據的響應一直以來都是只以單點為基礎，但是現在的開發者已經可以構建復雜的能實現自己想法的系統，使用云結構的靈活性構建的系統只有零或很少幾個故障點。
??上面只是一個快速總結。這是一個技術演變具有深遠影響的領域。
InfoQ：雖然很多開發人員都開始花費大量的時間來開發云應用，現實是還有很大一部分開發者在其日常工作中都沒有理由去接觸云。假定這部分開發者沒有充足的自由時間來體驗云環境，那么你們會推薦他們做什么以便與最新的云服務和戰略與時俱進？你們自己又是怎樣跟上這種不停向前流動的云空間的呢？
**Hall：**對于那些沒有接觸過云/公共云或剛出現的私有云的開發者來說，我發現兩種很有用的方式非常重要。
??學習一般的分布式系統。這些包括分布式數據庫、分布式計算（網格計算等）、通過自動化或大量其他選項進行的跨分布式環境的網絡管理。這段時間也出版了很多書籍，這些都能在這上面給予他們很多幫助，因為很多工作都已經極大地學術化了（對那些實際上正試圖利用分布式系統的編碼人員或運營人員并不是很有用），但其中很多東西在日常的開發和運營中基本上沒用。
??當這樣做有用時候，盡量嘗試在日常的開發過程中小規模地引入它們。即使沒有用到云，從分布式角度而不是垂直式角度出發來構建某個系統也可以擁有強有力、有用性和健壯性這樣的特性。下面就是我這段時間來一直堅決鼓勵的一個做法的要旨：除非應用只是臨時性的，否則請不要開發純粹的垂直式應用。如果某個應用的期望生命周期超過一年的話，那么請按水平擴展的、可伸縮的架構來構建該應用，這樣它在一個分布式系統環境之中也能很好地工作。
**M?rtensson：**向云邁出第一步很容易。首先我想提醒的是最大的問題是，從廣泛和普遍采用云計算方面來看，我們目前處于哪個位置？我是一名云計算的倡導者和忠實信徒，并且我真的很想相信現在我們正準備促進云的大爆炸。這就是說很多即使不是所有的信號都在指著這個方向：培訓公司在這上面的興趣在顯著增加，顧問們注意到更多關于云的喋喋不休，更多的客戶正在激起興趣而提供商的市場份額也在持續增長。我實在看不到一些關于正在快速增加地采用云技術的反面跡象。傳統寄宿選項仍會繼續掙扎求生并盡一切能力來顯示自己仍是可替代的選項，但在我看來這只是延緩了它們無法避免的命運的到來。特別如果你認為混合場景也是一種真正的云場景的話，我想我們應也將看到一個快速應用需求。如果我們談論技術采用生命周期，我認為我們在甲板上已擁有了早先的采用者，我們正站在深淵的邊緣，深淵將早先的采用者們與其它分割開來。
云平臺的提供商們正在盡力做到很容易就能采用并平滑地過渡到各自產品。比如Microsoft最近對于某些試用場合就取消了信用卡的要求。為了回答這個問題，開始與云計算同行將會實際上已經是很容易的了。你不需要花費大量時間來上手。你可以僅僅需用幾分鐘時間來注冊并獲得一個試用的可運行版本。實際上擁有一個已分配給自己的MSDN訂閱的每個人都已在云中有一個個人的開發/測試環境。所需要的就是[激活MSDN訂閱上的Windows Azure](http://bit.ly/140uyUP)，這大概需要2分鐘左右。大量的在線指南可以幫助你將自己的第一個應用部署到平臺。例如[我博客](http://magnusmartensson.com)上的視頻演示。確實地如果你有15分鐘的話，我敢打賭你肯定能將自己的第一個應用在Windows Azure云上正式運行起來。這可能是一件簡單得也許微不足道的事情，但它真的很酷很讓人耳目一新。
**Piper：**我想PaaS所提供的任何東西都是瞄著提供一個無阻力的部署表面——AppEngine、Cloud Foundry、Heroku、OpenShift以及Azure的涉及PaaS的很多方面等等確實都是這樣。如果在自己所選的平臺上沒有盡力提供一種在其上部署應用的簡單方式，那么很有可能你開始就沒有做對。當你開始尋找自己應用中的可伸縮性和數據訪問方面某些問題時，學習曲線上仍然還有很多要去學習。
個人來說雖然我發現像O'Reilly這樣的出版社所出版的很多不錯的語言和編程指南書籍常常都有好幾年的生存期，但由于云領域的快速創新，“云”相關的書籍顯然還沒有老到有這種火候。只要等待一個月，AWS就會已引入一個全新的API或調降了價格，某個PaaS提供商就會宣布有了新的合作者、插件或功能！這就是說在博客中挖來挖去并跟隨Twitter上的那些能推薦很好的鏈接的家伙會更有用。我發現兩個特別的來源是很有價值的。Github活動feed讓我能跟隨自己的聯系人所評級或創建的新的項目、apps和庫。DevOps每周簡訊（云和開發空間的每周匯總郵件）也是一個獲取關于最新進展的摘要信息的有用途徑。
作者簡介
**Adron Hall：**軟件架構師、工程師、程序猿、碼農、分布式系統的擁護者。他是位多產的開源貢獻者，[積極使用Github](https://github.com/Adron)來貢獻項目。你可以在[CompositeCode.Com](http://compositecode.com)上了解他的思想，還可以在Twitter上的[@adron](https://twitter.com/adron)跟隨他。
**[Magnus M?rtensson](http://magnusmartensson.com)：**就職于瑞典的Active Solution顧問公司，擔任云架構師/開發者。他是Windows Azure MVP、Windows Azure的業內人士、Windows Azure顧問。你可以在[MagnusMartensson.com](http://magnusmartensson.com)上閱讀其著述，還可以在Twitter上的[@noopman](https://twitter.com/noopman)跟隨他。
**AndyPiper：**倡導Cloud Foundry的開發者。他的日常工作是包含以下內容的有趣混合：技術市場、業務開發、與開發者交談、各種會議上的公開演講、撰寫文檔和示例、向工程師抱怨其中斷了事情、博客和推特、還有就是組織活動。從[這兒](http://andypiper.co.uk/about)可以了解他更多東西，還可以在Twitter上的[@andypiper](https://twitter.com/andypiper)跟隨他。
感謝[侯伯薇](http://www.infoq.com/cn/author/侯伯薇)對本文的審校。
查看英文原文：[Virtual Panel: Adjusting to Development in the Cloud](http://www.infoq.com/articles/virtual-panel-development-in-cloud)
查看原文：[虛擬專家座談會：邁向云開發](http://www.infoq.com/cn/articles/virtual-panel-development-in-cloud)
