Atlassian 將消滅 Server 版本

Hacker News Daily 上看到 Atlassian 打算消滅 server 版本:「Moving to a cloud future, together」。

話說回來,之前工作時用 Jira 的時候 (雲端版本),所有人都抱怨 Jira 慢到爆炸的問題不知道解了沒,當時記得每個按鍵都要 10+ 秒才會反應,不管是在台灣還是在香港都很慢,然後在公司反應了十個月也都沒什麼改善 XD

至於官方說要推 cloud 版本的理由聽聽就好,Hacker News 上有些討論反而還蠻有趣的,像是講到裡面同時在維護 Cloud 與 Server 版本時遇到的問題,看起來團隊沒有足夠的能量處理這些東西:「Atlassian moving to cloud-only, will stop selling server licenses (atlassian.com)」。

另外一個是討論裡面提到的替代方案,看起來也不算很好的替代方案啊,出現 MediaWiki 作為 Confluence 的替代品,少了 WYSIWYG 其實門檻高不少耶...

來看看這波反應會有多大 XD

Chromium (Google Chrome) 實做對 Root DNS 的影響

前幾天在 APNIC 上的這篇文章受到社群注意:「Chromium’s impact on root DNS traffic」,在 Hacker News 上也有對應的討論:「Chromium's Impact on Root DNS Traffic (apnic.net)」。

文章作者 Matthew ThomasVerisign 的員工 (Verisign Labs),可以看出來主力在 DNS 的部份。

Chromium (以及 Google Chrome) 會隨機產生一組 hostname,確認所在的網路是否有 DNS hijack:

這導致了在 Root DNS 上會看到大量不存在網域的 DNS query,這點隨著 Google Chrome 的市占率愈來愈高,在 Root DNS 上這些 DNS query 甚至佔到 40% 以上:

不過 Root Server 有上千台在跑,就目前的效能來說應該是還 OK:

As of 2020-08-27, the root server system consists of 1097 instances operated by the 12 independent root server operators.

把這個問題丟到 bugs.chromium.org 上翻,看起來有三張票在進行中:

瞄了一下裡面的討論,目前的方向有兩類,一種是主張完全關掉,這樣確定可以大幅減少對 Root DNS 的壓力,另外一種是設計 cache,使得 Root DNS 的 loading 降低。

這次有不少新聞都有報導,受到 PR 壓力看起來是動起來了... (這三張票看起來之前都沒什麼人有動力要處理)

家裡搞小機櫃的文章

Hacker News 的首頁上看到有趣的文章,在講怎麼搞個小機櫃弄起來專業一點的玩:「Home Lab Beginners guide – Hardware」,對應的評論在「Building a Home Lab Beginners Guide (haydenjames.io)」這邊可以看到。

照這個搞法好像可以塞兩三台 1U server,不過搞的大太就會像 Brad Fitzpatrick 搞的那樣,直接上 42U rack 了 XDDD

這好像也算是某種浪漫?

不停機把 server 搬到兩百米外的機房

Hacker News Daily 上看到的有趣故事,作者在 Reddit 上描述怎麼不停機把實體的伺服器搬到兩百米外的機房,中間還經過了停車場:「[Rant... sorta] Physically moved a server today...」,另外作者的 FAQ 在「[FAQ][Rant... sorta] Physically moved a server today...」這邊可以看到。

我會把這個當故事看一看就好,裡面還是有一些細節沒有被敘述 (像是網路不斷線的部份),感覺不太對,但就一個故事來看是蠻有趣的 XD

搬運的過程中間包括了使用 UPS 與多顆 switch 對接,另外中間經過一個停車場,算是很有趣的方式?

Hacker News 上對實體機房的討論 (雲與地的討論)

看到 Hacker News 上的「Ask HN: Is your company sticking to on-premise servers? Why?」這邊在討論為什麼還是有公司使用傳統的實體機房。

用雲的價值在於彈性,因為雲上加機器的時間成本比傳統實體機房低很多:加的量小的時候,主要的成本就是簽核需要的時間 (即使是電子簽) 與 setup 的時間 (如果沒有自動化),量大的時候可能會需要另外採購。

另外很多雲端服務的廠商除了 IaaS 以外也提供了很多 SaaS 的服務,這點對於建制的成本又降低了不少。

相反的,如果你的需求已經很固定了 (變動不大),而且又已經有一定的規模了,用傳統實體機房自己搭建會便宜很多,即使包含人力維護成本也都還是低很多。

另外討論裡也有提到雲端的頻寬費用,這一直都是雲端的痛點:目前雲上面的頻寬都超貴,所以用規模大一點的雲端公司會透過架構上的設計,把大的流量利用 HTTP/HTTPS 的 CDN 省下來。像是使用 AWSNetflix 設計了 Open Connect,藉以降低頻寬成本。

不過說到頻寬,AWS 的 Amazon Lightsail 就是個有趣的東西了,一樣是在 AWS 的架構內,但帳務上面把整包費用包的跟外面的 VPS 一樣...

玩一下 Zipcall,走 WebRTC 與 P2P 架構的會議系統

這個連結在瀏覽器的 tab 上好幾天了,要寫這篇的時候試著找了一下當時是從哪個管道看到的來源,翻了一下看起來沒有在 Hacker News Daily 上面列出,但在 Hacker News 上面有找到討論串,不過最近沒有去從那邊翻連結...

Anyway,Zipcall 是使用 WebRTC 實做出來的會議系統,會議相關的流量會直接透過點對點的架構傳輸,不需要透過 server 交換。

