I recently hosted a panel with AWS, Amgen, Ardigen, and Seqera on running omics workflows in the cloud. 


Here were my key takeaways from the talk: 

You can watch the full video here: 

<iframe width="560" height="315" src="https://www.youtube.com/embed/zQyh7LF6_h4?si=4QVkjvxM0E6Kj5Oq" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>

## Running omics workflows on the cloud is about understanding what tradeoffs you’re making. 

<iframe width="560" height="315" src="https://www.youtube.com/embed/T_keBXj_iuQ?si=KhA4UWL9n5647YkQ" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>

“For example if you're running a production pipeline where you just need to keep it churning, but you don't need to have the results immediately, you can wait and deal with retries. You might also not necessarily need the latest and greatest hardware. 

However, if you're in an R&D activity, the time of your developers is more expensive than the time of the machines. 

So you need to be able to have your developers progress very rapidly, be able to iterate extremely rapidly, because the cost you're paying the humans who are operating machines is higher, and also the cost of the opportunity cost of needing to define the solution faster than maybe your competitors.

What's more important?” 

Getting the answer fast? Getting to a product fast? Or do you have just something that's running in your background?” 


## When going full cloud, it’s important to understand what kinds of CPUs you need to for your pipeline.

<iframe width="560" height="315" src="https://www.youtube.com/embed/D1o36dL5tGQ?si=gEsVaUN5zSuENptI" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>

“Depending on the shape and size of the data and the kind of scientific algorithm that you're running, there are going to be different computational requirements.

In some cases you might want a beefy VM with a lot of compute, a lot of memory. Sometimes you just, it's going to be a small operation that's just cheap, but it's more disk bound. 

So there's some very different shapes and sizes of machine that might be appropriate.” 


## Case Study: How the Broad Institute leverages spot instances to reduce costs

<iframe width="560" height="315" src="https://www.youtube.com/embed/-OEZnDIB0fs?si=BJTFvermcyj8DUcf" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>

The Broad Institute saved ~90% on costs going from their first implementation to their final pipeline. By leveraging tools like Spot instances, they were able to take their costs from $85 per whole genome to $5. 

“When Broad's original genomic pipeline was migrated from on prem to cloud, the initial,  completely naive implementation was about, I want to say $85 per whole genome. With some basic optimization, they very quickly brought that down to $45 per genome, which is almost half. 

Three to six months of further investment, (today it would take much less time because we have all these tools), we took it down to $5 a genome.

And if you think about the cost reduction there, that was huge. Nowadays you can use those kinds of approaches. You don't have to do six months of R&D because a lot of the tools exist. But you can really make a really big difference from the naive implementation to an optimized implementation.”



## Ready to Learn More? 
Spot instances are a great way to use spare capacity in the cloud at 60 to 80% cheaper. 

If you're curious about seamlessly running your research and other types of computational workloads on spot instances, feel free to [book a chat with me](https://calendly.com/jing-memverge/30-minute-general-discussion?month=2023-12&date=2023-12-05). 


## More about Jing
I'm Jing, I run GTM for our memory snapshot product at MemVerge.

<iframe width="560" height="315" src="https://www.youtube.com/embed/gW2uf5-LEYM?si=-ND4_wi-YSGYxGAb" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>

We protect your workloads from being taken away or reclaimed by the cloud provider, even when they're not done running. And we are automatically finding you additional instances where you can continue to run your work to completion.

I love helping teams who may not have the resources to conduct their computationally intensive research locally or may not feel fully comfortable migrating their omics workflows to the cloud. 

