【Lynn寫點週報】為什麼大家怕微軟收購GitHub?除了形象問題,還有GitHub的政治中立立場

本週要來分析這週對許多開發者影響甚鉅的科技事件:GitHub被微軟收購的一事。如果微軟今天不想拖著 GitHub 一起"黑掉",最好的辦法就是直接創一家基金會或轉投資子公司,然後用這家公司的名義收購 GitHub 股權,最後沒人會知道他背後全資持有股東是微軟,還能繼續維持第三方中立機構的形象。
評論
評論

【Lynn 寫點週報】由 Lynn 為讀者精選 INSIDE 網站上 3 到 5 則最不容錯過的本週時事、並進行更深一步的點評討論,以協助讀者加深對於趨勢的理解。

輸入量暴漲 10 倍! 微軟收購 GitHub 案 GitLab 大獲漁翁之利

2018.06.05

建議閱讀時間:4 分鐘

這應該堪稱本週科技圈最大的新聞事件──微軟確認將以 75 億美元收購 GitHub,由微軟旗下的跨平台開發軟體  Xamarin  創辦人 Nat Friedman 擔任 GitHub 新執行長,而原 GitHub 執行長兼聯合創辦人 Chris Wanstrath 將加入微軟技術團隊。

早年因為商業軟體的營利模式、而和開源社群不合的微軟,竟然在收購了全球最大開源程式碼分享平台 GitHub。因為諷刺程度實在太高,還被對手 GitLab 發文道賀恭喜。

