【Lynn寫點週報】不會進軍銀行業:了解 Google 為何推出數位支票帳戶

支票帳戶服務能讓 Google 從數位廣告業務中賺到更多錢,花旗銀行也能從中接觸更多客戶。
評論
評論

Google 的支票帳戶服務絕對不是要跟 Apple Card 競爭,網路公司與金融機構合作都是為了讓使用者從口袋中拿到更多的錢,更多的是合作而非競爭。

關於 Project Cache ,這是 Google 傳出要跟花旗銀行、史丹佛信用合作社推出的數位支票帳戶服務(Smart Checking Account)專案,西方媒體都說是要跟 Apple Card 抗衡,還表示網路業全面要跟銀行業開戰, Google 此舉被視為進軍銀行業的指標,這個論點難免讓人好奇其正確性。

Project Cache 其實是 Google 要用來強化自身廣告產品「AdSense」的產品,透過與花旗銀行合作所開設的數位支票帳戶,方便廣告發布商(網站主)收取 Google 所提供的廣告獎金, Google Cache 整合進 Google Pay 之後能夠節省可觀的手續費與縮短收款時間,取代目前手續費高昂的銀行電匯與支票收款,讓更多中小型網站願意導入 Google AdSense 。

然後 Google 就能從數位廣告業務中賺到更多錢,花旗銀行也能從中接觸更多有價值的客戶。

開設支票帳戶是門賠錢生意

首先支票帳戶如果計入防洗錢與法律成本,那絕對是門「賠錢生意」,銀行不但要花一堆人力跟時間調查你的背景還有資金來源,還需要對監管機關報告,所以你現在如果走銀行進開戶,只說要存錢很容易被櫃員拒絕並踢出去銀行門外。

大多數情況下,你一定要假借「理財」的名義才可能闖關成功,因為銀行接下來才能藉由銷售理財產品獲利,否則純作開戶生意,個人存戶的金額很小,不符合成本效益,所以 Google 要從這項業務中獲利是很困難的。

有人認為 Google 可能會選擇向存戶收取支票帳戶手續費,那麼消費者不如去免費支票存款的銀行機構,不會有人選擇開設合作帳戶。

也有人提出 Google 希望分析使用者的存款、支出等數據以強化 Google 的廣告效益。但網路公司很可能拿不到使用者的數據,像是存款餘額、每月進出款項之類的私密數據,銀行跟監管機關不可能會讓 Google 拿去進行分析。

對於 Google 與花旗銀行共同開設支票業務的動機,我只想得到一個可能性:提高「Google AdSense」的成本效益。

Google AdSense 付款成本過高

Google AdSense 是 Google 讓外部網站掛上 Google 廣告欄位的產品,就是那些我們在網站上看到的煩人廣告,讓網站使用者可以用流量賺錢,它同時包含一套付款流程,YouTube 也是走 Google AdSense 的認證系統來付錢給 YouTuber 。

開設廣告的網站主必須通過一連串嚴格的防洗錢審核(KYC)才能收取 Google 的廣告獎金,包含詳細的個人資料與帳單地址認證, Google 提供的收款方式包含西聯匯款、銀行電匯或是支票收款。

銀行電匯是指傳統的跨國匯款,手續費雖然合理,但單筆匯款也需要數十美金,對於中小型網站主並不划算;西聯匯款雖然免手續費,但有 5,000 美元的單筆額度限制,也要有代理處才有辦法收款,像台灣現在只剩下京城銀行有在辦理這項業務,所以現在大多人仍選擇電匯方式進行,另外第三個「支票收款」則是最麻煩的選項。

支票收款是由 Google 以「普通郵遞」把支票寄出,美國境內約 2-4 週,跨國可能需要到一個月,網站主收到後才能拿去銀行存入帳戶,過程不但耗時又沒有效率,支票也有遺失的風險,有些銀行也不會代收 AdSense 的支票,而且支票代收的手續費是三種收款方式中最貴的選項,單筆要 35 美元起跳,值得注意的是,目前所有 Google AdSense 的付款支票均由「花旗銀行」負責開立。不符合成本效益,

