邁向云開發(fā)

derek_334892 發(fā)布于2019-04-25 17:35 / 2398人閱讀

摘要：給開發(fā)人員提供一致的體驗是構(gòu)建能支持云應(yīng)用的操作系統(tǒng)的目標(biāo)之一。你們認(rèn)為哪些最適合于云開發(fā)開發(fā)者應(yīng)為些添加哪些東西來增強(qiáng)其云開發(fā)的能力你們對基于云的有興趣嗎很個人的說我是有潛在偏見的作為一個提交者，我很喜歡，也是和的粉絲。

開發(fā)者正在不斷體驗多種不同的云環(huán)境。當(dāng)在云中工作時，開發(fā)者應(yīng)如何改變他們的思考方式？是否有某些云環(huán)境更適合于剛準(zhǔn)備入門的開發(fā)者？而那些目前尚未涉及云開發(fā)的開發(fā)者們又如何在此領(lǐng)域獲得相應(yīng)技能呢？

為了回答這些問題，就云開發(fā)的現(xiàn)狀、推薦工具和反面模式，三位意見領(lǐng)袖進(jìn)行了交流。我們的專家組成員是：

Adron Hall，通曉多種語言的碼農(nóng)和開發(fā)人員布道師。
Magnus M?rtensson，微軟MVP，擔(dān)任瑞典Active Solution顧問公司的云架構(gòu)師。
Andy Piper，熱衷于推動Cloud Foundry的開發(fā)人員。

是不是一位云開發(fā)人員的工具箱相比于普通開發(fā)者會有很大不同？如果是這樣的話，那么在你們看來，云開發(fā)者更依賴于哪些傳統(tǒng)的web開發(fā)者不會使用的工具呢？

Hall：首先我會定義當(dāng)聽到“云開發(fā)人員”這個詞時會想到什么。一名云開發(fā)人員就是負(fù)責(zé)這樣的代碼解決方案的人，解決方案是基于水平擴(kuò)展的、分布式的、冪等的和異步處理，同時具有可伸縮、高度可用和彈性存儲的特點。

我說在回答這個問題時當(dāng)然應(yīng)完全根據(jù)這個定義。一名普通的開發(fā)人員經(jīng)常是在某個傳統(tǒng)的RDBMS數(shù)據(jù)庫的基礎(chǔ)之上構(gòu)建應(yīng)用，在此過程中他會使用某個框架或是其它基于此框架之上的工具，并受到垂直擴(kuò)展的限制。這并不是不好的開發(fā)方式，但是對于云或其它任何可水平擴(kuò)展的環(huán)境來說，以這種方式來構(gòu)建應(yīng)用或服務(wù)效率會非常低。一旦達(dá)到較大物理擴(kuò)展極限，開發(fā)者就完全無能為力了，因為他再也沒有辦法使用任何合理的方式來提升性能。

一位云開發(fā)人員會橫跨廣闊的資源范圍來構(gòu)建應(yīng)用，他經(jīng)常將某個應(yīng)用的功能拆分成更為具體的服務(wù)或模塊。云開發(fā)人員也常需要涉足于某些含有更多語言的工具包，這些語言包括從JavaScript到C#、Ruby或其它語言等。這樣做的原因固然經(jīng)常是出于必要，但在很大程度上也是為了在每個特定工作最適合使用的工具之間提供匹配。

所以，簡而言之，云開發(fā)人員的工具是不同的。
M?rtensson：云開發(fā)人員需要用很多與非云開發(fā)環(huán)境不同的思考方法來武裝自己。較之于其他寄宿（host）選項而言，當(dāng)處于云部署平臺時，你可以很容易地獲取到很多東西。良好的云平臺會提供一個工具集，這個工具集與你可能使用過的相比顯得非常不同。它可擁有“無限的”存儲空間，該空間同時具有自動備份、內(nèi)建的緩存功能、強(qiáng)有力的服務(wù)總線和其他特性。

公平來說，你完全沒有必要僅為了獲得此工具箱而去100%買入云計算。如果需要的話，你完全可以只是使用來自云平臺的如服務(wù)總線這樣的某一項服務(wù)。與任何非云環(huán)境的寄宿類型不同的是，工具箱中擁有更多 “工具”，比如快速彈性、內(nèi)建容錯、故障轉(zhuǎn)移，以及你可以在任何時候按需優(yōu)化費用的完全可度量的服務(wù)等。這些云特點常被引為NIST云計算定義。我認(rèn)為，云開發(fā)人員有非常多的工具待去了解和運用。合適地運用這些工具可以助你構(gòu)建那些以前看起來近乎不可能的、或者即使可能但也是代價昂貴的解決方案。如果這些特性被濫用的話，那么云開發(fā)人員則會冒著失去獲得強(qiáng)大力量的希望的風(fēng)險，甚至于冒著構(gòu)建了更為昂貴的解決方案的風(fēng)險。因為能力越強(qiáng)大，責(zé)任也越多。