I post regularly about running omics workflows on spot instances and in the cloud. Check out my writings on [LinkedIn](https://www.linkedin.com/in/jingxie/).

## Abstract

This blog provides the evolution and the overview of the Memverge JuiceFlow solution, which is meant for highly performant and cost-effective Nextflow pipeline executions on Memory Machine Cloud. 

---

## What is JuiceFlow?

JuiceFlow is a transient, head-node setup that utilizes **JuiceFS** as its primary filesystem to execute Nextflow pipelines on MMCloud. [JuiceFS](https://juicefs.com/docs/community/introduction/), an open-source, high-performance distributed file system designed for cloud environments, brings several unique features to the table, including:

- **Separation of Data and Metadata**: JuiceFS stores file data in chunks within object storage platforms like Amazon S3, while metadata is stored in various databases, such as Redis. This architecture enhances performance and scalability.
- **Performance**: JuiceFS is engineered to achieve millisecond-level latency and nearly unlimited throughput, depending on the object storage's scale. This makes it exceptionally suitable for high-performance computing environments like those needed for Nextflow pipelines.
- **Easy Integration with MMCloud**: MMCloud facilitates the deployment process by providing pre-configured Nextflow head node templates with JuiceFS setup, simplifying the user's experience.
- **Comparison with S3FS**: JuiceFS offers significant performance and scalability advantages over S3FS. For those interested in a detailed comparison, refer to the [JuiceFS vs. S3FS](https://juicefs.com/docs/community/comparison/juicefs_vs_s3fs/) documentation.

Once a Nextflow run concludes, whether due to failure or completion, the node will self-terminate, thus the term "transient." Furthermore, JuiceFlow can reload previous runs from your S3 bucket, provided that one metadata file exists per bucket. This feature enables you to `-resume` runs or access data created by other runs within the same JuiceFS file system, streamlining data management and pipeline execution.

---

## Development of JuiceFlow

* The development of the JuiceFS + Nextflow solution has undergone many iterations, leading to the creation of JuiceFlow.

* Initially, the setup integrated the JuiceFS filesystem and Nextflow within the same instance. However, upon deployment via CLI, users were required to `ssh` into the instance to initiate their run and also manually dispose of the VM after execution.

* In the second iteration, we emphasized the "transient-ness" of the Nextflow head-node while aiming for minimal user intervention. The JuiceFS and Nextflow components were allocated to two separate instances. In this setup, JuiceFS remained persistent, whereas the Nextflow component mounted the filesystem and stayed active until the Nextflow run concluded, underscoring its "transient" aspect. This arrangement eliminated the need for users to `ssh` into the head-node instance, allowing them to interact primarily through two CLI command submissions.

* The ultimate configuration, **JuiceFlow**, merges the JuiceFS and Nextflow components into a single node, akin to the original setup, yet it inherits the "transient" hands-off characteristic of the second iteration. This was achieved through a singular CLI command.

---

## Overall JuiceFlow Setup

* The prerequisites for setting up include a functional MMC OpCenter, an AWS S3 Bucket, and the corresponding S3 access and secret keys.

* The user is required to submit a single command that encapsulates the aforementioned details along with two primary scripts: 
    - `transient_JFS.sh`: Formats the work directory S3 bucket to JuiceFS format.
    - `job-submit.sh`: Contains Nextflow input parameters and MMC config.

* Upon submission, a VM will be initiated. This VM is responsible for formatting a directory within the designated S3 bucket for JuiceFS. If the bucket contains a metadata file from a previous job, it will load the corresponding JuiceFS partition, granting the job access to that specific directory. Within the job, a Nextflow configuration file specific for MMCloud using the `nf-float` plugin is generated, and the designated Nextflow command is executed.

* The process integrates the use of the [nf-float](https://github.com/MemVerge/nf-float) plugin, which facilitates the spawning of additional instances for each process within the pipeline on MMCloud. These VMs are configured to terminate upon the completion of their respective processes.

* Following the execution of the pipeline, regardless of the outcome (failure or success), JuiceFlow will archive the metadata of the JuiceFS filesystem to the user's work directory S3 bucket. Should JuiceFlow be executed again using the same bucket, it will recognize the metadata file and reload the identical JuiceFS Filesystem. This feature is particularly beneficial for instances where the `-resume` command is utilized in Nextflow executions.

* For a more detailed setup, please refer to the [JuiceFlow AWS QuickStart Guide](https://www.mmcloud.io/resources/docs/juiceflow).

---

## Important Considerations

- **JuiceFS Bucket Requirements**: JuiceFS cannot be formatted on a sub-directory of a bucket. The root directory of the bucket, or the bucket itself, must be specified in the CLI command.

- **Google Cloud Platform Access Requirements**: For GCP users, the service account must have permissions to get and put objects into your `gs://` bucket.

- **Handling `gcp_key.json`**: This key serves as the credential for a service account with access to your `gs://` bucket. To incorporate the contents into the job, it is read into an environment variable that the container can access.

---

## Monitoring Execution Logs

### Workflow Execution Log

Once the head node job starts executing, you can monitor the Nextflow standard output in OpCenter GUI as follows:
- Click on the head-node job-ID.
- Navigate to the `Attachments` tab.
- Click "view" (eye-icon) on the `stdout.autosave` file.

![Workflow Execution Log](https://hackmd.io/_uploads/SJFcJlIlC.png)

### Individual Job Logs

To monitor workflow execution and get a detailed view of each process in the Nextflow workflow:
- Click on the Workflows dashboard in the OpCenter.

![Individual Job Logs - Workflow Dashboard](https://hackmd.io/_uploads/SyumxlIx0.png)

- Click on the workflow name. This allows you to monitor the jobs running in this workflow in a consolidated view.

![Consolidated Workflow View](https://hackmd.io/_uploads/rkpHeg8gR.png)

- To view the execution log of any particular job:
    - Click on the job-ID.
    - Navigate to the `Attachments` tab.
    - Click "view" (eye-icon) on the `stdout.autosave` file.

![View Execution Log](https://hackmd.io/_uploads/SkvG-lIx0.png)

---

<details>
<summary>Expand here for more details on work directory inspection instructions</summary>

To inspect the files in the work directory, follow these steps:

- Submit a job similar to the commands above with a script designed to "sleep forever," as shown in the script below:

```bash
#!/bin/bash
while true
do
  sleep 1s
done
```

- You can now `ssh` into the instance and inspect all files in the work directory by navigating to `/mnt/jfs`. There's no need to enter the container since JFS is mounted to the instance itself. It's also possible to create a template for easier execution, but ensure to specify the correct bucket in the ENV variables.

**NOTE**: This method assumes that no files in the JFS mount are being changed, as we are not updating the metadata in this setup. This is intended only for reading/copying logs. Should you alter anything in the file system, be aware that changes will NOT be saved unless the metadata is updated.

</details>

---

## Performance Metrics

* Below are some key performance & cost metrics of JuiceFlow using the `test_full` profiles of popular nf-core pipelines

| Pipeline        | Execution Time | Execution Cost ($) |
| --------------- | -------------- | ------------------ |
| nf-core/sarek   | 9hr 32min      | 6.3288             |
| nf-core/atacseq | 4hr 22min      | 6.6143             |
| nf-core/rnaseq  | 8hr 00min      | 21.8443            |

NOTE: All pipeline jobs were run on AWS Spot instances, utilizing MMCloud's spot-protection feature. This feature automatically saves job progress upon spot instance preemption and restores it on a new spot instance, ensuring continuity.

* We previously published detailed benchmark results on performance of JuiceFS for Nextflow Workflows in a blogpost that can be viewed [here](https://www.mmcloud.io/blog/unveiling-the-superiority-of-mmcloud-over-aws-batc)

---

## JuiceFlow Advantages

- **Transient node**: Once the Nextflow pipeline has finished running, the entire node is terminated, eliminating further costs for the user.

- **One-command submission**: JuiceFlow allows the pipeline to be executed with a single command, negating the need for the user to `ssh` into the instance and thus providing a hands-off experience.

---

## Summary

JuiceFlow revolutionizes Nextflow pipeline executions on MMCloud by leveraging JuiceFS for high-performance, cost-effective computing. It introduces a seamless integration that drastically reduces execution times and costs, exemplified by nf-core pipelines running on AWS Spot instances with impressive savings and efficiency. The system's transient nature ensures that nodes terminate post-execution, eliminating unnecessary expenses. Furthermore, JuiceFlow's one-command setup significantly simplifies user interaction, reinforcing its position as a superior choice for executing complex computational workflows with optimal resource utilization and budget control.

## What is AppCapsule and what problems does it solve? 
AppCapsule creates a snapshot of all the data in memory, and all the application states required to restore the application at this moment in time, as well as the data on storage. With AppCapsule, we can transport the application runtime across different machines. 

Three problems that AppCapsule can help to solve - 
1. **Spot** reclaim - If there is a spot eviction event, Memory Machine Cloud creates an AppCapsule, and moves it to another spot instance, where the job will continue. That means, you can save cost running jobs on spot instance, while keeping all your job progress and does not need to run from the beginning all over again. A.k.a. *SpotSurfer*.
2. **OOM** (Out Of Memory) - Memory Machine Cloud detects if OOM is about to happen and if so, creates an AppCapsule, and moves it to another instance to avoid the application crash as well as have the job continue running.
3. **Right-sizing** - vertical scaling down to avoid over-provisioning or up to provide more resources to the application as it is needed for shorter wall-time and possibly lower total cost. You can trigger either manually by using float cli command / OpCenter Web GUI or automatically done by Memory Machine Cloud (a.k.a. *WaveRider*).
   
![](https://baywatch-api.memverge.com/media/upload/202312/231220190505523032.png)

## What is AppCapsule++ and what benefits does it bring? 
Three enhancements and benefits that AppCapsule++ brings to the users - 

1. Only saving **delta** - instead of saving a full snapshot, AppCapsule++ only saves the difference (memory change) since the previous snapshot. This way, the time required for the final snapshot is minimal.
2. **Adaptive** trigger - instead of snapshotting in a fixed, pre-determined interval, AppCapsule++ automatically and intelligently checks the memory change and take a snapshot when it reaches a threshold, which is calculated based on the cloud service provider’s pre-emption window. The benefit is no need to guess the fixed interval for periodic snapshot.
3. **Asynchronous offloading** - instead of synchronous snapshotting which will pause the application, AppCapsule++ does asynchronous data offloading, which decreases the time that the application is frozen. The benefit is lower impact to job completion wall-time. 

Below is an overall comparison table of AppCapsule and AppCapsule++
| Comparison | AppCapsule | AppCapsule++ |
| - | - | - |
| **Snapshot content** | Full snapshot | Delta snapshot |
| **Snapshot trigger** | Can be<br/>- Periodic done by MMCloud, or<br/>- Manual done by user’s script | Adaptive | 
| **Configuration** | Pre-determined interval for periodic snapshot | No special configuration | 
| **Application completion wall-time** | Impact higher<br/>(Synchronous) | Impact lower<br/>(Asynchronous) | 
| **Storage overhead** | Relatively lower<br/>(only need to save final snapshot to restore) | Relatively higher<br/>(need to save all delta snapshots to restore) | 
| **Usage** | `--dumpMode full` | `--dumpMode incremental` |


## Benchmark comparison 
Below is the benchmark experiment result running on AWS comparing AppCapsule and AppCapsule++. The experiment is based on 50GB memory change in terms of 60GB, 120GB, 240GB, and 480GB application memory usage, and how much time in seconds did AppCapsule and AppCapsule++ take to take the final snapshot. 

Three observations from this benchmark - 

1. For AppCapsule, as application memory usage grows, the snapshot time also **increases**. The reason is that AppCapsule takes a complete snapshot every time.
2. For AppCapsule++, as application memory usage grows, the snapshot time **stays more or less the same**. The reason is that AppCapsule++ takes a delta snapshot, which is triggered when the amount of change in memory reaches a certain threshold.
3. Considering using spot instance on AWS, which has 2-minute pre-emption time window, AppCapsule can only support relatively small workload (in this experiment for example, 60GB since the snapshot time is 109 seconds). AppCapsule will not be able to support bigger workload (in this experiment for example, 120GB needs 250 seconds to finish a snapshot which is way over the 2-minute time window). However, since AppCapsule++ only takes delta snapshot, the snapshot time is consistent with memory change, not the application memory usage. 
![AppCapsule vs AppCapsule++](https://baywatch-api.memverge.com/media/upload/202312/231220185252866864.png)


More detailed information in table format below: 
| Experiment No. | Experiment Variable | AppCapsule | AppCapsule++ |
| - | - | - | - |
| 1 | Application memory usage: 60G<br/>Application memory change: 50G | 109s<br/>r5.2xlarge/gp3 | 91s<br/>r5.2xlarge/gp3 |
| 2 | Application memory usage: 120G<br/>Application memory change: 50G | 250s<br/>r5.4xlarge/io1 | 102s<br/>r5.4xlarge/io1 |
| 3 | Application memory usage: 240G<br/>Application memory change: 50G | 533s<br/>r5.8xlarge/io1 | 104s<br/>r5.8xlarge/io1 |
| 4 | Application memory usage: 480G<br/>Application memory change: 50G | 1548s<br/>r5.16xlarge/io1 | 80s<br/>r5.16xlarge/io1 |

## Call to action - save your spending and time 
What is the characteristic of your running job and environment? AppCapsule++ is available now with Memory Machine Cloud 2.4 Goa release. Please reach out or leave comments below and we would love to chat and help!

In the rapidly evolving world of cloud computing, the choice of platform can significantly impact both the efficiency and cost of operations, especially in specialized fields like bioinformatics. Recently, a meticulous benchmark study comparing MMCloud with AWS Batch across various bioinformatics pipelines has shed light on the remarkable advantages of MMCloud. Here, we delve into the key findings that position MMCloud as a superior choice for bioinformatics workflows.

## Pipelines used

* **[nf-core/rnaseq](https://github.com/nf-core/rnaseq)**
    * * [rnaseq samplesheet](https://github.com/nf-core/test-datasets/blob/rnaseq3/samplesheet/v3.10/samplesheet_test.csv) - 8 samples

* **[nf-core/atacseq](https://github.com/nf-core/atacseq)**
    * * [atacseq samplesheet](https://github.com/nf-core/test-datasets/blob/atacseq/samplesheet/v2.0/samplesheet_full.csv) - 6 samples

* **[nf-core/sarek](https://github.com/nf-core/sarek)**
    * * [sarek samplesheet](https://github.com/nf-core/test-datasets/blob/sarek/testdata/csv/HCC1395_WXS_somatic_full_test.csv) - 2 samples

---

## Benchmark Results

* Each pipeline was executed three times for each compute environment tested. The average result for each pipeline is shown in the following sections

## Exceptional Cost Efficiency

**Cost ($)**
| Pipeline | MMCloud-OnDemand | MMCloud-Spot | AWSBatch-OnDemand | AWSBatch-Spot |
| -------- | -----------| ------------ | ------------| ------------- |
| **atacseq**  | 10.70      | 5.45         | 17.70       | 6.20          |
| **rnaseq**   | 40.66      | 21.77        | 100.34      | 37.60         |
| **sarek**   | 11.21      | 6.94         | 29.73       | 34.33         |

![image](https://hackmd.io/_uploads/BJHRRBASp.png)

The most striking advantage of MMCloud is its cost-effectiveness. Across all tested bioinformatics pipelines, including nf-core/rnaseq, nf-core/atacseq, and nf-core/sarek, MMCloud consistently demonstrated lower costs in both OnDemand and Spot instances. For instance, the rnaseq pipeline on MMCloud-OnDemand is approximately 60% cheaper than on AWS Batch. This significant cost reduction opens up opportunities for more extensive and frequent computational experiments within a constrained budget.

## Reduced CPU-Hour Billing

**CPU-Hours (billable)**
| Pipeline | MMCloud-OnDemand | MMCloud-Spot | AWSBatch-OnDemand | AWSBatch-Spot |
| -------- | -----------| ------------ | ------------| ------------- |
| **atacseq**  | 74.53      | 78.83        | 104.10      | 91.83         |
| **rnaseq**   | 416.90     | 422.93       | 758.63      | 763.47        |
| **sarek**    | 113.17     | 149.93       | 225.50      | 215.83        |

![image](https://hackmd.io/_uploads/ryM9ArCS6.png)

Another crucial aspect where MMCloud shines is in its efficient use of CPU hours. The benchmark results showed that AWS Batch generally incurs more billable CPU hours than MMCloud for the same tasks. This efficiency not only contributes to the cost-saving aspect but also reflects optimized resource utilization, a critical factor in sustainable computing practices.

## Competitive Processing Times

**Wall-Time (h)**
| Pipeline | MMCloud-OnDemand | MMCloud-Spot | AWSBatch-OnDemand | AWSBatch-Spot |
| -------- | -----------| ------------ | ------------| ------------- |
| **atacseq**  | 4.17       | 4.82         | 3.43        | 3.56          |
| **rnaseq**   | 6.90       | 7.53         | 8.27        | 8.17          |
| **sarek**    | 7.51       | 8.59         | 10.36       | 11.91         |


![image](https://hackmd.io/_uploads/Skr20BAH6.png)

While AWS Batch exhibited slightly better performance in wall-time for some pipelines, MMCloud was not far behind, even outperforming AWS Batch in the sarek pipeline. This finding suggests that MMCloud provides a balanced approach, ensuring timely completion of tasks without compromising on cost and resource efficiency.

---

### Advanced Handling of Spot-Reclaims and Wave-Rider in MMCloud

#### Adaptive Job Management in Dynamic Environments

MMCloud's approach to handling spot-reclaims and utilizing the wave-rider feature during the benchmarks is a testament to its adaptive and robust job management capabilities. This sophisticated handling ensures uninterrupted workflow execution, even in the volatile environment of cloud computing.

#### Insight into Job Migration and Resource Optimization

A key inquiry in the thread was about the frequency of task migrations due to memory-instigated resizing. While MMCloud's operational center (opcenter) GUI currently doesn't provide detailed workflow-level reports on such migrations, the float CLI tool offers valuable insights. For instance, during the benchmark period (Nov 8 - Nov 22, 2023), a report generated using `float report get usage_report_by_job` revealed 125 jobs that migrated to more than one instance, primarily due to spot-reclaims or wave-riding.

#### Distinctive Features of MMCloud: Spot-Reclaims and Wave-Riding

- **Spot-Reclaims**: Majority of the migrations were due to spot-reclaims, showcasing MMCloud's efficient response to instance preemptions. This feature is crucial for maintaining workflow continuity in spot instance environments, a common challenge in cloud computing.
- **Wave-Riding**: The logs indicated several instances where jobs were migrated due to wave-riding, triggered by varying resource needs. For example, migrations occurred when memory consumption was below a certain threshold, or CPU usage exceeded set limits. This dynamic adjustment ensures optimal resource utilization and cost-efficiency.
- **Addressing Compatibility Issues**: Interestingly, some jobs floated up to 11 times due to instance compatibility issues, a concern that MMCloud has addressed with an upcoming fix in the 2.4 release.

#### Conclusion: MMCloud's Superior Resource Management

The way MMCloud handles spot-reclaims and wave-rider features adds another layer of efficiency and reliability to its platform. This advanced resource management capability, ensuring seamless job migrations and optimal resource utilization, further underscores MMCloud's edge over AWS Batch. By continually evolving and addressing issues like instance compatibility, MMCloud demonstrates its commitment to providing a robust and user-friendly cloud computing environment, particularly for complex bioinformatics workflows.

The benchmark analysis unequivocally places MMCloud in a favorable position, especially for bioinformatics workflows. Its outstanding cost efficiency, coupled with optimized CPU usage and competitive processing times, make MMCloud an attractive option for researchers and organizations seeking to maximize their computational resources.

In summary, MMCloud emerges as a compelling alternative to AWS Batch, offering a more balanced and economical solution for bioinformatics computing needs. Its advantages in cost-saving and resource optimization are crucial for advancing research within budgetary constraints, making it an essential tool for the future of bioinformatics and cloud computing.

---

## Versions used in Benchmark

| Name     | Version                   |
| -------- | ------------------------- |
| float    | v2.3.3-d0adfcc-FireIsland |
| OpCenter | v2.3.3-d0adfcc-FireIsland |
| nf-float | 0.4.0                     |
| Nextflow | 23.10.0                   |
| atacseq  | 2.1.2                     |
| rnaseq   | 3.12.0                    |
| sarek    | 3.4.0                     |

Anyway you look at it, the Chinese mitten crab (also known as the Shanghai hairy crab because of the setae on its claws) has something to offer. For the chef, a seasonal delicacy — full of sweetness and umami flavors. To the aquaculturalist, an important crop and revenue source. This crab is a marvel to biologists — it can live in freshwater and saltwater? Regenerate limbs? Really?

For the geneticist, the challenge is to trace these phylogenetic behaviors (behaviors typical of the species) back to the genome and transcriptome level.

![](https://baywatch-api.memverge.com/media/upload/202311/231127195706586901.jpeg)

## Eriocheir sinensis

The Chinese mitten crab (*Eriocheir sinensis*) is native to China where it is found in lakes and rivers. In Europe and North America, it is considered an invasive species. The mitten crab spends most of its life in freshwater although the reproductive phase occurs in brackish water and in seawater (the species is catadromous). The change in salinity requires a complicated mechanism (osmoregulation) to maintain the ionic balance in its cells.

The first discovery of Chinese mitten crabs in North America occurred in the San Francisco Bay in [1992](https://wildlife.ca.gov/Conservation/Invasives/Species/Mitten-Crab). Since then, specimens have been found in the Chesapeake Bay, Hudson River, and the Great Lakes. They have been found all over Europe — in the Thames River, the Tagus River, the Danube, and even in the Venice lagoon, although finding an isolated specimen does not mean that a permanent population has established itself. Mitten crabs have a high reproductive rate and can withstand physiological stress (such as starvation and dessication) which makes them a formidable invasive species whose burrows undermine river bank stability. It's a mystery why no Chinese mitten crabs have been seen in California since [2010](https://www.smithsonianmag.com/blogs/smithsonian-environmental-research-center/2018/06/05/wanted-chinese-mitten-crabs/).

Beyond its culinary, agricultural, and environmental impacts, the Chinese mitten crab is worthy of study because of its ability to [regenerate](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC9481118/) an entire limb (as long as it can molt). Regeneration capability is stronger in inverterbrates than in vertebrates where it seems to have declined. Birds and  mammals both demonstrate some cell and tissue regeneration capability, so it is an interesting topic of medical research to see if regeneration ability can be stimulated.

It is no surprise, then, that *Eriocheir sinensis* has been studied extensively, in particular, to discover the gene expressions that underly its physiological and behavioral traits.  The first genome sequencing, assembly, and annotation of the Chinese mitten crab was reported in [2016](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4730596/) and the current reference assembly was posted in [2022](https://www.ncbi.nlm.nih.gov/datasets/genome/GCF_024679095.1/). The haploid [chromosome number](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4814232/) is 73 (2n=146) and the genome size is about 1.27 Gb, which puts it the high end of chromosome number among [arthropods](https://www.nature.com/articles/s41467-021-22604-3) (inverterbrates with exoskeletons), although there is a large percentage of repetitive elements. For comparison, the haploid chromosome number for humans is 23 and the haploid genome has about 3.1 Gb.

Nextflow and MMCloud
--------------------

So, what has this to do with Memory Machine Cloud (MMCloud)? RNA-seq is a popular computational pipeline for analysing gene expression and transcription activation using data generated by next-generation sequencing (NGS) machines from Illumina, PacBio, Oxford Nanopore Technologies, and others. A complicated pipeline, like RNA-seq, requires a workflow manager, such as Nextflow, to schedule and manage the individual tasks in the pipeline.


In Nextflow terminology, each task is assigned to an "executor," which is a complete environment for running that step in the analysis. By attaching the [nf-float](https://github.com/MemVerge/nf-float/blob/master/README.md) plugin to a workflow, Nextflow can use MMCloud as an "executor." From an MMCloud point of view, the execution task that Nextflow assigns to it is an independent job that it runs just like any other batch job. For the Nextflow user, the user experience remains the same while benefiting from all the MMCloud features, such as SpotSurfer, WaveRider, and WaveWatcher.

MMCloud release 2.3.3 introduced a POSIX-compliant, distributed file system that allows Nextflow pipelines to use a high-capacity storage service (such as AWS S3) as a high-performance file system. For complicated pipelines where individual tasks share a file system for writing and reading intermediate data, the performance of the file system has a dramatic impact. 

Running a Nextflow pipeline on MMCloud is straightforward. To demonstrate using AWS EC2 compute instances, we ran [nf-core/rnaseq](https://nf-co.re/rnaseq/3.13.2) on experimental *Eriocheir sinensis* sequence data available from the [European Nucleotide Archive](https://www.ebi.ac.uk/ena/browser/text-search?query=Eriocheir%20sinensis) and the [National Library of Medicine](https://www.ncbi.nlm.nih.gov/datasets/genome/?taxon=95602).

The nf-float plugin requires a configuration file, in which you specify parameters that determine the execution environment. One parameter is the VM creation policy. For this run, we chose "SpotFirst", which means that MMCloud tries to start a spot instance. If, after three attempts, a spot instance does not start, MMCloud starts an on-demand instance. If AWS reclaims the spot instance that a job is running on, MMCloud moves the job to a new instance and follows the same policy - try for a spot instance first and go to an on-demand instance if not successful.

## RNA-Seq Results

At the end of the successful run, Nextflow displayed the following message, which shows that 170 tasks (jobs) completed with no failures.

`-[nf-core/rnaseq] Pipeline completed successfully -`
`Completed at: 25-Nov-2023 10:42:32`
`Duration    : 6h 14m 7s`
`CPU hours   : 123.3`
`Succeeded   : 170`

Included in the output of nf-core/rnaseq is [MultiQC](https://multiqc.info/), a reporting tool that summarizes (in html format) the statistics and quality metrics obtained from multiple analysis modules and data sets. MultiQC is helpful in checking the results of a pipeline run for errors and anomalies.

Examples of the output from MultiQC for the *Eriocheir sinensis* run are shown in the figures that follow.

![](https://baywatch-api.memverge.com/media/upload/202311/231127200149299985.png)

![](https://baywatch-api.memverge.com/media/upload/202311/231127200212828822.png)


## Conclusion

The Chinese mitten crab is a fascinating bundle of surprises. There is no doubt that the species will continue to receive attention - on menus, in departments of environmental conservation, and as the subject of a range of "Omics" studies (for example, [transcriptomics](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6328174/)). As researchers become aware of the power of MMCloud, many of those Nextflow pipelines will run on MMCloud in AWS, Google Cloud, or AliCloud.

For the residents of Shanghai, however, the annual appearance of the Shanghai hairy crab is always an eagerly anticipated milestone.

High-performance computing (HPC) traditionally involves clusters of compute servers deployed in dedicated facilities. In recent years, demands for scale and performance have pushed HPC from on-premises to the cloud - a transition that offers new opportunities as well as significant hurdles.

On the positive side, the cloud offers virtually unlimited on-demand computing and storage resources because cloud platforms provide elastic capacity that can grow (and shrink) dynamically when resource demands change.

There are economic benefits to moving to the cloud, although not always. A stable workload that runs 24x7x365 for several years may be cheaper to run on dedicated hardware (cloud service providers have responded to this case by offering bare-metal instances). The pay-as-you-go model eliminates upfront capital expenses and avoids the costs associated with unused compute cycles. The range of compute instance types available in the cloud allows users to pay only for what they need, when they need it.

However, running applications in public clouds introduces new challenges. Each cloud service provider has an extensive catalog of services, and each service has a wide array of features. Without the knowledge required to configure and optimize cloud services, the researcher may encounter unpredictable or unsatisfactory application performance, unexpected costs, or unnecessary security risks.

This is where Memverge’s Memory Machine Cloud (MMCloud) can help. MMCloud is an easy-to-use cloud automation platform designed for scientific computing and data science. MMCloud simplifies the deployment of data-intensive pipelines and interactive computing applications in the cloud through automation and containerization.

Containers are the key technology that enables application mobility and automates the deployment of applications, at scale, in the cloud. The container includes all the software dependencies and runtime libraries needed to run the application in a reproducible way. But container deployment requires a cloud orchestration platform to schedule, instantiate, and manage containers. MMCloud provides an intuitive GUI (as well as a CLI) that allows the non-cloud specialist to deploy complex workflows as containerized applications in the cloud.

There are many reasons why scientists rely on MMCloud to enhance their research capabilities. Here are the top five reasons why you should choose MMCloud as the platform to run your cloud workloads.

**1. Seamless Expansion of High-performance Computing to the Cloud**

Hybrid cloud (a combination of on-premises and cloud resources) is a popular architecture for HPC because of its flexibility and scalability. When demand for computing resources exceeds what is available locally (on-premises), applications can “burst” to the cloud.

MMCloud effectively augments the local HPC environment with public cloud by enabling the user to launch jobs in the cloud using the same familiar HPC job managers such as SLURM and PBS. This way, scientists can operate in an efficient hybrid environment. Containerization and automation are a core feature of MMCloud. MMCloud automates deployment of containerized applications into the clouds, and it automatically deletes cloud resources after a job completes, removing the risk of unattended resources adding to the monthly cloud bill. Interactive sessions can be hibernated and restarted when needed again.

![Memory Machine Cloud HPC Bridge extends HPC into the cloud](https://baywatch-api.memverge.com/media/upload/202312/231207200802821427.jpeg)


Figure 1 MMCloud expands HPC to clouds

**2. Insightful Monitoring of Cloud Workloads**

Some users are reluctant to move workloads to the cloud because of a concern that they will have limited insight into, and control over, how their applications run in the cloud. Will the job complete in a shorter or longer time? Are the resources over- or under-provisioned?

Visibility into workload performance and resource utilization is critical when operating in the cloud. Granular monitoring of resource usage and costs can identify opportunities for optimization through rightsizing, shutting down idle resources or shifting workloads based on the current prices of compute instances. While cloud service providers do offer monitoring tools, these tools are not always easy to use and often come with additional costs.

MMCloud provides a comprehensive solution with advanced monitoring and metering capabilities, ensuring that scientists have a detailed understanding how their workloads run. CostReporter gives you a summary how much you spend on the jobs running in the cloud. WaveWatcher makes it easy to see the real-time consumption of resources including CPU, memory, storage, and network transfer speeds. For example, an application may exceed its storage limits or crash because of insufficient resources. Issues like these can be identified using MMCloud’s graphical interface, making troubleshooting much more straightforward.

MMCloud generates event and performance logs at both the job and host (worker node) level. Logs can be viewed in real-time to track the progress of a job as it executes, or downloaded after a job completes to identify issues or errors. The monitoring features enable researchers to fine-tune their environments for maximum efficiency.

![MMCloud WaveWatcher provides insights to cloud workloads](https://baywatch-api.memverge.com/media/upload/202311/231121040115584000.png)

Figure 2 MMCloud WaveWatcher provides insights to cloud workloads

**3. Reliable Spot Instances**

Almost all service providers offer spot Instances as a way for users to purchase excess computing capacity at a significantly lower price than on-demand instances (discounts can be as much as 90%). The trade-off is unpredictable availability. The cloud service provider can reclaim these instances with nominal warning (usually two minutes or less). Spot instances are ideal for stateless applications and can be used in stateful, batch-oriented pipelines if the workflow manager can requeue any failed jobs, although the total cost and wall clock time become unpredictable.

MMCloud's SpotSurfer feature allows stateful applications to always run to completion by "surfing" to a new VM instance if the underlying Spot Instance is reclaimed. Customers can realize the cost savings of spot instances without the risk of job interruptions. The technology that makes SpotSurfer possible is AppCapsule. AppCapsule creates a snapshot of the in-memory state as well as file system data. AppCapsule is triggered automatically when the cloud service provider signals that it is reclaiming the spot instance. Job execution pauses and then resumes on a new spot instance.

For interactive sessions, MMCloud provides a reverse proxy to ensure that each interactive session appears to clients as an IP address that does not change even if the session moves to a different virtual machine with a different IP address.
![MMCloud SpotSurfer protects workloads on spot instances](https://baywatch-api.memverge.com/media/upload/202311/231121040319580845.png)

Figure 3 MMCloud SpotSurfer protects workloads on spot instances

**4. Cost Control**

Cost management is a major concern for researchers, many of whom are grant-funded with strict budget constraints. While cloud services can be cost-effective, they can also lead to unpredictable expenses if not managed carefully. Institutions must develop new financial governance models to control cloud spending, ensuring that costs align with research budgets. Managing costs at cloud scale demands continuous monitoring of cloud resource usage to guard against runaway expenses. MMCloud’s Job Cost Reporting tools allow for precise budgeting, and the SurfZone feature provides real-time enforcement of limits on cloud spending.

Lifecycle management of cloud-based workloads can be critical for cost control. MMCloud provides control over of resources, for example, by enforcing automated schedules for job startup and shutdown, and maximum job execution times. This level of control is essential for managing costs in group settings where multiple users may run concurrent experiments. There are actions that individual users can take, for example, canceling jobs, moving jobs to smaller (cheaper) instances, or suspending interactive sessions. These actions can result in saving cost and can be used for avoiding idle charges.

Performance can be critical for cost control too. When jobs run on the spot instances, the slower jobs in data pipelines have a higher chance of getting reclaimed and the time and expense penalty for starting over might be huge. MMCloud’s integration with third-party high-performance file systems has improved the efficiency of file operation and has shown a significant advantage for Nextflow workflows.

WaveRadar, an interactive dashboard created on mmcloud.io is a free FinOps tool for viewing historical spot EC2 prices across all major AWS regions. WaveRadar lets you identify the regions offering the lowest rates for a given instance or instance family.

**5. Rightsizing Cloud Resources**

Compute instances available from cloud service providers range in size from one vCPU and 500 MB memory to 192 vCPUs and 1.5 TB memory (and even more in some specialized instances). Choosing the optimal cloud resources for scientific workloads is a complex task. Sizing for the peak load is safe but inefficient. Sizing for the average load reduces the cost but can lead to unacceptable performance or even out-of-memory (OOM) errors.

MMCloud's WaveRider feature simplifies this process by removing the need to select a single instance for each task. WaveRider provides the capability to migrate running jobs to optimally sized virtual machines based on their real-time resource utilization.

Job migration can be initiated in three ways: manually, driven by policy, or programmatically. At any time, you can manually migrate a job to a specific instance type, or to an instance whose capacities you define. With a rules-based policy, WaveRider monitors the resource utilization of your workload. If the upper threshold for CPU or memory utilization is crossed for a specified interval, the job is migrated to a virtual machine that has more virtual CPUs or more memory. Similarly, if the lower threshold is crossed and utilization remains low for a specified interval, the job is moved to a smaller virtual machine. For jobs with a well-known resource usage profile, job migration can be programmed into the job script so that the job migrates at predetermined stages in the execution.

Rightsizing has a positive effect on the optimal allocation and sharing of cloud resources. The optimization of using cloud resources has a profound impact on environmental sustainability. Users who proactively release underutilized resources allow the cloud service provider to increase server utilization. Fewer servers running at higher utilization lowers operational as well as embedded emissions. In a world increasingly conscious of climate change, optimizing cloud resource usage is a step towards reducing the overall carbon footprint of the IT industry. MMCloud provides a carbon emissions dashboard so that users become aware of the impact of how they run their jobs in the cloud.

![MMCloud Carbon Emission Monitor](https://baywatch-api.memverge.com/media/upload/202311/231121040303736482.png)

Figure 4 MMCloud Carbon Emission Monitor

**Conclusion**

Moving HPC workloads to the cloud, or bursting workloads to the cloud when needed, has benefits in terms of cost, scalability, efficiency, and sustainability. Challenges in usability and cost control in the cloud have prevented users from taking advantage of the cloud or a hybrid cloud architecture.

MMCloud is a powerful, yet easy to use, platform that facilitates the use of cloud computing by the research community. MMCloud is cloud-agnostic and is supported on AWS, Google Cloud, and AliCloud today. A free 30-day, no obligation trial is available. Register at [https://mmcloud.io/customer/register](https://mmcloud.io/customer/register) today.

<h2>Cloud’s promise unfulfilled</h2><p class="ql-align-center"><img src="https://miro.medium.com/v2/resize:fit:1400/1*jCza7dtD08vfltfQw2XhYw.png" height="207" width="700"></p><p>Recent news suggest that the growth of cloud adoption is encountering serious impedance. There are even organizations repatriating compute resources back to on-premises data centers, and cloud cost seems to be the culprit.</p><p>Indeed, a 2 CPU (24 core)/48 GB RAM server sells for ~$10,000. On AWS, a 24 vCPU / 48 GB RAM VM costs ~$1.18/hr. If you continuously ran the VM for 1 year, you would have paid $10,195 and could have bought the server hardware. Since the typical useful life of server hardware is 4–5 years, you would’ve overpaid 4–5 times for the server. Of course in a more rigorous comparison we need to consider operational costs but I think we all agree that continuously running the cloud server the same way as an on-prem server is costly.</p><p>The key word, of course, is “continuously.” To reap the benefit of the cloud you need to use it efficiently, i.e., releasing resources that you are not using, and using resources that match the needs of your applications.</p><h2>Several challenges stand in the way of efficient cloud usage in the enterprise:</h2><h2>App owner access to the cloud</h2><p>The team that manages the cloud resources, i.e., the cloud admin team, is not the team that is running the applications, i.e., the application owners: the developers, the analysts, the scientists, et al. The application users often need to wait hours or days to gain access to cloud resources, and they don’t have the tools or the discipline to release the resources as quickly as possible.</p><h2>App owner flying blind</h2><p>The application owners may not know the most appropriate machine size to use for their applications. Often, they do not have the tools necessary to view the resource utilization of the application. They only know their cloud bill is high, their application seems to take a long time to complete, they suffer out-of-memory errors, and their application crashes and must be restarted.</p><h2>Forced to provision for peak usage</h2><p>Even when the application owner understands the application, it is often difficult to pick one machine size because most applications have peaks and troughs in their resource utilizations. If one picks the machine size that can handle the peak utilization, it often means the machine is under-utilized most of the time. If one sacrifices performance by under provisioning, then the application may crash (OOM) or otherwise run very slowly.</p><h2>The serverless model for complex, stateful apps</h2><p>When we set out to build a product for the cloud, leveraging the fruits of our research in Big Memory Computing, we asked ourselves, “Can we build software that enable all applications, including stateful apps, to be serverless?” That means application owners can focus on their subject areas and never need to worry about management of servers or other cloud resources, nor depend on another team to do so.</p><p>Stateful applications should be able to take advantage of the elasticity of the cloud and consume resources most appropriate for it, even when the resource utilization is bursty. Serverless computing services, such as AWS Lambda, have proven that the serverless model is highly desirable for cloud native microservices. But how do we enable complex applications, even stateful applications, to run serverless?</p><h2>Decoupling complex, stateful applications from servers</h2><p class="ql-align-center"><img src="https://miro.medium.com/v2/resize:fit:1400/0*ETvWyn5e8XFOeJGV.png" height="354" width="700"></p><p class="ql-align-center">Application runtime is “chained” to servers</p><p>Recent news suggest that the growth of cloud adoption is encountering serious impedance. There are even organizations repatriating compute resources back to on-premises data centers, and cloud cost seems to be the culprit.</p><p>Indeed, a 2 CPU (24 core)/48 GB RAM server sells for ~$10,000. On AWS, a 24 vCPU / 48 GB RAM VM costs ~$1.18/hr. If you continuously ran the VM for 1 year, you would have paid $10,195 and could have bought the server hardware. Since the typical useful life of server hardware is 4–5 years, you would’ve overpaid 4–5 times for the server. Of course in a more rigorous comparison we need to consider operational costs but I think we all agree that continuously running the cloud server the same way as an on-prem server is costly.</p><p>The key word, of course, is “continuously.” To reap the benefit of the cloud you need to use it efficiently, i.e., releasing resources that you are not using, and using resources that match the needs of your applications.</p><h2>AppCapsule technology makes it possible</h2><p>We invented a solution for decoupling stateful apps from servers with AppCapsule technology. A stateful application is one whose execution depends on the data stored in memory. Because memory is not persistent, when the server hardware reboots or changes, the data in memory is lost, and the application must start from the beginning again. Our AppCapsule creates a snapshot of all the data in memory, and all the application states required to restore the application to this moment in time, as well as the data on storage. With AppCapsule, we can transport the application runtime across different machines, even different clouds.</p><p class="ql-align-center"><img src="https://miro.medium.com/v2/resize:fit:1400/0*X_gS1OCoelC4ImVA.png" height="303" width="700"></p><p class="ql-align-center">AppCapsule Snapshot</p><p>Armed with this technology, we set out to build control components that natively integrates with the clouds, and the user interface designed to serve the application users, and voilà, we have Memory Machine Cloud, the cloud automation platform that delivers the Serverless experience for most applications.</p><h2>The Floating App</h2><p>The internal engineering codename for Memory Machine Cloud is “Float,” because when you launch your application using Memory Machine, your application is floating on the cloud, untethered to the server it is running on. For that reason, our CLI commands all start with the keyword “float.”</p><p>It’s pretty amazing what you can do when your application is floating. The first use case we tackled was running long, stateful jobs, such as genomic sequencing, on spot instances. Spot instances offer the most economical way to tap into the vast compute resources in the public cloud, but because the CSP can evict your workload on spot with a very short notice period, they are not suitable for these jobs. That is, unless you use Memory Machine Cloud.</p><p>When you launch your genomic sequencing job using Memory Machine, you simply specify the spec of the machine, and that you want to leverage spot instances. Memory Machine takes care of finding the spot instances, deploying your containers, mapping your storage, and launching your job. If there is a spot eviction event, Memory Machine creates an AppCapsule, and moves it to another spot instance, where the job will continue. In fact, the application is unaware of the floating event. This use case alone, we have found, consistently saves our users more than 60% in compute cost.</p><p><strong>Submitting a job with the Float GUI</strong></p><p class="ql-align-center"><img src="https://miro.medium.com/v2/resize:fit:1400/0*yALS-Fy-kHvybR0h.png" height="502" width="700"></p><p class="ql-align-center"><strong>Launching your job in the Cloud takes &lt;1 minute</strong></p><p>Another use case is rightsizing. Often an application’s resource utilization curve has peaks and valleys over time. That is problematic for picking the appropriate machine capacity for the application. However short-lived, the peak memory usage typically becomes the minimum memory capacity for the machine, lest the application will experience an OOM and crash. That also means that during the majority of the execution, the machine is underutilized.</p><p>By making the application runtime float on the cloud VM, Memory Machine Cloud has a great solution for this problem. It constantly monitors the resource utilization of the application, and when it detects under- or over- utilization conditions, it can “float” the application to a more appropriate machine. This becomes especially handy when the user uses a workflow manager, such as NextFlow or Cromwell, to kickoff hundreds and thousands of jobs, and it is virtually impossible to manually pick the most appropriate machine types for each of the jobs.</p><p class="ql-align-center"><strong>Monitoring resource utilization and “floating” the app to a more appropriate VM</strong></p><p class="ql-align-center"><img src="https://miro.medium.com/v2/resize:fit:1400/0*xs9uaSJDYLK_n3m2.png" height="361" width="700"></p><p class="ql-align-center"><strong>WaveWatcher shows how jobs automatically “surf” to the most appropriate instance type</strong></p><h2>The post-server era</h2><p>In the hardware world, we are seeing tremendous progress in the deconstruction of servers, composable CPU, Storage, and most recently, memory. Those innovations will manifest themselves in the public cloud soon. There is a need and an opportunity to build the automation layer that enables application users and IT operators to transition into “post-server” mode TODAY, not only for cloud native applications, but for all applications. That is the mission of Memory Machine Cloud.</p><iframe class="ql-video ql-align-center" frameborder="0" allowfullscreen="true" src="https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fwww.youtube.com%2Fembed%2F2juNvP3BbK8%3Ffeature%3Doembed&amp;display_name=YouTube&amp;url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D2juNvP3BbK8&amp;image=https%3A%2F%2Fi.ytimg.com%2Fvi%2F2juNvP3BbK8%2Fhqdefault.jpg&amp;key=a19fcc184b9711e1b4764040d3dc5c07&amp;type=text%2Fhtml&amp;schema=youtube" height="480" width="854"></iframe><p><br></p>

Blog - MMCloud SpotSurfer