星期三, 1月 17, 2024

IBM Mobile Platform Foundation End of Support 之關於開源軟體的省思

  


IBM Mobile Platform Foundation 是很多客戶當初在建置行動應用 App 的選擇。早在他還叫做 Worklight 的時候,我就有接觸這個產品。一開始,他還是用 PhoneGap 這個名字,後來 Adobe 保有 PhoneGap 而開源的部分則命名為 Apache Cordova

 

回想,跟這個產品相處從 v5 到現在第八版,也有七八年的時間了!然而,在 2022 年宣布,該產品將於 2025 年九月終止支援。通常,危機也是一個轉機,這代表台灣某塊 App 應用的市場將有所變化。

 

有一段時間,我們跟 IBM 談過合作,也試圖打造一個相對應的產品。技術的問題,我們團隊都有一一克服,但最終沒有推出市場 (這是另外一段故事)

 

離開前一份工作後,又再次面臨到這個問題,所以還是再調查一下可能的解決方案。當然,我知道在台灣有一支強悍的團隊可以處理這件事情,不過通常他們會讓客戶思考整個 App 打掉重做。

 

一個應用,每隔三五年就會面臨打掉再做下一個世代的產品。有時候,我不得不懷疑其實我身處「硬體」產業。怎麼這些打造出來的軟體,都需要捨棄而不能增強。

 

好吧!再來講講目前針對這件事情可以提供的幾個建議方向:

 

(1)   找到一個新的單位,繼續買維護的授權,你可以繼續使用

 

原本,我們的資訊是這產品就這樣不見了!不像 Louts 那些產品線,有一間 HCL 的公司來承接。但,後來我在 IBM 官方的網站,找到了一個新的說明。有一間叫 Persistent 的公司,他可以繼續提供產品的維護服務,當然包含 code level 的修正。但是,IBM 卻沒宣告他把這個產品賣掉了,所以這些事情我還在與該廠商確認當中。

 

(2)   找到夠熟悉這個產品的人,讓他協助你改造應用程式

 

基本上,我知道很多客戶買了這個產品,但也不是用了他 100% 的能力。所以,要能夠寫一些模組來取代既有機制,基本上問題不大,只要你對產品夠熟悉,你可以用比較小的成本來完成這件事。如此,就可以讓你脫離 IBM 的包袱。

 

(3)   財大氣粗,整個 App 重做一次

 

當然很多時候,App 是不是可以整個打掉重做取決於客戶的商業戰略與預算。如果,這麼恰好也到了一個週期,那麼重做沒什麼不好的。只是,回想一下你在做的是「硬體」還是「軟體」?

 

那麼,在重做的時候,我們就會開始思考新的 App 該用什麼方式實現?

 

1.     Native Application

2.     Hybrid Application

3.     Cross Platform Application

 

依據自己業務目標跟營運的狀況應該選定不同的策略,當初使用 IBM Mobile Platform Foundation 的客戶,大多數是使用 Apache Cordova 這個技術框架。所以,雖然在全球來說,這個技術正在走下坡,但在台灣還是有一定的商機跟市場。特別是,通常使用這個技術的客戶,都是算得上有頭有臉的。

 

另外,還有一隻強悍的團隊讓這件事情在業界上得以存活下去。

 

很多時候,客戶會問我說 Apache Cordova 還可以用嗎?剛好,在 2023 年末,Cordova 官方部落格有一個2023  Survey Result 文章,它說明了 Cordova 的發展以及所遇到的困境。

 

1.     通常使用 Cordova 的客戶,在什麼平台上建置其應用

 

根據其數據顯示,97.4% 應用在 Android 上,89% 應用在 iOS 上。

其他的部分,可以參考原文

   

2.     你是否將 Cordova 移轉程其他的技術

 

使用該平台的有 76.8% 回覆「沒有」,不過會來做這個問卷的可能也還在使用這個平台,所以比例這麼高也不太意外。另外,有 3.1% 的人移轉到 Flutter、有 3.5% 的人移轉到 React Native。好吧,我們有那少數 3% 的經驗。

 

3.     針對 23% 想移轉的,他們的想法是?

 

