PaaS遍地開花!整理各種平台的Heroku-like解決方案

隨著雲端的概念逐漸發酵,像是Heroku這樣的新一代網站代管服務越來越受到歡迎,以Heroku為首許多不同平台的類似服務也相繼誕生,包含了Python、Java和PHP等都有相對應的服務,一起來看看吧!
評論
評論

[Image Credit]

隨著雲端的概念逐漸發酵,像是 Heroku 這樣的新一代網站代管服務越來越受到歡迎,以 Heroku 為首許多不同平台的類似服務也相繼誕生,包含了 Python、Java 和 PHP 等都有相對應的服務,一起來看看吧!

什麼是 PaaS?

PaaS 是 Platform As A Service 的簡寫,便是以提供平台作為一種服務。以 目前最具盛名、不久前才被 Salesforce 所收購的 Heroku 而言,就是提供了大家一個以 Ruby 為基礎的平台,讓大家可以自行在平台上開發各種網站,並且由 Herkou 來提供平台的架設管理。

透過 PaaS 的最大好處,便是可以減少維護管理系統底層的成本。相對自己架設機器而言,必須要自己管理的系統、機器和軟體,其中只要一個環節一不小心出錯了,就有可能像 某些網路服務一樣,將資料庫的帳號密碼等重要資訊通通曝光 ,造成敏感資料暴露在危險當中。

除此之外,架設在 PaaS 的服務也可以透過簡單的介面來調整所需使用的硬體設備等級,程式完全不需要修改馬上就可以處理突如其來的龐大瀏覽量,而當使用者逐漸退去時,也可以馬上的將硬體降為一般的水準,省下額外的開支。

就如同先前本站文章所提到的:

網路創業實例:意外起飛、24 小時累積 10,000 名用戶的 Rapportive

Rapportive 的服務是放在知名廠商 Heroku 上,對於突然湧進的流量只需要增加 Dynos 的數量(Heroku 提供服務的基本單位),基本上你是不需要修改你的程式的;當然,程式的優化、調整可以在同樣能耐的硬體等級上容納更多人。

使用 Heroku、不需要調整程式、只需要增加 Dyno 數量?真的有這麼美好嗎?事實上 Rapportive 就是這麼辦到的,在來自全世界的流量突然湧進時,Rahul Vohra 手邊沒有電腦,於是他隨即拿起 iPhone 並且利用 Nezumi 這個設計來管理 Heroku 的應用程式,將 Rapportive 的 Dynos 增加到 20 個,就這麼簡單,可能不到一分鐘吧?!系統的能耐馬上就提昇了。

而在台灣也已經有團隊使用 Heroku 作為主要的環境:

Cardinal Blue 的 Facebook 應用程式開發經驗分享:使用 Ruby on Rails 與 Heroku

使用 Ruby on Rails 並搭配知名的 Ruby 雲端運算平台:Heroku,特色是應用程式隨著流量的成長,無需擔憂系統管理(System Administration)或是硬體水平擴展的問題,Heroku 提供了優越的 Scalability 能耐,透過簡單的應用程式指令或是 Web 介面便可依照需求調整所需的硬體資源。(類似 Amazon EC2 Instance 的計費方式,每小時有一定額度的費用)

然而並不是每個團隊都是使用 Ruby 作為主要的開發語言,在市場上目前使用 PHP/Java/.Net/Python 的使用者仍然佔了很大部分的比例,隨著 Heroku 的流行,許許多多不同語言但類似的平台服務陸續竄出,以下便是我們的整理:

Python 的 Heroku

與 Ruby 相同熱門的 Python 是現在很多新一代網路創業者的首選,包含 Instagram、Quora 和 Dropbox 等服務在內都是使用 Python。

Google App Engine

Google App Engine 算是相當早期的 PaaS 服務,是 Google 所提供的雲端網站服務,搭配了 webapp 這套輕巧簡單的 Python web framework 和 Datastore 這套 NoSQL 的資料庫系統。