最后，如果我們再多談?wù)擖c傳統(tǒng)開發(fā)人員工具，其實對于云開發(fā)人員和其他類型的開發(fā)人員來說，這些工具都是極其一致的。按照我的經(jīng)驗，雖然在 Windows Azure平臺上使用PowerShell可以在云環(huán)境中獲得很多收益，并且也自動化了構(gòu)建和部署。但對于大多數(shù)其他寄宿情形來說，這種做法也可以獲得同樣的效果。我只是覺得在一個像云這樣的內(nèi)在的分布式環(huán)境中這樣做是很自然的。對于任何一個想使用云來讓自己能力更強(qiáng)大的開發(fā)人員，我的建議是去學(xué)習(xí)和了解云計算的真正力量。它們是你的新工具，將會助力你實現(xiàn)從一名傳統(tǒng)開發(fā)者成為云開發(fā)人員的目標(biāo)，你曾經(jīng)為此有過一段痛苦的時光甚至于以前這只能是一種奢望！

Piper：好問題，這也是我一直仔細(xì)考慮的問題之一。Adron在一件事上正確，就是云帶來的是規(guī)模——無論是就數(shù)據(jù)本身而言（同時到達(dá)的數(shù)據(jù)量，或存儲的數(shù)據(jù)量）還是就你如何在云環(huán)境中為了獲得可用性而擴(kuò)展你的應(yīng)用至跨地理位置的多個實例而言。也就是說，雖然很多專為這個新時代而創(chuàng)建的工具和技術(shù)（如Riak和其他的分布式數(shù)據(jù)庫）紛紛出現(xiàn)，并且與以前比工具箱中出現(xiàn)了很多不同的工具，我總是傾向于認(rèn)為，開發(fā)者使用新的云平臺的最重要的一件事，就是忘掉他們過去的假設(shè)——換種方式來思考如何部署應(yīng)用。

給開發(fā)人員提供一致的體驗是構(gòu)建能支持云應(yīng)用的操作系統(tǒng)的目標(biāo)之一。我們寧愿如此簡單：用Ruby或node.js或隨便某個工具來編寫一個簡單 web應(yīng)用，然后本地運行，或者運行在自己的單一服務(wù)器上，亦或運行在一個可縮放的彈性的云環(huán)境中。所以我們構(gòu)建一個抽象層來隱藏不同的云基礎(chǔ)設(shè)施（AWS、OpenStack或無論什么）之間的差異，讓開發(fā)人員能夠很輕松地部署應(yīng)用。這確實意味著他們需要意識到不能依賴于自己應(yīng)用的位置、硬編碼的 IP地址或其他配置，這些都是不好的做法，而應(yīng)是在編碼時應(yīng)盡可能將代碼與數(shù)據(jù)庫（它們有可能會改變）之間解耦。所以思考方式和架構(gòu)都是不同的，不過最起碼很多工具和代碼都可以保持不變。

你們認(rèn)為哪些IDE最適合于云開發(fā)？開發(fā)者應(yīng)為些IDE添加哪些東西來增強(qiáng)其云開發(fā)的能力？你們對基于云的IDE有興趣嗎？

Piper：很個人的說我是有潛在偏見的（作為一個Eclipse提交者），我很喜歡Eclipse，也是IntelliJ和 RubyMine的粉絲。現(xiàn)在大部分成熟的IDE都擁有非常好的插件與云服務(wù)進(jìn)行交互，比如有低級別的AWS Explorer，也有提供了平滑的構(gòu)建/測試/部署體驗Eclipse的Cloud Foundty集成插件。

我曾使用過像Eclipse Orin和Cloud9這樣的基于云的IDE和編輯器，它們都非常方便。我很高興地看到它們演進(jìn)得也很快，從而可以利用的web特性。

當(dāng)然很可能具有諷刺意味的是，我自己的開發(fā)者工具集根本不是以IDE為中心的。我將一天的大部分時間都花在Sublime Text以及命令行上，并且我也是Ubuntu的包管理和OS X的自制軟件開源包管理器的大粉絲 :-)。

M?rtensson：聽到Andy這么說很有趣，因為我有類似的背景，不過剛好相反。我是一個Microsoft/C# /Windows Azure的開發(fā)人員，這使得我在面對IDE環(huán)境和開發(fā)體驗上極具偏見。最近Microsoft在Visual Studio中實現(xiàn)無縫的云開發(fā)體驗上投入的努力是無與倫比的，而這是我在Visual Studio身上前所未見。它們確實做出了巨大的努力來支持快速和強(qiáng)有力的云開發(fā)。Visual Studio中的Server Explorer能夠踏足任何云賬戶并和運行其上的任何服務(wù)進(jìn)行交互。你可以管理它們，監(jiān)控它們，并可以在云上運行類似于IntelliTrace和性能監(jiān)視器這樣的工具。然后你可以下載結(jié)果并在Visual Studio中進(jìn)行分析。很自然地，你能在本地構(gòu)建和測試任何云應(yīng)用，包括最近加入的非超級管理員模式的計算模擬器（Express版本）。隨后你可以將應(yīng)用作為一個單元推送到位于Windows Azure上的自己的網(wǎng)站和云服務(wù)中。我在Visual Studio IDE所見到的用于云開發(fā)的（讀作：Windows Azure開發(fā)）部分在Visual Studio歷史上是無與倫比的。干了這杯Kool-Aid？是??！大口地享受它吧！