Plugins 的維護速度不佳,因為很多都是開源的,當社群不夠熱絡的時候相關的維護速度就不好。過去,我們團隊有撰寫一些自己的 Plugins 來解決這些問題,但我們沒有開源 

 

4.     再進一步地追問,為什麼參與問卷調查的人不挺身貢獻?

 

不外乎就是沒時間,或是有冒牌者症候群 (沒自信)

 

為什麼會去找這個文章,因為最近我在整理一個客戶的應用,他們還是想要透過編寫 html 的方式來完成 App,只是他不希望使用 Cordova 而是我們自己打造一個新的平台。

 

於是,我思考,為什麼我們不是從 Cordova 出發,而是自己打造?其實,在底層我們要做的事情可能部分類似,而 Cordova 又已經經歷了多少年的歷練,有多少既有的 Plugins 可以用。

 

對,他是在走下坡,但也是因為我們沒把自己修改的東西貢獻出來。取之於開源,用之於開源,或許我們也該思考一下自己的作法。不然,未來可能有更多我們現在使用的開源平台得不到好的支援。

星期一, 12月 25, 2023

2023 年回顧

 


今年是變化快速的一年,從去年底或年初也沒想過到了 2023 年底是這個狀態。不過,都已經到了這一步,就面對然後想辦法走出一條路。檢視今年各個階段所做的事情:

【產品開發的初體驗】

今年每一季都有著不同的狀態,在開年之初,任職的公司完成了階段性目標的高光時刻。思考去年訂立下的工作目標,關於《產品開發》。團隊經歷了一陣子的努力後,最終我們把這個計畫停了下來,所以這個部分我從自己的回顧來看應該就算是一個失敗的體驗。

首先,我們過去以來就是一個執行「專案」的團隊,對於怎麼發展「產品」並沒有那麼的熟稔。但,技術其實也不是我覺得宣告失敗的主因,畢竟技術問題總是可以解決的。那麼,我自己如何檢視這件事?

第一點:團隊缺乏共同的目標與願景,簡單來說也就是我們組了一個團隊,但這個團隊並非都是「自願」的人選,再者團隊成員之間的屬性與磨合並未最佳化,使得工作的時候缺少「火花」,無法有效點燃團隊自己的熱情。甚至,團隊自己也不認為這件事情有趣。中間,也有人退出了這個產品團隊。

再來一次,我想能解決這件事情最好的方式是「深度的參與其中」,創造出更多挑戰的場域,讓事情變得有趣,吸引「自願者」加入團隊。很少人可以扮演「開創者」的角色,這是需要承擔風險的。而這段時間因為一些其他的外務,讓我像個「管理者」交辦任務,而不能用「領導者」的模式,捲起袖子跟大家一起共事。

第二點:對於商業的策略上並未與公司達成共識。這個產品當初發展的初心是「讓客戶安心」。因為原本客戶使用的產品,原廠已經宣告一個時間後就不再販售。但,該產品卻應用在客戶的重要服務上。在這個基礎上,第一波的商機就是協助既有客戶的轉換。但,這部分的「數量」顯然到不了公司要求的規模。

這部分,我原本認為在執行前跟公司已經充分溝通,但同仁們執行時仍然遇到不少的壓力。或許是基於訓練的前提,希望大家有更廣泛的思考。但,幾次下來信心已經渙散。無法獲取高層的支持,也是計畫失敗的原因。

第三點:沒有立即的訂單,客戶要求驗證方案是否可行。

這件事對客戶來說是「必要」面對的,但是因為原廠公告訊息後,又有一段時間讓大家可以應對。所以,並沒有馬上進入「緊急」的狀態。但是,因為該方案跟既有系統營運有關,為求謹慎客戶會要求驗證方案可行性。

為此,我們團隊需要先投入資源,以應對後續的挑戰。但,此時在公司的規範下,大家不太好做事。這造成我們到了一個進退維谷的狀態。

基於以上幾點因素,我們在第一季暫時擱置了這個發展計畫,轉而處理短期的專案任務。當下次,我再面對《產品開發》這類型的工作項目時,可以更加成熟地處理相關議題。

【職涯的轉換】

首先,分享今年度對我來說最大的變化就是我離開了本來的公司與職務,讓一切從零開始。

