今天聽的內容
[TOC]
# What is web3
## polling / monitor web3

def pooling_event_from_nodes(
    from_block=0,
    to_block=None,
    step=3500,
    delat=0.5):
    """
    Polling event 
    """

## Cdk cronjob

## Transaction
1. 整個web3就是大型一致性交易資料故。
2. 每段時間便會將不定數量的交易請求完成並廣播。
3. 交易完成便不能回朔，但可以知道待交易的請求。
4. ERC20 / Value不是徵證存在錢包裡面。
5. 任何交易動作等交易完成才算數。
6. 不能排除有重組區塊問題ETH PSD可能需要等待至15分鐘才能做確認驗證。(重組區塊：可能交易行為整段出問題)

# Wallet Knowhow
## Wallet
1. Wallet 背後透過其實也是連到節點。
2. 前端是透過waller的AＰＰ去請使用者千數教億
3. 除非必要，不建議由後端送交易資訊
4. 透過Ecrecover實施使用者登入系統，原理是請使用者用撬安數資組訊息並驗證。
5. 錢包流暢度在手機端還不是很好，整合上要非常注意管理錯誤。

就像銀行的驗證機制一樣，需要一組使用者代碼的密碼，所以這些錢包其實也是依靠節點去判斷是誰簽的資料，以驗證是不是你本人的錢包。

## Auth
verify_proof
checksun_address = w3.toCheckSumAdd
EC_recover

* oauth2
* token(POST)
* userinfo(GET)
* authorize(POST)

# What diff in web3 and 2 in E-Connerce
Customer, Order, Payment

## Customer Comparison
| web3 | web 2 |
| -------- | -------- |
| wallet address | Email/phone number/username |
| can scan all history on blockchain |base on privacy policy|
|cannnot restore/reset|can restore/reset password|
|cannot contact customer|depends on username|
|cross website membership by NFT|Need Oauth /OIDC to get user info|

## Order
| web3 | web 2 |
| -------- | -------- |
| cannot return order if using tokens| return policy|
| physical items requires shipping address|need billing address and more personal data|
## payment
| web3 | web 2 |
| -------- | -------- |
| blockchain networking|public network (Some TLS required)|
| identity currency contract address（要自己寫好要用什麼幣值）|payment provider|
| can use NFT or bundle|Need implement coupon|
|Multi to multi（不同的幣排列組合）, depends on contract|one way|
|cannot cancel|with-holding（可以先扣款但不請款）|

## Purchase
Create order:Amazon API gateway-> aws lambda->amazon dynamoDB
Payment: browser fox wallet -> ooo
update payment status: amazon eventBridge->aws lambda->ooo
terraform 可以不用 amazon API gateway

show case: theremade.io

## Redeem system
1. check RNFT counts
2. create order
3. approve RE:VREAMER burn your tokens
4. burn tokens and redeem
5. update order status
6. shipment

# 新創上雲之商業模式與資訊架構演化史 天氣即時預報 on AWS
天氣即時預報
https://apps.apple.com/tw/app/%E5%A4%A9%E6%B0%A3%E5%8D%B3%E6%99%82%E9%A0%90%E5%A0%B1/id1277710469
* 將預報的資訊轉換成12種穿衣建議(根據氣溫、濕度、風向)
* 營利行為：品牌露出＋社群小編的文字

## 開發期
啟發：氣象專欄如果有很多人有看，那應該就很有用
天氣ＡＰＰ的痛點：
1. 突如其來的大雨：即時降雨推播系統，哪個地區，幾分鐘後，即將下雨
2. 呈現的方式：app介面的整合
3. 移動應用創新賽（認識蘋果總監）
4. 後臺架構怎麼崩潰的：每月不斷地燒錢

面臨挑戰： 伺服器成本高、系統穩定度低
## 商業化第一階段
如何轉換收益：人流轉金流->app轉金流只有兩種：購買時收費、收廣告（或賣個資）。
### 廣告格式：
* banner ads 橫幅廣告
* interstitial ads 插頁式廣告
* rewarded ads 獎勵式廣告(錢最多)
* Native ads-原生廣告(最能客製化、但不賺錢) -> 最後的選擇
* open ads 開屏廣告
### 系統穩定度優化
初期困難：流量高峰時不穩定、成本高。
加開EC2, ELB平衡流量。
與依雲谷合作（導入server less)
* Api fateway, Lambda
* User連入API gateway->lambda(轉址服務、GPS轉經緯度)->redis
* 與此同時 eventBridge->Lambda->Redis並且同步到RDS(Mysql)
成本降到原本的10%

* 案例分享
* 降低server負擔
* 快取: 不是用經緯度查詢（gps小數點六位後面四位通常不同）
* 全台共368鄉鎮
* google map金門無法取得鄉鎮資訊、部分路段無法轉換：解決方案：開發地理位置轉換程式。
面臨挑戰：
更新速度慢、廣告收益差
## 商業化第二階段
已經有套相對完整個架構
廣告聯播網五花八門(google admob（前最少）, meta audience network, applovin max（錢最多）, iron source)

* 廣告中介（mediation）
* 每個功能都要開發兩次：Flutter

目前架構
最下面：系統排程->用
繪圖
圖資更新

最右邊EC2:文章管理系統（wordpress)
面臨挑戰：全球化

* 阿波羅計劃
cloudFront->s3->api gateway
lambda: seo, jango

