Trino Gateway

先前一直有在追蹤 TrinoHA 方案:「High Availability #391」,昨天看到有人更新消息,提到 Trino Gateway 這個專案,以及九月底的時候的公告:「Trino Gateway has arrived」。

主要是從 Presto Gateway 整理出來的:

The release is the result of many, many months of effort to move the legacy Presto Gateway to Trino, start a refactor of the project, and add numerous new features.

原始的 Presto Gateway 專案上面也已經標示後續請大家去看 Trino Gateway:

NOTE: This is a legacy version of Trino Gateway. Please refer to https://github.com/trinodb/trino-gateway for active development and updates moving forward.

然後 Release notes 這邊可以看到前幾天又出一個新版了,看起來是有能量在專案上的。

從「Design」這頁可以看到軟體本身分成 BaseApp、ProxyServer 與 Gateway 三個部分,架構面上可以看得出來是 Proxy 架構。

從「References」這頁可以看到一些組織使用前身 Presto Gateway 的心得:

目前應該會需要一些時間,把積在 backlog 的功能開發出來。之後如果還有遇到 Trino 的話可以拿出來重新研究發展到什麼地方...

OpenTF 開張

前陣子有提到因為 HashiCorp 沒有正面回應 (如預期的) 授權的爭議,所以決定將最後一個 open source 版本的 Terraform 給 fork 出來:「OpenTF 宣佈從 Terraform 最後一個 Open Source 版本 fork 出來」。

剛剛在 Hacker News 上看到「OpenTF repository is now public (github.com/opentffoundation)」這個,OpenTF 正式開張了。

瞄了一下 issues,初期還有蠻多雜事得處理的,但跨出第一步了,可以看看社群的能量到底有沒有超過 HashiCorp 自家的能量...

Amazon EBS 十五週年,以及一些數據

AWS 的 SVP James Hamilton 寫了一篇「Amazon Elastic Block Store at 15 Years」在講 Amazon EBS 的十五週年,裡面提到了一些數字。

目前的每天的 IOPS 是 100 trillion,如果攤平的話大約是 11.57 billion IOPS/sec,如果很單純以目前高階 NVMe 卡大約是 1M IOPS/sec 這個數量級來算的話,在沒有任何 redundancy 架構,需要的量大約是萬張?以 AWS 的量感覺好像是個合理的數字... 考慮到 IOPS 主力應該是 SSD 或 NVMe 類的應用,加上 redundancy 以及保留 burst 空間的架構,最少有個十萬張... 應該不算有問題。

I asked the EBS team to quantify customer usage in 2023, the 15th year of EBS. Focusing first on daily usage, EBS delivers more than 100 trillion input/output operations per day.

另外一個是傳輸量,每天有 13EB,攤平大約是 150.46TB/sec,如果用上面提到的十萬顆來攤的話大約是需要 1.5GB/sec 的速度,拿數量級來算應該是差不多。

Perhaps even more staggering is the fact that EBS transfers more than 13 exabytes of data for customers every day.

另外一個是百萬客戶 (也許是帳號) 每天會開出三億個 EBS storage,我猜這跟機器的起起落落有關,現在 EC2 開機主要都是要掛 EBS 的 boot disk 了:

Continuing to focus on daily usage, millions of customers use EBS daily, and these millions of customers create more than 390 million EBS storage volumes each day.

的確如同 James Hamilton 說的,EBS 現在已經變成一個蠻重要的基礎建設了,很多 AWS 上的服務都是架在他上面,像是 RDS 利用了 EBS 的 block replication 組出了 readonly repica,而非走傳統的 replication 路子。

Twitter 的 2022 年架構 (?)

Elon Musk 自己貼了以後,有人把白板圖整理成數位圖後好讀一些:

不過心裡可以先有底,這是解釋給大老闆聽的架構圖,底層可能還會有不少東西是沒有在這上面的,尤其是其他重要的子系統,像是圖片與影音怎麼處理之類的。

先把圖拉出來看原圖大小 (可以自己點),比較清楚一點:

從最前端往後看,可以看到 TLS-API 被標成淘汰中,照圖上寫的剩下 Android 版本在用,後續應該是往 GraphQL 靠;另外內部有使用到 Thrift,但沒有標 gRPC,我猜是這邊的主線上沒有 gRPC 而已,其他系統可能還是會有。

另外是有些東西有標 next-gen system,應該就是正在做而還沒上線的東西。

Ansible 的爭論

前幾天在 Hacker News Daily 上看到「Five Ansible Techniques I Wish I’d Known Earlier」這篇,裡面提到了一些 Ansible 的用法還蠻有用的,算是開始用 Ansible 後應該都會有幫助的用法... 不過 Hacker News 上的討論「Ansible Techniques I Wish I’d Known Earlier (zwischenzugs.com)」比較精彩...

目前在頂端的留言對 Ansible 幹到不行,尤其是那個 YAML 格式:

Ansible is abysmal. I don't know why anyone still chooses it. It's a mess of yaml and what feels like a million yaml files that is always extremely hard to follow. Honestly writing some python, or bash is a lot easier to follow, read, and understand. The only thing it has going for it is the inventory system. I wish ansible would die already.

然後講到 bash 與 python 之類的工具時有人提到 idempotent:

>bash and python
Neither of those of idempotent.

馬上就有人幹勦,大多數人在寫 Ansible playbook 時根本沒人在注意 idempotent,而且一堆 shell script 的東西被塞進 YAML 只能說痛苦 XDDD

