rna - seq is the direct sequencing of transcripts by high - throughput sequencing technology and can profile an entire transcriptome at single - base resolution whilst concurrently quantifying gene expression levels on a genome - wide scale [ 13 ] .
rna - seq not only has considerable advantages for examining transcriptome fine structure  for example , in the detection of novel transcripts , allele - specific expression , and alternative splicing  but also provides a far more precise measurement of levels of transcripts than that of other methods [ 4 , 5 ] . with no probes or primers to design
, rna - seq delivers unbiased and unparalleled information about the transcriptome and gene expression .
early studies have demonstrated that rna - seq is very reliable in terms of technical reproducibility [ 6 , 7 ] .
compared to microarray - based profiling , rna - seq can detect the expression of low abundance transcripts and the subtle change under different conditions ; has a wider dynamic range ; and avoids technical issues in microarray related to probe performance such as cross - hybridization , limited detection range of individual probes , and nonspecific hybridization [ 8 , 9 ] .
currently , rna - seq is becoming an attractive approach in the profiling of gene expression and in evaluating differential expression [ 1013 ] .
until recently , sequencing has primarily been carried out in large genome centers which have invested heavily in computational infrastructure that enables genomic sequence analysis [ 14 , 15 ] .
the recent advancements in sequencing technology have greatly decreased the sequencing costs and increased the size and number of datasets . as a consequence ,
larger amounts of sequence data are not only being produced at lower costs , but also being more often by small to midsize research groups .
it is expected that clinical sequencing will become produced a part of the diagnostic routines shortly .
however , the enormous data from large - scale rna - seq studies poses a fundamental problem of data management and analysis in a local environment and requires increasingly complex computational methods .
consequently , limited access to computational infrastructure and high - quality bioinformatics tools and the demand for personnel skilled in data analysis and interpretation remain a serious bottleneck for most researchers .   in recent years
, cloud computing has emerged as a viable option to quickly and easily acquire computational resources for large - scale data analysis [ 1822 ] .
several cloud - based bioinformatics applications and resources have been developed specifically to address the challenges of working with the very large volumes of data generated by next generation sequencing ( ngs ) technology , including cloudburst , crossbow , myrna , clovr , cloudaligner , and peakranger .
cloud computing has created new possibilities to analyze ngs data at reasonable costs , especially for laboratories lacking a dedicated bioinformatics infrastructure .  
differential analysis of rna - seq data consists of three key steps : ( i ) reads mapping ; ( ii ) expression quantification ; and ( iii ) statistical testing to determine significantly differential expressed ( de ) genes . for statistical tests ,
several r - based packages have recently been developed specifically for de analysis in rna - seq experiments , including deseq , edger , and bayseq . as an input ,
these algorithms take count data in the form of a rectangular table of integer values .
the table cell in the ith row and the jth column of the table corresponds to the number of sequence reads mapped to gene i in sample j. to obtain such a count table , we need to generate it from the raw sequence reads , which is done by steps ( i ) and ( ii ) that are mentioned above .
both steps are very computationally intensive , especially for rna - seq studies in which hundreds or even thousands of samples are sequenced .  
stormbow , as described in this paper , is a cloud - based tool developed to meet the computational challenges in large - scale rna - seq data analysis and to significantly reduce the turnaround time in rna - seq data analysis .
the tool simply takes raw sequence reads in fasta format as inputs and generates a gene count table for large rna - seq studies in a very short time by processing individual rna - seq samples in parallel using the cloud .
stormbow is an extension of rainbow , a software package that we developed for large - scale whole genome sequence data analysis in the cloud .
both rainbow and stormbow were developed to meet the computational challenges in large - scale genomic sequencing , with rainbow for whole - genome sequencing while stormbow for rna - seq .
stormbow comes with scripts that automate the stormbow pipeline on amazon 's elastic compute cloud ( ec2 )   utility computing service .
the ec2 driver script can be run from any linux computer with internet connection ; however , all the computations are executed remotely by multiple ec2 instances in the cloud .
. there are multiple open - source based aligners available to mapping reads to a reference genome .
with stormbow , we wrap the omicsoft sequence aligner ( osa ) , a fast and accurate alignment tool for rna - seq , and run it in amazon 's cloud environment .
benchmarked with existing methods , such as tophat , osa improves mapping speed 410x with better sensitivity and less false positives than similar tools .
osa has built - in features to automatically trim those nucleotide bases with low - quality score at 3-end when it maps sequence reads to a reference transcriptome and genome . for raw sequence data ,
no additional preprocessing is needed .   the raw sequence data for a large - scale rna - seq study , in which several hundred samples are sequenced ,
is typically multiple terabytes ( tb ) in size . for a deep rna - seq sample , the raw sequence data in fastq format ranges from 20 to 25 
gb , and after reads mapping , the corresponding bam file ( binary version of a sequence alignment map ) ranges from 8 to 10  gb . assuming 200 samples , the input data will be 4 to 5  tb , with the output bam files adding another 2  tb . for such large volumes of data ,
it is impractical to transfer them to and from amazon via a typical network connection .
the most efficient and reliable way is to move them through amazon 's import / export service .
this service allows a user to ship multiple hard drives via fedex to amazon ; after which , amazon copies the data to s3 directly .
the user has the option to encrypt the data on the hard drives to ensure security during transit .
when stormbow runs , it can fetch the sequence data from s3 directly ( see figure 1 ) . in the stormbow pipeline
after an ec2 instance finishes its computational tasks , it is instructed to terminate itself .
s3 provides virtually unlimited storage space for cloud computing , ensures high durability of its data , and allows for parallel i / o , which is why we chose s3 as the centralized data storage for the stormbow pipeline .
however , amazon does not offer an analysis solution ; it is the user 's responsibility to properly utilize the resources to analyse data .
after requested resources from amazon become available , they must be configured with the necessary software , datasets must be downloaded , and then analysis can be run .
the m1.xlarge instance consists of a 64  bit platform , 15  gb memory , 4 virtual cores , 1,690  gb instance storage , and very high i / o performance .
since there are 4 cores , 4 parallel threads can be launched to map millions of short reads to the reference genome and gene model .
after an m1.xlarge instance is requested , these required software packages are installed , including the following : ( 1 ) zlib - devel , a library for data compression and inflation ; ( 2 ) mono-2.10.8   to provide a runtime environment in linux for applications that require  .net framework support ; ( 3 ) osa software ; ( 4 ) hg19 ( the human reference genome in its 19th version ) ; ( 5 ) refseq gene model  both the reference genome and gene model are required in reads mapping and expression quantification and are downloaded from omicsoft 's reference library website  ; and ( 6 ) s3cmd command line tool   to transfer data to and from s3 . in principle
, all required software can be installed on - the - fly when each ec2 instance is launched in the cloud . however , the total time required for system configuration is about 50 minutes if starting from the default amazon 's linux amazon machine image ( ami ) 2013.03 ( ami-3275ee5b ) .
a better solution is to create a customized ami with all the needed tools preinstalled and configured .
this approach saves 50 minutes when launching a new ec2 instance from this customized ami , which adds up quickly when several hundred ec2 instances are launched in the cloud .
another advantage to using this customized ami is reliability ; all the needed software packages are properly configured and tested , which eliminates mistakes in system configuration .
stormbow is distributed with a script file that contains all the unix shell commands needed to create this ami . when an ec2 instance is launched from the customized ami above
although it is ready for processing rna - seq data , it does not know which sample to process and/or how to analyse it .
these two problems are solved through the cloud - init mechanism , which passes a piece of user - data to an ec2 instance when it is launched .
the user - data itself is an executable shell script that is responsible for the following : ( 1 ) setting the proper environment variables , such as sample , genome , gene_model , and reference_library and ( 2 ) downloading and executing rnaseq.sh , which contains step - by - step data processing instructions .
the separation of rnaseq.sh from the customized ami allows for flexibility and eases maintenance of the stormbow pipeline .
software packages and reference genomes do not change very often , but rna - seq datasets and their analyses might vary with platforms and projects .
rnaseq.sh is fetched on - the - fly by each ec2 instance , and tailored rna - seq analysis can be achieved by customizing rnaseq.sh . as shown in the right side of figure 1 , the main tasks for the default rnaseq.sh script are as follows : ( 1 ) fetching sequence data from s3 ; ( 2 ) mapping reads to the reference genome ; ( 3 ) quantifying gene and transcript expression ; ( 4 ) quality checking of mapped reads ; and ( 5 ) uploading result files to s3 .
the script also keeps track of the progress and status of the application 's execution and collects and records runtime metrics , such as processing time , transfer time , and file sizes .
in addition , rnaseq.sh handles some common and foreseeable errors to make the workflow more robust . for instance , it is not uncommon for a data transfer from s3 to ec2 to fail due to network congestion .
our script handles this failure by waiting a few minutes and attempting to download the data again instead of failing and terminating the instance . when the analysis is finished , this ec2 instance is terminated immediately to release all the requested resources .
so far , we have explained all the details on how to analyse a single sample in the cloud , including the hardware , software , and the analysis workflow .
now , it is time to discuss utilizing multiple ec2 instances to process many data files in parallel .
stormbow includes stormbow.pl , a perl script that can be run from any linux computer with an internet connection to start ec2 instances in the cloud .
stormbow.pl takes a manifest file ( to be discussed below ) as input , prepares a piece of user - data for each sample listed in the manifest file , and writes this user - data to local files .
the user - data files are shell scripts containing instructions for the ec2 nodes on how to process each specific sample . as a consequence , all ec2 instances process different samples in parallel , which significantly reduces the clock time of rna - seq data analysis .
amazon offers virtually unlimited cpu resources , and thus provides a computational environment that is ideally suited to large - scale rna - seq data analyses . as a result , stormbow can easily scale up or down with the number of rna samples , and the total running time remains almost constant no matter how large an rna - seq study is .
the default file names might be too generic or even exactly the same . if we simply upload them to s3 , we risk name conflicts and the overwriting of result files .
for an rna - seq study with several hundred subjects , there will be several thousand result files generated when using osa to analyse them .
all these files need to be named consistently and managed properly . in order to centralize and manage different types of results files in s3 in an automated fashion , a manifest file and naming convention
the manifest file is a plain text file to describe the subjects in an rna - seq project .
each subject has a corresponding entry in the manifest file , and each entry follows the convention below :  j1 s3://bt / j1_1.fq;s3://bt / j1_2.fq s3://bt / out  j2 s3://bt / j2_1.fq;s3://bt / j2_2.fq s3://bt / out j1 s3://bt / j1_1.fq;s3://bt / j1_2.fq s3://bt / out j2 s3://bt / j2_1.fq;s3://bt / j2_2.fq s3://bt / out each entry consists of three fields separated by spaces or tabs : ( 1 ) a unique identifier ; ( 2 ) raw sequence data in s3 ; and ( 3 ) an output location in s3 .
the naming convention , together with the unique identifier for each subject , controls how all the intermediate and result files are named , where these files are stored , and how they are logically organized in s3 .
for instance , the gene count table for sample j1 has a file name j1.gene.count.txt , while its transcript count table is accordingly named as j1.transcript.count.txt . the manifest file and naming convention work together to guarantee all files
are named and stored consistently and to avoid overwriting any file associated with another subject .   a perl script , merge.pl , was written to automate the merging of results .
the script first fetches the result files corresponding to each subject from s3 using the s3cmd command line tool .
it then calls merge.r , an r script to perform the joining , and then puts the merged results back in s3 .
in addition to the generation of a combined gene and transcript count table , the alignment and mapping summary statistics for each sample are also merged .
the gene count table can be directly fed as input to differential expression analysis packages such as deseq or edger .
we applied stormbow to analyse those 178 rna - seq subjects listed in supplementary table s1 which is available online at http://dx.doi.org/10.1155/2013/481545 .
we first made copies of the dataset for the original subjects onto an encrypted 2  tb hard drive and shipped it to amazon via fedex .
after the sequence data was available in s3 , we created a manifest file , in which each sample was given a unique identifier , locations of inputs , and an output folder in s3 .
then , we ran the stormbow.pl script to launch 178  m1.xlarge instances in the cloud .
it took an average of 7 hours to process a sample , including sequence download , analysis , and upload of result files .
after the analysis of 178 samples was completed , we merged the results and shipped an empty hard drive to amazon for encrypted data export , which took another 5 days including hard drive shipment time to and from amazon .
lastly , the large amount of data in s3 was deleted to eliminate continuing charges for data storage . in total
, the rna - seq analysis of 178 samples using stormbow in the cloud was done in less than 10 days , and the total cost was less than $ 1,000 , including amazon import and export charges .
amazon charges $ 0.50 per hour for m1.xlarge instances , which made the average ec2 cost of processing a single sample $ 3.50 .
for the amazon import service , the total cost was ~$150 for a single 2  tb hard drive , including ( a ) $ 30 for fedex shipping , ( b ) a flat $ 80 charge per device , and ( c ) $ 42 for the data loading fee , which is calculated at $ 2.49 per data - loading hour .
the time required for analysis varies from sample to sample , but the majority of samples were processed within 6 to 8 hours . on average , each sample has 53 million pairs of reads , and the average fastq file size is 23  gb . the average download and upload times are 18 and 12 minutes , respectively . to create a gene count table from a bam alignment
file it takes an average of 24 minutes , and the same time is needed to create a count table at transcript level .
the mapping of more than 100  m reads to a reference genome is the most time consuming step and takes an average of 321 minutes to accomplish .
the relationship between the alignment time and the fastq file size is shown in figure 2 .
there is no discernibly linear relationship between the computational time and the number of sequences .
each sample is analyzed in identical environments , including cpu , software , and parameters for alignment , but the running times seem to vary significantly for samples with comparable numbers of reads . after discussing our results with osa developers and rerunning the analysis for sample j1 four times in the cloud
first , the time to map a single sequence read to a reference genome varies significantly .
also , samples with more unmapped reads and multiple mapped reads will require additional alignment time .
if we repeat the analysis in a local environment , the running times are nearly identical . however , when we analysed sample j1 in the cloud 4 times using the same computational environment , the running times were 5  h:20  m , 5  h:06  m , 5  h:19  m , and 5  h:44  m. when alignment begins , all the sequence reads and reference genomes are in local instance storage drives , so we can not attribute the difference to network fluctuations .
therefore , we can assume that the ec2 instances themselves give rise to the observed time difference .
an ec2 instance is a virtual machine , and many ec2 instances can run on a single piece of hardware .
depending on the neighbouring ec2 virtual machines , each ec2 instance may get slightly varying amounts of perceived cpu , memory , and i / o bandwidth . as a consequence ,
the analysis time does vary . despite the running time difference , the result files are identical for all separate runs of the same sample .  
when we implemented stormbow , we chose amazon 's cloud as the execution environment over local clusters for two reasons : ( 1 ) amazon offers virtually unlimited storage and cpu resources for easy and fast scaling to handle large rna - seq studies ; the option to set up a local high - performance cluster to keep pace with the computational and storage challenges for ngs data analysis was not a feasible option for us ; and ( 2 ) amazon provides on - demand access to a wide range of cloud infrastructure services , charging you only for the resources you actually request . this  pay - as - you - go 
model works better for our research because we do not need dedicated resources for rna - seq data analysis year - around . with its massive economies of scale
furthermore , cloud computing offers operational advantages , such as setting up infrastructure in minutes rather than months , and completing massive computational tasks with a large number of resources quickly .  
we chose s3 to centralize data storage , including inputs , intermediate results , and outputs from every computational step in stormbow .
s3 provides virtually unlimited storage space for cloud computing and stores multiple copies of its data , which guarantee the safety of data in amazon 's cloud .
all objects in s3 have unique identifiers and can be fetched in parallel without input / output ( i / o ) congestion .
this parallelism is critical when multiple ec2 instances are uploading or downloading large amounts of data simultaneously to and from s3 .   to apply rna - seq to differential expression analysis
, we need first to quantify the gene expression level in each sample , and then run statistical tests to identify de genes .
the quantification task typically involves ( 1 ) the mapping of large number of reads to a reference genome or transcriptome , and ( 2 ) the estimation of gene and isoform abundances based on the read mappings .
in addition to osa , there are other algorithms available to map reads in rna - seq studies , such as tophat .
the reasons we chose osa are as follows : firstly , osa is several times faster than tophat with better sensitivity and less false positives ; secondly , osa takes a parameter file to control how the reads are mapped to a reference genome or transcriptome , which is more versatile to pass to an ec2 node in the cloud than using a command line parameter ; thirdly , the vendor of osa has provided and maintained prebuilt genome and gene models for many common organisms , which removes the time and complexity of developing these by ourselves ; finally , osa not only is an alignment tool , but also has a built - in subcommand for expression quantification .
of course , tophat remains a tool widely used in the rna - seq community .
in fact , we use it for the discovery of novel genes and isoform or the detection of gene fusion . however , for differential studies in which we investigate the effects of compound treatment and/or gene knockdown , our main interest is to identify those known genes that are differentially expressed , not to discover novel genes or transcripts . in this scenario ,
osa fits our needs better .   to generate a gene count table from mapped reads
the first major complication in quantification is the fact that rna - seq reads do not always map uniquely to a single gene or isoform .
the transcripts from which rna - seq reads are derived are not always uniquely determined .
paralogous gene families , low - complexity sequence , and high sequence similarity between alternatively spliced isoforms of the same gene are primary factors contributing to mapping uncertainty .
in addition , polymorphisms , reference sequence errors , and sequencing errors require mismatches and indels to be allowed in read alignments and further contribute to lower confidence in mappings . as a consequence ,
a significant number of reads are multireads : reads that have high - scoring alignments to multiple positions in a reference genome or transcript set .
if a read is mapped to such regions , to which gene this read should be counted is ambiguous .
osa implements an algorithm similar to rsem   to deal with gene overlapping and multireads .
osa estimates maximum likelihood ( ml ) expression levels using an expectation maximization ( em ) algorithm and gives more accurate gene expression estimates than those using only unique reads or other alterative rescue strategies .
both rainbow   and stormbow are cloud - based tools we have developed for large - scale sequence data analysis , but they have different goals .
rainbow is developed for whole genome sequence data analysis , where typically there are more than 1 billion reads per sample . with rainbow , instead of launching a single ec2 instance to map billions of reads , a compute cluster is launched in the cloud to process the data in parallel with the output being all the single nucleotide polymorphisms ( snp ) for a sample .
in contrast , stormbow is designed for much smaller rna - seq data analysis , and its output is a gene count table to represent the expression levels of all genes in a gene model .
myrna [ 25 , 43 ] is another cloud computing tool for calculating differential gene expressions in large rna - seq datasets .
myrna was developed more than 3 years ago , and it uses a modified bowtie   for short read alignment
. the bowtie version in myrna does not handle insertion and deletion when mapping reads to a reference genome .
thus , myrna 's biggest drawback is that it does not attempt to align reads across junctions , assemble isoforms , or otherwise analyse on the isoform or junction level .
unfortunately , many sequence reads from rna - seq indeed span two or more exons . although stormbow and myrna are both designed to process large rna - seq datasets , the parallelism is achieved by different strategies .
stormbow launches multiple individual ec2 instances to process rna - seq samples in parallel , while myrna launches a large compute cluster to sequentially process rna - seq data sample by sample , and parallelize data analysis within each rna - seq run .
of course , mapping millions of reads can be easily accomplished in parallel , but not all steps in data analysis can be easily parallelized .
compared to myrna , stormbow achieves a higher parallelism than that achieved by myrna and virtually can scale up to a large rna - seq study of any size .
rna - seq is a powerful technology that is predicted to replace microarrays for transcriptome profiling .
the amount of data coming out of an rna - seq experiment can be staggering , orders of magnitude more than microarrays .
for instance , a typical raw cel data file generated from affymetrix ht hg - u133 + pm array is 5  mb per sample , whereas rna - seq data is about 23  gb in our study . the raw data alone increases 4,600-fold .
leveraging recent advances in sequencing technology , rna - seq experiments produce larger amounts of sequence data at lower costs , and quite often by small to midsize research groups that have no access to local high - performance computing environment .
the cloud - based stormbow processes the large volume of rna - seq data quickly at an affordable price as our in - house test run has demonstrated .  
stormbow is fully scalable and developed for large - scale rna - seq differential studies .
it is written using perl , shell , and r scripts , and it is simple to be deployed and used by third parties .
it can be used out of the box to process illumina rna - seq datasets .
the manifest file is the only file that a user needs to prepare in order to run stormbow .
in essence , stormbow is a wrapper of osa , but it hides the complexity of directly using osa for rna - seq data analysis in the cloud .
more importantly , the performance of stormbow has been tested by practically applying it to analyze 178 rna - seq samples simultaneously .  
to analyse large volumes of data in amazon 's cloud is different from in a local environment . quite often , large datasets are stored in s3 .
they have to be downloaded from s3 to ec2 instances first , which is not trivial .
physically , the data transfer is done through amazon 's internal network , which is not always reliable .
we encountered this situation a few times during the development of stormbow and in our test run .
as shown in figure 3 , the download time was an average of 18.4 minutes per sample ; however , it had taken as long as 79 minutes to download sample j3 in our test run of stormbow .
we repeated the analysis for j3 , and the download time was about 18 minutes .
, the s3cmd command line tool is used to fetch sequence data from s3 to an ec2 instance . when the network connection is lost during an upload or download
when you move data around in the cloud , it is always advised to check and make sure the data transfer is successful regardless of the data size .
amazon offers a variety of ec2 instances for you to choose with different pricing models .
you need to understand how your algorithm works and benchmark to choose the best option . in stormbow
, the m1.xlarge instance was chosen to run osa due to reasons stated previously . when we tested on an instance type with more cpu cores , the running time was not strikingly different .
the reasons behind this are as follows : first , more threads cause i / o congestion since all threads write the results into the same hard drive ; second , more threads increase the parallelism only for the first step in osa , but not the second step . for our application ,
for those developers who want to wrap other standalone applications and launch multiple ec2 instances to run them in parallel , they might be facing some common challenges , including the following : ( 1 ) transferring large amounts of data ; ( 2 ) launching many ec2 instances automatically ; ( 3 ) instructing instances to perform specific computations ; and ( 4 ) managing the large number of result files in s3 . in stormbow
, we wrote a driver script to automate the launch of ec2 instances , and made use of the cloud - init mechanism to pass instructions to new ec2 instances .
the manifest file and naming convention standardize how the intermediate and result files are named and logically organized in s3 .
all these ideas and practices have proven to work well in stormbow , and can be helpful for developing other cloud - based bioinformatics tools .
in this paper , we described the motivation for the development of stormbow , its implementation , and evaluation .
stormbow is a cloud - based software package that wraps osa for parallel execution in the cloud .
it is designed for large - scale rna - seq studies in which several hundred or even thousand samples are sequenced for differential analysis .
it is cost effective and simple to use as we have demonstrated in our test run .
stormbow is open - source based and implemented using perl , shell , and r scripts .
osa is free to academic users , but for commercial users , you need to contact omicsoft inc . since all computations are performed in the amazon cloud , a user will need to pay amazon to be able to run analyses .
 rna - seq is becoming a promising replacement to microarrays in transcriptome profiling and differential gene expression study . 
 technical improvements have decreased sequencing costs and , as a result , the size and number of rna - seq datasets have increased rapidly . 
 however , the increasing volume of data from large - scale rna - seq studies poses a practical challenge for data analysis in a local environment . to meet this challenge 
 , we developed stormbow , a cloud - based software package , to process large volumes of rna - seq data in parallel . 
 the performance of stormbow has been tested by practically applying it to analyse 178 rna - seq samples in the cloud . in our test 
 , it took 6 to 8 hours to process an rna - seq sample with 100 million reads , and the average cost was $ 3.50 per sample . utilizing amazon web services as the infrastructure for stormbow allows us to easily scale up to handle large datasets with on - demand computational resources . 
 stormbow is a scalable , cost effective , and open - source based tool for large - scale rna - seq data analysis . 
 stormbow can be freely downloaded and can be used out of box to process illumina rna - seq datasets . 
1. Introduction
2. Materials and Methods
3. Results and Discussions
4. Conclusions