到了第二季與第三季陸續發生了些事情,使得我自己陷入了一個職涯的低潮期。在這段時間,也不斷地思考下一步是什麼?中間有了一些嘗試,開始人生的第一次投履歷,面試等等的旅程,因為要考量的因素太多,所以最終沒有前往錄取的公司。

人生是一段冒險的旅程,一直以來我不斷地學習、觀察如果有一天我要創辦公司的話該怎麼做。這個想法早在還沒 20 歲的時候就存在,所以當初選擇「專題」題目與方向時,我選擇了軟體這個領域。理由是,假設有一天我想創業,只要一台電腦就可以出發。

基於一些因素的考量,短時間我也不適合到其他地方上班,加上自己的年紀。如果,某一個時間我要做這件事,那應該就是「現在」了!這可能是在 2022 年回顧時都還沒思考過的情境。於是,我開始了解怎麼創辦一間公司,有哪些程序等,然後也採取了行動。


這段過程我都有做一些相關的紀錄,待後續整理再進行分享。


【持續學習】


無論日子過的是順遂還是艱困,需要時時刻刻讓自己保持學習的習慣,今年有翻到「猶太人的寶典-塔木德」,裡面提到猶太人在小孩子小的時候,都會問他們一個問題。假設,有一天你家裡遇到火災,你應該帶走哪些東西。我印象中,在小學也有一個老師問過這個問題,當初的答案是「護照」,而書上的答案是「知識」。知識放在你的腦袋裡面是別人偷不走的東西,而猶太人認為知識就是財富。所以,持續學習是重要的,並且除了學習之外還需要「實踐」。


回到《學習》這件事情,自己的學習之旅持續地展開,從閱讀、上課及工作轉換等不同面向,持續的學習當中。在這一年,最大的驚奇,應該就是 AI 了。在過去的一段時間,我自己蠻多時候需要幫客戶規劃系統,轉寫一些相關技術導入的「建置計畫書」。


AI 讓我做這件事情的時間變快了,因為它可以很快地為我產生一些素材。基於這個現象,很多人認為「程式設計師」的工作很快地會被取代。我自己倒是有不同的見解。我認為目前這工具對於你自己是哪個領域的專家可以起到相當大的作用,其重點就是你自己要判斷內容的「品質」。


你可以把 AI 想像成是你自己聘請的員工,但是不應該把他的產出直接交付。在我自己來看,有些必較細節的部分其實目前是有問題的,或許我就算直接把他產出的結果貼出去也沒有人會覺得奇怪。因為,網路上的錯誤資訊本來就很多,所以大家可能被這些錯誤的資訊引導。然而,如果你是該行的「專家」,你就不應該妥協,應該為品質把關。


再者,思考一件事情,我們到現在都還在思考怎樣做軟體會更好的這件事。不斷地迭代,而這些 AI 的模型,是從既存的大量資料歸納出來的,在可以做更多的推論之前,你能做到的就是到資料搜集的當下最好的程度,更何況很多時候我們根本提不出那麼好的「問題」。你想創新,或是大幅度的進展,現在的AI 是輔助工具,而不是銀子彈。


再來,第四季之後,我沒有同事可以差遣了!想做任何事,任何的技術驗證,就是捲起袖子自己來。所以,除了那些技術發展的原理之外,我有更多的時間確認這些技術的細節,也可以思考真的導入會碰到什麼難題。


當然,我現在有一個非常得力的第零號員工《AI》,這使得我做事的效率經量測快了三四倍(還沒到葉問可以打十個的境界)。但,透過一些好的執行方式,確實讓我用更少的時間完成更多的事情。


所以,對於學習跟工作來說,我覺得後面一段時間要會的是應用與駕馭「AI」,而不是被 AI 駕馭。


2023 年閱讀書籍推薦】


「思考的框架」

 

作者在開篇,提到「教育並沒有幫我們做好迎接世界的準備」,這跟我自己的想法類似。但,並不是說教育本身不重要,而是我們要面對真實世界的問題只是運用自己學校所學的內容,通常不足以滿足。於是,作者開始探索各種做「決策」的方法,也去念 MBA 學位,期望在求學的過程中可以讓自己獲得如何做「決策」的方法。

