曾引發Google與Uber訴訟大戰的自動駕駛天才創辦Kache.ai,將捲土重來與兩家企業為敵

Levandowski 是自動駕駛產業的研發天才。從Google 自動駕駛部門出走後創業打造出自動駕駛卡車公司 Otto ,而後被 Uber 收購引來了一場巨頭之間的法院大戰。這次創辦自動駕駛卡車 Kache.ai, Levandowski 可能正在累積大絕招。
評論
評論

本篇來自合作媒體  雷鋒網  ,INSIDE 授權轉載。

還記得那個讓 Google 和 Uber 撕破臉皮告上法庭的 Anthony Levandowski 嗎?(參考 INSIDE 此前報導: Google 告 Uber!疑似前員工從子公司偷了自動駕駛核心 技術 )他簡直是打不死的小強,又帶著自己的新公司 Kache.ai 回到自動駕駛的大舞台了。

Levandowski 新話劇的第一章已正式開演

不可否認的是, Levandowski 是自動駕駛產業不可多得的研發天才。他先是攜自己的自動駕駛摩托車在 DARPA 挑戰賽上一戰成名,後又憑藉能力在 Google 自動駕駛部門扶搖直上,接著出走創業打造出自動駕駛卡車公司 Otto ,而後被 Uber 收購引來了一場巨頭之間的大戰。

這次重回自動駕駛產業, Levandowski 的方向還是自動駕駛卡車,現在的 Kache.ai 還不為人所知, Levandowski 可能正在累積大絕招。

其實七個月前這家公司就正式註冊誕生了,但 Kache.ai 一直沒對外透露半點風聲,即使深挖各種文件, 普通人也難以發現 Levandowski 與它有任何關聯。

在公司的註冊文件上,總裁一欄填著「Thomas S. Lee Jr」的名字。在 LinkedIn 上搜索一番你會發現他是一位軟體開發者,此前就在聖地牙哥創辦過兩家公司。奇怪的是,在 Kache.ai 被人挖出後,所有關於該公司的訊息都在 LinkedIn 上消失了。

不過,公司註冊文件上的地址卻讓人生疑, Kache.ai 的誕生地是加州聖赫勒拿,而 Levandowski 生父和繼母是公司資產的實際控制人。值得一提的是, Levandowski 的繼母 Suzanna Musick 是該公司執行長,而此前她還擔任過 Levandowski 創辦的 510 Systems 的執行長。

雖然 Kache.ai 並未回應這份曝料,但自動駕駛產業內一位消息靈通的人士確認, Kache.ai 與 Levandowski 本人關係密切。

目前關於這家公司的訊息還極為有限。不過有人猜測:「Kache is not ‘cache', it is Chinese for truck (卡車).」(Kache 不是「cache」,而是中文「卡車」的意思。)

這種猜測可能最接近事實。「Kache」這個詞符合中文漢語拼音的寫法,也符合「卡車」的中文發音,也就是說,這家自動駕駛卡車新創公司可能與中國有關。

來中國有兩個目的:一方面, Levandowski 想在中國尋求促成自動駕駛卡車上市的合作夥伴(物流公司是首選目標);另一方面,他也想為新公司尋求新的融資。但後因行程原因未能成行。

官網被「大清洗」前的圖片, Kache.ai 主要業務是什麼一目了然
官網被肉搜前的圖片, Kache.ai 主要業務是什麼一目了然

Kache.ai 的官方網站設計相當簡單,它只是簡單描述了自己的願景且只有 Lee 的郵件聯繫方式。在被知情人士曝光後, Kache.ai 的官網已經一片空白(如下圖),只剩下一張滿是起伏連綿山脊的圖片。

另外,此前網站上的招聘訊息還寫道:「我們正在開發下一代公路自動駕駛卡車解決方案。我們的發展理念需要效率快速且積極敏捷的團隊來支撐,因此我們正在尋找有志的軟硬體工程師。」

顯然,這家公司正在瘋狂招人,無論是地圖、資料庫還是機器人和模擬技術人才都是 Kache.ai 招募的對象。除此之外,這家公司還也急需卷積神經網路軟體工程師、電腦視覺和機器學習演算法技術人員。

