您有聽過伯恩斯斷崖、哥倫比亞山、奮鬥隕石坑以及維多利亞隕石坑嗎？沒錯！這些都是美國太空總署的火星探測車 (MER) 曾經到過的幾個地理結構。多年來，火星探測車傳回這顆紅色行星大量珍貴且令人興奮的資料，包括高解析度圖像。現在，Amazon Simple Workflow Service (Amazon SWF) 引進部分關鍵計算技術，讓美國太空總署科學家可以放心執行關鍵任務操作以及有效處理從宇宙收集到不斷增加的知識。
火星探測車
包括火星探測車 (MER) 和北極水資源保留區碳脆弱性實驗 (CARVE) 在內的幾項任務中，噴氣推進實驗室 (JPL) 都使用 Amazon SWF。這些任務持續產生大量數據，而且必須經過有效、可靠的處理、分析和儲存。策略行動和科學分析的數據處理流程涉及大量有序的執行步驟，需要多部機器之間的同步計算。例如產生圖像的立體資料、拼接數十億像素的全景圖，以及保存這些圖片，讓科學家感受火星上的地形，並可隨時調用這些圖像。目前有一個仰賴這些資料的全球決策者和科學家社群。這個社群經常負責在最短的時間內擬定好策略行動，時間可能只有幾個小時。為了達成任務，噴氣推進實驗室的工程師設定了一個目標，需在數分鐘之內便處理好並傳送火星圖像。
噴氣推進實驗室長期以來便利用 AWS 處理以及儲存數據。大部分工作採用 Polyphony 架構完成，噴氣推進實驗室的雲端服務導向結構 (Cloud Oriented Architecture) 推薦採用這種架構。有了這個架構，科學家便可以利用雲端服務佈建、儲存、監控以及協調數據處理工作。Polyphony 現有的資料處理和分析工具包括 Amazon EC2 (可擴大運算容量)、Amazon S3 (用於儲存以及分發資料)，還有各種 Amazon SQS 和 MapReduce 實作，例如利用 Hadoop 來分發以及執行任務。然而，我們漏掉了一個關鍵部分：我們需要協作服務來有效管理大型、複雜工作流程的各項任務。
雖然佇列提供一種有效方法來分配大規模並行作業，但工程師很快就發現了缺點。由於無法表達佇列之間的順序和依存關係，造成佇列不適合複雜的工作流程。使用佇列的時候，噴氣推進實驗室工程師不得不處理重複的資訊。例如，拼接圖像時，重複的拼接操作會造成成本昂貴且不必要的處理，還會導致計算成本激增，即使完成整個工作流程也沒有任何意義。噴氣推進實驗室也遇過很多比數據處理還要慘痛的案例，不得不借助各種手段以恢復整個工作流程的正常運行。雖然工程師利用 MapReduce 便可以輕鬆實現資料工作流程，不過他們發現要想在這種架構的邏輯下，想要表達整個工作流程中的每一個步驟實在相當困難。尤其是，隨著資料處理複雜性的增加，他們在處理步驟之間的依存關係以及應付各種分散式運算失效時，問題便接踵而至。
噴氣推進實驗室工程師明白他們需要具備以下特點的協作服務：
- 高可用性：支援關鍵任務操作
- 可擴展：讓數百個 Amazon EC2 執行個體平行執行
- 一致性：排定的任務必須以非常高的或然率執行一次
- 可表達：簡單地表達複雜的工作流程以加速開發
- 靈活性：工作流程的執行不得侷限於 Amazon EC2，任務必須可以移交他處完成
- 效能：排定的任務盡可能沒有延遲。
噴氣推進實驗室工程師利用 Amazon SWF 並將這項服務與 Polyphony 工作流程整合，負責處理策略行動所需的火星圖像資料。對於研發流程的分散式運作，現在他們得到前所未有的掌握與了解。最重要的是，他們能夠將複雜的工作流程用簡潔的語言表達，不用拘泥於各種制式規定。
為了讓好奇號火星探測車 (又稱火星科學實驗室)可以進行快速運動現場測試，噴氣推進實驗室工程師必須處理圖像、產生立體圖像以及製作全景圖。若要製作立體圖，我們就需要同時拍攝一組圖像，而立體圖會產生範圍資料，讓策略指揮官可以知道火星探測車距離圖像中的像素有多遠、位於什麼方向。左、右兩邊的圖像可以平行處理；但是，只有每張圖片都處理完畢之後，才能夠開始處理立體圖。這種典型的分割結合工作流程很難用佇列式系統表達，而利用 SWF 表達時，卻只需要幾行簡單 Java 程式碼和 AWS Flow Framework 註解。
要產生全景圖，也必須以工作流程的形式實現。為了達到策略目的，會在火星探測車停留拍攝相片的每個位置建立全景圖。因此，每次從特定位置送來的新照片之後，全景圖都會增加新的可用資訊。由於科學家需要相當大量的全景圖，而且希望能夠在最短的時間內建立完成，所以這個問題就必須交由眾多的機器來分攤解決。工程師運用的演算法會將全景圖分割成幾個大圖塊。工作流程的第一件任務就是根據拍攝地點得來的圖像，產生一個個的圖塊。產生圖塊之後，便會按照各種解析度縮小這些圖塊，然後拼成大圖之後，提供給遠端的用戶端使用。噴氣推進實驗室利用 Amazon SWF 提供的諸多功能，將這種應用流程以 Amazon SWF 的工作流程形式表達。
由 77 張彩色圖像拼接而成的機會號全景圖，圖片尺寸為 11280×4280 個像素。需要六個層次的細節，才能將這張圖片傳送給任何大小的檢視器。黃色格子代表每張圖像所需的小圖。火星科學實驗室的 Mastcam 儀器所拍攝的全景圖，包含高達 1296 張解析度接近 20 億像素的圖像！下面是相關的全景圖。
Amazon SWF 提供雲端服務來處理各項數據，讓噴氣推進實驗室可以利用環境中的內部和外部資源，在公共雲端服務進行各種應用，如此一來他們便可以靈活擴大應用規模，實現真正的分散式執行模式。
許多噴氣推進實驗室資料處理流程，都是設計成自動化工作者的形態，負責上傳被攔截的數據，工作者負責並平行處理資料以及下載結果。上傳和下載工作者是在本機伺服器上執行，而資料處理工作者則可以在本機伺服器和 Amazon EC2 節點上執行。利用 Amazon SWF 的路由功能，噴氣推進實驗室開發人員可以根據實際需要，將工作者納入工作流程，還能夠利用工作者的各種特性，例如資料的地理資訊。這種處理應用程式的實用性相當高，因為即使當本機工作者故障，雲端服務上的工作者仍然會繼續接手處理。由於 Amazon SWF 並不會限制工作者節點的位置，因此噴氣推進實驗室可以在多個區域及當地的資料中心執行工作，而關鍵任務系統也能得到最高的可用性。隨著 Amazon SWF 在諸多領域的應用，噴氣推進實驗室計畫將自動容錯移轉功能整合到各個領域的 SWF。
噴氣推進實驗室中的 Amazon SWF，並不侷限於資料處理的用途。噴氣推進實驗室工程人員利用 Amazon SWF 的排程功能，設計了一套分散式 Cron 作業系統，可以準時可靠地執行關鍵任務操作。除了可靠性之外，噴氣推進實驗室利用 AWS 管理主控台的 Amazon SWF 的檢視功能，全盤掌握各個分散的工作。噴氣推進實驗室設計了一個應用程式，負責從 Amazon S3 備份重要資料。噴氣推進實驗室透過分散式 Cron 工作，根據專案期望的頻率來更新這些備份及審查資料的完整性。這個應用程式的所有步驟，例如加密、上傳至 S3、隨機選擇要稽核的資料，也即將現場資料與 S3 作比較 (實際稽核)，都可以透過 Amazon SWF 進行協調。此外，一些噴氣推進實驗室團隊利用 AWS Flow Framework 提供的程式設計支援，早已將現有的應用程式遷移至雲端服務以運用其協調功能。
噴氣推進實驗室繼續將 Hadoop 應用到簡易的資料處理流程，而目前想在處理步驟之間實現複雜依存關係的應用時，Amazon SWF 自然成為首選。開發人員在開發與追蹤分散式任務時，也經常利用 AWS 管理主控台的診斷和分析功能來找出應用程式中的各種錯誤。利用 AWS，以往需要數個月時間才能開發、測試以及部署完成的關鍵任務應用程式，現在只要幾天的時間就可以搞定。