後來,在某次考試中,他察覺到就算他在 MBA 的學程中求學,但是卻仍然像小學生一樣,只是從書裡面找答案。畢竟,只要知道書裡面的答案,考試就會及格。於是,他改變了自己的做法,不再是將所有的精力都放在指定作業上,轉而開始研究一些成功的人士,特別是查理、蒙格。他開始學習「多元思維模型框架」,並將學習心得寫成文章。

這是年初參加「天下年會」的時候在會場上買的書,在一月份看了一下這本書之後,似乎也把今年學習的主題給定義下來「決策」。

 

「庸才猛抄筆記、人才勤寫心得」

 

去年我推薦一些同仁去進修,然後回來後跟我分享的時候提到了這本書。但是,他又是一本買不到的書籍。簡單來說,就是他絕版了!不過後來,我還是找到了這本書。

 

他以「發問」、「思考」、「決策」、「行動」、「感染」及「學習」的活動閉環,來展示其核心的理念。在這本書中,我理解的最重要概念是從消費型學習提升到產出式學習。

 

一個人一天有 24 小時,這是每個人都不變的資源。如何讓這些時間變得更加有價值,過得充實讓自己成長。書中針對上述六個活動分別提供了一些執行時的指引,告訴你如何實踐,讓自己不斷地成長。

 

「低谷-贏家與輸家之間的距離」

 

這本書在前幾年就有出現在腦袋中,基本上他是一本已經絕版的書籍。後來,我在電子書中買到了原文版「The dip」。不過,礙於讀英文的速度,我手上的一些原文書籍閱讀的速度實在是有夠慢。

 

後來,我無意間找到了這本書。看了一下裡面的內容,其實蠻適合我當下的心境。這本書大概是今年第一季底到第二季看的書。書中提到,我們應該要有能力辨識自己現在面對的是「低谷」還是「懸涯」,如果是低谷就應該堅持下去,而如果是懸涯則是建議儘早止步。

 

在過去我們的學習過程中總是告訴我們「堅持下去,永不放棄」。但,書中有提到「贏家通常懂得適時放棄,而且放棄者未必是輸家」。你可能是找其他的方式來獲取成功。這就是 Do the right thing vs Do the thing right 的差異。

 

除此之外,它也強調在你需要堅持下去的領域,做到第一之後會享受到的紅利。這與成功的道路上通常很寬敞的原理一樣,因為只有經過低谷的逆境,才可以跳脫這個賽道,到達贏家的路上。

 

「賽氏企業 設計未來組織新模式」

 

這本書我忘記是從哪邊發現的,但當時我一直在思考到底怎樣的組織是一個比較好的模式。所以看到這本書的時候,就想要了解一下何謂「未來組織新模式」。書中的主人翁其實是企業的第二代,他父親已經讓企業進入某個規模之後才由他開始接手。

 

在這之間他經歷了許多個困難,也用了許多的方案來改革,整個歷程其實跟我們在談的「敏捷組織」很類似。在這段期間,他面對併購、工會、分拆、簡化組織流程、輪調、績效考核及持續改善等循環。以故事的方式,敘述著這一切的調整以及他一路以來的心路歷程。

 

書中很多概念看起來激勵人心,希望自己可以在這樣的組織中做事。但,沒有真的去實踐,無法理解這樣的組織會遭遇的問題以及如何排除,也希望有一日自己可以建立這樣的組織。於是,我也開始了一些嘗試。

 

5000 天後的世界」

        

凱文、凱利是一個科技的預言家,他深入觀察科技發展的趨勢,並且傾聽科技,了解未來。書中提到的觀點,科技的發展有 51% 是好的,49 % 是壞的。經過長時間的洗禮,最終好的影響將大於壞的影響。

 

        在書中,針對資訊科技、生物科技等有著各種不同的觀點,都值得我們去關注,在未來無論是投資或創業,這些都可能成為趨勢。或許,我們可能不容易成為該領域的最大贏家,例如:MicrosoftGoogle或是Facebook 等。但是,一個大平台的興起,將帶來成千上萬個小贏家。觀察這些趨勢,可以讓自己了解科技未來的走向,也為自己提供一些指引的道路。

 

「逆思維」


