我的印尼朋友問我:為什麼從接觸的台灣人中,我感受到他們認為「東南亞」就是落後?

我的印尼朋友問我:為什麼從接觸的台灣人中,我感受到他們認為「東南亞」就是落後?

我們想讓你知道的是

「當越南、印尼、新加坡、泰國等東南亞國家今日不斷快速發展之際,台灣相對停頓,為什麼台灣人還會有這樣的眼光看東南亞呢?」

文:賴珩佳

我在印尼有一位好友,他創立的餐飲集團是當地前三大的。近期他計畫將旗下的品牌餐廳拓展至國外,第一考慮的對象是新加坡或台灣,也因而與一些台灣同業的人有更多接觸的機會。

最近碰面,他小心翼翼問我:「在妳身上我從沒這樣的感受,但為什麼從與我接觸的台灣人中,我感受到他們認為『東南亞』就是代表落後?真抱歉,妳覺得是不是我有些誤會了?」我不太清楚與他接觸的台灣同業對他的態度,我只知道這位在印尼相識十年的好友,雖是富二代卻自願闖盪江湖,成功卻謙卑低調。對於他的感受,我真是滿懷歉意,因為我猜想他的感受是正確的。

他接著說,20多年前當他還是青少年時,曾到過台灣,當時覺得這地方很酷,東西又特別好吃。但當他十多年前與近期再訪台灣,感覺變化已不大,甚至已不是他印象中的「進步國家」。他問我:「當越南、印尼、新加坡、泰國等東南亞國家今日不斷快速發展之際,台灣相對停頓,為什麼台灣人還會有這樣的眼光看東南亞呢?」這個問題真是讓我啞口無言,事實上,這已經不是我在印尼第一次聽到這樣的疑惑了。

是的,在1980年代台灣經濟狂飆時期,我們自豪於曾是亞洲龍頭的代表;然而龜兔賽跑的競局中,當跑在前頭的我們在路上躊躇猶豫了好一陣子,不代表在後面的烏龜永遠趕不上。當烏龜已不是當年的吳下阿蒙,看我們的眼光也早已不同,我們看待印尼這個國家與人民的眼光與胸襟,是否也該有所調整?

印尼因為在地理上是位居世界重要樞紐位置的國家之一、擁有世界第四大人口、同時也是世界第一大伊斯蘭教國家。近年來和平民主的政權轉移、快速發展的經濟等等因素,再再將印尼推向世界舉足輕重的大國。如前文所提,印尼如今的經濟與政治,正被新一代受西方文化影響更勝東方的人帶領著;在經濟領域,華人尤占多數。這些人有宏觀的國際觀、有創新的思考能力,再加上印尼的人口結構是青壯人口占絕大多數,比起許多有人口結構老化問題的已開發國家,印尼的經濟發展爆發力與未來國家前景,實在不容小覷。

台灣因為險惡的世界政治局勢,常常被排除在世界組織外,如東南亞國家協會(ASEAN)、東協十加三(加上中、日、韓)等。即便如此,我認為透過半官方或民間力量,還是很有著力點。

以鋼鐵業為例,韓國最大的浦項鋼鐵廠已於2011年與印尼唯一的國營鋼鐵廠合資,將建立全東南亞唯一一個整合性鋼鐵廠,總投資額為30億美元(韓國浦項鋼鐵占七成,印尼國營鋼鐵占三成)。2012年,日本最大鋼鐵廠也與澳洲最大鋼鐵廠結盟,在印尼合資發展。

反觀台灣,原本與日韓鋼鐵廠並列為世界一線鋼鐵廠的中鋼,雖然地理位置更為接近,卻遲至2015年才開始放眼可能在印尼的投資案,雖然有些失了先機,但如果可以更加積極努力,在遠未飽和的印尼鋼鐵業,一定也可以奪下一席之地。

當前台灣政府積極力推「新南向政策」,印尼無論在娛樂產業、觀光旅遊、農業、餐飲、HALAL認證商機、電子商務、金融、教育、醫療等領域都大有可為。長久以來,台灣與印尼彼此了解不深,事實上,近年來台灣在印尼人民與印尼社會的眼中已淡化了一段時日。如果我們可以敞開心胸,透過教育交流與產業契機,試著了解印尼這個國家與當地民俗風情,勢必可奠定台印互惠的基礎。古語有云:「敬人者,人恆敬之。」我們要重新贏回尊重,最重要的是,我們或許也該學習尊敬印尼這個國家、這片土地,以及這裡的人民與文化。