Hall：很明顯有至上之選：Cloud9IDE。

雖然如此，在現(xiàn)在很多情況下IDE看起來有所妨礙。當(dāng)某個人需要在具有很多種語言和工具的不同環(huán)境之間切換時，最容易的就是抓到Sublime或類似的某個東西并運行。

在重量級有像Visual Studio、Eclipse、IntelliJ、WebStorm和其他應(yīng)用工具等這樣的IDE。這些都很好，并且為一種或某幾種語言提供了鉤子以方便日常的運維編碼工作。但是有可能當(dāng)某一天快要結(jié)束時，某個不在那個IDE范圍之內(nèi)的語言突然冒出來，那就毀了你這一天。

另外一方面，如果一個團(tuán)隊能夠?qū)Ｗ⒂谀硞€特定IDE，使用它來加載任何開發(fā)所需要的一切，并且IDE能夠和推薦的云環(huán)境協(xié)同工作，那么Visual Studio和其他幾個IDE就會脫穎而出。一個很好的例子就是用于Visual Studio的AWS的.NET插件。這個特殊的插件是我所見過的僅有的沒有將開發(fā)者綁定于實際云的工具集。它只是極大地簡化了部署和查看云服務(wù)，這些都不用離開Visual Studio。對于.NET開發(fā)者來說，這是極大的好處，因為他們總是被鼓勵并習(xí)慣于在云開發(fā)過程中一直呆在一種IDE中。

然而，在大多數(shù)web開發(fā)和云環(huán)境中，你會推送一些東西并使用像SSH這樣的工具。在這種情形中Visual Studio和Windows通常都不是推薦者（non-starter：比賽中不是首發(fā)的隊員）。讓W(xué)indows和Visual Studio與SSH和其他Linux或相關(guān)環(huán)境一起工作所花費的時間會非常讓人沮喪。此時，非常戲劇性的是，像下面這樣做反而容易得多，抓到一個終端，學(xué)會如何擺弄它，然后SSH連接到在這些終端，實際上就可以工作了。即使在使用Windows Azure，如果你并不打算在Windows上寄宿或也不想使用Visual Studio的至Azure的私有鉤子，那么完全可以甩開基于Windows的開發(fā)工具轉(zhuǎn)而使用運行于Linux或OS-X之上的來自于 JetBrains的工具。從這些工具上獲取好處，你的開發(fā)團(tuán)隊最終會感謝你。云畢竟是源自于Unix并將在多年來已成為Unix技術(shù)世界一部分的很多理念的基礎(chǔ)上繼續(xù)演化著。

當(dāng)開發(fā)者在構(gòu)建云規(guī)模的應(yīng)用時，應(yīng)避免哪些反面模式呢？云提供商又如何避免你們犯這些錯誤，或反過來說，讓你們做些錯誤的事情？

Hall：在開發(fā)云分布式應(yīng)用時，開發(fā)者會掉入很多巨大的陷阱之中。

我曾一次又一次看到的較大問題是，他們更愿意搭建單一的數(shù)據(jù)中心（比如AWS，一個區(qū)域等）。使用局限于某個數(shù)據(jù)中心的框架棧和故障轉(zhuǎn)移所構(gòu)建的某個應(yīng)用仍然趨向于引起很多停機(jī)情況，比如“East 1 AWS Failure”，綽號為復(fù)活節(jié)故障。

另外一個很大的問題就是很多提供商——好吧，也許是所有的提供商——仍然還有很多SPOFs（單點故障）。Windows Azure在幾個月前由于其證書問題而打破了大數(shù)據(jù)中心的故障記錄。AWS也出現(xiàn)過由于數(shù)據(jù)中心的某個網(wǎng)絡(luò)設(shè)備而導(dǎo)致的故障。Rackspace同樣也有類似的問題，也鼓勵了人們使用機(jī)架設(shè)備，這又在已有的其他故障點之上生成了更多的SPOFs。整個想法是想讓云架構(gòu)具有彈性，而這些情況適得其反。

