引言
本内容取自2022年3月15日我们与客户的一次线上讨论。在这次会议上，李雪良博士分享了他对生物反应器“云”服务这种商业模式的理解，并结合该商业模式对软、硬件的需求，介绍了迪必尔CloudReady解决方案的设计思想和创新特性，包括高度可扩展的软、硬件架构，丰富的远程监控功能，内置项目和用户管理，工作流程自动化，标准的数据库接口以及数据的可追溯性。 迪必尔CloudReady解决方案中，CloudReady如果直接翻译是“云就位”的意思。我们认为比较合适的翻译是云服务综合解决方案，也是我们对其定位。云反应器究竟有没有内涵？给大家分享一下我们的见解。
     
它其实是一种商业模式，核心的特点是最终用户不拥有硬件，通过完成租赁的形式获得硬件的使用价值。云服务的提供商拥有硬件并且对硬件进行维护。云的本质，硬件本身并不是云的核心。如果去看国内的阿里云，使用的硬件用户也可以买来放在家里，或者在公司里用，本身并没有本质的区别。但是“云”肯定是需要对外提供使用的，其数量肯定是庞大的、肯定是可扩展的。其核心是量的问题，不是质的问题。

为了支撑这种商业模式，其实软件技术是首要的。因为要对外提供服务，要去管理大量的硬件、管理你客户信息（包括收费、包括任务分配），这些也是云服务，从技术上首先要解决的问题。需要些东西才能为云服务的商业模式服务，具体到生物反应器上，业内之前已经有类似的服务，比如说一些平台的租赁，还有现在非常非常火爆的CRO、CDMO、CXO。
   
那他们和云反应器服务有没有区别？我们总结了一下，从硬件的所有者来说，最终用户不拥有硬件是核心的差异。这点来说平台租赁还有CXO都是service provider（服务提供商）；硬件维护上，CXO还有云服务都是服务提供商来提供，平台租赁会简单地维护用户，但主要还是服务提供商来做，试剂的提供如果是CXO的话就全部都是服务提供商来提供了，如果是平台租赁主要也是服务提供商和客户各提供一部分。

对云服务来说，是不一样的，因为它会涉及到专有的部分，如培养基的配方，客户并不想透露给服务提供商，这些试剂或许会提前配置好寄给服务提供商，比如氯化钠、水、或者是分离提取的一些常用的溶剂服务提供商可以准备。还有菌种、细胞、质粒这些东西，如果是平台租赁的话只出租硬件，这些东西都是客户自己带过去的。如果是CXO、CRO服务提供商有些会负责一部分菌种或细胞增强，甚至设计方面也提供一部分，但主要还是客户来提供。对于反应器云服务来说100%是客户提供，上面这些问题并不决定着云服务的核心，真正有差别的地方是实验设计、数据分析、结果评估、实验迭代。这一部分可能主要是CRO来完成，因为research本身分工了，实验设计、数据分析、结果评估这些属research的一部分，将由CRO来做。
但是云服务，实验设计、数据分析，还有结果评估，是客户自己做的，而不是CRO帮他做，这是云服务和CRO的本质区别在。云服务只提供硬件服务，不替你做研究。当然里面还涉及到实验操作，那么实验操作CXO不用说，肯定是他们自己来帮客户来做；云服务也是服务提供商来做，但是，他不做实验设计和结果分析。实验设计和结果分析的客户，是不需要到现场的，可以远程来进行实验设计和结果分析。如果把实验操作拿掉，客户完全是可以远程做的。  
我框起来的一部分是反应器云服务和CXO它的区别点，它们之间是不同的，云服务是有自己的内涵，而不是为了市场营销而创造的东西。

那么回到CloudReady产品来说，我们针对这些特点，对我们系统进行了从头开发，当然硬件很大程度上是基于之前已有的成熟的minibox开发的。
     
1）丰富的远程监控功能 & 标准的数据库接口 & 内置项目管理和用户管理

整个构架我们重新进行了设计，比如说客户的结果、实验设计、数据分析，是可以远程来做的。远程来做就必然要求我们有丰富的远程监控功能，这我们可以通过PC或者是移动端随时查看过程的数据，还有运行的实时视频。如果没有这些过程就很难实现了，当然技术本身并不复杂，IT产业有成熟的技术我们可以拿来用。

标准的数据接口：我们如果看现在其他的产品，国内其他产品他们一般是专有的数据库还有加密，压缩等保护，不能很轻易调取数据进行分析。这样的话，给到第三方给客户进行数据分析和进行结果评估，用到的工具和用到的软件，可能无法进行对接。迪必尔可以实现客户直接访问我们的数据库，用自己已经熟悉的软件，或者已有的workflow automation或者pipeline直接对接，按照自己的习惯去进行分析，再重新设计，再迭代实验，这同时也是云服务解决方案所必须要考虑的问题。

我们的软件系统需要内置项目管理和用户管理，因为我们是要给别人提供服务的，并知道谁是在做哪个实验，在做哪个项目，要用哪个反应器。
 
2）高度可扩展性  & 工作流程自动化 & 数据可追溯性
 
我们还需要在硬件和软件构架上实现可扩展。假设一开始有80套或者是100套反应器，后面要扩展到200套或者是500套，我们的软件还有硬件都是可以支持扩展的。这一点更类似于我们现有的IT行业的云服务。可以选择增加他的容量，高度可扩展的同时满足更多客户的需求。

工作流程的自动化：客户自己如果要操作200套反应器，如果没有这些工作流程自动化的工具，就必须全部靠人去做，成本太高，出错的概率也会很高。是不太作为可持续的商业模式的。自动化最好是用脚本的形式，可以远程编脚本，然后下载到我的反应器上去运行，这也是云服务必须提供的工具。

数据可追溯性也是很重要的，对客户来说，可以看到所有的操作。当看结果的时候，可以回去看整个操作过程中的视频录像，例如追溯当时在操作取样步骤做了哪些改变。
 
CloudReady 生物反应器系统架构是什么呢？有哪些特性呢?
下期我们将继续整理成文字发布。