除了 webapp 之外,任何支援 Python wsgi 標準的 web framework 包含最熱門的 Django 在內都可以在 GAE 上面運行。

順道一題,台灣也已經有由知名開發者 ericsk 所撰寫的 Google 應用服務引擎開發實戰 一書可以供入門者作為參考。

Djangy

顧名思義,Djangy 所提供的便是 Django 的平台服務,支援背景工作(background job),如同 Heroku 一般是使用 git 作為上傳佈署的方式,並提供了 shell 下所使用的管理指令,看起來相當的不錯且完整。

Djangy 目前仍然在封閉測試當中,有興趣的使用者可以在其官方網站上索取邀請函。

DjangoZoom

另外一個專門為 Django 打造的 PaaS 服務,同樣是使用 git 作為上傳佈署的方式,目前也仍然在測試當中,有興趣的使用者可以在其官方網站上索取邀請函。

ep.io

ep.io 則是另外一個我相當看好的選擇,相對於 Djangy 是以 Django 的支援為主,ep.io 支援了透過 Python 標準 WSGI 所設計的網頁框架,所以包含 Django 在內,其他熱門的選擇像是 Flas 或者是 Quora 所使用的 Pylons 都可以支援。

ep.io 目前也在封閉測試當中,有興趣的使用者同樣可以在其官方網站上索取邀請函。

Java 的 Heroku

Java 在網路的開發領域上算是具有數一數二的份量,許許多多的企業都是透過 Java 作為其網站開發的主要語言,且具有龐大的使用者基礎,故仍然在雲端時代相當的受到歡迎。

Google App Engine for Java

是的,Google App Engine 同樣有提供 Java 的服務,使用標準的 servlets 和 JSP 等技術,搭配上 JDO 和 JPA 介面的 DataStore,讓 Java 的使用者同樣可以透過 GAE 來開發程式。

AWS Elastic Beanstalk

談到雲端時代,最重要的網路公司之一莫過於 Amazon 了,其所提供的 EC2、S3 或是 Cloudfron 服務都是許多先進網站的重要底層架構(包含 Heroku 實際上便是運行在 EC2 上),而最近他們所推出的 Elastic Beanstalk 便是提供了 PaaS 的服務,讓開發者可以快速的部屬 Java 程式到 Amazon 的機器上。

雖然目前此項服務仍在測試當中,但我相信 Amazon 所提供的雲端服務一向是具有相當水準的,在未來一定會有很好的發展。

PHP 的 Heroku

PHP 是專為網路服務所打照的語言,由於其相對好上手的特性,在網站中是相當的普遍,包含 Inside 部落格在內,許許多多的網站、部落格論壇都是用 PHP 所開發,其中最著名的代表莫過於就是 Facebook 了。

phpfog


phpfog 是 PHP 的 Heroku 類服務中最受矚目的一個,標榜秉持著 N-Tier 的概念,就是將資料庫、平衡負載和網頁伺服器等等通通分配在不同機器上,來達成最佳的效能和穩定度,並且提供許多 PHP Apps 的快速安裝功能,和 git 為主的程式上傳功能。

目前 phpfog 也是在測試當中,有興趣的讀者可以透過網站上的表格加入等候邀請函,或是參加其 Facebook/Twitter 的活動來獲得搶先的測試機會。

cloudcontrol

cloudcontrol 也是針對 PHP 所提供的 Heroku-like 服務,其特殊的地方是在計費的方式是透過所謂的 boxes,也就是透過 access_log 分析來顯示出使用的直線圖,然後選定一個方形的大小來付費。

另外一點特殊之處在於,cloudcontrol 不需要邀請函,已經是一個正式開放的服務了。

.Net 的 Heroku

ASP.Net 雖然是微軟的解決方案,一般需要較高的授權金而讓許多網路創業者卻步,但是仍然有包含像是 stackoverflow 等知名網站使用。

Windows Azure

