What does this mean for bioinformatics? Quite a lot, probably. One of the biggest headaches of any major bioinformatics task is orchestrating a workflow (or pipeline) to carry out batches of data analysis in a reproducible and consistent manner. For instance, you might have a LIMS (laboratory information management system) to manage the flow of samples through your lab from test tube to sequencing machine, but you'd also need a workflow to process the output of the sequencing machine into usable information. SWF is designed in such a way that it could easily take on the job of both LIMS and workflow as it allows for human interaction as well as fully automated processes.

Existing workflow tools such as eHive, Taverna, Knime, Pipeline Pilot, Galaxy, etc., were all initially designed long before the days of the cloud when everyone either analysed data on standalone machines (because pre-NGS most data was relatively small) or had a large in-house compute cluster with suitable job management software installed (e.g. SGE, LSF, Condor, etc.) for the workflow software to interact with. Upon the advent of the cloud, all these systems (and their competitors) sprouted cloud-compatible versions but the nature of their compatibility is tenuous at best in most cases (eHive being one good exception to the rule) – many just wrapped up existing tools and packaged them as cloud images with exactly the same limitations and restrictions as the originals.

Amazon's SWF is the first workflow management system to be designed specifically for the cloud by the very people who built the most popular cloud in the first place, know exactly how it works, and how to take best advantage of it to manage this type of task.

Like most other Amazon APIs it is HTTP-based, but has extended client APIs available in Java, .NET, PHP and Ruby, plus a richly-featured development SDK in Java for those wishing to get their hands really dirty. Whilst the workflow itself is managed from Amazon's servers, clients can run on the cloud or on local hardware, mobile phones, or can be human beings interacting with a web interface. Importantly for life science companies dealing with commercially confidential or sensitive data, this means that companies can use SWF to co-ordinate their workflows without needing to upload their private data into the cloud, putting SWF into direct competition with all existing workflow technology from other vendors (Taverna, Galaxy, etc.).

For bioinformatics specifically there is much to be excited about. A true cloud-compatible workflow environment means that more efficient use can be made of the cloud than ever before, which should help speed up the more complex analyses that biologists need on a regular basis. Access costs are very low (in the order of a tiny fraction of cents per workflow execution) which will help encourage experimentation and exploration of this new technology for scientific use. The lack of a Perl API may make adaptation of older scripts a little hard, as Perl is very common in bioinformatics, but it is not insurmountable – it is easy to set up an SWF-compliant script in another language that then simply calls out to an existing Perl script to carry out the tasks required.

All in all SWF looks great, and we can't wait to see the first useful bioinformatics workflow implemented on it. In fact I'm pretty sure a few of us here at Eagle have already started work…

Assuming that the technology lives up to the hype, how will bioinformatics be driven by 3G sequencing? We've already had to adapt to various high-throughput sequencing platforms spewing data with different read length/error models during the transition from Sanger to 2G (next-gen). Alongside the advances in bioinformatics algorithms and workflows, there has been a cascade of capability, with genomics core facilities now able to provide services that were previously the exclusive domain of genome institutes. Going by the "USB drive" sized prototype sequencers exhibited last week, with an expected price tag of $900, one can only assume that the cascade will continue with 3G, from core to lab, soon to reach researcher's desktop.

What will be the bioinformatics needs of "desktop sequencing"? A new breed of super-efficient GPU-exploiting desktop sequence analysis software? Or (and those familiar with this blog will be unsurprised by the suggestion) a Microsoft-esque cloud service for sequence management and analysis? The latter has a certain resonance when coupled with Oxford Nanopore's CTO (Clive Brown's) description to their technology as "sequencing on demand" (New York Times). How better to couple "sequencing on demand" than with "computing on demand".

Eagle Genomics are conducting a second survey of current issues in operational bioinformatics.

We build on the success of last year's survey which polled over 100 worldwide responses from both industry and academia. A report detailing the results of our first survey can be viewed here.  See also Genomeweb's coverage. One of the highlights was that data integration was one of the largest technology concerns for the community, and while both academic and commercial groups relied to a large extent on in-house data centers, they were considering shifting to the cloud in the future.

We are excited this year to see how the field has shifted over the past 12 months!

In appreciation of your support we will enter all participants in a draw for a $100 Amazon voucher.

This should take no longer than 5 minutes.

