2015 年 10 月
第 30 卷，第 10 期
本文章是由機器翻譯。
Microsoft Azure - Microsoft Azure--概觀
由 Tony Meleg |2015 年 10 月
每個月，這份雜誌探究一些新的或有趣的服務在 Microsoft Azure 的詳細資料。沒有永無止盡的資料流的開發人員顯然必須的知道有關，但在相同時間混淆所有不同的方式完成相同的動作。它並不容易將這些片段全部放在一起並查看 「 綜觀全貌 」。 目前遇到業界的創新的腳步失敗的全貌呈現類似的 IT 從業人員及 IT 組織的真實挑戰。其實這篇文章的重點幫助您的 Azure 而不深入探索任何特定的服務 — 我們通常執行的相反。
老實說，開發人員不一定很擅長讓複雜的事情更簡單。通常我們一些簡單的問題並實作非常複雜的解決方案。我們必須了解如何運作、 特別的東西我們沒有建立自己。這是部分信任的問題，但它也讓我們了解如何調整和微調我們的特定需求的軟體元件或整個。它是控制項的功能，以及。
Microsoft 的大首選
如果您不打算像我們即將告訴您接下來則，環 a bell 有關開發人員我判斷提示。Azure 是提供您可能在您想要建置的應用程式有時需要的不同功能的每個應用程式的建置組塊或 「 服務 」 的集合。Microsoft 認為這些區塊應該是原本就是彈性、 高度可擴充和自我管理。您可以佈建世界各地的任何服務、 支付僅適用於您的使用及最重要、 能夠隨時隨地變更您的耗用量。以下是您不喜歡的位元： 這些服務能夠運作。它們抽象您遠離複雜度。您不需要很大的控制權。您無法看到在它們。換句話說，您必須只信任它們。聽起來像是一些您可能會想要的、 不會，因為您想控制，您不 「 信任 」 和您喜歡複雜度嗎?
您可以大致劃分 Azure 三個層級 — 資料中心基礎結構、 基礎結構服務與平台服務中所示 [圖 1。
.png "Microsoft Azure 的概念檢視")
[圖 1 Microsoft Azure 的概念檢視
您應該將這三層為堆疊在彼此之上與每個圖層的下一層的抽象概念。因此，基礎結構即服務 (IaaS) 是主要的抽象基礎實體伺服器、 儲存體和網路。平台即服務 (PaaS) 是應用程式的軟體基礎結構就像通常在伺服器上安裝和使用當您建立應用程式，例如 Web 伺服器、 資料庫、 郵件系統和身分識別基礎結構的抽象。是服務的工作不提供此軟體，但讓您了解整個執行、 彈性、 間斷的服務 (及監視並沒有略過任何您應用程式無障礙地修正任何問題幕後工作)。
在 Azure 公用雲端，不僅任何地方使用這些服務。這可能是您的資料中心、 主控件或外包。Microsoft 最近宣布 Azure 堆疊來進行這項作業 — 認為 Azure 般簡易性與服務封裝和部署這在您自己的硬體上。畢竟它是只是 Windows Server 和 HYPER-V 的核心基礎上建置的軟體。在這個新的世界裡，不過您根本不在乎因為您的焦點是只針對您所需的服務、 適當地將您的方案架構設計人員以及如何對服務進行程式設計。
平台建置組塊
讓我舉概略了解所有 Azure。[圖 2 配置一組分散的基礎結構服務和平台服務的功能群組中的所有服務。您應該將基礎結構服務為這些功能可讓您建立的現有應用程式的低層級基礎結構。您需要有磁碟; 的電腦您需要網路它們在一起。您需要共用的磁碟。而且您需要將它們連接至其他系統與網路中其他地方等等。
.png "Microsoft Azure 服務")
[圖 2 Microsoft Azure 服務
在基礎結構服務層級較熟悉的抽象概念是因為它們代表基礎的實體資料中心，例如虛擬機器 (VM) 與您連接至機器的虛擬磁碟的表單中的電腦。這可讓您執行的系統您已經有而因為只有一個抽象概念是不可能使用的應用程式軟體的電腦目前執行的相同方式執行動作。它仍然是您必須負責安裝、 管理、 修補、 修正和進行復原您在執行中或跨一組連接網路的任何的 Vm 軟體如同您今天在您自己的資料中心。
平台服務相較之下，牽涉到功能的距離利用您從較低的層級的電腦/儲存體/網路服務。所有抽象遠離您的。一般而言，如果您無法實際接觸或連線至基礎中特定的服務、 VM 的服務都是 PaaS。此外，您不可以選擇提供服務的軟體，且未收到微調或控制該軟體。它是服務作業來運作、 修正和修補程式本身以及監視服務跨所有 Azure 資料中心所需的所有部分。您可以專注於只會使用它 — 這其實是您的工作是，還是。
順道一提 — Azure 資料中心基礎結構
您可能有興趣，因為我們其實所有的基礎複雜運算和資料中心基礎結構提供 Azure 中的所有電腦玩家。您可能想要了解實體硬體規格的伺服器使用何種參數，機架的建置方式。您可能想要了解複雜的網路拓樸超級快速一致的速度提供跨所有服務和全域網路連接在一起的 Azure 資料中心區域。或許您感到好奇所有 Azure 所在現今世界各地的 24 資料中心區域 (或您很快會如在加拿大和印度的五個新區域上線) 中所示 [圖 3。
.png "全域的 Microsoft Azure 資料中心耗用量")
[圖 3 全域 Microsoft Azure 資料中心耗用量
這是您第一項測試身為開發人員在新的世界中： 您必須先停止至少關懷相關的資訊，在 Azure 中。如果您想要建立您自己"Azure"在您自己的資料中心與 Azure 堆疊，然後您 (或您組織中的某個人) 仍然必須負責所有這些實體的情況下。您必須負責在過去，甚至是關於特定應用程式所需的基礎結構的原因之一是因為出錯的成本太高。您永遠不會真的知道的數量和大小的伺服器所需。您假設最糟的可能案例並將它們加入更多，以防萬一。在 Azure 中，因為如果您需要更多的項目只佈建多個不存在這些問題。如果您需要更大的機器，您會取得一個;如果您收到太多，您只是將它變更。在 Azure 中，您只需要找出您的應用程式的使用者、 哪些是最佳的資料中心使用來提供解決方案。通常它是一個最接近。
基礎結構服務 — 更多的控制、 更多工作
當您檢視在 60 個服務之間 [圖 2, ，它是個令人困擾的清單。但大部分的應用程式建置，大部分的情況下，包含只有幾個功能。通常是 Web 伺服器和關聯式資料庫在核心、 加上一大堆的身分識別、 報告以及或許某些批次程序的其他項目。讓我們把重點放在 Web 基礎結構和資料庫現在。
Straightaway，您可以進行選擇： 您工作的基礎結構或平台層級的抽象嗎? 轉動一些 Vm、 安裝網頁伺服器和資料庫並持續進行的是取得您嗎? 請記住，這個抽象概念是主要的相關的實體伺服器、 存放區/磁碟和網路但不是需要在這些伺服器上執行的軟體。簡單的聲音聽起來很熟悉，和 — 您猜怎麼著 — 它是。它是完全您不要完成整個職涯。看看 [圖 4。VM 有虛擬磁碟和這些可以共用跨 Vm 或連接至特定的機器。Vm 可以放在虛擬網路讓彼此能夠通訊及網路可以連接到您自己的資料中心以及跨越 Azure 地區。這所有透過此軟體抽象和就表示您得到有一或多個磁碟並連線到其他電腦的網路上的電腦。
.png "虛擬機器的伺服器、 磁碟和網路的抽象概念")
[圖 4 虛擬機器的抽象層的伺服器、 磁碟和網路
裡面的所有一切所需的 Vm 組，就可以控制和微調和調整和更動。事實上，它會更佳比您自己的內部世界裡，由於抽象概念。您不在意了實體機器、 主機作業系統、 hypervisor。您不必擔心的虛擬磁碟基礎的存放裝置基礎結構的彈性。沒有幾乎很驚人組的 VM 大小 (不同組合的 CPU 和 RAM、 不同的磁碟大小和速度的網路頻寬與) 的選擇。
最好還是它是所有自我服務，而且所有項目可以非常輕鬆地定義需要和組織數百個具有簡單的指令碼的執行個體的基礎結構是自動化。
讓我們假設您的應用程式需要適當的層級的延展性和彈性。很容易建立 Vm 的 Web 伺服陣列與 Web 伺服器與建立資料庫叢集。您知道 (或 IT 專業人員最好的朋友知道) 如何執行這項操作 — 它並不容易但可行。也可以在任何時間白天或晚上。您可以提供任何位置世界;您只需支付您使用和隨時都可以改變了主意它清除所有及支付完全沒有。您說高不高明？ 但是聽起來太好是 true，那麼是什麼附帶條件？
在基礎結構層級的 catch 是您仍然必須執行很多工夫來部署和執行的所有內容。它所有執行之後，您必須執行更多工作來讓它保持執行。沒有說明，不過特別為 「 取得它執行 」 部分，衍生自內部世界是部署一組複雜的相互關聯的 Vm，例如 Azure 資源管理員和透過 Windows PowerShell 自動化 Azure 以及其他許多協力廠商的解決方案包括功能甚至更麻煩。一旦所有工作，您仍然必須修補您使用 Vm，包括您執行任何作業系統內的所有軟體。您必須管理的健全狀況的所有應用程式軟體，這並不是 Web 伺服器和資料庫太困難，但是當您調整這個向外或新增其他五個功能更加困難。
您交易控制針對工作或工作。如果您想控制，您必須精力投入更多心力建置您的需要並讓它所有的工作。
平台服務 — 較少的控制、 較少的工作
您可能記得說 「 就沒問題無法解決加入另一個間接取值層級的電腦科學中。 這是有另一個句子我看過沿著每一行加入至這個 「...但這通常會建立另一個問題。 」
為 true，而且平台服務的絕佳範例。Azure 服務的圖片 [圖 2 顯示為兩個範例中所需的建置組塊的兩個平台服務抽象概念 — Web 伺服器和資料庫。在 Azure 中的這些抽象概念是 (位於 Web 和行動裝置] 區段中) 的 Web 應用程式和 SQL 資料庫 (位於 [資料] 區段中)。您提供這些服務在 Azure 中的佈建任何服務時，前往 Azure 管理入口網站、 選取您想的服務並填寫必要的詳細資料的方式相同： 服務名稱、 資料中心位置、 初始效能/定價層級等等。
以下是就越不控制小於 where 工作事派上用場。比方說一下資料庫。我佈建在北歐資料中心的資料庫。在不到一分鐘，取得完整工作資料庫而且然後我將我的結構描述和資料部署到資料庫以及連結我的 Web 應用程式的工作。沒有任何軟體安裝。我得到什麼結果，這是 SQL 資料庫。事實上，我不只是取得資料庫、 取得三個，所有在高度可用的叢集中一起運作，讓我擁有驚人的彈性層級。我可以只是藉由選取不同的效能層級 (這會變更我需要支付的價格) 向上和向下撥三個資料庫的效能。您無法選擇不將此三向叢集的資料庫。您只是取得它因為服務一定會想要確定它可讓您使用資料庫也是這麼做的最佳方式。
您可以看到在 [圖 5, ，類似的模型中沒有播放當您使用 Azure Web 應用程式的應用程式佈建 Web 基礎結構。您可以選取您想使用簡單的滑桿的執行個體數目。您必須撥打的執行個體計數向上或向下和服務就會執行其餘。您甚至可以告訴系統對您的負載或排程執行這個動作。最重要的是，它是一定要提供您所指定的執行個體計數和來監視和修正損毀的執行個體的服務作業。您的工作只是撰寫 Web 應用程式程式碼並讓它可以確定它們能透過您的執行個體所需的所有地方位元交給服務。
.png "變更 Web 應用程式執行個體計數")
[圖 5 變更 Web 應用程式執行個體計數
因此，平台服務的抽象通常會提供負責佈建、 彈性和管理您的服務的服務。建立一個抽象概念與 「 其他問題 」 是您會遺失一些控制項。您無法選擇 「 軟體 」 和您無法取得"內附 」 和調整或微調從堆疊中一路向上作業系統所用軟體 — 它會給您一個黑色方塊。您會遺失的其他控制項是您要現在鎖定到該服務，以及服務; 的 API 功能也就是如何應用程式程式碼互動的服務。或許您需要特定選項，例如在資料庫中並不提供服務。它可能是特定資料型別或甚至整個像全文檢索搜尋功能。或許您要移動現有的雲端應用程式和您的應用程式中使用的功能不符合 Azure 中服務的能力。您要怎麼辦呢？
Azure 服務建置組塊的圖片 [圖 2 分層至 IaaS 或 PaaS 的所有服務但不認為無法使用這些 」 在一起 」 並且跨越該界限，因為您可以。沒有理由，比方說，您無法使用 PaaS Web 應用程式服務與說的 VM 安裝 Oracle Linux 或在 Windows 上執行的 SQL 伺服器上執行的位置。您現在有控制項與工作之間取得平衡。事實上，您可以將此檔案更進一步。所有這些建置組塊反正在那裡等候可用，因為您當然可以使用它們從任何地方。它只要是簡單的應用程式開發介面或某些現有的通訊協定已經用來溝通這些服務。您可以與您現有的系統使用任何這些區塊在您自己的資料中心。您可以使用這些區塊與其他協力廠商和甚至從其他雲端提供者的區塊。這假設，當然應用程式可以容忍延遲挑戰您可能會引進，但有可能。
其他服務
因此您為什麼需要在 Azure 中的所有其他功能? 如果您看著您自己的 IT 工作室在現今的生產環境中執行的所有應用程式就會發現很廣泛的集合及支援這些應用程式的應用程式軟體 — 傳訊系統、 資料分析功能、 識別基礎結構、 安全性層級、 備份系統、 資料倉儲、 監視和管理系統等等。以下合稱跨整個 IT 產品組合您需要所有此"東西一塊丟掉。 我想要將 Azure 視為一系列"IT 樂高"。 您要建置的下一個最棒的一點，但您需要使用它們全都放在您的工具組您不需要指定區塊的每個型別所有的時間。
您要如何決定您要建置新的方案時所要使用哪一個區塊？ 它是實在沒什麼兩樣比從前 — 您必須了解什麼建置組塊和它們對應到您的應用程式的特定需求並進行呼叫。認知是建置在雲端中的應用程式不同且更複雜。它是兩者都不但是您只因為目前處於 「 共用 」 的基礎結構的基本概念需要一些其他內容。這表示許多服務有條件約束和這些條件約束將會隨著不同的功能等級而有所不同而且價格層您正在使用。您需要知道這些有哪些。請記住，您不想這些是常數。您想要變更您的需要根據應用程式負載和需求。您不必程式依舊這些條件約束，以及做為服務的可用性和回應性。您可以使用相同的工具、 相同的語言和架構來建置解決方案，並以最低層級的所有服務都擁有以 REST 為基礎的 Api 加上特定架構的包裝函式使用。這表示您可以從任何項目都有簡單的 Web 堆疊逐字取得建置組塊 — 像是感應器定域機組的原因而推動暴增的 Internet of Things 解決方案。
在雲端優點是您可以逐一查看快速 (因為很容易運轉上線的服務);您可以嘗試一些其他替代方案。而且您可能會失敗快速且廉價地因為您已經投資很少。回頭看一下 [圖 2。沒有任何項目嗎? 您可能會看到您認為您永遠不需要的圖片中的項目但我相信您會很難尋找並不會呈現某些功能需要或已經有。有很多出可以幫助您、 廣泛的指引以及詳細的實作指南所服務的指引。
它會在大部分的開發人員，若要了解新事物喜好的 DNA。很有您想要玩玩試用新的技術。即使您的公司是永遠不會在想都別想要建立任何項目並將它放在公用雲端，仍然是全球最佳開發人員場地，讓您學習和成長。
因應變化
我想要處理一個的最後一個主題完成前，而且所有有關處理變更。我必須承認，我發現很難掌握所有發生的步調密集遞送在 Azure 中的創新或其有點我跟上它的工作。日子已經過去是當您有三到五年的藍圖會傳遞的特性和功能的天數。近來如果這是六個月您運氣好。您會發現建置東西的過程會出現新的功能，甚至是全新的服務和很容易評估及重構這些到您的方案。也會以一年聲明句號不 10-plus 年支援週期一直都可供伺服器軟體的移除功能和服務。
現在發生服務版本控制，這表示新功能會加入至服務，可能會中斷該服務和建置在其上的應用程式的實作。所以決策都對是否版本，也就是若要建立新的並行所實作。最近這是使用 Azure SQL Database 在 Azure 上。請參閱有關在 Azure SQL Database 12 版在新的文章 bit.ly/1Dcjpo4。
重點是課稅的沒有定域機組中支付的稅金和您需要留意成本的因素。您必須連接到雲端支援/變更通知程序讓您能事先計畫並不會攔截大吃一驚。稅務當然就是變更和成本會更高、 更頻繁比它會在內部。雖然是更大的優點是不要讓放置您關閉。您可以在其中執行作業的速度會更快、 品質就會比較高和您採取的風險會變得很低。
想要進一步了解嗎？ 虛擬活動可讓您聽到 Azure 專家 AzureCon 問答集做為檢視並找出所有最新的 Azure 創新。您可以存取所有封存的會議內容在註冊 bit.ly/1KRD76d。
Tony Meleg是 Microsoft Azure 團隊的技術產品經理。他平常都在建立適用於各種目標群的技術內容、 自編 Azure 並開啟成簡單的概念的複雜性。