提到 C#的 Heroku,一定要提到微軟官方所提供的 Windows Azure 平台了,隨著雲端時代的到來,微軟也提供了許多相關的服務,主要分為 Windows Azure 和 SQL Azure,也就是運算平台和資料庫的平台提供開發者使用。

目前 Azure 的成功案例大多為企業用戶為主,不過在微軟的努力推廣之下,也逐漸有越來越多的開發者陸續投入。

AppHarbor

AppHarbor 則是.Net 平台上的另外一個非官方的選擇,其官方網站強調的他們為「Azure done right」,也就是改善了許多 Windows Azure 的缺點,比如說像是佈署時間過長,或者是操作設定上的不方便等等。

個人認為 AppHarbor 具有相當的潛力可以和 Azure 抗衡,無論是在操作的簡便度或者是收費的策略上,都相對於官方的平台好上一些。

綜合型 PaaS

Makara

Makara 是前陣子被 Red Hat(知名 Linux 領導廠商)所收購的 PaaS 平台,現階段提供 PHP 和 Java 的平台服務,未來可以支援包含 Ruby/Python 等在內的各種語言。而相對於其他一般的 PaaS,Makara 提供了更好的彈性讓開發者可以選擇佈署到不同的雲端上,包含 Rackspace 和 Amazon EC2 等。

由於背後有 Red Hat 的加持,加上高度的延展性,我認為 Makara 也會是未來市場上相當具有競爭力的。

結論

在創業過程中,我們往往需要對於人力資源的分配斤斤計較,許多創業者都曾經感嘆好的人才是需要花上很多時間才能找到的,而千辛萬苦找到的程式設計夥伴,當然要讓他們能夠專心撰寫程式,而不是浪費時間在系統的管理、維護上面。

此外,若是您的網路服務具有極大潛力,隨時有可能受到網友關注、一夕爆紅,那們更應該要使用 PaaS 的服務,便可以隨時增加硬體的負荷能力,而不會錯過任何一位寶貴的使用者。

有更多的 PaaS 使用經驗想要與我們分享?歡迎大家的留言與討論!


QNAP的一小步,NAS的一大步:初嚐QTS 5.0的威力

歷經多年演進,QTS一直是QNAP備受好評的家用NAS儲存作業系統,本次就以一位因為疫情關係在家工作的Power User角度,檢視QTS的發展歷程與5.0帶來的使用者體驗。
評論
評論

歷經多年演進,QTS 一直是 QNAP 備受好評的家用 NAS 儲存作業系統,這次以三級警戒下,在家工作者的角色,替大家檢視 QTS 5.0 帶來的使用者體驗。快速整理這次產品的重點:不只是檯面上的UI優化, QTS 5.0 從安裝設定流程到底層系統,均帶來了飛躍性的演進,不僅功能更強、管理更加方便,重新調整後的 NVMe SSD 快取機制,更讓效能脫胎換骨。

這兩個多月來,很多公司行號盡其所能的減少進入公司上班的人數, WFH (Work From Home) 的人數激增,不僅挑戰公司VPN服務的極限,更讓原本公司提供的檔案共享服務 (很多都是很陽春的 Windows 檔案分享服務) 捉襟見肘,不是VPN速度慢到讓人吐血,就是容量不足,甚至兩者都有,嚴重影響工作效率。畢竟這波疫情是全球性的現象,不僅是公司內部,或多或少都可以感受到連到國外好像也沒過去那麼順暢了,更不用講某些雲端儲存服務、即時通訊軟體和線上視訊會議,都「默默的」降低服務品質。

這時如果自己平常就有養 NAS ,做很多事情就會輕鬆很多,也能趁在家時間變長,好好地進行管理與設定。筆者目前使用的 QNAP NAS 機種是 TS-453D (四核心的 Intel Celeron J4125 處理器與 4GB 系統記憶體),安裝四顆 6TB 硬碟 (RAID5) 與兩片 256GB M.2 SATA SSD,並超前佈署。久未更新版本的筆者,趁著某次重整磁碟區組態、整個「砍掉重練」的機會,體驗 QTS 5.0 的威力。

