們在企業(yè)IT中所做的一切都應(yīng)該能夠提高敏捷性。為什么? 因為未來是通過技術(shù)創(chuàng)新來定義的，而且這些創(chuàng)新發(fā)生的既快速又激烈。因此，我需要確保我的系統(tǒng)、流程、技術(shù)和領(lǐng)導(dǎo)能力更加敏捷，易于改變。 這就是我今天的主題——OpenStack。OpenStack已經(jīng)存在了很長時間。更重要的是，OpenStack是一種旨在幫助我們獲得敏捷性的方法的早期表現(xiàn)。在OpenStack出現(xiàn)后的幾年中，其他人也創(chuàng)建了OpenStack的替代方案，但它們都是類似的：利用通用硬件，開放標(biāo)準，虛擬化和編排工具來實現(xiàn)流暢，便攜和完整的服務(wù)(計算、存儲和網(wǎng)絡(luò))。憑借流暢，便攜和完整的IT服務(wù)，我們可以根據(jù)需要，靈活地規(guī)模化地轉(zhuǎn)移和修改我們的服務(wù)。

如果我們想要在技術(shù)驅(qū)動的市場中生存和發(fā)展，這些是我們需要的能力——不，是必須具備的能力。

為什么選擇OpenStack

我來分享我的OpenStack故事。幾年前，我們對我們的技術(shù)產(chǎn)品和服務(wù)進行了現(xiàn)狀檢查。事實是，我們意識到要改變我們的IT服務(wù)，很難，也很緩慢，因此使用成本很高。我們的一些客戶則采取實際行動，尋找替代我們服務(wù)的方案。

在這個反思中，我們設(shè)定了一些積極的目標(biāo)。其中一個目標(biāo)是我們可以每天都完成部署。在開始之前，我們詢問了一系列“什么是必須的”問題，才能達成這個每日部署的目標(biāo)。

我們最明顯的“什么是必須的”答案之一是，我們需要利用基礎(chǔ)設(shè)施即服務(wù)（IaaS）和平臺即服務(wù)（PaaS），從而實現(xiàn)可擴展，靈活的IT運營。IaaS和PaaS平臺的一個重要要求是對容器的支持。 為了避免供應(yīng)商鎖定， 我們選擇OpenStack作為我們的IaaS框架。（Cloud Foundry是我們PaaS的框架，Docker是我們的容器技術(shù)。）

現(xiàn)在，完成一個主要的架構(gòu)和平臺的改變不是輕而易舉的——從我們傳統(tǒng)的方法遷移到IaaS/PaaS的方法意味著很多的工作和重構(gòu)——所以我們花了大量的時間研究我們的選擇，并進行了一些概念證明項目。事實上，我們很謹慎，我們實際上花費了幾個月運營了兩個競爭的PaaS技術(shù)，這樣我們可以通過實驗，找到更適合我們目標(biāo)和需求的技術(shù)。

一旦確信不會犯下嚴重的錯誤，我們開始了為了適應(yīng)OpenStack框架，推翻舊方法的，具有挑戰(zhàn)性的流程。

我們從OpenStack/Cloud Foundry的一個可用的實施開始。（與Linux一樣，你可以完全開放源碼，也可以從多個供應(yīng)商中選擇支持的版本）。但是，隨著我們對于OpenStack框架的知識和經(jīng)驗的增長，我們發(fā)現(xiàn)了一些問題，會造成職責(zé)分離（這對于SOX、SOC 2和其他合規(guī)性標(biāo)準至關(guān)重要）。 我們開始修改我們自己的版本，其中包括我們創(chuàng)建了一些技術(shù)來更好地處理應(yīng)用級安全性和數(shù)據(jù)訪問控制。

請記住，我們對于OpenStack和Cloud Foundry框架的采用和挑戰(zhàn)，是我們變得更敏捷，更靈活的總體規(guī)劃的一部分。為了獲得敏捷性，我們需要一個“Lego”模型，包括為我們編寫的軟件提供一個以微服務(wù)/ API為中心的架構(gòu)。 當(dāng)然，我們一路走來也犯過錯誤。

我們做的一些技術(shù)選擇，其結(jié)果太過于限制（一種技術(shù)創(chuàng)造了API瓶頸）；我們早期選擇中的另一項技術(shù)還沒有完全成熟。但是，由于我們使用了基于標(biāo)準的工具和框架，并且都松散耦合，所以進行恢復(fù)，然后再前進并不困難。

事實上，我們對敏捷性的追求完成的很好。我們并不需要每天進行部署，但是我們能這樣做的能力是我們敏捷性的標(biāo)志。我們還是會偶爾尋找OpenStack框架的替代方案，但是還沒有找到一個令人信服的理由進行轉(zhuǎn)換。

對于那些還沒有采用OpenStack的人，我的建議是做一個測試，探索OpenStack方法能為你做些什么——風(fēng)險相當(dāng)?shù)停绻m用于你，帶來的好處則是巨大的。