相關評論:

書籍介紹:

3AB1080

本文為《那些你未必知道的印尼》摘要,寶瓶文化

*透過以上連結購書,《關鍵評論網》由此所得將全數捐贈兒福聯盟

第一線的印尼觀察,Google也查不到的在地切身體會,
賴珩佳要告訴你:印尼的江湖在哪裡?

對印尼,你的印象是什麼?印傭、印尼勞工、印尼新娘,落後、貧窮、教育水準低,還是⋯⋯印尼和印度差不多?

誤會大了!當台灣鼎泰豐、日韓國際企業、新加坡醫院紛紛到印尼開疆闢土時,不了解印尼,你就不知道這裡是未來的一片江湖。

責任編輯:吳象元
核稿編輯:楊之瑜


猜你喜歡


挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

我們想讓你知道的是

企業如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署,減輕人力負擔,提升專案服務運作效率?

所謂現代化智慧 IT,所有工程師最希望的境界,莫過於只要輕鬆點幾下設定,系統就會自動跑起來,管理者再也不用隨時待命在機台旁邊,從此工作悠哉又快樂!儘管這樣情境還沒到來,但隨著敏捷式開發的流行,除了 DevOps 人員,有越來越多開發者將 CI/CD 概念融入到工作流程當中,例如從 build code、執行 unit test、到部署應用程式。

透過 AWS 增加雲端技能 在組織發揮影響力

上述種種反覆步驟自動化執行,也就能提昇服務品質、主動通知開發人員以減輕人力負擔,讓專案服務能持續運作。

其中,GitLab 是執行 CI/CD 常用的工具之一,也是開發者使用程式碼儲存庫的地方。為了讓 GitLab Runner 在雲端快速實踐 CI/CD,《AWS 開發者系列》透過影片分享,如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署。

以下節錄工作坊影音內容,幫助開發者快速理解如何運用 Amazon EKS 的高可用性且安全的叢集,將修補、部署節點、更新等關鍵任務,全部做到自動化設定。同時影片也會示範 Amazon EKS 搭配 GitLab 如何展開自動部署,幫助工程團隊實踐 CI/CD 價值。

Amazon EKS 對容器管理輕鬆簡單、維運省時省力

容器化服務越來越興盛,當容器(Container)越來越多,在複雜的微服務(Microservice)系統環境之下,運維團隊的管理成本可能相對會增加不少,為了有效調度容器部署, 導入Kubernetes 無疑是近年企業熱門的話題之一。

建構 Kubernetes Cluster 流主要可區分兩大塊,一是安排容器調度的Control Plane、另一則是容器運行時需要用到的 Worker Node。

Control Plane 裡面涵蓋有儲存狀態的 ETCD、CoController manager 、Scheduler 的調度管理、甚至是操作時進行互動的 APIServer,若是自己創建 的 Kubernetes Cluster ,需要自己安裝這些元件,後續仍需要對 Control Plane 進行相關管理、維護、升級工作。為了減少上述 Components 的繁複維護,在透過 AWS EKS 代管的 Kubernete Control Plane 部可以獲得以下三大好處。

Amazon EKS 一鍵式部署,展現三大優勢

第一,Amazon EKS代管的 Control Plane實踐了跨AZ的高可用部署,使用者不需要擔心單一節點故障的風險。

第二,Amazon EKS 支持至少四個 Kubernetes版本,持續跟進每季 CNCF 的發佈,同時 EKS 也完全符合上游 CNCF 規範。

第三,部署 Amazon EKS 之後,可直接使用 AWS 平台上現成的服務工具,在安全性管理、網路設定方面,可以做到無縫整合。

最後 AWS 台灣解決方案架構師也提到,若想在容器環境進行 CI/CD 及應用程式的管理,可以進一步透過 IaC 整合部署 Amazon EKS 叢集,透過使用 Console、把 EKS 變成 Cloudformation 的模板、使用 AWS 所開發出來的 eksctl.io、或指令是採用 AWS CDK 可以讓開發者用自身熟悉的語言,在 AWS 平台整合 CI/CD 工具進行維運及部署 EKS。

打造第一個在 AWS 上的應用程式

了解 Amazon EKS 整合 GitLab ,獲得三面向價值