更加直覺貼心的安裝設定與管理操作

為求「乾淨」起見,筆者將 NAS 回歸原廠預設值,從 QNAP 官網下載 QTS 5.0 的韌體,很快就感受到明顯的改進,全新改版的安裝精靈,不但簡化了步驟,初始化時同時進行更新韌體版本並建立新管理帳號。

QTS 5.0 的使用者界面亦讓人感到耳目一新,明顯提升了視覺舒適度及反應速度。其中最值得注意的莫過於初次登入時,右下角頻繁跳出的通知板,提供初次使用導覽,將多次通訊訊息以應用方式歸納後統整顯示,只要照著做就可順暢的完成初次設定,令人驚豔。

脫胎換骨的執行效率

QTS 之所以進版到 5.0,理由想必也不外乎升級作業系統核心。QTS 5.0 升級到Linux Kernel 5.10 LTS (Long Term Support,可維護到 2026 年底),大幅提高內核安全性並強化效能。此外,新核心也改善了AMD處理器的運作能力,並支援新一代硬體平台與內建的顯示晶片。根據 QNAP 網站的說明,搭配新核心, QTS 5.0 也改進的 NVMe SSD 的快取 (Cache) 效能,優化快取模組,能更有效率的使用SSD空間,也能更節省記憶體使用量,並改善多人存取同一份資料夾的效率。值得一提的是,不僅 NVMe SSD,SATA 協定的 M.2 SSD 也同樣獲得提升,剛剛好筆者就有兩片 M.2 SATA SSD 作為快取之用。

既然都整個重來,就靈機一動,藉機試試效能提升幅度,包含平時根本不會用到的 iSCSI 協定 (Windows 10 有內建 iSCSI 啟動器)。整體來說的確有飛躍性的成長,提升幅度最少也不低於 10%,尤其對於網路芳鄰的SMB協定,吞吐量 (Throughput) 約有 14-17%,而每秒的 IO 總量 (IOPS) 在 4K 隨機讀取時,更高達 56%。筆者的檔案也多半是體積不大的文件檔、圖片與 PDF,這對「讀多寫少」、將大量工作檔案放在 NAS 的筆者而言,簡直是一大福音。

測試項目 測試設定 提升幅度
吞吐量(Throughput)

循序讀取1M

14%
循序讀取512K 17%
每秒 I/O 總量(IOPS) 隨機讀取4K 56%

讓數據資產更有保障的安全保護等級

近年來 NAS 頻頻成為駭客攻擊的目標,早已不是新聞。 QTS 5.0 也針對這點,提升安全保護等級。像支援 TLS 1.3、預設關閉admin帳號、支援進階加密套件、更符合安全防護標準的安全設定、韌體與 APP 自動更新、以及可提高網頁存取安全性並隱藏敏感網路服務埠以避免潛在風險的 Reverse Proxy 等。

但最讓筆者眼睛一亮的是:QTS 5.0 可以用指定的金鑰進行登入執行管理工作。

只要在本機電腦產生 SSH 金鑰,新增到偏好設定中的金鑰,即可搞定。如果是 Windows 用戶,建議使用 PuTTY 內建的 Key Generator,記得在空白處移動滑鼠 (筆者第一次使用這功能,結果等了很久都沒反應,才知道自己忘記動滑鼠了),就會自動產生。

至於 macOS 就更簡單了,在命令列直接輸入即可:

#ssh-keygen -t rsa
#pbcopy < ~/.ssh/id_rsa.pub

說到 VPN,QTS 5.0 的全新 QVPN 支援 WireGuard VPN,更加輕量、容易設定、支援更多樣化的用戶平台,大幅提升速度,除了利於個人在工作,也讓連線 NAS 更安全且更方便。

加強檔案應用服務提供更精細的服務設定