這本書翻開的第一頁就寫著「來自全世界的最高讚譽!」,他目前有分成兩種封面版本販售。會知道這件事是因為有一位同事說他有看這本書,我說就是那本「黑」色的?他回我是白色的吧!後來,我才知道他有兩個流通的封面。

 

他的英文書名叫做 Think Again,就是要我們再一次思考的意思。其實,「逆思維」一開始我是連結到查理、蒙格的思維模式「如果我知道自己會死在哪裡,我就一輩子都不要去那個地方」。

 

書中舉了許多的小故事,告訴我們重新思考的重要。例如:我們經常用「溫水煮青蛙」的故事來比喻我們要反應環境的變化,否則就像那隻青蛙一樣被煮熟了。但,有人去做了實驗,首先大家認為青蛙丟到滾燙的水中,會馬上跳走。可是,該實驗的結果顯示因為水溫太高,青蛙的肌肉組織遭到破壞,就直接當場斃命了。

 

在另外一方面,當青蛙在逐漸加熱的水中,開始感到不適的時候,他就跳走了。這些顯然與我們既有的認知有所不同,所以面對一件事,我們可以用多個面向來思考這件事。

 

有時候,我們所知道的所堅持的不一定是事實。所以保持開放的心態,讓自己不斷地思考,不斷懷疑不斷的證明才是一條求真求知的道路。如同先前「低谷」與「懸涯」的判斷,我們總是覺得那條路行得通才會往前走。但是,逆思維這本書讓我知道需要不斷地省思,運用數據跟執行的結果來驗證我們自身的假設。

 

「部落-一呼百應的力量」

 

這本書是一本談「影響力」與「領導力」的書籍,很多時候我們因為年資或是本身的權力使得我們大多是透過權勢來「命令」他人,而不是發揮自身影響力來影響其他人。

 

部落本身指的是自身的「領域」或是「能力圈」,如何在自己的「能力圈」中以身作則,做到領導者的地位。聚眾成事的力量,就是「部落領導學」。因為網際網路的盛行,現在形成一個部落不再像以前一樣有地域的局限性。我們可以透過發表自己的意見凝聚網路上的任何人,形成一個部落,只要你願意開始行動。

 

        最特別的是,這本書的「最後一件事」,假設我們有從這本書上得到任何的東西,不仿考慮將這本書給別人,請他們讀一讀,請他們考慮成為領導者。這是一種不一樣又新穎的傳播概念。

 

「決策思考-一種稀有又精湛的心智工作原則」

        

這本書主要帶給我幾個概念,第一是策略不等於營運。策略是去發掘最重要的事,而營運主要是在改善短期的效率。策略思考是一種主觀的心智觀點,每個人都有策略,無關好壞,只在於自己掌握資訊的多寡。

 

書中以魔球、哥倫布發現新大陸、IBM 的轉型來說明策略的模糊性以及科學性。從這本書的觀點,策略是用於「改變事業」,而營運則是用於「經營事業」。而一個好的點子從初期發展到完全實現效益,中間會經歷很長的一段時間。如同許多科技的產出到實現經濟規模都要十年以上的沈澱。

 

當然,隨著世界的變遷,這些速度可能越來越快。書中舉了許多的案例,說明策略的本質,讓我們細心觀察身邊的微弱信號。策略通常具備模糊性與不確定性,要能夠有所察覺並逐步得頗析是相當消耗腦力的工作。而人們通常不喜歡這樣做,於是更常使用的是「慣性」的沿用長期以來的做事方法,也就是落入營運思考的慣性。

 

透過這本書,我們可以檢視自己目前的工作模式,倒底始在處理「改變事業」的策略思考,或是增進效率的「營運思考」。我自己認為,如果沒把這兩件事情釐清楚的,可以看一下本書了解兩者的差異,並協助自己建立對應的思維模式。

 

 

「點子就是一直來」


        這本書是之前看過「點子都是偷來的」與「點子就要秀出來」的下一冊。會買下這本書,是因為前兩本看完感覺還不錯。雖然,這本書是「藝術」從業人員所寫。但是,很多觀念其實我自己認為相當受用。

 

        打開這本書的第一個觀念,如果你想要讀一本有關於 的書,那你就會去尋找相關資訊。如果有這樣的書籍,那麼就去讀它吧!如果你找不到,那就自己寫一本。光這個概念,就讓人覺得充滿行動力。所以,當你覺得缺少些什麼,那們就動作吧。

 

        這本書要我們把握當下「讓我們盡力一次過好一天就行了」,也帶有自律ˇ的要求「按表操課」。當我們怎樣過每一天,就必然會怎樣地過自己的人生。在書中,他有許多的名言跟作法,如同書名一般,只要我們堅持執行,不斷地去做就可以讓我們的點子一直湧現。

 