對開發者而言,想把 Amazon EKS 整合到 CI/CD 工具之一的 GitLab 平台上,可以看到那些實際的優勢?

在 DevOps 開發者示範工作坊當中,GitLab 資深解決方案架構師指出,GitLab 使用到 Kubernetes 技術,主要有三種搭配方法,包含 GitLab Server、GitLab Runner、以及創建 Deployment Environment。

本次示範教學會主要聚焦在 GitLab Runner 如何採取 Auto-scaled 方式進行 Build、Test、Package Apps;以及在 Deployment Environment 運用 Kubernetes 技術,做到 Auto Deploy、Review App。

正因為 Amazon EKS 能夠在 DevOps 過程提供所需要的彈性計算資源,幫助開發者在 GitLab 平台上面獲得以下三個層次的優勢:

  • 在 GitLab 內建的部署工作流程當中,自動生成整套 CI/CD 最佳實踐腳本。
  • Review App 過程,從 Merge Request 中可直接訪問應用程式 /App 的 UI 介面,並且根據 Git branch 名稱、專案名稱,自動生成 Review App 的 URL,以及在 Merge 前的最後防線進行 Approval 檢查。
  • 加速 CI/CD 流水線,GitLab Runner 運行時候還可藉由 Amazon EKS Cluster 進行 Auto-scaled 的支援。

Amazon EKS 整合 GitLab ,需要兩大流程

影片最後,GitLab 資深解決方案架構師示範如何把 Amazon EKS 整合至 GitLab 執行 Auto Deploy,主要可分為兩大區塊流程,第一部分聚焦在 Amazon EKS cluster 的設置,第二部分則執行 Auto Deploy 設置。

第一塊可拆分為四個階段,首先教學怎麼創建 EC2 節點的 EKS cluster,第二階段示範把 EKS Cluster 連接到開發者的 GitLab Instance、Group 或 Project,下一步則使用 Cluster Management Project Template 創建一個 Cluster Management Project,以及最後一階段透過 Cluster Management Project 自帶的 Helm Chart,安裝在 Cluster 所需要的內建 App。

第二塊執行 Auto Deploy 設置,針對需要部署的 App 創建一個 GitLab Project,接著再把 gitlab-ci.yml 添加到 Project,並從 Web IDE 選擇及導入 Auto Deploy 的 CI 模版,讓 GitLab 自動生成最佳實踐的整套流水線。

幫助開發者更了解 Amazon EKS 整合 GitLab 的 QA 系列

Q:使用 Amazon EKS 之後,如何更有效率或優化資源去配置 Worker Node 的機器數量,以及如何有效空管開發維運的成本?

A:Kubernetes 除了本身有 HPA(Horizontal Pod Autoscaling)可根據使用程度自動調整資源流量,另外也能延伸使用 AWS Auto Scaling 方案,針對可擴展資源去設定自動擴展管理。另外在成本管控,雖然 Amazon EKS 會收取額外管理費用,但可透過 AWS 平台的 Calculato r計算每個 EKS 的價格,你會發現自動化部署及管理的費用,相對工程師人力的成本更加便宜。

Q:越來越多客戶考慮把現有 Application 變成容器部署,大多是爲了加快部署的效率,那麼變成容器模式之後,對 CI/CD 的工作流程有什麽影響嗎?

A:運用容器技術最直接的效果,可以讓應用程式的環境更一致化,例如 testing 環節、stage production,讓容器避開一些差異問題。至於 CD 部分要 delivery 一些 usage 不太一樣的時候,容器會幫忙做配置,所以 CI/CD 對容器的效益是相輔相成的。

Q: 客戶在開發流程漸漸會把 Infrastructure 變成代碼或文檔,是不是可以把程式碼跟現有的應用程式的 CI/CD 流水線整合在一起,達到一套完整的 CI/CD 部署流程?

A:觀察目前市場作法,主要分成兩個階段去做整體部署。如果規模比較小的團隊,會把 Infrastructure 代碼跟 App 代碼分開,在管理上會比較靈活;如果企業規模比較大,會有另外一個 Infrastructure 團隊來控制部署事情,這種情况之下,APP 的項目會生成一個 APP package,主要做到 delivery 這個階段爲止。而 Infrastructure 的項目會指定把需要版本的文檔,部署到他們的 Kubernetes Cluster。

填寫表單 找到適合的快速上雲服務與工具!


猜你喜歡