雖然微軟在新執行長納德拉上任後,近幾年大力擁抱開源和雲端服務,然而過往和自由軟體與開源圈作對的印象太強烈,稍早還出現了一波 GitLab 逃亡潮。現在 GitLab 流量這麼大,不知道又會不會有員工不小心來個 rm -rf 誤刪再發現所有備份全不能用,最後再在 YouTube 上直播看怎麼恢復?(參閱 INSIDE 此前報導:Gitlab.com 誤刪 300 G 資料,備份失效後直播搶救過程!

之前有 GitLab 有被 fire 掉的創辦以來第九號員工出來評論 GitLab 的企業文化也不是很開放、認為執行長有剛愎自用的問題,因此他決定不履行自己的股票選擇權;而另一方面 Google 在論文研究或軟體上也沒有多開源。然而今天若是 Google 收購 GitHub 還會有這麼龐大的逃亡潮嗎... 當然 Google 還是一家 "evil" 的營利企業, 但在許多人心中的形象還是比微軟開放的多,有時候真的只是印象經營的問題而已,人家愛用哪個服務憑的也就是個直覺。

尤其是自從 2014 年微軟新執行長 由 Nadella 接下後,該公司開始大力擁抱開源並積極轉型。GitHub 先前也發表過統計資料:目前微軟有 16,419 名開源貢獻者,登上開源人數最多的全球第一企業。如果這年頭還說微軟是家形象又" 黑" 又封閉的公司,那印象可能還停留在 2000 年而已,2018 年的微軟可說是洗的很白了。

另外也是微軟現在手上現金太多,2017 全年財報微軟現金與短期投資佔總資產高達 55.16%,每年軟體業務收進來的大筆現金都要苦惱著怎麼投資,與其放沒效率的放在手上或返還給股東,不如拿去收購新業務拓市佔。同時 GitHub 這邊也還在持續虧損,兩者剛好一拍即合。

如果微軟今天不想拖著 GitHub 一起「黑掉」,最好的辦法就是直接創一家基金會或轉投資子公司,然後用這家公司的名義收購 GitHub 股權,反正 GitHub 沒公開上市不怕被發現,而微軟只要用三層子公司架構也不會被要求在財報上揭露,最後沒人會知道他背後全資持有股東是微軟,還能繼續維持第三方中立機構的形象。

與其說微軟老實,不如說它大方公布自己買下 GitHub 就是為了要讓客戶都知道 GitHub 服務也包括在微軟的產品線當中,也能跟自家的 Azure 結合,求個品牌效益而已。畢竟 GitHub 和 StackOverflow 一樣,就算不停的虧損也已經是不能倒的一種精神指標,很多開發者會去上面看其他人的專案尋找靈感 或是同性交友

甚至這樣的收購是一種表態:我們支持開源是以行動來支持,GitHub 被我們養就很安全不會倒了。要表現自己擁抱開源及轉型為雲端公司的決心,用講的不如買一家知名的品牌進來,畢竟手上還持有許多會產生大量現金流的事業體,不怕燒錢。

不過最重要的一點還是:被收購後,微軟會不會屈服於國家的壓力去刪除一些政治性的 repo?即使上面有很多對中國不利的 repo,比如在講六四天安門或法輪功等等事件,而導致 GitHub 伺服器不斷地被 DDOS 攻擊,然而現階段的 GitHub 仍持續著自己的政治中立立場。這實在是很難得的一件事情(多少也是因為這種原因而造成虧損啦)。

另一方面,無論是微軟還是 Google,被當地政府索取使用者資料的時候都會退讓,最近又爆發出 Facebook 和華為等中國企業的使用者資料授權問題(參閱 INSIDE 此前報導:個資外洩事件越滾越大!臉書被爆與華為等中國企業共享資料),

GitHub 上有很多關於64、西藏或法輪功等被中國政府靜音的資訊。photo credit: GiHub
GitHub 上有很多關於 64、西藏或法輪功等被中國政府靜音的資訊。photo credit: GiHub

未來,就讓我們繼續拭目以待大廠買走 GitHub 的憂慮會不會成真吧。

除了一級玩家之外,復古熱潮造就了最近滿滿的雅達利新聞,還不趕快來看看 Lynn 的遊戲專題文嗎!

2018.06.01

建議閱讀時間:3 分鐘

最近關於雅達利的新聞實在很多。去年有美國團隊獲得雅達利的授權和 Al Alcorn 的支持,將 PONG 遊戲做成實體版的咖啡桌放到 Kickstarter 上做群募,還有 10 張限量版有 Bushnell 的親筆簽名。無論放在酒吧還咖啡廳都超潮的,呼朋引伴來玩這個簡直嗨爆。

雅達利公司自己也有與 Gameband 生產的最新穿戴式硬體廠進行合作,發售了一款名為 Gameband 2017 with Atari 的智慧型手錶,裡面預裝了 20 款經典雅達利迷你遊戲,包括「PONG」和打磚塊遊戲「Breakout」。

另外,雅達利今年還在在美國 E3 遊戲展上透露他們要推出新主機的消息。儘管很多人抱著質疑的態度,但現在看來這並不是一個玩笑。最新的消息是,雅達利在一封郵件中展示了這台命名為 Ataribox 的主機,首次全面公布它的外觀和部分細節。身為 Atari 2600(雅達利在 1977 年發行的遊戲機)復刻品,Ataribox 在造型設計明顯繼承了前作。 (參閱 INSIDE 此前報導:想重溫亞爾的復仇、打磚塊等經典遊戲的玩家久等了,Atari 復刻主機開賣!

最後要講一件悲傷的事情,今年的 5 月 26 日,與 Nolan Bushnell 一同於 1972 年創辦雅達利的共同創辦人 Ted Dabney 去世,享年 81 歲。由於 Dabney 因為理念不合的緣故,在 1973 年就把自己持有的股份以 25 萬美金全數賣給 Bushnell、離開 Atari 跑去開餐廳和雜貨店了,因此我在後面雅達利崛起的故事中沒有多提及這個人,但關於 Pong 街機的成功,有 Bushnell、有 Al Alcorn,當然也有 Dabney。

說了這麼多密密麻麻的雅達利新聞,還不包括今年三月的大熱電影《一級玩家》中對於雅達利滿滿的致敬。

photo credit: Inverse
photo credit: Inverse

如果你還不知道雅達利這家一說到遊戲產業就絕對必須提到的名字,就算後面帝國倒閉產業衰頹,在歷史定位上仍有著舉足輕重的一家公司,你要怎麼跟風復古潮流?怎麼知道歐美市場是在玩什麼的?怎麼知道一個產業的歷史文化背景?最重要的是… 怎麼抓到商機?說了這麼多,趕快來看看 Lynn 的雅達利商業策略分析文吧!

是誰作為幕後推手,塑造並操縱年僅 9 歲的髒話網紅 Lil Tay?

2018.05.30

建議閱讀時間:6 分鐘

9 歲小女孩 Lil Tay 在網路上因為狂飆髒話炫目跟假裝吸大麻成為網紅,在很重視兒童權益的北美社會都十分擔心。之前 INSIDE 有一篇新聞講過 Lil Tay 的母親是加拿大某家房地產公司的仲介商,因為這樣帶小孩而被炒魷魚。(參閱 INSIDE 此前報導:9 歲網紅 Lil Tay 高調炫富人氣狂飆,媽媽因此被炒魷魚

Photo credit: Lil Tay @liltay on Instagram
Photo credit: Lil Tay @liltay on Instagram

看到新聞的瞬間,一個十分困惑我的疑問便浮現出腦海:聽起來是中產階層的小康家庭,而非家庭環境因素不得以讓孩子接收到這樣的教育(小孩子能罵出這麼多髒話和成人用語真的很令人瞠目結舌),是家長為了靠小孩成名撈一筆才有的結果?Lil Tay 後續被記者查到的背後團隊經紀人出來解釋,表示其實是因為我們都老了、才不能理解現在年輕人想要表達自己的獨特聲音。

在 2017 年美國調查,有高達 70% 以上的美國小孩希望可以成為 YouTuber、Vlogger 或線上影音相關的職業。還有家長專程送小孩去上網紅訓練班。

以 Lynn 自己寫網誌的經驗來說,我覺得讓孩子自己學著經營網紅品牌來說並不是件壞事。只是第一最好是國小以上,第二是成人要在旁邊引導向正確的心態(質重於量)。收穫正反面都有。缺點的部分是青春期間可能更容易過度在意外外界言論把自己弄得心神不寧,或是為了求關注度而做出傷害自己或他人的行為。

然而以我個人目前經營的結論仍是利大於弊。無論是藉由發圖文或寫作評論,在這個年代為自己做到內容行銷是很重要的事情。與其說網紅,更好的說法是個人線上品牌,因為網紅是求紅、品牌是求品質。

主要好處有三點。一是交朋友:認識更多不同背景的讀者、得到更多討論交流的機會。二是潛能開發:逼我開發一些技能樹,包括文筆溝通、經營社群帳號、錄影拍照、訓練口條等。

三是幫助他人的責任感建立:觀察旁人是否需要幫助,有什麼樣的需求,而因此對旁人傳達某些觀念或資訊,比如開箱文分享或正能量的鼓勵等等。過程中要把資訊確認好並溝通清楚,以免有誤導的問題;同時對自己說過的言論負起責任,學著承擔語言的力量,瞭解哪些是能公開講的話哪些不行。

以上都是小朋友可以經營自己的社群網站或拍影片直播的理由。有些家長會完全禁止孩子使用智慧型手機或上 FB / IG,但我覺得不用到成年,才要適應並學會如何在資訊快速流通的社會中篩選資訊、有效率的傳達自己的聲音等等。雖然連我自己在內的成人可能都還很難完全理解,然而網紅在現在的確是一種社交方式。

Lil Tay 的問題是無法確定她現在說的是不是自己真正的想法,還是由成人寫的腳本讓她照搬而已,有些字眼或許連她自己在使用上都不是完全理解意思,酸民對她的攻擊言論有些也有牽涉到色情的謾罵。我想在孩童的自我認知都還未形塑完成的時候,就讓她直接往某一個成人訂定的人格方向走,是真的滿危險的......。

------

今天的週報就到這邊結束啦,讓我們下週見!


開發者享受 CI/CD 價值!運用 Amazon EKS 整合 GitLab 創建自動化部署

企業如何在 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 部可以獲得以下三大好處。

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

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。

了解 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。

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