After the survey closes on 28th March, answers will be summarized and represented as a report freely available from Eagle Genomics' website. This report will be of great relevance to both policy makers and software developers as they plan for the coming decade.

The answers will also be discussed at our symposium: " The Next 10 Years of Genome Content Management " on 29th March.

Finding 1. Scientic applications have special requirements that require solutions that are tailored to these needs.

The claim is made that scientific applications are special because they "rely on access to large legacy data sets and pre-tuned application software libraries" which are currently addressed by HPC setups that have "low-latency interconnects and rely on parallel file systems", giving a set of "unique software and specialized hardware requirements". Science needs to stop thinking of itself as special – the kinds of data processing problems faced by science are no different to many of those faced in finance or logistics in terms of their scale, complexity, and structure of data. Whilst it is true that the DOE may be dealing with particularly complex datasets related to environmental and biological research, this does not make their situation unique.

The perceived issues faced in moving from HPC to cloud are to do with addressing paradigm changes, but are the result of trying to make simple like-for-like comparisons. The report authors suggest that cloud's inability to exactly replicate HPC architectures and performance is more of a roadblock to the use of cloud than the reluctance of scientific software developers to optimise their algorithms to cloud environments, whereas I would suggest the opposite is true.

Blended into this finding in the report is a claim about incompatibility of business models – clouds work on a pay-per-use basis whilst scientists have an "open-ended need for resources" with an implied reluctance to have to account for the resources they use. That's not an obstacle, that's just a change needed in the way that IT budgets are allocated to science, and a change that is probably well overdue at that. If scientists paid the true cost of accessing existing HPC resources by paying for it in direct proportion to their usage of it, and grant providers stopped preferring the purchase of expensive (and often partially redundant) dedicated hardware over the more efficient use of shared or external resources, then this argument would no longer stand. The report says that "the cost model for scientic users is based on account allocations", well, there is no reason that this couldn't be provided for on the cloud as well via some kind of dedicated institute accounts managed by the IT department.

Finding 2. Scientic applications with minimal communication and I/O are best suited for clouds.

"Performance of tightly coupled applications running on virtualized clouds using commodity networks can be signicantly lower than on clusters optimized for these workloads". Yes, true. But, the cloud can scale to a much larger number of nodes than most HPCs have, and definitely more nodes than most smaller research departments have access to, meaning that although each individual node is slower the total number of nodes available can help make up for this. Plus, as you only pay for the nodes whilst they are being used, they can be cheaper than keeping a set of fixed nodes up and running waiting for work to appear. So although the report is technically correct in pointing out that the test data ran "7x slower at 1024 cores on Amazon Cluster Compute instances" than it did on the DOE's HPC centres, that is not necessarily telling the whole story. The comment above about reluctance to optimise algorithms specifically for the cloud could equally well apply here.

Finding 3. Clouds require signicant programming and system administration support.

It seems as though the authors are comparing direct access to cloud resources against sys-admin mediated access to HPC resources. It is odd to suggest that a move from HPC to cloud would result in requiring scientists to do all the technical work themselves. HPCs already take huge amounts of programming and sys-admin support to operate and so a move to cloud would simply see the HPC staff working on cloud resources instead of in-house resources. Scientists would not see any difference if the move were managed properly. This finding is nonsense!

Finding 4. Signicant gaps and challenges exist in current open-source virtualized cloud software stacks for production science use.

This finding is true, but it applies only to deployment of private in-house clouds, i.e. installing cloud software into existing data centres. It does not apply to public cloud services although it omits to mention this.

Finding 5. Clouds expose a different risk model requiring different security practices and policies.

True. But… only if you permit users to create their own images. If you are offering managed services on a private cloud that use cloud technology behind the scenes to coordinate work whilst still presenting traditional HPC-style interfaces to the end users thus restricting their ability to run arbitrary code, then the issues in this finding are greatly reduced in severity.

Finding 6. MapReduce shows promise in addressing scientic needs, but current implementations have gaps and challenges.

Absolutely. The issue here is that science relies a lot on scripted/interpreted languages such as Perl, Python, and Ruby, whilst cloud models (being from enterprise computing backgrounds) use more complex (semi-)compiled languages for increased efficiency, such as Java or C++. Unfortunately, ne'er the twain shall meet. Scientists and scientific software developers who wish to make use of advanced technologies such as MapReduce will have to learn the relevant programming languages, and staff at IT and HPC centres providing cloud-related services to scientists will have to develop and deliver the appropriate training courses.

