5 criteria of a true cloud laboratory

All scientists wish they could focus on designing experiments that answer their most burning questions about nature. Unfortunately, many spend most of their time simply ensuring their lab operates smoothly. To overcome this conundrum, engineers and computer scientists are seeking ways to allow these researchers to focus on the science and not all the logistics involved in experimenting.

Enter the cloud lab. A cloud lab is a semi-autonomous laboratory in which experiments run remotely – exactly as designed by a scientist, but without the need for constant attention from researchers. With an annual subscription that often costs less than a single laboratory instrument, scientists can ship in samples and then design, execute, analyze, interpret, visualize and report experiments using more than 200 unique pieces of instrumentation — without ever having to set foot in the lab. With a cloud lab, research companies and institutions do not have to purchase and maintain equipment, set up and break down instruments, or hire many highly skilled technicians.

Not all cloud labs are built the same, however, and most do not meet the standard of a true cloud lab. Using the IT industry as a model, five criteria have emerged that define a true cloud lab and support the transition from physical infrastructure to complete cloud lab capabilities.

Those five criteria are:

1. Remote, on-demand experimentation.
2. On-demand control of every experiment.
3. Comprehensive instrumentation.
4. Comprehensive sample preparation.
5. A single software interface for the entire lab.

This article will take a closer look at the first two criteria for what constitutes a true cloud lab.

Remote, on-demand experimentation

A cloud lab must allow scientists and researchers to remotely conduct experiments on-demand, 24/7/365, via a computer interface without requiring the customer to physically visit the lab or communicate additional instructions outside of the computer interface.

A distinguishing feature of a cloud lab, compared to a CRO or CDMO, is the ability to remotely access and run laboratory equipment, entirely from a software interface, without the follow-up person-to-person emails and conference calls typical of conventional method transfers and collaborations. The method inputted via the software interface must be sufficient to remotely execute the experiment. Otherwise, the additional communication overhead to complete the method outside of the software would reduce the cloud lab experience to a conventional CRO without any added benefits.

Why so? Let’s consider the counterfactual scenario in cloud computing. Netflix is hosted on AWS’s cloud. Now imagine if, when you select a movie on Netflix, you turn subtitles on, but you don’t specify the language since you know you only speak English. Later, however, you see that all of the subtitles are in French. Fixing the issue would necessitate an email to AWS to clarify that you would like English subtitles. Then imagine having to wait 24 hours for an AWS technician to reply to your email and process your request, after which you may still have the movie with French subtitles, which would require a call to AWS to attempt to resolve the issue.

Such a remote service would be less than ideal because the introduction of personal communication creates both a point of friction and failure – even if most of the work is computerized and automated. Likewise, a cloud lab reliant on person-to-person communication about a method would be similarly compromised and thus must be avoided.

In the ECL, we use a type of AI called an expert system within the user interface. This system enables customers to completely define their experiments without being inundated with every option an instrument allows while still allowing them to go down to that level of detail as required. In practice, this works a lot like a conversation with a highly skilled lab technician, adapting to the changes in method options with reasonable default values and flagging issues that block the method from being run as stated.

On-demand control of every experiment

A cloud lab must allow customers to fully specify any and all aspects of experiments conducted remotely, providing the same flexibility they would have standing in front of the instrument itself, without any lead time or the involvement of software or automation engineers to reconfigure programs or hardware.

Since software-mediated remote-only access is a prerequisite for a cloud lab, it follows that such access must allow the user to fully express their methods in the software interface. To satisfy this, users must have full control over all of the options and features of an instrument or technique. Without full control, a cloud lab cannot be fully remote, and if it is not fully remote, it is effectively no different than a conventional CRO.

Furthermore, this control must also be readily available so as not to impede the customer’s experimentation with the need to bring in software or hardware engineers to redevelop code or reconfigure instrumentation. Adding in engineers would create a point of communication friction and failure, as described in the first criteria. There is a useful parallel to cloud computing, where customers of all sizes are free to write programs for their own specific needs and run them in the same cloud without further customization to the platform, be it Unilever, Zoom, Netflix, Goldman Sachs, Airbnb, Boeing or a million other companies. To realize its full potential, a cloud lab should be flexible enough to support a similarly diverse set of research missions.

Together, these two points enable cloud lab users to freely iterate on an experimental protocol or take an entirely new approach without needing to reprogram software or make physical modifications to equipment. Iteration is a core component of any lab activity. Designing a method from scratch, troubleshooting a method result, optimizing method performance, and running a method at scale all require iteration. To properly take advantage of this freedom, the cycle time (design, execute and receive data) for any experiment must be fast enough to match in-person activities in a traditional lab. If the cycle time in a cloud lab is a week, compared to a day in a traditional lab, then it would not be comparable for day-to-day lab activities.

It is crucial to remember that not all research needs require this functionality. When a technique is well defined and predictable in both performance and need, it makes more sense to stand up a dedicated service than it does to deploy a cloud lab. Genetic sequencing is an excellent example of this practice, where experiments follow a well-defined protocol, allowing for specialized services to operate efficiently, improving customer turnaround and pricing. When you are engaging in open-ended research, however, this flexibility is a requirement.

Conclusion

Remote on-demand experimentation and on-demand control of every experiment are critical components of what makes a cloud lab so effective for letting scientists run their open-ended research without needing to physically be in the lab. In addition, by offering complete control over experiments without the logistics, a true cloud lab frees scientists to explore avenues of research that were previously inaccessible due to limitations in budgets, time, or capacity.

Today, many companies are building tools that increase efficiency and speed by reducing the demand placed on scientists. When business leaders and scientists are looking at these tools and evaluating them for use in their organizations, it is crucial to understand which tools are appropriate based on the particular need. In the case of open-ended research, true cloud labs demonstrate their ability to make the biggest impact on the lives of scientists and the speed of research.

In the second part of this series, we will take a closer look at the three remaining criteria that truly define what a cloud lab is: comprehensive instrumentation, comprehensive sample preparation, and a single software interface for the entire lab.

Toby Blackburn is the head of business development at Emerald Cloud Lab.