2020年9月26日 星期六

導入敏捷最難的是什麼?

enter image description here
『導入敏捷最難的是什麼?』上課時同學這麼問。

『這問題,我可是很有經驗呢。』我心裡這麼想著,然後慢慢的回答…

導入敏捷最難的是…『組織總想在其他條件都不改變的狀況下,實現敏捷轉型。』

我常說:『人人擁抱敏捷,但真實狀況是…沒人想要改變。』

你說,不會啊,我們公司常常改變! 老闆總是朝令夕改…搞的大家無所適從。

我笑著說:『是啊,那是他改變你,不是改變他自己。況且,你不是也不喜歡別人常常改你的工作模式…對吧?』

總之組織從上到下,沒人喜歡『被改變』。

所以,導入敏捷當然可以…但,不能碰KPI、不能違反ISO、不能調整考績與獎金制度、不能改變合約簽訂方式、不能變更HR既定規則、不能調整休假與簽核流程、不能違反愚蠢的勞基法規法條、不能取消既有的公司會議(不管多麼無效)、不能改變組織結構、不能拆分部門與團隊…在所有外界環境都不改變的狀況下,要我們協助導入敏捷…幹的好。

這不是『難』,這根本是『為難』。

但我得說,這才是企業轉型的真實狀況。有興趣『談』轉型的老闆很多,有膽量豁出去的可算是鳳毛麟角,除非…

『除非什麼?』學生問。

除非…那公司差不多快掛了,死馬當活馬醫,這時候老闆可能會破釜沉舟,孤注一擲。但也往往能帶來最好的成效。

這也是大家常常看到,新創和小公司比較容易導入敏捷的關係。在大概超過百人左右的組織中,即便想要在一個小部門中導入敏捷,都很容易碰到與企業規範衝突的問題。

要知道,你可是在跟整個組織既有的習慣和文化對著幹,後台不夠硬,身段不夠軟,導入到最後,往往沒能改變組織,先陣亡的會是你自己。

『那怎麼辦?』另一位學員問。

『看起來很難,但也不是沒辦法。』我說『先準備好自己,別聽到台上講的精彩,一股熱血就勇往直前。也別亂找顧問,敏捷轉型不是小事。要幫企業實踐轉型,得長時間陪著企業一步步解決問題,身為顧問,你要非常清楚每一個工具、每一個activity想達成的目的,然後幫助企業選擇最適合的方式,量身訂做,趨吉避凶。』

好啦,先上課吧。先搞懂Scrum每一個角色和活動的意義,到時…才能真的幫上企業實現轉型。

2020年9月14日 星期一

什麼是Azure Cosmos DB?

Cosmos DB是微軟的高可用性、低延遲資料庫。近代的電商網站或微服務應用程式,都強調所謂的高可用性(就是網站或服務很難死掉)與快速回應,一旦系統上線,大概都不太容許服務的中止或延遲。

要實現這個能力,我們在Web或AP層可以做HA(high availability)架構,一般透過負載平衡(Load Balance)搭配Auto Scale的方式來實現。從Azure的Web App到常見的Container解決方案(像是K8S, AKS)的使用,背後很多的考量都是為了實現這樣的高可用性需求,讓流量增加的時候動態的在Web或AP層自動延展(動態增加伺服器):
enter image description here

但你慢慢會發現,當Web/AP伺服器可以近乎無限的延展之後,瓶頸接著發生在DB身上,因為傳統的關聯式資料庫,要實現像是Web Server或AP Server這樣快速延展分流成本相對而言非常高。且在資料的抄寫和回應的速度上要能夠有所保障,其架構都不若Web/AP Server的Scale那麼單純。

過去,用戶端的數量大多可以預測,但現在人手一台平板手機加NB,網際網路上的服務所面對的用戶端數量較之以往不可同日而語,如果要支撐一個全球服務的網站,傳統DB的Cluster架構常常力有未逮。

舉例來說,我們知道在資料處理上,有個CQRS架構(讀者可以上網搜尋相關資訊,例如 https://docs.microsoft.com/zh-tw/azure/architecture/patterns/cqrs ),其基本的概念是,真實世界中,資料查詢(讀取)與寫入的比例其實並非對等的。例如,台灣前陣子的口罩銷售地圖這類的應用,很明顯查詢的需求遠高於更新(寫入),大部分的全球化應用都有類似的情境。而傳統的資料庫程式設計,卻往往將讀取和寫入設計成同樣的工作通道(例如同樣的db access connection)。

倘若我們可以將資料的讀取,分散在全球不同的資料中心,讓讀取的節點可以分散,而工作比例較低的寫入動作,僅在其中一兩個節點進行,再將寫入的資料自動抄寫到不同的讀取節點,將有助於提升應用程式的查詢效能,這對於很多全球化或分散式的應用來說,是一個相對理想的架構。

這時候,NO SQL(Not Only SQL)類型的資料庫,就開始被許多大型網站考慮了,而Cosmos DB就是一個可以滿足這樣需求的資料庫。

透過Cosmos DB,我們可以動態的設定多個讀取區域,讓應用程式的讀取效能大幅提升:
enter image description here

資料會在異動時自動抄寫到不同的資料中心,微軟對資料讀取的效能進行保證,並提供 99.999%高可用性的承諾。開發人員在使用上也很簡單,只需要建立一組CosmosDB Account,就可以建立多個Database以及Container(類似關聯式資料庫的Data Table)。

建立Cosmos DB

要建立Cosmos DB,只需要在Azure Portal新增Azure Cosmos DB即可:
enter image description here

建立完成後,取得endpoint與金鑰,其實就可以使用了:
enter image description here

在取得endpoint與金鑰之後,可以參考筆者的github上的範例:
https://github.com/isdaviddong/dotNetCoreCosmosDB

透過上面這個dotnet core的console app範例,你可以很簡單的把endpoint與金鑰換掉,就可以體驗一下CosmosDB的使用,包含資料庫與Container的建立、資料item的建立與查詢。

CosmosDB的資料item的store是以JSON的形式保存,而查詢也可以透過"類似"SQL方式的語法,在上面這個範例中都有展示。你會看到我們在程式碼中,建立了一個Customer類別,並且動態建立100筆資料存入container:
enter image description here

當你把資料成功的建立好之後,可以回到Azure Portal,你會發現有個資料總管,它是個簡單好用的工具,你可以在資料總管中做簡單的查詢:
enter image description here

當你執行我在Github上的範例,將會看到我們透過C#程式碼新增和查詢資料:
enter image description here

OK,就這樣,高可用性DB唾手可得。

Related Posts Plugin for WordPress, Blogger...

熱門文章