由此可知,花旗銀行早就是 Google 長年以來合作的開票夥伴了,這次將花旗銀行納入 Project Cache 並不意外— 兩者早已建立成熟的付款流程與合作關係。

Google 支票原先就是花旗負責開立,透過合作帳戶收款可省下大筆費用

也就是說,如果透過 Google Cache ,以後廣告收款人直接在花旗銀行開立支票帳戶,付款就不用這麼麻煩了,由 Google 直接付款到該帳戶即可,不用再郵寄支票,過程省掉許多紙本作業的成本跟時間,如果走傳統跨國電匯的話,也可以省下中轉行的手續費,讓付款流程更具成本效益。

合作帳戶這項舉動預計可為網站主省下可觀的手續費,因此會有更多的網站主願意裝設 Google AdSense ,讓更多流量導進 Google 的廣告業務當中,花旗銀行也會藉此接觸到龐大的 Google 潛在客戶,因為未來會有龐大的網站主湧進花旗銀行開設支票帳戶,銀行可藉此推銷其他金融產品,可說是雙贏的合作計畫。

Project Cache 目的是拓展 Google 本身的廣告業務,沒有任何要跟傳統銀行搶生意的意思,也不會是 Facebook Pay 或 Apple Card 的競爭對手,後者是各大網路公司為了強化本身的業務才選擇與銀行串連金流,讓使用者在網路上更容易消費或是幫助業者推廣他們的商品。

網路公司與金融機構更多的是合作,而非競爭

舉例來說,近期推出的 Facebook Pay 本意是要拉高中小型企業主投放廣告的預算,他們認為消費者如果可以直接購買廣告上的產品,不用導流到第三方網站,例如蝦皮、露天等網站,廣告主會願意投放更多的預算在臉書上。

另一個例子,現在不管企業或個人要舉辦活動、講座或是聚會都是透過 Facebook 宣傳,如果可以直接在 Facebook 上完成購票跟領票,那麼這些企業是不是會更願意投放廣告預算在臉書上?

由於中間少了一層導流到第三方票券平台或購物網站的程序,直接將廣告預算轉化成營收,可以提高社群平台對廣告主的吸引力,進而砸更多錢在臉書廣告上,這就是 Facebook 一直極力推動社群平台支付服務的主要動機。

Apple Card 則是希望消費者能進一步被綁定在 iOS 生態之中,將 Apple Pay 用於訂閱蘋果生態系的各項軟體產品,例如手遊 APP 內購、 Apple  Music 、 TV 、 Arcade 等服務,於是找了高盛來為他們發行卡片,也拉高日後跳到 Android 的門檻,因為使用者早就習慣用這張卡進行消費,如果不用 iPhone ,日後的消費跟扣款都會變得很麻煩,讓使用者牢牢地綁死在蘋果產品中,蘋果還可從中賺取軟體營收。

網路公司進軍銀行業不符合成本效益

截至目前為止,網路公司還沒有辦法攻入傳統金融公司的業務,因為網路公司不知道如何承擔傳統金融機構業務的法律遵循與監管要求,限制重重的金融法規也難以融入網路公司的組織架構中,並不符合成本效益。

相反的,網路公司與金融機構兩者互相合作以增加綜效的例子反而更多,網路公司藉由整合金流來讓功能更多元、更容易引誘使用者從錢包掏出現金,想想沒有 Apple Pay 或是 Google Pay 的年代,每次購物都需要反覆輸入卡號與安全碼,現在有了支付功能,直接進行解鎖認證就能購買成功。

好比手遊課金一樣,一個按鍵就能立即刷卡,購買後虛擬寶物或點數瞬間送達到道具欄內,不久後將會進化到社群網站的廣告一旦跳出,使用者點擊後可以直接下單、一鍵支付完成後便讓貨物送抵家門。

「晚上購買,隔天早上起床就踢到包裹」。

網路金流整合會讓線上消費越來越容易,使用者錢包失血的速度相對也會越快,這將導致其他沒有與網路公司合作的金融業者感受到不小的壓力,害怕自己逐漸在金融零售市場被邊緣化。  

核稿編輯:Anny

延伸閱讀:



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

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