從純粹的開發(fā)者角度來看，較大的錯誤在于很容易在云的計算和存儲環(huán)境中只是簡單地構(gòu)建一個傳統(tǒng)的垂直堆疊在一起的應(yīng)用。在云環(huán)境中使用按照傳統(tǒng)架構(gòu) 信條所構(gòu)建的應(yīng)用會付出高昂的代價昂貴，并且效率很低。然而一次又一次，我看到人們只是重新實現(xiàn)某個垂直設(shè)計的應(yīng) 用；Sharepoint，WebSphere和其他所能想到的。他們通常只有單一的RDBMS，在此之上有個數(shù)據(jù)層，以及一個或者可能是幾個應(yīng)用節(jié)點，而這幾個應(yīng)用節(jié)點卻位于某個有著SPOF的緩存層之上。

總的來看，云開發(fā)中有很多反面模式，而運維和開發(fā)總是很容易實現(xiàn)它們。

M?rtensson：一個真正而又常見的反面模式就是將老的思考方式應(yīng)用到新的范式上。比如認(rèn)證；“我們想讓顧客能夠使用他們自己已有的Google，Yahoo！，F(xiàn)acebook和Microsoft帳號來認(rèn)證我們的服務(wù)。當(dāng)然我們也需要標(biāo)準(zhǔn)的用戶名/密碼登錄方式?！蹦銇碚页?其中的缺陷！基本上就是他們說想要設(shè)法變得很時髦，然后又想通過將自己的祖母帶到聚會上來回歸保守。如果這確實是你的開發(fā)和維護(hù)工作所要關(guān)注的，當(dāng)然你可以運行并處理自己的用戶名/密碼認(rèn)證服務(wù)。但如果你正在采用所有的方式來外部化自己的應(yīng)用的認(rèn)證，那么就需要通過將自己寄宿的認(rèn)證服務(wù)（術(shù)語也稱為安全令牌服務(wù) STS）從你的應(yīng)用中分離出來，然后才能真正實現(xiàn)這些方式。簡而言之，你的應(yīng)用不應(yīng)關(guān)心任何認(rèn)證。然而它應(yīng)擁有一個可信任的、為你處理這個多帶帶的關(guān)注點的標(biāo)識符提供者。如果你不保存密碼，則你根本不用保留此職責(zé)。最開初的表述是害怕由于不提供的標(biāo)準(zhǔn)的用戶名/密碼認(rèn)證選項從而失去顧客。但這只會增加你的工作負(fù)荷，并且你將會失去使用云服務(wù)進(jìn)行外部化認(rèn)證的好處。如果你不能公正地對待這種新的模式，除了在開始就以完全錯誤的方式來使用它這種壞處之外，你最終還將會損害自己的業(yè)務(wù)。

Piper：好吧，說到現(xiàn)在我已經(jīng)很難在Adron和Magnus所闡述的常見反面模式之外再添加其他內(nèi)容了——這些我都見到過。有個很明確的傾向就是以傳統(tǒng)的方式思考并構(gòu)建垂直而不是水平擴(kuò)展的應(yīng)用。在這樣的情況下，當(dāng)一個開發(fā)者“發(fā)現(xiàn)”像RabbitMQ這樣的異步消息傳遞和像 Redis這樣的內(nèi)存中的數(shù)據(jù)結(jié)構(gòu)，然后想到，哦，這是一種“全新”的做事方法時，我總是很吃驚。不，完全不是，這些概念已經(jīng)出現(xiàn)了很長一段時間，而云平臺比曾經(jīng)任何時候都提供了一個冪等的、最終一致的服務(wù)模式。

在云提供商如何幫助你避免失誤方面，就我自己來說，Cloud Foundry盡了其較大努力盡可能地來提供作為其環(huán)境一部分的有用配置信息，所以你可以編碼來從配置信息中去查找值而不用硬編碼端口、數(shù)據(jù)庫設(shè)置等。這并不妨礙你硬編碼，但是這樣做確實不是一件好想法。

Redmonk的Stephen O’Grady曾經(jīng)說過“云計算的最重要特征：進(jìn)入的低門檻。”你們認(rèn)為哪些云對于開發(fā)人員來說學(xué)習(xí)會更容易一些？不僅只是讓開發(fā)者注冊，而且還向開發(fā)者展示了該如何開始部署應(yīng)用這些方面，誰工作做得好？對于開發(fā)人員仍然還存在哪些進(jìn)入門檻？