Still it is true that current implementations of MapReduce do not support the complex and interlinked/referential/hierarchical dataset structures that are common in science. This is one area that the technology needs to improve in before it can fully realise its potential.

My earlier point comes back yet again – that scientific software developers need to optimise their code for the cloud, rather than simply port existing paradigms and claim it is the cloud's fault when they do not perform so well. This is easier said than done, as scientists like to use tools that are well-referenced and well-established. Given the choice of old-fashioned-but-functional cloud-ignorant Tool A which is the industry standard, versus brand-new cloud-optimised Tool B which has been shown to produce the same results but is too new to be widely cited in journals, Tool A will win every time (and anyone using Tool B and mentioning it in their subsequent journal paper will almost certainly get pulled up on this fact by the reviewers who will have very strong opinions of their own about which tool is most appropriate based on citations in prior publications, thus perpetuating the reign of Tool A even though Tool B may be more advanced).

Finding 7. Public clouds can be more expensive than in-house large systems.

Yes, but usually only if you attempt to replicate in-house systems like-for-like, i.e. you set up a large number of machines that are running constantly regardless of workload. It is widely accepted that cloud costs for a machine that is running 24x7x365 are similar if not greater than the equivalent total cost of ownership (TCO) for the equivalent machine in an in-house data centre, but the point of the cloud is that you shouldn't need to have machines up and running permanently in anticipation of workload – rather you should create them just-in-time when work peaks, and tear them down again as soon as they fall idle. As you pay only for the time the machine is up-and-running then this management technique will soon reduce the costs below the level of provisioning and maintaining equivalent in-house hardware. The report does not appear to address this possibility at all.

Interestingly, it is in this finding that the second sign of the authors trying to justify the existence of their own HPC centres comes into light (the first being the earlier complaint about clouds requiring extra programming and sys-admin knowledge amongst scientists), suggesting that the report overall may be biased towards the interests of the authors. They state that the costs they use for comparing cloud with HPC "do not take into consideration the additional services such as user support and training that are provided at supercomputing centers today" which are "essential for scientic users who deal with complex software stacks and dependencies and require help with optimizing their codes to achieve high performance and scalability". A move from cloud to HPC does not necessarily mean that all that support goes away – it is highly likely that staff who used to run the HPC would now manage access to the cloud resources instead, providing all the same additional services to scientists as they did before. Does this paragraph of the report imply that the DOE is seriously considering moving its HPC function to the cloud and that the HPC centres who authored this report are trying to prevent it from happening? Who knows.

Finding 8. DOE supercomputing centers already approach energy eciency levels achieved in commercial cloud centers.

Great. That might be the case for the huge HPC resources at the DOE, in which case congratulations as that's quite an achievement, but for the rest of us this point is highly unlikely to be true of our own data centres. For those IT managers needing to comply with green agendas, the cloud is almost always going to be more energy-efficient than in-house operations.

Finding 9. Cloud is a business model and can be applied at DOE supercomputing centers.

This is an interesting finding and is very true – the cloud is indeed a business model as well as a technical innovation. The whole way in which people interact with resources changes under the cloud, with instant access to dedicated virtual resources on demand rather than queued access to shared and traffic-managed HPC resources.

The finding says that "Rapid elasticity and on-demand self-service environments essentially require different resource allocation and scheduling policies that could also be provided through current HPC centers, albeit with an impact on resource utilization". This is about private cloud vs. public cloud, about the fact that even if converted to private cloud technology, HPC centres will still face resource utilization issues due to the limited size of their compute capacity vs. the number of people needing to make use of it. Public clouds are generally larger than most in-house data centres, able to grow faster through commercial investment processes, are quicker to respond to and manage demand, are more able to fairly share demand over a greater number of diverse users and requirements, and are more highly utilized. All these reasons are why private cloud will only be useful as a halfway-house until systems can be established that make use of the public cloud.