需要注意的是,網站顯示 Kache.ai 的總部位於舊金山。

一個看起來不大可能的回歸

如果把時間調回一年前,恐怕大部分人都不敢相信 Levandowski 還有勇氣重新站上自動駕駛的舞台,但在他此前的同事和熟悉的人眼裡, Levandowski 怎麼可能會被這樣的挫折打倒。

不過,現在猜測這位自動駕駛天才回歸的還都基於傳言與推測。

在自動駕駛這個概念還沒火起來之前, Levandowski 一直是支持這一技術的智囊團成員,不過當時大家都還醉心於學術研究。

不過,2004 年的 DARPA 自動駕駛挑戰賽卻改變了一切,15 個車隊在沙漠中的廝殺徹底點燃了整個產業的熱情,而當年的 Levandowski 是唯一一個帶著兩輪車參賽的奇才。現在,在這輛被命名為「惡靈騎士」的戰車已經成了史密森尼美國歷史博物館的藏品。

第一屆 DARPA 比賽中,15 支參賽隊伍全團滅亡,這一結果隨後又讓 DARPA 舉辦了兩屆自動駕駛挑戰賽,而當年的參賽者中,有許多都是如今自動駕駛產業的中流砥柱, Levandowski 就是他們中的一員。

2007 年, Levandowski 正式入職 Google ,他成為 Google 街景項目的「首席架構設計師」之一。在 Google 工作時,他還打造了 510 Systems,這家公司製作感測器,而且反賣給了 Levandowski 的東家 Google 。510 Systems 也算得上是雷射雷達技術的先驅之一,2011 年 Google 花大錢收購了 510 Systems 和 Levandowski 的另一家新創公司。

雲霄飛車式人生

在 Google 待了九年後, Levandowski 選擇離開,他這一走還順便挖走了 Google 員工 Lior Ron。隨後,他們共同創辦了自動駕駛卡車公司 Otto 。

Otto 誕生的時機實在是太有先見之明了。當時,自動駕駛的風潮正在不斷升溫,許多有遠見的公司都開始投入這一產業,而各家公司之間的競爭也帶來了大量的熱錢,人才爭奪戰瘋狂開啟,許多經驗豐富的自動駕駛老兵身價驚人。同時,傳統汽車巨頭們也反應過來了,財大氣粗的它們通過瘋狂收購來尋覓自動駕駛人才。

風頭正勁的 Uber 就在 2016 年 8 月收購 Otto ,當時 Uber 花了 6.8 億美元,震驚業界,而那時 Otto 才剛剛創立幾個月而已。

可以這麼說,讓 Uber 一擲千金的並非 Otto 這家公司,而是 Levandowski 。不出意外, Otto 併入 Uber 後 Levandowski 成為 Uber 自動駕駛部門的負責人。

後續的事情大家都了解, Uber 因為知識產權和 Waymo 鬧上法庭, Levandowski 黯然離開, Uber 還不得不賠償 Waymo 2.45 億美金,這一切的發生距 Otto 併入 Uber 還不到九個月。除了 Levandowski , Otto 的其他三位創辦人也都離開了 Uber 。

Kache.ai 的下一個篇章

Levandowski 的回歸必然會帶來新的問題,他甚至會成為 Waymo 和 Uber 兩家公司的公敵。不過,在經歷了這麼多之後, Kache.ai 是否會繼續選用雷射雷達(涉及商業機密,是 Waymo 和 Uber 告上法庭的主要原因)還是一個謎。

其實,業內一些自動駕駛卡車新創公司就對雷射雷達「視而不見」,因為這些公司覺得這款感測器還不太適合在道路上高速運行的重型卡車。如果 Kache.ai 也繞過雷射雷達,至少能少惹不少麻煩,而且「清白之身」也更容易拉來投資。

眼下, Kache.ai 故事的開始依然與 Levandowski 不太光彩的過去緊密相聯。因此,未來這家公司能否在業界發出自己的聲音主要還得靠硬技術和產品。


開發者享受 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。

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