M?rtensson：在瑞典我們說“"tala i egen sak”，意思就是說你是偏頗地來表達(dá)自己關(guān)于事情的看法。再次說明，我是一名虔誠的.NET/Visual Studio/C#開發(fā)人員。當(dāng)然就會偏向Windows Azure云。仍然……哦！不用暴露我的年紀(jì)，我在這個持續(xù)的消防比賽中已經(jīng)有很好的數(shù)十年的經(jīng)歷，而且我還從來沒有在Microsoft看見過像這樣的事情。也許巧合的是，微軟的云的氣息到來適逢其時？也許只是因為這就是應(yīng)當(dāng)做的？但我還從來沒有在Microsoft身上見過如此致力于推動技術(shù)變遷的情況。并不僅是VB和C#，還有很多。Microsoft為現(xiàn)在的Windows Azure的多種平臺和IDE構(gòu)建和維護(hù)了工具集和SDK。PHP、Java、Node.js、Ruby、Python & Visual Studio、Eclipse和開發(fā)一次并可給很多不同類型設(shè)備發(fā)送消息的能力；這些設(shè)備有iOS、Android、Window Phone和Windows 8。挑選你的毒藥吧！今天誰是對Linux較大的開源貢獻(xiàn)者？是的，這就對了，但是誰又曾知道這些呢？對于那些泡在這個空間的人以及那些知道 Microsoft的人來說，這是一筆非常大交易！這是一個擁抱多元化的全新的Microsoft，并且它意識到許多公司為了日常運營將會使用很多服務(wù)和平臺來構(gòu)建自己的現(xiàn)實世界。這就是我們現(xiàn)在所處的情形，而Microsoft就在這兒。有哪個其他的棧/平臺能匹配這個呢？

Hall：對于任何PaaS（平臺即服務(wù)），進(jìn)入門檻都盡可能如你所能達(dá)到的一樣低。當(dāng)我們深入探討這些時，這會得到一些奇怪的比較結(jié)果。Window Azure據(jù)稱首先是PaaS，然后才是IaaS（基礎(chǔ)設(shè)施即服務(wù)），它以這種方式開始，然后努力推廣它。AWS甚至都沒有提到過PaaS這個詞，即使他們擁有很多提供了PaaS風(fēng)格的單一命令行（某些時候要點擊）部署方式的服務(wù)和特征。而對于其他那些沒有一個明確的PaaS說法的環(huán)境，門檻過多，而且很笨重，并且我覺得不太值得提及。所以對于那些沒有一個合理的PaaS說法的我將會在其他時候再討論。

這帶來了另外一個關(guān)鍵之處，在AWS上實際運行的所有PaaS服務(wù)都是怎么樣的。Heroku、EngineYard、AppHarbor、 AppFpg和幾乎每個Cloud Foundry或OpenShift PaaS服務(wù)都安裝在AWS上。所以很明顯，如果某個應(yīng)用包含了AWS的服務(wù)和AWS提供了PaaS服務(wù)的客戶，那么它在可用性方面就大幅領(lǐng)先于其他人。即使我們回溯并只是看看首批AWS客戶的安裝和使用，這些客戶在使用Beanstalk、EC2或S3，其安裝和使用都極其簡單。簽約、檢查認(rèn)證機(jī)制或類似于通過郵件發(fā)送的編碼令牌，然后安裝好上面所提到的項目之一并啟動，你就已經(jīng)在運行一個應(yīng)用了。

可以說最嚴(yán)重的障礙都在基于Heroku、EngineYard、Cloud Foundry和OpenShift的PaaS中被移除了。在上面這樣PaaS環(huán)境中可以很容易地安裝、使用和部署應(yīng)用，這些恰好都是位于AWS中。

但是對于Windows Azure，Windows Azure團(tuán)隊和努力將這些云選項從一個“不”移動到“嘿，這是非常容易的且功能豐富的”。 Windows Azure，我不會再為回答這個問題而談?wù)撈溥^去，它已經(jīng)戲劇性地重新定義了如何更貼近部署，并積極地比幾乎其他每一個PaaS或IaaS服務(wù)提供商提供了更多的部署選項和部署能力。另外其已轉(zhuǎn)變?yōu)槎嗾Z言的，在這場由AWS扮演兔子的龜兔賽跑中獲勝。比如AWS節(jié)點Beanstalk功能。在 Windows Azure能夠極為容易地、優(yōu)雅地和極好地在AWS上部署基于Node.js的應(yīng)用差不多一年之后，AWS才實現(xiàn)。加上它可以圍繞Node.js來定價，對于小型的共享的云寄宿模型來說，.NET、PHP和其他的應(yīng)用已經(jīng)為零。這對于開發(fā)者來說當(dāng)然非常棒，他們可以在運營之前測試、調(diào)試大多數(shù)的應(yīng)用。

總的來說，上面幾乎涵蓋了我個人所使用和一直關(guān)注的主要提供商的基本內(nèi)容。Windows Azure、AWS、Cloud Foundry、OpenShlft、Heroku、EngineYard都是現(xiàn)在值得關(guān)注的主要公司，它們正在這個空間內(nèi)做著繁重的創(chuàng)新工作，并正在逐漸地前進(jìn)以移除更多的進(jìn)入門檻。

Piper：我喜歡Redmonk的這些家伙！他們都是非常聰明的人，并且我推薦那些任何不熟悉他們意見的人去尋找他們。開發(fā)者都是新的擁護(hù)者。