Overall the report makes some good points, when read with a pinch of salt regarding its limitations of research (DOE requirements only) and of authorship (the authors' interests are linked with preserving the role of existing HPC centres). For an organisation of a similar size to the DOE who has made similar investments in HPC, it is a very relevant and salient report. For smaller organisations and those who do not have their own HPC resources already, remember that one size does not fit all.

Richard Holland

The title is: Exploiting whole genome sequencing for public health microbiology

Presented by: Jonathan Green, Head of Bioinformatics, Health Protection Agency

   "Next Generation Sequencing (NGS) represents a revolution in DNA sequencing technologies, making routine rapid analysis of the complete DNA sequence of viral and bacterial genomes a reality.  It is already the case that microbiological investigations of any significant outbreak of infectious disease include whole genome sequencing (WGS) of a putative causative agent. for example  pandemic influenza strains, MRSA and Acinetobacter baumannii.

The potential impact of these technologies on Organisations such as the HPA is far-reaching.  The bioinformatics challenges of NGS and other 'omic technologies, in terms of IT infrastructure for the storage and management of the large amounts of data generated, are well-known but not resolved.  A key challenge is how to ensure it has the appropriate workforce capability for the analysis of these data in order to best use the extracted information for public health purposes. This requires meaningful integration of 'omics data with other laboratory information pipelines, clinical datasets and surveillance systems which is a significant challenge. Public health microbiology is increasingly 'data-rich' and laboratory scientists are being required to spend more of their time on data analysis using desktop bioinformatics tools or working with bioinformaticians to deliver these analyses, and this will increase as automation replaces much of the current manual approach to development of data.  This is likely to create a significant shift in the skill-mix required to deliver reference microbiology, epidemiology and surveillance.  The need to enhance microbiology and to integrate molecular typing into International as well as national surveillance context is recognised as paramount and needs to be a component of the current strategy.The presentation will aim to describe the relevance and likely impact  of these technologies on public health microbiology, to describe the challenges and the work being undertaken to provide a platform for further development."

See the titles of the other talks here.

<< Previous abstract

The Pistoia Alliance, a global, not-for-profit, pre-competitive alliance of life science companies, vendors, publishers, and academic groups, with a vision for the future of managing and sharing pre-competitive pharmaceutical genomics R&D data, has created detailed requirements under the banner of Sequence Services Phase 2. The system, with a number of add-ons for analyzing this data through the use of standard bioinformatics tools and custom workflows, must ensure that each customer using it is completely confident that their data will remain private and confidential.

Building on Cycle Computing's extensive experience in securing and scaling large-data applications in the cloud, combined with Eagle Genomic's enviable track record in delivering bioinformatics applications and workflows to 8 out of 10 top global pharmaceutical companies, the joint Eagle/Cycle project is on track to be a robust, scalable, and highly adaptable solution that meets the vast majority of current Pistoia member needs, plus many of their future ones.

David Flanders, CEO of Eagle Genomics, said "The Pistoia Alliance’s vision in recognizing the significance of disruptive technologies and associated new business models presents a superb showcase for the talents of Cycle Computing and Eagle Genomics to provide open innovation solutions to customers in the pharmaceutical sector – and beyond"

"Cycle is committed to supporting the standards that help spark innovation, unify silos and streamline data digestion,” said Jason Stowe, CEO of Cycle Computing. “We look forward to collaborating with the alliance members and with the talent of Eagle Genomics in bioinformatics and Cycle Computing in Cloud HPC workflow management, meet the challenges facing both researchers today and into the next generation.”

The proof-of-concept system for the Sequencing Analysis Platform will be delivered and demonstrated at the annual Pistoia Alliance Conference, to be held in April 2012 in Boston, MA. The award carries 25% of an overall $200K allocated by Pistoia.

Many questions have been asked about the subjectivity of the way in which the entries will be judged. Given the diversity of possible input formats and variations between platforms it is not possible to provide a test dataset that represents all of them. Indeed, many compression tricks work only if the dataset is known to be of a particular type or relate to a particular organism.

The contest judging script takes a simplistic approach of running each entry using default settings only on a fairly limited test dataset that is at least internally consistent (i.e. it all comes from the same organism and from the same sequencing platform). This provides an easy way to rank generally better entries under a number of useful categories (ratio, speed, etc.) and identify the top few in each category for further scrutiny by the human judges. The leaderboard shows the results of this automated process.

Whether the ratio or the speed is considered more important is largely subjective, and so the judging panel will consider performance in all categories as well as looking into the effectiveness of any optional flags/optimisations that may be included in the code, plus the quality and robustness of the code itself (there's no benefit in having an open-source algorithm contest if the source code of the winner is indecipherable or does things that would cause concern in a production environment). Admittedly the subjectivity of this process may cause concern, which is why the judging panel consists of leading bioinformaticians from each of the three main sequencing centres of the world – the Broad, BGI, and Sanger. As a team they stand the greatest chance of identifying what would best suit the needs of NGS data managers.

One question that comes up frequently is to do with the mismatches. Just how important is it to reproduce the input data exactly when decompressing, and can low-information data be discarded? To prevent complicating matters even further with judging this contest, it was decided that input data should be fully reconstructed at decompression (although the sequences do not have to be in the same order or even in the same files, but they should all be present). Entries are scored for the number of sequence headers or lines of bases or quality scores that do not match. A few mismatches might indicate a minor issue with the code that could be fixed with a bit of investigation – and the human judges will take this into account – but a large number of mismatches would be a definite problem.

The contest closes to new entries in just over 6 weeks on March 15th, and winners will be announced at the Pistoia Alliance Annual Conference in Boston MA (USA) on April 23rd. We eagerly await the results!

The title is: Out of the shadows – the future of bioinformatics

Presented by: Mick Watson, Director of ARK Genomics (Roslin Institute)

  "With bench scientists increasingly incapable of handling the volumes and types of sequence data, bioinformatics is now the most important aspect of genomics. It is impossible to carry out genomics research without sophisticated tools and intelligent, driven bioinformaticians. Often, bioinformaticians are best placed to design experiments and to advise on how to get the best results from genomics projects. BBSRC describe the current period of research as "The Age of Bioscience" when perhaps it should be "The Age of Bioinformatics". It is now time for bioinformatics to mature as a science, to increase the emphasis on "bio" as well as "informatics", and for bioinformaticians to lead the new wave of genomics research. Rather than a single genome per species, we must now recognise that every individual consists of a collection of genomes that are structurally variant; in addition to which, we can now measure epigenetic effects, such as methylation, at single-base accuracy. The paradigm is one individual, many genomes, many epigenomes. In addition to microbial metagenomics and the challenges faced therein, we are rapidly approaching large, eukaryotic metagenomics. All of these, combined with modern ways for communicating scientific research, combine to demand a new paradign for genomics research and an increased emphasis on the importance of bioinformatics."

See the titles of the other talks here.

<< Previous abstract      Next abstract >>

The title is: A toolbox for high throughput in-depth analysis of omics data. 

Presented by: Vitali Proutski, Head of Bioinformatics, Almac Diagnostics

  "Almac Diagnostics is a premier provider of Bioinformatics and Biostatistics consultancy services focusing on the analysis and interpretation of complex 'omics' datasets. In order to satisfy the requirements of internal and external customer projects Almac have developed an extensive and highly customisable set of tools covering the entire continuum of a typical data analysis project, from data QC to in-depth mechanistic analysis or development, evaluation and selection of optimal predictive biomarker models. The tool box, some components of which will be presented and discussed, ensures consistency and high efficiency of analysis without compromising the quality and depth of it."

See the titles of the other talks here.

<< Previous abstract       Next abstract >>

The title is: Just Enough Developed Infrastructure

Presented by: Dan MacLean, Head of Bioinformatics, Sainsbury Laboratory

  "The Sainsbury Laboratory is a small independent research lab of approximately 80 researchers, we concentrate on Plant/Pathogen interactions with a focus on the genetics and genomics of a wide and frequently shifting line-up of organisms under study. A large proportion of our projects are focussed on a relatively modest goal, for example identifying Resistance genes in a novel model, rather than producing a gold-standard annotated genome. Recently we have made the decision to abandon our own compute cluster in favour of merging with larger users ie TGAC in an 'Access is more important than ownership model'. Similarly, we have found that many existing tools for genome sequence and feature annotation management, while great in their own way, can be too large and more difficult to manage than is useful for our projects and personnel profile. I'll describe the sequencing pipelines and hardware that feed into our data store as background for the core of our management structure, our lightweight sequence and feature versioning tool Gee Fu. Gee Fu interacts with our assembly and annotation pipelines from the command-line and from our Galaxy installation. It acts simultaneously as a store and annotation editor that has appropriate interfaces for users with a wide range of computing skills and can be used to share data externally via its RESTful interface and a web based front end."

See the titles of the other talks here.

<< Previous abstract      Next abstract >>