portal.azure.com這個網站是怎麼做出來的？

這個控制台可是甩了阿里雲100條街（阿里雲有模仿azure的意圖）

自己開發這樣的一個網站難嗎？

這東西做了好久了，前幾個月宣布的GA，舊的http://manage.windowsazure.com也要退休了，雖然我還是沒有習慣使用新的portal。

我並不是portal部門的，所以我的答案並不權威也有可能有很多錯誤。不過我們部門也在裡面做了某個組件的UI（Data Factory裡面的），從我們組的同學們的反饋來看，新portal的技術含量是要遠超舊版的。它解決了一個重要的問題：各個Azure的不同組件部門，如何協作迭代開發一個統一的前端網站。

要知道，Azure現在大大小小的組件怎麼也有三十多個了，每個組件都需要在portal有一定的UI，而且每個組件都在不停地做自身的迭代，也就需要不停地更新它的UI。

首先，不可能建立一個專門的團隊給所有組件做portal，因為不同的組件的領域知識太專業了，溝通成本太大。所以每個組件是自己做自己的portal部分。那麼，自然出來一個問題：如何協調發布？以前的做法是每個組件各自做自己的後端服務，這個大家沒有依賴關係，但有一個專門的code branch放所有的前端代碼，大家通過RI來把自己的代碼放進release裡面。自己後端的服務，你隨時都可以自己更新；但是前端是一個統一的網站，那麼自然大家都需要跟著統一的release的步伐來走，如果錯過一個release就得等下一次，哪怕你只改了很少東西。

新版的框架裡面，不同組件的「前端邏輯代碼」，並不是放在同一個代碼系統及發布單元裡面，而是直接放在各自所搭建的webapi服務裡面，自己獨立開發發布及運維，在瀏覽器中運行時才把不同服務中的內容通過龐大的javascript邏輯和Ajax整合在一起呈現給用戶。核心部分就是這個由portal團隊開發的框架，它本質上可以說是一個完整的開發平台了，甚至有點像一個操作系統，和在上面的組件之間的耦合很弱，不需要把代碼放在一起，也不需要把伺服器端放在一起。

這樣的好處不言而喻，不需要通過一個統一的大範圍的portal release來上線某個組件的新功能，一個組件隨時可以通過更新自己的獨立webapi服務來改變其行為。比如像我們部門做的那個組件，從code check in到上線只需要2小時左右，而在此之前這個時間可能是一個月。

當然我不是搞前端技術的，所以並不能確切回答這裡面所使用的技術，比如具體怎麼解決cross site的各種問題的。有興趣的同學可以研究一下。