所以，是的，我完全同意進(jìn)入的低門檻對于開發(fā)人員快速采用我們所討論的云技術(shù)來說非常重要。實際上，這就是某個“啊哈時刻”，這可以讓我從自己以前在IBM的角色轉(zhuǎn)換到VMware的Cloud Foundry上來——本地編碼應(yīng)用的能力，無需任何改變地將其推送至云上，然后在幾秒鐘內(nèi)將其擴(kuò)展。鑒于我的角色，不用想就我可以說，很明顯，Cloud Foundry進(jìn)入門檻很低……但就如Adron所說，我想很多相似的PaaS提供商都是這樣，如Heroku。我同樣對為所見過的在Visual Studio和Azure環(huán)境中開發(fā)者所展示的工具集成所驚嘆，在這個環(huán)境中開發(fā)者會覺得走向云的旅程十分愉快。我應(yīng)該指出的是，很多云提供商，特別是 PaaS提供商也擁有工作得很好的IDE插件。然而對于真正地低進(jìn)入門檻，我仍然喜歡源自于Github命令行方式的克隆，本地構(gòu)建和測試，然后從命令行推送至云的體驗， Cloud Foundry和幾個其他云提供商都提供了這種——這比需要一個IDE更輕量級。

對于開發(fā)者來說哪些事情在過去曾經(jīng)是很難的，而現(xiàn)在由于云變得簡單多了？而且，有沒有某些事情在過去是簡單地忽略掉或者根本不做，而現(xiàn)在變得簡單明了的？

M?rtensson：這是一個大局觀的問題。當(dāng)我們開發(fā)時什么是重要的？我們會在某一天回憶起云之前的“黑暗時代”并問自己在那個時代我們是曾經(jīng)如何讓一切運轉(zhuǎn)起來的嗎？構(gòu)建一個全球可伸縮的供幾十萬甚至上億用戶使用的解決方案確實不是我們大部分人都曾經(jīng)做過的。但是我們確實可以做到這一點。如果我們業(yè)務(wù)比像Facebook那樣構(gòu)建自己的數(shù)據(jù)中心要小得多的話，那么能有機(jī)會看到過自己能做到哪一步嗎？如果有一個了解了云平臺的力量的像樣的架構(gòu)師的話，我就敢說再開發(fā)這樣的解決方案甚至都不再是什么難事了?，F(xiàn)在沒有新成立的公司會說“好吧，我們現(xiàn)在獲得一筆風(fēng)險投資，讓我們出去采購一些服務(wù)器回來。”如果我們展望未來并設(shè)想我們開發(fā)將會所使用的環(huán)境，我確信CPU的能力、內(nèi)存的大小、存儲容量、甚至互聯(lián)網(wǎng)的速度對于我們構(gòu)建應(yīng)用的方式的重要性會越來越小。相反我們會開始依賴于總會有足夠的容量給我們正在做的無論什么東西，以及能滿足我們的服務(wù)所要求的無論什么樣的使用模式的需要。當(dāng) 然事情在未來仍然會出現(xiàn)中斷，并且某些時候服務(wù)會出現(xiàn)故障。但不應(yīng)會出現(xiàn)這樣的情形，即我們不得不恐慌地沖到市中心去買一個全新的硬盤驅(qū)動器。我們的服務(wù) 將會是自愈的。在這個大局觀中我們會使用新的模式來開發(fā)，這些模式從開始就會把所有這些問題都考慮進(jìn)來，而且我們從來也不會再關(guān)心是否擁有足夠的計算能力。

Hall：我將建議的是排在前三名的事物：

已經(jīng)影響到開發(fā)人員能如何來開發(fā)的較大的影響是能力，即僅需在這兒或那兒點擊一些選項或某個腳本就可以讓整個運行開發(fā)環(huán)境跑起來。服務(wù) 器、測試服務(wù)器、UAT服務(wù)器等。在以前，即使在簡單的虛擬化下這些在很多方式上都會受到限制。但是現(xiàn)在，在擁有AWS、Azure以及其他類似云環(huán)境所提供的云計算能力的情形下前面那些都完全不再是問題。以前需要耗時幾小時或幾天甚至幾個月的事情現(xiàn)在幾分鐘之內(nèi)就可以完成，并且以一種能向前移動并保留全部努力的方式工作，而這種方式在6-7年前完全無法想象可以這樣做的。

跨地理邊界的分發(fā)系統(tǒng)的能力，這在6-7年前，即便不用花費數(shù)百萬美元資本投資，也會需要數(shù)十萬。現(xiàn)在每個月僅只需要幾百或幾千美元，一個龐大的、跨越廣為分散的多個國家的分布式系統(tǒng)在幾分鐘之內(nèi)就可以安裝并運轉(zhuǎn)起來，并準(zhǔn)備好投入使用。