12 週做完一年工作」

 

這本書是最近看到,標題很嚇人,內容很實在。看了之後,會想樣 Agile  OKR 等相關的知識融合在一起的一個執行手冊。過去,我們制定年度計畫的時候通常以一整年的維度來進行評估。

 

因為一年的週期太長,經常使得人們進入一個拖延症的狀態。根據研究,12 週看起來是一個不長不短的週期,特別適合用來檢視目標的執行狀況。這與 OKR 的理論不謀而和。

 

透過更頻繁地檢視自己執行的狀況,及早的進行修正,讓我們隨時保持在一個強度之上。而不是每年到了年底再來做最後的衝刺。藉此,來提昇自己的績效。本書以「打造願景」、「制定計畫」、「追蹤管理」、「評量成效」與「時間分配」等幾個主題來讓整件事落地。一年 12 週,其實已經有官方網站與相關推廣課程,協助我們改善自身的效率。


【新的一年】


再來的工作,就進入一個新的模式,在這段時間,我將不再像之前擁有的資源那麼豐沛。從現在起,要專注的是不是跟從潮流,而是進行有價值的活動。透過這些活動建立新的工作團隊。


新一年的目標,就是能扎實的做好手邊的工作,提供高品質的服務,奠定新團隊的文化基礎。

星期四, 6月 22, 2023

【觀念整理】雲端運算的概念與企業的雲轉型第二階段

 


回顧前一次的文章,當你把應用程式部署到公有雲或是容器化平台後,就代表你完成雲運算應用系統的建置了嗎?基本上,這應該是我們開始踏上雲端旅程的起點。在我們順利將應用程式移轉到容器化平台之後,我們可以透過下列指標,來檢驗我們是否能得到雲原生應用程式的好處。


(1)  你是否可以因應不同的需求量任意地配置雲平台的資源以滿足應用上的需求


這個衡量的指標,說明的是我們的應用程式是否可以動態地擴充,這時我們就會檢視應用程式是否具備《狀態性》。

 

無狀態(Stateless):表示應用程式並未採用記憶體和硬碟來儲存狀態和日誌,因此可以將應用部署到一個全新的環境中。

 

有狀態 (Stateful):表示應用狀態將依賴於本地的運行環境,因此無法將應用隨意部署到其他環境,不能隨意的擴展。

 

所以,假設你檢查之後應用程式屬於《有狀態》的服務,那麼我們就必須調整應用程式的架構,讓他不依賴於本地運行環境來決定其狀態。方法不外乎就是將需要留存於本地的資訊,移轉到第三方的儲存體,例如:資料庫或是 Redis 等相關的中介軟體。藉此,讓應用程式滿足無狀態可任意擴展的狀態。

 

(2)  應用程式本身是否具備多租戶的能力

 

多租戶(multi-tenancy)是指一個系統或應用程式能夠支援多個不同的租戶或使用者,每個租戶或使用者可以獨立地設定和管理自己的資源、數據和安全性,同時共享同一個系統或應用程式的基礎架構和資源。

 

在雲原生應用中,多租戶架構可以讓不同的企業、組織或客戶共享一個系統或應用程式,從而減少基礎架構的成本和管理負擔。這種架構還可以使系統更加靈活和可擴展,因為不同的租戶可以根據自己的需求和資源使用情況來分配和調整自己的資源。同時,多租戶架構也需要考慮如何保護每個租戶的數據和安全性,以確保系統的可靠性和穩定性。

 

(3)  雲原生應用程式具備自我恢復能力 (容錯能力)

 

雲原生自我修復是指雲原生應用在運行過程中,能夠自動偵測和解決可能的錯誤和故障,並恢復到正常運行狀態的能力。這種能力通過自動化的監控、分析和回應機制實現,可以大幅降低系統管理和維護的負擔,同時提高系統的可用性和可靠性。

 

