cloud computing  programming  

Nov 19, 2016 • Michael Chen

就像其他的學門,生物資訊的研究也類似於堆積木的過程。新的研究需要根基於許多過去的研究成果,而這些新的研究成果,也會變成日後的研究的資產。然而,當這些研究成果是以軟體 (software)、函式庫 (library) 或框架 (framework) 等模式傳承,傳承這件事情就起了奇妙的化學效應。

軟體開發時,不同語言間形成各自獨立的生態圈,所以,不同生態圈會有各自的解決方案。像是很多語言都有 libxml2 的 binding,但是不同 binding 間無法直接交互使用,而可視為該語言獨立的解決方案。有時候,不同語言間會對同一個問題領域各自開發自己的解決方案,像是 R 和 Python 都可用來處理 data mining,但是兩者相關的函式庫是各自獨立開發的。

為什麼要在不同語言間處理相同或相似的問題領域呢?不同語言也代表著不同的需求,一個語言生態圈很難滿足所有的情境。我們在開發軟體時,通常會使用同語言的函式庫或框架,軟體較容易包裝成套件,易於重覆再利用,使用者也不需要額外建置另一個語言的執行環境。即使是底層使用 C/C++ 的延伸套件,仍然會包裝成易於該高階語言使用的格式,使用者不太需要去面對異質語言間的問題。雖然不同語言都可以解決相似的問題,工程師仍傾向在不同生態圈間各自發展其解決方案。

然而,在生物資訊圈,情形就不一樣了。由於科學研究重視的是學理上的正確性,不會也不應該強迫研究者使用某一個特定的語言或函式庫來解決問題。不同的研究團隊,依其各自的考量,使用不同的語言開發其生物資訊軟體。從事研究和軟體開發不同,即使熟悉某個軟體的演算法,也很少會重新實作該軟體,而傾向於直接再利用該軟體。這時候,產生一個很有趣的現象,某個生物資訊軟體可能其中包括三、四種或更多語言所實作的軟體。筆者有一次,為了解決 gene fusion 相關的問題,下載某個軟體後,發現其實這個軟體是由至少八到十個軟體所組成,而為了滿足這些軟體的需求,又要各自建置不同的執行環境。

這樣大雜燴式的生物資訊軟體,缺乏良好的橋接,只能用命令稿將其串起來,也無法包裝成套件,充滿著許多的問題。首先,這些軟體的使用者,得重新建立相容的執行環境,無形中耗費了許多寶貴的時間。另外,這種軟體的運行,是相當脆弱的,往往在某個中間的步驟錯掉了,軟體無法正確運作,使用者只能試圖在成堆的錯誤訊息中,找尋蛛絲馬跡,甚至無法處理。設計精良的演算法就埋沒在這種運作不良的軟體中。

科學研究的目的在學理上的探討,通常生物資訊學家比較想開發新的演算法和軟體,以解決新的問題,而不會為了軟體工程的因素而去重新實作某個演算法。那麼,我們是否就只能忍受這種什錦式軟體呢?虛擬機器提供了一個相對可行的方法。像是 Laravel Homestead 就是一個預先包好的 Laravel 開發環境,這個虛擬環境為 Vagrant box。Vagrant 底下可搭配數個虛擬化方案,像是 VirtualBox、VMWare 或 Hyper-V 等。近年來掘起的 Docker,也是另一條輕量化的可行方案。透過虛擬化環境包裝相關軟體,大大地減低使用者的負擔。

結合 Dockerized software 的雲端運算平台,成為新的可能性,像是 Docker Cloud 等商業化平台的推出,就是回應這個需求。在生物資訊圈,Seven Bridges 的 Cancer Genomics Cloud 平台,就充分地利用 Docker 的優勢來處理異質環境的問題。雖然我們無法改變紛亂的生物資訊世界,但我們至少可以優雅地包裝它。