# 兼顧成本進行架構優化的地方智慧 Cost Optimization on AWS （上）
Jaffer Li@ trend Micro
* business engagement with aws
* you should know
* thchnical-oriented cost optimization solution
* contract-oriented
* management-oriented
* balance betwween cost, security, revenue

## start from why 為什麼要聽這個議題
* Your stockholder inquiry 股東的提問
* profit adn loss report const element 損益表費用
* revenus vs cost portion 收入成本佔比
* ESG 社會責任永續經營
* technical skill level raise 提升技術技能
* technical lifecycle refreshment 技術技能演進

## business engagement with aws 雲服務廠商供應模式
* Direct business(直接交易)
* partner business（代理中介商）

## you should know 前情提要
* Pay as you go | on-demand | spot |reserved
* AWS shared responsibility model in Iaas/paas saas
* reserved instance(RI)/saving plan(sp)
* availability vs durability(4個久和11個久的差異)
## technical-oriented
* provision on-demand or for-peak （最好找到的答案）
* low utilization resource | 使用量過低
* ex: low CPU specification
* Inappropriate access pattern
* cons of storage vs access | 儲存成本與存取成本
* ex: S3也就像是 FUSE: file system存取過高
* ex: Glacier (搬動資料成本超高，所以要想辦法打包)
* Technology refreshment
* newer technology price wins | 新技術成本相對較低
* ex: arm-based processor, gp3（GP2轉GP3先省20%)
## contract-oriented
* RI/SP management
* contract:1y,3y,marketplace
* converage range dilemma(覆蓋率的迷思)：不要一口氣全買來省錢，兩邊服的痛苦更高
* RI: AZ/regional/convertible(複選題)
* SP: regional compute/ML(複選題)
* AWS activate program
* contact aws sales 洽原廠業務
* Special discount contract from aws
* * contact aws sales 洽原廠業務
## management-oriented 成本優化管理
* Consolidated bulling tagging rules(不會省到錢，但你能更好知道錢用到哪裡)
* cost explore tag search key
* CE api understanding
* consolidated billing const allocation (加錢要先講清楚)
* group by account; roll up to service, department and BU
* shared const (RI/SP)
* cost and Usage feedback

## aws cost explorer
* console (required activate with IAM)
* consolidated billing on aws organization account
* tagging

## AWS trusted advisro
* business support (15000w 美金會是10~6%)
* challenges: multiple account consolidation 多帳號整合
## cloud one - conformity
* multiple aws account
* multiple cloud provider
* central compliance rule

## balance betwween cost, security, revenue
1,000,000,000,000 人生健康就是前面的那個1, 服務的資安事件也是那個1
所有的架構師都應當注意服務的營收及費用佔比、並且同時關注成本及安全事項。

# 兼顧成本進行架構優化的地方智慧 Cost Optimization on AWS(下)
Clay
## 情境說明
* 找代理商開發票
* 中小規模新創、組織扁平、
* 已經在ＡＷＳ上有幾年經驗
* 帳號數量少、帳單內容不多
* 帳務分析工具excel

## 省錢專案啟動

* 主管或公司支持。
* 研究帳單和排序、可行係
* 確認計費方式（小時ＶＳ次數）: hosting cost per month vs requests per month(tiles served vs hosting cost/month)
* 基本：買ＲＩ、saving plan, 已使用時間評估是否採購
* 看整年度支出（中間可能好看，但實際上增加了RI的成本也要考慮）
* e.g. 實際流程：會先去找大流量的支出項目（像是ＩＰＳ相關的lambda）然後才去做項目調整。

## 經驗分享：一般開發
* 原則是下班關機、使用cli, boto3
* 單一az網路資料流
* EKS node group 使用spot instance（要注意的是，選instance type要多選一些類型）
* cloudwatch logs 設定保留時間

## 經驗分享：正式環境
* 善用 auto scaling
* 清理EC2 volu,e 備份檔案等
* 使用G系列的ＲＤＳ
* 清理或合併load balancer
* 自動化備份和house keeping(EC2 Data life cycle manager, aws backup)
* compute optimizer 檢視EC2用量

## 制度化
* 在變更之前分析對費用之影響
* 新計畫費用評估
* POC或專案life cycle 管理：死掉的服務要刪除
* 定期review/調整架構

## Cost optimization pillar white paper導讀
* design principles:
* implement cloud financial management(雲端的財務管理)
* 費用告警
* 監控費用
* adopt a consumption model
* measure overall service
* Expenditure and usage awareness：把費用歸屬到對應團隊、使用tag標註、帳號管理、管管控使用的資源、分析固定和變動成本(EC2開機與運算的差別)。
* cost0effective resources
* 選擇服務時評出成本、定期review所用服務
* licensing cost可透過使用open source 講低
* select the correnct resource type size and number
* 在使用cloudwatch資料分析系統時候建議反應使用者體驗與時間區間
* AWS auto scaling, apis, sdls, s3 intelligent0tiering
* precing model: ondemand spot(服務可中斷)、Saving plan, RI, 地理位置選擇
* 優化網路相關費用 cloudfrontm vpc endpoint（減少走到internet)

* magage demand and suppluing resources
* api gateway throtting 和sqs的取捨
## take away
* 了解使用之ＡＷＳ服務計費方式
* 假設和求證，調整後隔幾天觀察是否有改善
* 控制成本和營收獲利的比率
* 善用服務進行自動化
* 追蹤新的服務可否省錢
* 寫文件傳承知識經驗