與垂直疊高的方法相比，分布式系統(tǒng)正在成為普遍的做法。隨著這種改變，隱藏在冪等、彈性、自愈、異步、可伸縮、高度可用性系統(tǒng)背后的思想在大大小小公司的絕大多數(shù)程序員中出現(xiàn)。隨著越來越多的開發(fā)者轉(zhuǎn)向水平擴(kuò)展的做法，垂直擴(kuò)展背后的極端受限的設(shè)計逐漸地被扔到路旁。隨后一系列很多用來增強(qiáng)利用這些功能的能力的語言和框架應(yīng)運而生。這種觀念模式和方法的變化一直在持續(xù)進(jìn)行著，并日益增強(qiáng)著云計算的能力。

……這就是在我腦袋中立刻能想到的排在前三的最重要的事物?，F(xiàn)在已經(jīng)發(fā)生那么多的變化，獲得了很多的進(jìn)展，以至于關(guān)于這個話題有人能寫一本書了。

Piper：對于開發(fā)人員來說，云讓哪些變得容易呢？

按需的、潛在的可自由支配的環(huán)境。實際上，像Vagrant這樣的本地工具還一如既往是開發(fā)者的朋友，但是能快速提供和千篇一律的克隆環(huán) 境以及能以通常很小的代價運行這些環(huán)境的能力也極具價值。這對于開發(fā)和運維活動一直是巨大的推動力——開發(fā)者不用再面對運營維護(hù)者的突發(fā)奇想，開發(fā)者曾經(jīng) 得去為他們提供新的環(huán)境。這并不是為了敲打運營團(tuán)隊——新的云工具和環(huán)境也為他們提供更多的敏捷性。“作為服務(wù)”是*aaS縮寫的關(guān)鍵部分。

可伸縮性、可用性、彈性。我想Magnus和Adron對這部分已經(jīng)說得很好。在這里除了將它們歸結(jié)為這三原則之一之外，我無法再補充什么了。

我認(rèn)為有兩件事——“大數(shù)據(jù)”和“物聯(lián)網(wǎng)”——因為云的可用性在很大程度上變得更有能力。垂直擴(kuò)展的大數(shù)據(jù)庫這許多年來已經(jīng)成為可能，但是具有海量存儲容量、復(fù)制、MapReduce等特性的分布式數(shù)據(jù)庫更傾向于與云聯(lián)系在一起。傳感器的連通性、數(shù)據(jù)的采集和對數(shù)據(jù)的響應(yīng)一直以來都是只以單點為基礎(chǔ)，但是現(xiàn)在的開發(fā)者已經(jīng)可以構(gòu)建復(fù)雜的能實現(xiàn)自己想法的系統(tǒng)，使用云結(jié)構(gòu)的靈活性構(gòu)建的系統(tǒng)只有零或很少幾個故障點。

上面只是一個快速總結(jié)。這是一個技術(shù)演變具有深遠(yuǎn)影響的領(lǐng)域。

雖然很多開發(fā)人員都開始花費大量的時間來開發(fā)云應(yīng)用，現(xiàn)實是還有很大一部分開發(fā)者在其日常工作中都沒有理由去接觸云。假定這部分開發(fā)者沒有充足的自由時間來體驗云環(huán)境，那么你們會推薦他們做什么以便與的云服務(wù)和戰(zhàn)略與時俱進(jìn)？你們自己又是怎樣跟上這種不停向前流動的云空間的呢？

Hall：對于那些沒有接觸過云/公共云或剛出現(xiàn)的私有云的開發(fā)者來說，我發(fā)現(xiàn)兩種很有用的方式非常重要。

學(xué)習(xí)一般的分布式系統(tǒng)。這些包括分布式數(shù)據(jù)庫、分布式計算（網(wǎng)格計算等）、通過自動化或大量其他選項進(jìn)行的跨分布式環(huán)境的網(wǎng)絡(luò)管理。這段時間也出版了很多書籍，這些都能在這上面給予他們很多幫助，因為很多工作都已經(jīng)極大地學(xué)術(shù)化了（對那些實際上正試圖利用分布式系統(tǒng)的編碼人員或運營人員并不是很有用），但其中很多東西在日常的開發(fā)和運營中基本上沒用。

當(dāng)這樣做有用時候，盡量嘗試在日常的開發(fā)過程中小規(guī)模地引入它們。即使沒有用到云，從分布式角度而不是垂直式角度出發(fā)來構(gòu)建某個系統(tǒng)也可以擁有強(qiáng)有力、有用性和健壯性這樣的特性。下面就是我這段時間來一直堅決鼓勵的一個做法的要旨：除非應(yīng)用只是臨時性的，否則請不要開發(fā)純粹的垂直式應(yīng)用。如果某個應(yīng)用的期望生命周期超過一年的話，那么請按水平擴(kuò)展的、可伸縮的架構(gòu)來構(gòu)建該應(yīng)用，這樣它在一個分布式系統(tǒng)環(huán)境之中也能很好地工作。