雲原生自我修復能力主要包括以下幾個方面:

 

1.     自動監控和偵測:系統能夠自動收集和分析數據,並及時偵測和識別可能的錯誤和故障。

2.     自動回應和處理:系統能夠根據預設的規則和策略,自動回應和處理錯誤和故障,例如重啟應用程式、調整資源分配等。

3.     自動恢復和重建:系統能夠在發生災難性錯誤或故障時,自動恢復和重建數據和應用程式,以保護系統的可用性和穩定性。

 

通過這些能力,雲原生自我修復可以使系統更加穩定和可靠,同時減少系統管理和維護的工作量和成本。

 

(4)  雲原生應用程式具備《自動化部署》能力

 

雲原生自動化部署機制指的是利用自動化技術和相關工具,將應用程序及其相關的基礎設施、服務等自動化部署到雲原生環境中的過程。這種部署方式通常會涉及使用容器、叢集管理工具、自動化配置管理工具等技術,以實現應用程序和基礎設施的自動化部署、擴展和管理。透過這種自動化部署機制,可以大幅降低部署時間和成本,提高應用程序的可靠性和可擴展性,同時還能夠更容易地應對變化和挑戰。

 

(5)  針對雲原生應用應該具備的應用程式管理能力

 

1.     自動化管理:雲原生應用程式需要支援自動化管理,包括自動化部署、擴展、維護和修復等功能,進而提高系統的可靠性和可用性。

 

2.     監控管理:對雲原生應用程式的監控需要全面、深入,包括監控應用程序的運行狀態、資源利用率、性能指標等,從而能夠及時發現和解決問題。

 

3.     安全管理:在雲原生應用程式中,需要結合容器和微服務的特性,強化對應用程式的安全管理,包括控制訪問權限、防範安全漏洞和保護數據等。

 

4.     統一管理:需要具備統一管理的能力,包括統一管理應用程序、數據和基礎設施,從而可以實現更高效、更一致的管理。

 

5.     故障管理:對雲原生應用程式的故障需要有快速反應和修復的能力,需要支持故障自動檢測、自動修復等功能。

 

6.     優化管理:需要支持優化管理,包括自動優化資源利用率、自動調整運行環境等,從而能夠更好地滿足不斷變化的需求和挑戰。

 

(6)  雲原生應用程式必須具備《隨處可行》(任意部署的能力)

 

雲原生應用的任意部署能力指的是應用程式可以在任何基礎架構上運行,並且可以自由地部署到任何雲端環境中,而不受特定的基礎架構或雲端平台的限制。這種能力是雲原生應用程式的一個關鍵特性,可以大大提高應用程式的靈活性和可攜性,從而能夠更好地應對不斷變化的需求和挑戰。

 

具有任意部署能力的雲原生應用程式通常是基於容器化技術來實現的,這使得應用程式可以在不同的基礎架構上運行,而不需要進行重寫或重新配置。同時,透過容器化,可以實現應用程式的快速部署、擴展和管理,從而提高系統的靈活性和可擴展性。

 

在實際應用中,具有任意部署能力的雲原生應用程式還需要考慮與不同雲端平台和基礎架構的兼容性,以確保應用程式能夠在不同的環境中順利運行。

 

雲原生的技術賦予現今的開發人員得以將應用程式建置並執行於任何現代化的雲平台之上,例如:公有雲、私有雲及混合雲等。容器化技術、服務網格 (Service meshes)、微服務以及 Web API 等就是雲原生技術的範例,這些機制將使得鬆散耦合的系統具備彈性、可管理性與可觀察性。結合強大完善的自動化工具,使得開發人員得以頻繁地修改應用程式,縮短交付的週期。


透過上述的六個評估指標,可以協助我們判斷目前我們的處境,也可以針對這些狀況來思考相對的改進措施或是要導入的工具。還有一個指標是我沒放在上面的,叫做雲原生應用程式是分散式系統,其實他指的就是用微服務來實踐可能是一個好的概念。不過,這進一步又牽扯到服務的拆解等相關議題,就先不列在這個早期的階段。畢竟應用程式好好的,也可以應付複雜的需求,所以先不要把事情搞複雜了,維持簡單是一件好事。