由於架構上沒有 server 幫忙重新壓縮再轉給不同的使用者,也就 client 得自己處理,對硬體要求應該會比較高,另外對頻寬的要求也比較大。

另外他提到 latency 比較低這件事情,剛剛用兩隻 webcam 測試,一個掛到 vm guest 裡面,另外一個掛在 vm host 上面,測試下來很明顯可以感覺比起之前用 Zoom 高,可能要再研究到底是什麼原因,不確定跟 vm 有沒有關係,不過還在可以接受的範圍。

安全性與隱私性的實做方式也還得再看看是怎麼弄的,不過目前看起來應該可以先拿來玩玩...

OpenSSH 的三個進階用法:CA 架構、透過 Jump Server 連線、2FA

在「How to SSH Properly」這篇裡面講了三個 OpenSSH 的進階用法:CA 架構、透過 Jump Server 連線,以及 2FA 的設定。

之前蠻常看到使用 -o StrictHostKeyChecking=off 關閉檢查,但 OpenSSH 有支援 CA 架構,可以先產生出 Root CA,然後對 Host 的 Public Key 簽名,在連線的時候就可以確保連線沒有被調包 (通常是 MITM),但得設計一套機制,自動化機器生出來後的步驟。

另外一個可能的方式是 SSHFP,搭配 DNSSEC 也可以確認連線沒有被調包,不過這又牽扯到 DNS 的部份...

第二個提到的是 Jump Server (Bastion host),之前的作法是用 -A 把 authentication agent 帶過去再連進去,這邊則是教你怎麼下指令直接連線,而不需要先連到 Jump Server (但實際上底層是透過 Jump Server)。

第三個是 2FA,對於還是使用密碼登入的系統可以多一層保護。文章裡面講的是 TOTP 的方式 (就是現在還蠻常見的 app + 六碼動態數字)。

先知道有這些東西,之後真的有用到的場景時再回來看...

HTTP/1.1 與 HTTP/2 的最佳化技巧

這篇在討論,無論是 HTTP/1.1 時代,或是 HTTP/2 時代下 (裡面還包括了 HTTP/2 的 Server Push),各種讓下載速度最佳化的技巧以及造成的複雜度:「Performance testing HTTP/1.1 vs HTTP/2 vs HTTP/2 + Server Push for REST APIs」。

文章裡其中一個提到的是各類「打包」的技巧,也就是 JavaScript 的 bundle,或是 CSS 的 Image sprites,甚至是 API 的合併,像是很多人會考慮的 GraphQL

雖然在 HTTP/2 年代我們常說可以省下來,但這並不代表「打包」在 HTTP/2 情境下沒有效果,只是改善的幅度比較少,所以這個最佳化的技巧比起 HTTP/1.1 年代,可以放到後面一點再做,先把人力放到其他地方。但如果團隊工具已經熟悉打包技巧的話 (可能是以前就已經做好了),其實繼續使用沒有太大問題...

另外是 Server Push 的情境,意外的反而可以提昇不少速度,看起來主要是少了請求的時間,所以快不少。

再來是跨網域時 CORS 的問題,在 Flash 的年代是一個 crossdomain.xml 解決,但現在的解法是多一個 OPTIONS request,反而造成很大的效能問題... 文章裡提到現在看起來有個 Draft 在發展與 Flash 類似的機制:「Origin Policy」。

作者在測試完後得到的結論其實跟蠻多「直覺」相反的:

  • If speed is the overriding requirement, keep using compound documents.
  • If a simpler, elegant API is the most important, having smaller-scoped, many endpoints is definitely viable.
  • Caching only makes a bit of difference.
  • Optimizations benefit the server more than the client.

一個超小的 HTTP Server Library

httpserver.h 這個專案是用 C 寫的,就一個 .h 檔,從範例可以看到用法不算太複雜:

#define HTTPSERVER_IMPL
#include "httpserver.h"

#define RESPONSE "Hello, World!"

void handle_request(struct http_request_s* request) {
  struct http_response_s* response = http_response_init();
  http_response_status(response, 200);
  http_response_header(response, "Content-Type", "text/plain");
  http_response_body(response, RESPONSE, sizeof(RESPONSE) - 1);
  http_respond(request, response);
}

int main() {
  struct http_server_s* server = http_server_init(8080, handle_request);
  http_server_listen(server);
}

然後同時支援 epollkqueue。拿來寫小東西還蠻有趣的,不過如果複雜一點的東西還是會考慮其他的框架就是了,畢竟會 blocking 的東西太多了...

Caddy Server 要採用 Open Source...

Caddy Server 是一套 HTTP Server,目標是讓使用者可以很容易設定一個安全的 HTTP Server。

程式碼本身是 open source (採用 Apache License 2.0),但官方包出來的 binary 則是限制個人免費使用或是購買訂閱,但如果你自己編譯打包的話又還是 open source license,是一個很奇怪的商業模式...

再加上看到他的設定檔的格式後,發現他包太多東西了 (連 markdown 相關的處理都包進去),實在是不愛這種設計 (感到遲早會有滿滿的 CVE),而 nginx 就是把 HTTP Server 相關的業務處理好,相較起來就懶的理了...

現在看起來 Caddy Server 應該覺得這樣沒賺頭而決定把訂閱拿掉,全部都開放出來:「Proposal: Permanently change all proprietary licensing to open source」。

但比較奇怪的還是,這件事情其實你也不用徵求社群意見,你們自己公司內部確認好就好,這個比較像是 PR 而已...