原文發表於 Backup for Azure Web Sites is now generally available
Azure 網站服務最近有了新的更新——網站的備份還原功能脫離預覽階段，正式對外提供服務。而正式推出後，也會增加一些功能。
首先，備份的部份支援更大的網站內容，同時我們也排除了一些可能會造成備份失敗的狀況，像是備份時檔案被鎖定等等。
而現在您也可以透過預覽的新 Azure 管理介面來操作網站備份及還原的服務，在網站頁面可以看到備份的狀態，並且直接啟動備份的功能。同時也能設定備份的保存時間，而不必手動或自己寫 script 來刪除舊的備份。
另外一個重要的改良是你可以從任何一個備份來還原網站內容，提供更多的彈性。
這些改變將提供您更有彈性地備份或還原您的網站服務。
原文發表於 Azure Mobile Services: why should ASP.NET developers care?
Azure 行動服務為行動應用程式開發人員提供了以雲平台為基礎的後端解決方案，現在這項服務除了可以使用 JavaScript (Node.js) 來客製化後端平台之外，也支援了使用 ASP.NET Web API 的技術來客製後端平台的運算邏輯，所以對於要開發給行動裝置應用程式 API 的 ASP.NET 開發人員來說，Azure 行動服務是相當有吸引力的：
開始使用 Azure 行動服務是很容易的，只要在 Azure 管理後台上建立一個新的行動服務，並且在第一個畫面記得在 BACKEND 欄位選擇「.NET」。一旦行動服務建立完成後，您可以到 Quickstart 的頁面，根據您要開發的行動平台下載一個起始專案來開發。
如果您比較喜歡從 Visual Studio 開始，那也可以在新增一個新的 ASP.NET 專案時，選擇新增 Azure Mobile Service 專案範本，稍後再將它直接發佈到 Azure 上。請注意：這項功能是在 Visual Studio 2013 Update 2 之後新增的。
不論用哪一種方式，都會拿到一個 Mobile Service .NET 的專案範本，同時您也可以發現它其實是一個簡單的 Web API 專案（加上一些 NuGet 套件）。
您可以打開 TodoItemController.cs 這個檔案，在 GetAllTodoitems() 處設定中斷點，這個控制器的程式碼也展示了要如何操作 Azure 行動服務上的資料：
public class TodoItemController : TableController
{
protected override void Initialize(HttpControllerContext controllerContext)
{
base.Initialize(controllerContext);
csharp_testContext context = new csharp_testContext();
DomainManager = new EntityDomainManager(context, Request, Services);
}
// GET tables/TodoItem
public IQueryable GetAllTodoItems()
{
return Query();
}
// GET tables/TodoItem/48D68C86-6EA6-4C25-AA33-223FC9A27959
public SingleResult GetTodoItem(string id)
{
return Lookup(id);
}
// PATCH tables/TodoItem/48D68C86-6EA6-4C25-AA33-223FC9A27959
public Task PatchTodoItem(string id, Delta patch)
{
return UpdateAsync(id, patch);
}
// POST tables/TodoItem/48D68C86-6EA6-4C25-AA33-223FC9A27959
public async Task PostTodoItem(TodoItem item)
{
TodoItem current = await InsertAsync(item);
return CreatedAtRoute("Tables", new { id = current.Id }, current);
}
// DELETE tables/TodoItem/48D68C86-6EA6-4C25-AA33-223FC9A27959
public Task DeleteTodoItem(string id)
{
return DeleteAsync(id);
}
}
您可以看到這裡我們產生了所有的 CRUD 方法來處理 TodoItem，同時這個控制器使用了 EntityDomainManager，它為 Entity Framework 模型包裝了一層，讓您可以很容易地選擇不同的資料來源，像是：
現在 Azure 行動服務支援您可以在本地端進行偵錯（按 F5 執行），啟動的頁面將可以幫助您瞭解 Web API 送出的資料是否正確。按下頁面中的 GET tables/TodoItem 就可以開始進行測試；按下「try this out」的連結，並按下 send，就會觸發程式中的 GetAllTodoItems() 方法，由於剛才已經設定過中斷點，所以就可以在 IDE 裡進行偵錯。
當您完成了 API 的開發，您可以立即從 Visual Studio 中將專案按右鍵發行至 Azure，而不必另外打開 Azure 管理介面來操作。
一旦完成發行，Azure 行動服務便會立刻將您開發的 Web API 上線，同時進行監控。
想要瞭解更多關於 Azure 行動服務的 .NET 支援，可以參考下列文章：
如果您是一個有經驗的 Web API 開發人員，您也許會想瞭解把 Web API 服務放上 Azure 行動服務有什麼好處？下面舉出了一些好處：
當您開時使用 Azure 行動服務打造應用程式時，您會發現 Azure 行動服務提供了許多有用的功能，這些功能可以為您省下好幾個禮拜的開發時間。
在企業系統的開發上，.NET 是很常見的開發平台，所以在 Azure 行動服務支援 .NET 程式語言後就有更多與企業系統結合的機會，您可以參考這一頁的資訊，看到更多的展示。
除了上述的功能之外，與 Visual Studio 開發工具的整合也是相當重要的，除了可以直接開發、偵錯及發行之外，您也可以在 Visual Studio 中產生像是表格控制器、自訂控制器或是排程工作等程式範本。
同時我們也整合了遠端偵錯的功能，您只要在伺服器總管（Server Explorer）上連結到對應的 Azure 行動服務，按右鍵選擇「連結偵錯工具（Attach Debugger）」，這樣就可以直接在 Visual Studio 中進行偵錯已發行至 Azure 行動服務的程式碼（要是 Debug 編譯）。
另一個很棒的功能是，您可以在伺服器總管（Server Explorer）上使用「檢視記錄（View Logs）」的功能看到 Azure 行動服務上的所有 log，也包含錯誤訊息堆疊等。
我們衷心地希望這些新功能會吸引您在下一個專案來試用 Azure 行動服務。如果您有任何意見或是建議，歡迎透過 Twitter 連絡 @theYavor。
原文發表於 Migrating Azure services to new regions
最近我們接到了需要將資料中心從美國中南部移到美東的客戶需求，該工作包括計劃一個適合的 SKU，以及有效利用地理複寫 (Geo-Replication) 的高可用性和可回復性。
客戶試圖整合他們 Azure 服務，並遷移之，其中最重要的需求是資料庫的預期停機時間，他們希望停機時間越短越好，不可超過6小時。
客戶概觀
此客戶是個社交手機遊戲 (可按地理位置搜尋) 的開發商，該遊戲存有世界各地知名的城鎮，玩家於遊戲中會選擇他們所在的地理位置。
計畫
從計畫的角度來看，我們考量了多個選項。這些都不是特別長的討論，但值得思考和關注的問題點，且通常都是必要的討論。
該客戶是最重視的是移動性，因此我們必須擁有相當足夠地於經緯度數量。
該資料庫約 35 GB，而其中約 5 GB 的資料被認為是於轉移過程中需保持 online 狀態，其餘的資料則可於 offline 狀態下進行添加。
該資料庫是企業版的 SKU，且並沒有使用任何具體 Azure 功能。
他們可以容忍長達 8 小時的停機時間，但若停機時間可小於 2 小時，是企業及消費者的期望。當然每週有特定的時間點是最適合停機的，因此停機時間控制是一個可被設計的需求。
客戶是成本導向的，但願意瞭解屏除成本考量外的任何方案。
客戶對於 DBCopy 過程是相當謹慎的，並認為資料的 import/export 時間若超過 10 小時，將造成嚴重損失。
計算節點的轉移不是主要考量，也不是迫切地需要將現有的 Blob Storage Data 轉移，解決方案是建構像是 No Cross DC Logic，以便訪問現有的 Blobs。
解決方案包括：
首選是「啟用地理複寫功能」，原因是：
比較值得注意的是，該服務是預覽版，但這被認為是一個容忍的風險。於分析歷史資料後，決定一個 P1 就足以滿足他們的需求。另外不可避免的風險是，複製過程是否會佔用過多資源，但這被視為是特殊事件，畢竟可預期的資源需求不高，故最後還是決定保有 P1，並隨時準備升級到 P2。
於容量規劃過程中，客戶是參考「變更資料庫服務層和效能層級」決定 SQL Azure 資料庫的版本。
執行
客戶必須註冊為 Premium SKU 預覽，這必須通過 portal 花幾秒鐘的時間完成。
一旦簽約，該資料庫可升級到 Premium，請參閱「更改資料庫服務層級和性能水平」。以下公式實際上是相當準確的，預估升級時間為 12 小時：
3 * [ 5分鐘 + 資料庫大小 / (150 MB/分鐘) ]
接下來的步驟是建立理想中的複製區域，即美國東地區，這部分較難預估需要多長時間，也較難預估即將開展的副本所需資源。這些步驟可參考「設定作用中地理複寫 (連續複製)」。
值得注意的是，這個執行計劃是基於程式碼間的部署，若過程是純技術性的，大多於 24 小時內完成。但客戶選擇多等一兩天再執行計畫的下一步，其理由是完成特定程式碼的修改，而發生在現有的拓撲不是在一個新的數據中心。他們關心DDL更改是否會被複製。所有的更改都將被複製，除了於更新主資料庫後必要的更動，像是登入設定等。這些必須在每個環境中進行，而使用者的創建可在 source 完成，詳情請參見「作用中地理複寫的安全性」，將具體說明登入相關議題。
最後一步是切換到新的區域。以下步驟是客戶特別分享的經驗談，提供給未來可能負責此工作的 IT 專業人員們。對於終止作用中地理複寫，可參考「終止連續複製關聯性」一文。
以下為客戶完成此偉大工作後的經驗談：
「轉移非常順利，我們停機約 1 小時，其餘大部分時間是在等待我們的新程式碼部署，配置更新和 prod / staging 的互換。中止 Azure DB 的複製和改變 read / write 模式是相當簡單的過程。」
本文原始發表於 TechNet 台灣部落格
Microsoft Azure 的網站服務可以讓 PHP 網站開發人員架設網站（參考教學課程），如果要在網站系統中使用 Cache 來提升系統效能，可以考慮 Azure 上的 Redis Cache 服務（目前在預覽階段）。
要使用 Redis Cache，目前需要到預覽中的新版 Azure 管理介面來操作，在新增服務的選項中選擇 Redis Cache。
然後選擇要用哪一個訂閱、什麼方案（Basic or Standard）、還有快取服務要用哪一座資料中心（建議與您的服務放在同一座資料中心，以減少網路的延遲）來提供服務。
建立完成後，Azure 需要一些時間把服務建立起來，一旦建立完成便能立即使用，而也可以在管理介面中看到它的一些狀態，可以點開 KEYS 來看金鑰或是 Properties 來看它的設定
點開 Properties 就會看到連線資訊，還有連接埠號碼。
搭配 KEYS 裡面顯示的金鑰就可以來使用 Redis Cache 服務了。
如果您使用 Azure 的網站服務來運作 PHP 網站，要連接 Redis Cache 服務也很容易，只要下面幾個步驟：
在上傳部署套件之前，先到 Azure 網站服務的管理介面上，將 app settings 加一個 PHP_EXTENSIONS 的常數，然後指到擴充套件的位置（如：bin\php_redis.dll 要用 Windows 的目錄表示法），像是這樣（圖為新版管理介面的網站設定，在現在的管理介面可在設定頁籤中找到）：
上面這個 PHP Redis Cache 是使用這個套件，它的連接方式像這樣：
<?php
$redis = new Redis();
$redis->pconnect('您 Redis Cache 的 hostname');
$redis->auth('在 KEYS 頁面中找到金鑰');
#開始使用 $redis 做 cache 操作 ...
您可以在專案的 GitHub 頁面上查詢它的使用方法。
在上個月，我們宣佈支援部署 Docker 上 Azure 虛擬機器上，並且應用我們的技術，讓客戶能夠盡快地使用 Docker 的威力。為了持續為我們的客戶提供更好的支援，我們宣佈將與 Google 及 Docker 合作，預計將在 Microsoft Azure 上支援 Kubernetes 及 libswarm 這兩個開源專案。
Kubernetes 這個專案發表於今年六月份，它是一種「宣告式容器管理解決方案」，原本是在 Google Compute Engine 上管理 Docker 的工具，在 Microsoft Open Technology 於這個專案的 GitHub 專案上的貢獻後，也讓這項工具支援在 Microsoft Azure 的 Linux 虛擬機器上運作。這讓使用 Microsoft Azure 來建置 Linux 虛擬機器的用戶多了一個管理工具的選項。
同樣地，MS Open Tech 也開始貢獻 Docker 的命令式管理工具 -- libswarm 專案，Microsoft Azure 也有了原生的支援，能夠在 Azure 虛擬機器上部署 Docker 容器。
這項宣佈呼應了我們 Microsoft Azure 一貫對客戶的承諾 -- 回應客戶的需要，並且支援多樣的系統、技術及語言（從 Windows, SQL, .NET 到 Python, Ruby, Node.js, Java, Hadoop, Linux, 以及 Oracle ），讓客戶能夠快速在 Microsoft Azure 提供的公有雲服務上建置及部署應用。同樣我們也持續打造 Microsoft Azure 為開放的平台，如同最近宣佈支援的 Puppet, Chef 及其它開源專案一樣。在 Microsoft，我們一向看重與開發人員、合作夥伴以及客戶在複雜 IT 環境的需求，也期待能從您的需求中瞭解什麼對您是最重要的事。