返回網站

前端資源成本控管

由於一直以來都會需要做成本的控管與評估,比較少看到相關的討論,這次來分享一下我們團隊如何評估與降低成本的方式。

· 團隊雜感

 

broken image

                                                                                     Photo by olieman.eth on Unsplash

(以下的 $ 都是美金喔)

(以下的 $ 都是美金喔)

CI/CD tool

大家最推的就是 netlify 啦,一開始我們將 ci 都丟去 netlify 處理,無腦又有 pr preview url。不過其實 netlify 也不是吃素的,隨著團隊長大,pr 變多,測試變多,程式變多,隨之而來的就是 netlify 所要執行的時間就會拉長,我發現開銷越來越大,因為超過的 build time 收費更高。而且他還是 per member 收費的。即使你共用一組帳號,$19/month per member + 1000 minutes /month(then $7 per 500),光 build time 每個月就會花到將近 $100。

broken image

之間我們也一直在減少 build time ,或者是讓某些 pr 不要執行,或減少 daily build 的次數,但覺得還是有點事倍功半,或者一直在犧牲品質,後來決定自建 CI/CD 這條路,降低對 netlify 的依賴。

如果只算 build time ,以一個月 8000 min 來估算的話

broken image

FE@verybuy bitrise

去年底推出了一個 Gen2 的方案,而且當時說即將在今年中強制要換掉,跟他們技術窗口確認了一些技術細節,覺得換了實在太貴,我們如果不改架構的話直接移轉過去大概一個月要噴 $800,換到的好處是 build time 快兩倍。當時評估實在不太划算就先擱著,還好後來他可能發現推不動,取消了這個強制換方案行動。🥳

Testing

broken image

($10 Per User / Month)

codecov 是拿來 monitor code coverage 的工具,也可以幫你在 pr 檢查 codecov 品質的一個工具,非常好用,不過免費和付費的價格差的有點多,我們現在還在當免費仔,5 個人使用不用錢,人多的話就把 senior 踢掉(senior 多數已經內建 code coverage 在心中了)。

broken image

 FE@Verybuy code coverage

Development/Production

lambda/Cloud function

雖然是前端還是免不了會有一些需要後端處理的事情需要做,通常會是比較跟會員/db 較沒有關係的事情,我們選擇用 AWS lambda 來處理,價錢也比 GCP 便宜,支援/整合的程度也比較高。

broken image

 

S3 的計價分為呼叫次數與流量,呼叫次數非常便宜(PUT $0.000005, GET $0.0000004),基本可以忽略,需要注意的是流量費用,送進去不用錢但拿出來要錢,但也還是很便宜啦,幾乎也可以不用太在意。

broken image

 

Analytics/Log

firebase

firebase 也有許多付費功能,不過我們主要用到的推播,dyncmic link,analytics 都是免費的,真是佛心。

Google Analytics

這應該不用介紹了,總之就是埋 log ,免費。

sentry($26/month)

sentry 拿來追蹤 error log 的,我們用的是最便宜的方案,基本每個月都爆掉(XD),主要是我們有自己的 log server,但他好處是可以 trace code,所以還是可以做一些更細緻的追 log 紀錄。

小計

  • netlify: -$117
  • bitbucket pipeline: $55
  • bitrise: $31.5
  • codecov: -$50
  • TestRail: -$36
  • Cypress: -$75
  • lambda + s3: 根據專案大小評估開銷
  • sentry: $26

每個月:

  • 共節省:$223
  • 共花費:$112.5

(有些服務可以買年費會比較便宜,這邊只是大概估算)

小結:

以上大概是我們前端 Team 的預估花費,可以當作前端團隊評估或提交預算的一個參考,當然如果公司資源多不 care 這點小錢以開發順手最重要囉。

(也有可能是摩羯如我生性節儉啦 🤣🤣。)

個人認爲對那種 per member/per scale/per request 的收費方式都要小心一點,如果 scale up 是會讓成本大幅提高的話,就需要考慮自建的可能性了,就像最一開頭提到的 netlify,當時也是令我又愛又恨,一方面他減少許多開發時的心力,但隨之而來的是每個月不斷增加的帳單,所以才開始評估自行開發的可能性。關於這個議題可以參考我之前的文章:前端邁向 DevOps 之路(Pull Request Preview URL) 💪

如果你覺得這篇文章對你有幫助的話請不吝給個 👍👍👍👍👍

文章出處是Bingo的Medium Blog,內有其他軟體工作的相關技術與心得文,歡迎點閱