M?rtensson：向云邁出第一步很容易。首先我想提醒的是較大的問題是，從廣泛和普遍采用云計算方面來看，我們目前處于哪個位置？我是一名云計算的倡導(dǎo)者和忠實信徒，并且我真的很想相信現(xiàn)在我們正準(zhǔn)備促進(jìn)云的大爆炸。這就是說很多即使不是所有的信號都在指著這個方向：培訓(xùn)公司在這上面的興趣在顯著增加，顧問們注意到更多關(guān)于云的喋喋不休，更多的客戶正在激起興趣而提供商的市場份額也在持續(xù)增長。我實在看不到一些關(guān)于正在快速增加地采用云技術(shù)的反面跡象。傳統(tǒng)寄宿選項仍會繼續(xù)掙扎求生并盡一切能力來顯示自己仍是可替代的選項，但在我看來這只是延緩了它們無法避免的命運的到來。特別如果你認(rèn)為混合場景也是一種真正的云場景的話，我想我們應(yīng)也將看到一個快速應(yīng)用需求。如果我們談?wù)摷夹g(shù)采用生命周期，我認(rèn)為我們在甲板上已擁有了早先的采用者，我們正站在深淵的邊緣，深淵將早先的采用者們與其它分割開來。

云平臺的提供商們正在盡力做到很容易就能采用并平滑地過渡到各自產(chǎn)品。比如Microsoft最近對于某些試用場合就取消了信用卡的要求。為了回答這個問題，開始與云計算同行將會實際上已經(jīng)是很容易的了。你不需要花費大量時間來上手。你可以僅僅需用幾分鐘時間來注冊并獲得一個試用的可運行版本。實際上擁有一個已分配給自己的MSDN訂閱的每個人都已在云中有一個個人的開發(fā)/測試環(huán)境。所需要的就是激活MSDN訂閱上的Windows Azure，這大概需要2分鐘左右。大量的在線指南可以幫助你將自己的第一個應(yīng)用部署到平臺。例如我博客上的視頻演示。確實地如果你有15分鐘的話，我敢打賭你肯定能將自己的第一個應(yīng)用在Windows Azure云上正式運行起來。這可能是一件簡單得也許微不足道的事情，但它真的很酷很讓人耳目一新。

Piper：我想PaaS所提供的任何東西都是瞄著提供一個無阻力的部署表面——AppEngine、Cloud Foundry、Heroku、OpenShift以及Azure的涉及PaaS的很多方面等等確實都是這樣。如果在自己所選的平臺上沒有盡力提供一種在其上部署應(yīng)用的簡單方式，那么很有可能你開始就沒有做對。當(dāng)你開始尋找自己應(yīng)用中的可伸縮性和數(shù)據(jù)訪問方面某些問題時，學(xué)習(xí)曲線上仍然還有很多要去學(xué)習(xí)。

個人來說雖然我發(fā)現(xiàn)像O’Reilly這樣的出版社所出版的很多不錯的語言和編程指南書籍常常都有好幾年的生存期，但由于云領(lǐng)域的快速創(chuàng)新，“云” 相關(guān)的書籍顯然還沒有老到有這種火候。只要等待一個月，AWS就會已引入一個全新的API或調(diào)降了價格，某個PaaS提供商就會宣布有了新的合作者、插件或功能！這就是說在博客中挖來挖去并跟隨Twitter上的那些能推薦很好的鏈接的家伙會更有用。我發(fā)現(xiàn)兩個特別的來源是很有價值的。Github活動 feed讓我能跟隨自己的聯(lián)系人所評級或創(chuàng)建的新的項目、apps和庫。DevOps每周簡訊（云和開發(fā)空間的每周匯總郵件）也是一個獲取關(guān)于進(jìn)展的摘要信息的有用途徑。

作者簡介

Adron Hall：軟件架構(gòu)師、工程師、程序猿、碼農(nóng)、分布式系統(tǒng)的擁護(hù)者。他是位多產(chǎn)的開源貢獻(xiàn)者，積極使用Github來貢獻(xiàn)項目。你可以在CompositeCode.Com上了解他的思想，還可以在Twitter上的@adron跟隨他。

Magnus M?rtensson：就職于瑞典的Active Solution顧問公司，擔(dān)任云架構(gòu)師/開發(fā)者。他是Windows Azure MVP、Windows Azure的業(yè)內(nèi)人士、Windows Azure顧問。你可以在MagnusMartensson.com上閱讀其著述，還可以在Twitter上的@noopman跟隨他。

AndyPiper：倡導(dǎo)Cloud Foundry的開發(fā)者。他的日常工作是包含以下內(nèi)容的有趣混合：技術(shù)市場、業(yè)務(wù)開發(fā)、與開發(fā)者交談、各種會議上的公開演講、撰寫文檔和示例、向工程師抱怨其中斷了事情、博客和推特、還有就是組織活動。從這兒可以了解他更多東西，還可以在Twitter上的@andypiper跟隨他。