無論從學生時代至今,看似簡單的 FTP,一直是最基礎也最常用的檔案應用服務,TCP 定義的通訊埠 21 和傳輸埠 20,早已深深的烙印在所有 IT 人的腦海中。QTS 5.0 的 QuFTP 服務帶來煥然一新的檔案傳輸機能,對應基於用戶、限制上傳與下載速度的 QoS 設定,也具備允許存取或拒絕的使用時間的條件式設定。

行文至此,不得不感慨,假若學生時代就有這樣好用的功能,在宿舍網路架設「黑站」就不必這麼麻煩了。(問題發言)

增進人工智慧加速能力並預測磁碟機壽命

現在是一個人工智慧看似無所不在、卻又好像很難明確講出究竟與我何干的時代。但唯一可以肯定的是, NAS 已顯現足堪邊緣運算中的推論中心角色。QTS 5.0 可搭配 Coral Edge TPU (Google Edge TPU 晶片),提升照片整理、物件辨識的效能,並大幅降低所需的處理器資源。此外,QTS 5.0 可同時支援多種、多組 TPU 裝置,並可動態調整 TPU 優先權,指定 TPU 裝置給特定應用程式。

這樣寫很可能各位還是會看得一頭霧水,講的實際一點,針對人臉與物件辨識,QTS 5.0 的 QuMagie 支援強化的人工智慧核心,使得 QVR Face 可協助用戶建立智慧人臉辨識,QVR Human 更可主動計算通過特定區域的人數。這對零售店家或用餐場域絕對是天大的好消息,可用現成的商用品,去建置過往需要系統整合商執行特定專案才能搞定的應用。

也許會覺得這應用距離自己有點遙遠,但要如何預測如同「桃園三結義」般「不求同年同月同日生,只願同年同月同日死」的磁碟機壽命,就是切身相關的議題了。QTS 5.0 的 DA Drive Analyzer 基於訂閱制,基於工作覆載分析,便於預防性維護更換,可謂重中之重。這功能就不得不試試看了。

申請並啟動 DA Drive Analyzer 有點複雜,先從 App Center 下載並安裝,按下圖示後就會連到註冊申請網站,輸入相關資料後並送出,在一個工作天內就會將通知信寄到信箱。

再根據信件中的詳細說明,一步一步的確認啟動 myQNAPcloud APP,設定這台 NAS 在QNAP 雲端服務的「名稱」,才能讓 license.qnap.com 網站找得到這台機器。

接著再從 license.qnap.com 網站,找到 DA Drive Analyzer,再選擇啟用方式 (雲端、認證碼、離線)。筆者直接選擇從雲端啟動。

接著就會收到啟動成功的信件。大功告成。

在 QTS 的桌面上按下 DA Drive Analyzer 圖示,就跑出正常運行的功能。不過需要十五天的時間進行資料分析,也請記得晚上不要關閉 NAS ,以便收集到完整的數據。

你也會在 License Center 上看到授權資訊。

QNAP 的一小步, NAS 的一大步

體驗完整個功能,對於 QTS 5.0 的感想,腦中浮現了「博觀而約取,厚積而薄發」,象徵著 QNAP 累積多年成果的大爆發。QNAP 徹底精鍊了最基礎的使用者體驗,並且帶來數項堪稱「必殺技」的嶄新功能。不只現有的 QNAP 用戶可直接感受到其吸引力,對於尚未踏入 NAS 世界的新手,也帶來了更多購入人生第一台 NAS 的誘因。搭載 QTS 5.0 的 QNAP 機種,值得各位讀者認真考慮。

☞了解更多QTS 5.0: https://www.qnap.com/qts/5.0/zh-tw/

🔥 INSIDE讀者限時9折購機優惠🔥
購機這裡買: https://store.qnap.com.tw/promotion/cool3c.html
折扣期間:2021/10/5~2021/11/4
結帳時輸入優惠碼:COOL3CQTS5