Most of the ansible roles I come across written by my team are not idempotent either, its a huge lie that Ansible is idempotent. Its idempotent if you put the effort into make it be but if I see tons of shell or command module invocations without prerequisite checks to see if the work should be done. Most devs I see using Ansible treat it like a shell script written in YAML and to that purpose it sucks.

我自己目前會挑 Ansible 主要還是因為 server 不需要另外裝軟體,是個 production 為導向的設計,再更大的時候就要想一下要怎麼繼續搞下去了...

Terraform 進入 1.0 版

HashiCorp 的東西都還蠻有品質的 (相較於其他的類似方案),其中有一個觀察到的特性是,如果他門把版本維持在 0.x,代表他們自己對軟體的品質與成熟度都不算滿意。

Terraform 算是他們家對於基礎建設資源管理所提出的方案 (尤其是雲端時代的資源),不過之前最頭痛的,每次升級就會發現有些基本的概念會被改掉,所以不是改改關鍵字就可以解決。

這次 Terraform 推出 1.0 版,代表了他們認為產品有一定的成熟度:「Announcing HashiCorp Terraform 1.0 General Availability」,另外在 GitHub 上面的「Release v1.0.0 · hashicorp/terraform」也可以看到:

Terraform v1.0 is an unusual release in that its primary focus is on stability, and it represents the culmination of several years of work in previous major releases to make sure that the Terraform language and internal architecture will be a suitable foundation for forthcoming additions that will remain backward compatible.

另外也可以從他們對相容性的宣示「Terraform v1.0 Compatibility Promises」看出來他們覺得架構上成熟了:

For all future minor releases with major version 1, we intend to preserve backward compatibility as described in detail in the Terraform v1.0 Compatibility Promises. The later Terraform v1.1.0 will, therefore, be the first minor release with new features that we will implement with consideration of those promises.

總算是開始進入會考慮 backward compatibility 的週期了...

AWS 推出了與 5G 結合的 AWS Wavelength

看到「Announcing AWS Wavelength for delivering ultra-low latency applications for 5G」這篇,裡面提到了與 5G 結合的 AWS Wavelength

裡面提到的東西包括了把 AWS 的架構延伸到各家電信的架構裡面,看起來跟剛推出的 AWS Outposts 有關 (參考「AWS Outposts 總算要開始出貨了」這邊的介紹):

AWS Wavelength brings AWS services to the edge of the 5G network, minimizing the network hops and latency to connect to an application from a 5G device.

然後目前已經公佈的,會跟四家電信業者合作,包括北美、歐洲、日本與南韓:

AWS is partnering with leading telecommunications companies around the world, including Verizon, Vodafone, SK Telecom, and KDDI, to launch Wavelength across North America, Europe, Japan, and South Korea in 2020.

有點噱頭,但技術上還在想有什麼用...

各種對 AWS Managemenet Console 的抱怨...

Hacker News Daily 上看到 Reddit 上面有一篇對 AWS Management Console 的抱怨文,差不多是兩個月前開始累積的:「I am stupefied every day by the awfulness of the AWS web console」。

AWS 的主力開發因為是以 API 為主,而 AWS Management Console 能做的事情一直都少蠻多的 (看起來是一個團隊在開發,然後呼叫 API),而且的確是常常中 bug,所以會有這樣的抱怨其實不太意外...

然後就有人放火了:

[–]canadian_sysadmin 24 points 2 months ago
I see you've never used Azure...

[–]myron-semack 18 points 2 months ago
AWS’s console sucks because they don’t give a damn about UI. They are API-first.

Azure’s console sucks because they tried to make it nice but failed.

[–]ryantiger658 5 points 2 months ago
I was scrolling looking for this comment. Azures interface has made me appreciate AWS even more.

Azure 被偷戳了好幾下 XDDD 然後 GCP 也被偷戳了:

[–]edgan 1 point 2 months ago
It could br better, but it is far better than than Azure and GCP. Azure's old one was better than their new beta interface last I saw it. GCP has some interesting ideas, but the side bar centric design doesn't function well. It also tries to do too much, and is too JavaScript-y happy.

通常用 AWS 自己的 CloudFormation 或是第三方的 Terraform 管理還是比較常見的方式 (基於 Infrastructure as code 的概念),而 AWS Managemenet Console 當作是輔助,因為目前的雲端服務在設計上的確是希望你多用 API...

Apache Software Foundation 把程式碼交給 GitHub 託管

ASFGitHub 兩邊的新聞稿都釋出了:「Apache Software Foundation joins GitHub open source community」、「The Apache® Software Foundation Expands Infrastructure with GitHub Integration」。

整個搬到 GitHub 上面省得自己管,而且這個年頭的開發者 (至少是 ASF 這群) 大多也都熟悉 Git 與 GitHub 的操作,轉移過去的學習成本不算高...

另外就是一堆既有的服務 (像是 CI/CD 類的) 都有支援 GitHub,不少對 open source project 是有免費方案可以用的,只需要按幾個鍵授權就好了,不用自己架設...

Dropbox 在全球建機房加速...

Dropbox 為了加速傳輸,在全球到處建機房降低 latency:「Infrastructure Update: Pushing the edges of our global performance」。

就他們測試發現,透過 proxy server 降低 latency 的效果很不錯:

We’ve tested and applied this configuration in various markets in Europe and Asia. In France, for example, median download speeds are 40% faster after introducing proxy servers, while median upload speeds are approximately 90% faster. In Japan, median download speeds have doubled, while median upload speeds are three times as fast.

亞洲區是效能增加最多的...