Book:Choosing and Implementing a Cloud-based Service for Your Laboratory/Cloud computing in the laboratory/Deployment approaches

From LIMSWiki
Jump to navigationJump to search

4.3 Deployment approaches

Chapter 2 also looked at deployment approaches in detail, so this section won't get too in-depth. However, the topic of choosing the right deployment approach for your laboratory is still an important one. As Agilent Technologies noted in its 2019 white paper Cloud Adoption for Lab Informatics, a laboratory's "deployment approach is a key factor for laboratory leadership since the choice of private, public, or hybrid deployment will impact the viability of solutions in the other layers of informatics" applied by the lab.[1] In some cases, like most software, the deployment choice will be relatively straightforward, but other aspects of laboratory requirements may complicate that decision further.

Broadly speaking, any attempt to move you LIS, LIMS, or electronic laboratory notebook (ELN) to the cloud will almost certainly involve a software as a service (SaaS) approach.[1] If the deployment is relatively simple, with well-structured data, this is relatively painless. However, in cases where your LIS, LIMS, or ELN need to interface with additional business systems like an enterprise resource planning (ERP) system or other informatics software such as a picture archiving and communication system (PACS), an argument could be made that a platform as a service (PaaS) approach may be warranted, due to its greater flexibility.[1]

But laboratories don't run on software alone; analytical instruments are also involved. Those instruments are usually interfaced to the lab's software systems to better capture raw and modified instrument data directly. However, addressing how your cloud-based informatics systems handle instrument data can be challenging, requiring careful attention to cloud service and deployment models. Infrastructure as a service (IaaS) may be a useful service model to look into due to its versatility in being deployed in private, hybrid, and public cloud models.[1] As Agilent notes: "This model enables laboratories to minimize the IT footprint in the lab to only the resources needed for instrument control and acquisition. The rest of the data system components can be virtualized in the cloud and thus take advantage of the dynamic scaling and accessibility aspects of the cloud."[1] It also has easy scalability, enables remote access, and simplifies disaster recovery.[1]

Notice that Agilent still allows for the in-house IT resources necessary to handle the control of instruments and the acquisition of their data. This brings up an important point about instruments. When it comes to instruments, realistic decisions must be made concerning whether or not to take instrument data collection and management into the cloud, keep it local, or enact a hybrid workflow where instrument data is created locally but uploaded to the cloud later.[2] In 2017, the Association of Public Health Laboratories (APHL) emphasized latency issues as a real concern when it comes to instrument control computing systems, finding that most shouldn't be in the cloud. The APHL went on to add that those systems can, however, "be designed to share data in network storage systems and/or be integrated with cloud-based LIMS through various communication paths."[3]

So what should a laboratory do with instrument systems? PI Digital's general manager, Kaushal Vyas, recognized the difficulties in deciding what to do with instrument systems in September 2020, breaking the decision down into five key considerations. First, consider the potential futures for your laboratory instruments and how any developing industry trends may affect those instruments. Do you envision your instruments becoming less wired? Will mobile devices be able to interface with them? Are they integrated via a hub? And does a cloud-based solution that manages those integrations across multiple locations make sense at some future point? Second, talk to the people who actually use the instruments and understand the workflows those instruments participate in. Are analysts loading samples directly into the machine and largely getting results from the same location? Or will results need to be accessed from different locations? In the case of the latter, cloud management of instrument data may make more sense. Third, are there additional ways to digitize your workflows in the lab? Perhaps later down the road? Does enabling from-anywhere access to instruments with the help of the cloud make sense for the lab? This leads to the fourth consideration, which actually touches upon the prior three: location, location, location. Where are the instruments located and from where will results, maintenance logs, and error logs be read? If these tasks don't need to be completed in real time, it's possible some hybrid cloud solution would work for you. And finally—as has been emphasized throughout the guide—ask what regulations and security requirements drive instrument deployment and use. In highly regulated environments like pharmaceutical research and production, moving instrument data off-premises may not be an option.[2]

One additional consideration that hasn't been fully discussed yet is whether or not to go beyond a hybrid cloud—depending on one single cloud vender to integrate with on-premises systems—to a cloud approach that involves more than one cloud vendor. We examine this consideration, as well as how it related to vendor lock-in, in the following subsection.

4.3.1 Hybrid cloud, multicloud, and the vendor lock-in conundrum

Devuan GNU-Linux - tty login as root in an ownCloud instance - server rack.jpg

In Chapter 1, we compared and contrasted hybrid cloud, multicloud, and distributed cloud deployments. Remember that hybrid cloud integrates a private cloud or local IT infrastructure with a public cloud, multicloud multiplies public cloud into services from two or more vendors, and distributed cloud takes a public cloud and expands it to multiple edge locations. Hybrid and distributed deployments typically involve one public cloud vendor, and multicloud involves more than one public cloud vendor. But why would any laboratory want to spread its operations across two or more CSPs?

"Multicloud has the benefit of reducing vendor lock-in by implementing resource utilization and storage across more than one public cloud provider," we said in Chapter 1. The benefits of choosing a multicloud option over other options are a bit contentious however. Writing for the Carnegie Endowment in 2020, Maurer and Hinck address the issues of multicloud in detail[4]:

Proponents argue that this approach has benefits such as avoiding vendor lock-in, increasing resilience to outages, and taking advantage of competitive pricing. However, each of these points is contested; for instance, some might argue that ensuring a CSP’s infrastructure architecture is secure is a much better way to enhance resilience than replicating workloads across multiple CSPs ... However, using multiple cloud providers can create greater complexity for organizations in terms of managing their cloud usage and creating more potential points of vulnerability, as the Cloud Security Alliance discussed in a May 2019 report.

However, that very same complexity, found with most any cloud technology, brings with it risks related to vendor lock-in, seemingly forming a vicious circle. Carnegie Endowment's Levite and Kalwany noted in November 2020[5]:

... the complex technology behind cloud services exacerbates risks of vendor lock-in. There are two main factors to consider here: the level of interoperability (how easy it is to make different cloud services work together as well as work with on-site consumer IT systems), and portability (how easy it is to switch data and applications from one cloud service to another, as well as from on-site systems to the cloud and back). Standards enabling both interoperability and portability of cloud services are likely to emerge as [among other things] a means of avoiding vendor lock-in.

To be sure, interoperability and portability are important concepts, not only in cloud computing[5][6] but also in laboratory data management, particularly with clinical data.[7][8] The U.S.' current SHIELD initiative speaks to that, aiming "to improve the quality, interoperability and portability of laboratory data within and between institutions so that diagnostic information can be pulled from different sources or shared between institutions to help illuminate clinical management and understand health outcomes."[7] You see this same emphasis taking place in regards to cloud systems and biomedical research data sharing and the associated benefits of having interoperable, portable data using cloud systems.[9][10][11][12]

As Levite and Kalwany point out, interoperability and portability is also useful in the discussion on whether or not to use two or more CSPs. Let's again highlight their questions[5] (which will also be important to the next chapter on choosing and implementing your cloud solutions):

  • How interoperable or compatible is one public CSP's services with another public CSP's services, as well as with your on-premises IT systems?
  • How portable or transferable are your data and applications when needing to move them from one cloud service to another, as well as to and from your on-premises solutions?

These two questions, along with the vendor lock-in conundrum, are illustrated well in the ongoing saga of the Pentagon's JEDI project. The Joint Enterprise Defense Infrastructure (JEDI) project was officially kicked into gear in 2018 with a request for proposal (RFP), seeking to find a singular cloud computing provider to help usher in a new cloud-based era for Defense Department operations. The adamancy towards choosing only one CSP, despite the sheer enormity of the contract, quickly raised the eyebrows or watchdogs and major industry players even before the RFP was released. Claims of one provider having too much influence over government IT, as well an already skewed bidding process in favor of Amazon, complicated matters further.[13] Defending the stance of choosing only one CSP, the Digital Defense Service's deputy director Tim Van Name cited an "overall complexity" increase that would come from awarding the RFP to multiple CSPs, given the challenges already inherent to Defense Department data management in and out of the battlefield. Van Name also cited a "lack of standardization and interoperability" of complex cloud deployments as another barrier to accessing data when and where they need it.[14] This has inevitably led to a number of lawsuits before and after Microsoft was awarded the contract. With legal battles raging and an overarching "urgent, unmet requirement" by the Defense Department still not being realized because of the litigation, the government was rumored to be considering taking a loss on the single-vendor JEDI plan and moving forward with a multicloud plan, particularly with the departure of senior officials who originally backed the single cloud proposal.[15][16][17] The success of the CIA's C2E cloud-based program, which was awarded to five cloud providers, may have proven to be a further catalyst[13], as by July 2021, the JEDI project was finally pulled by the DoD[18] and related lawsuits by Amazon were dismissed.[19] Almost immediately afterwards, the DoD announced a new proposal, the Joint Warfighter Cloud Capability (JWCC) project, with a rough projection of being awarded to multiple vendors by April 2022.[19] The DoD limited bids to four vendors—Amazon, Google, Microsoft, and Oracle—with all four gaining a piece of the indefinite-delivery, indefinite-quantity contract by December 2022.[20][21] An April 2023 report in SIGNAL on the JWCC provided further insight on the unique approach to the contract, highlighting that despite all the stated complexity, some definitive benefits emerge from a multicloud arrangement[22]:

Officials structured the JWCC vehicle to be a one enterprise contract and set up direct relationships with the cloud service providers (CSPs)—which is unique. [Hosting and Compute Center] works with DoD customers to shape their cloud service requirements and interacts directly with the four private sector cloud companies on the contract, instead via a third-party ... 'No contract in the department has that direct relationship with the CSPs,' McArthur said. 'Having that single point to be able to go to the vendors and be able to [interact with them] when it comes to meeting capabilities, needing to drive cost parity or cybersecurity incidents, those are groundbreaking things for the department at large.'

What does all this mean for the average laboratory? At a minimum, there may be some benefit to having, for example, redundant data backup in the cloud, particularly if your lab feels that sensitive data can be safely moved to the cloud, and that there's overall cost savings long-term (vs. investing in local data storage). But that "either-or" view doesn't entirely address potential risks associated with vendor lock-in and the need for data availability and durability. As such, having data stored in multiple locations makes sense, even if that means moving data to two different cloud providers. With a bit of analysis of data access patterns and a solid understanding of your data types and sensitivities, it may be possible to make this sort of multicloud data storage more cost-effective.[23] However, remember that the traceability of your data is also important, and if quality data goes into the cloud service, then it will be easier to find, in theory. As is, it's already a challenge for many laboratories to locate original data—particularly older data—and some labs still don't have clear data storage policies.[24] As such, any transition to the cloud should also be considering the value of reinforcing existing data management strategies or, forbid they don't exist, getting started on developing such strategies. In conjunction with reviewing or creating data management strategies, data cleansing may be required to make the data more meaningful, findable, and actionable.[25][26] This concept holds true even if a multicloud deployment doesn't make sense for you but a hybrid cloud deployment with local backups does. This hybrid approach may especially make sense if the lab uses a scientific data management system (SDMS). As Agilent notes, if you already have an on-premises SDMS, "extending the data storage capacity by connecting to a cloud storage location is a logical first step. This hybrid approach can use cloud storage in both a passive/active capacity while also taking advantage of turnkey archival solutions that the cloud offers."[1]

But what about the concept of vendor lock-in overall? How much should a laboratory worry about this scenario, particularly in regards to, for example, moving from an on-premises LIMS to one hosted in the cloud? Some like tech reporter Kimberley Mok, writing for Protocol, argue that as major CSPs begin to make multicloud-friendly upgrades to their infrastructure, and as users perform more rigorous vetting of CSPs and migrate to more portable, containerized software solutions, the threat of vendor lock-in is gradually diminishing.[27] However, business owners remain fearful. A summer 2020 survey published by business communications company Mitel found that among more than 1,100 European IT decision makers, a top contractual priority with a CSP was avoiding vendor lock-in; "46 percent of respondents [said they] want the ability to change provider quickly if the service contract is not fulfilled."[28] HashiCorp's third annual State of Cloud Strategy Survey in 2023 found that 48 percent of respondents thought single-vendor lock-in was driving multicloud adoption, further highlighting an increasing concern among businesses turning to the cloud.[29]

In the end, the laboratory will have to come down to a crucial decision: do we outsource services to several specialists (i.e., disaggregation) or stick to one, risking vendor lock-in? U.K. business software developer Advanced's chief product officer Amanda Grant provides this insight[30]:

For larger enterprises, disaggregation works best. The vast operations they undertake require a level of scalability and expertise that is best delivered by specialist companies. These specialists can target specific and more complex needs as well as support mission-critical operations directly. [For mid-sized organizations,] disaggregation demands a lot of internal investment. They would need in-house expertise to manage multiple suppliers and successfully integrate the services. The alternative would be to use an open ecosystem that brings all their cloud software solutions together in one place. This enables users to consume all of their cloud applications with ease while minimizing risk of vendor lock-in.

It's possible that as cloud computing continues to evolve, interoperability and portability of data, as well as tools for better data traceability, will continue to be a priority for the industry overall, potentially through continued standardization efforts.[6] As a result, perhaps the discussions of vendor lock-in will be less commonplace, with multicloud deployments becoming common discussion. The adoption of open-source technologies as part of an organization's cloud migration may also help with interoperability with other cloud platforms in the future.[31] In the meantime, laboratory decision makers will have to weigh the sensitivity of their data, that data's cloud-readiness, the laboratory budget, the potential risks, and the potential rewards of moving its operations to more complex but productive hybrid cloud and multicloud environments. The final decisions will differ, sometimes drastically, from lab to lab, but the risk management processes and considerations from Chapter 3 should be the same: same starting point but different destinations.

That leads us to the next chapter of our guide on the managed security service provider (MSSP), an entity that provides monitoring and management of security devices and systems in the cloud, among other things. These providers make make it considerably easier, and more secure, for a laboratory to implement cloud computing in their organization.

References

  1. ↑ 1.0 1.1 1.2 1.3 1.4 1.5 1.6 Agilent Technologies (21 February 2019). "Cloud Adoption for Lab Informatics: Trends, Opportunities, Considerations, Next Steps" (PDF). Agilent Technologies. https://www.agilent.com/cs/library/whitepaper/public/whitepaper-cloud-adoption-openlab-5994-0718en-us-agilent.pdf. Retrieved 28 July 2023. 
  2. ↑ 2.0 2.1 Vyas, K. (September 2020). "Cloud vs. on-premises solutions – 5 factors to consider when planning the connectivity strategy for your healthcare instrument". Planet Innovation: Perspectives. https://planetinnovation.com/perspectives/cloud-vs-on-premises-solutions/. Retrieved 28 July 2023. 
  3. ↑ Association of Public Health Laboratories (2017). "Breaking Through the Cloud: A Laboratory Guide to Cloud Computing" (PDF). Association of Public Health Laboratories. https://www.aphl.org/aboutAPHL/publications/Documents/INFO-2017Jun-Cloud-Computing.pdf. Retrieved 28 July 2023. 
  4. ↑ Maurer, T.; Hinck, G. (31 August 2020). "Cloud Security: A Primer for Policymakers". Carnegie Endowment for International Peace. https://carnegieendowment.org/2020/08/31/cloud-security-primer-for-policymakers-pub-82597. Retrieved 28 July 2023. 
  5. ↑ 5.0 5.1 5.2 Levite, A.; Kalwani, G. (9 November 2020). "Cloud Governance Challenges: A Survey of Policy and Regulatory Issues". Carnegie Endowment for International Peace. https://carnegieendowment.org/2020/11/09/cloud-governance-challenges-survey-of-policy-and-regulatory-issues-pub-83124. Retrieved 28 July 2023. 
  6. ↑ 6.0 6.1 Ramalingam, C.; Mohan, P. (2021). "Addressing Semantics Standards for Cloud Portability and Interoperability in Multi Cloud Environment". Symmetry 13: 317. doi:10.3390/sym13020317. 
  7. ↑ 7.0 7.1 Office of the Assistant Secretary for Planning and Evaluation. "SHIELD - Standardization of Lab Data to Enhance Patient-Centered Outcomes Research and Value-Based Care". U.S. Department of Health & Human Services. https://aspe.hhs.gov/shield-standardization-lab-data-enhance-patient-centered-outcomes-research-and-value-based-care. Retrieved 28 July 2023. 
  8. ↑ Futrell, K. (22 February 2021). "COVID-19 highlights need for laboratory data sharing and interoperability". Medical Laboratory Observer. https://www.mlo-online.com/information-technology/lis/article/21210723/covid19-highlights-need-for-laboratory-data-sharing-and-interoperability. Retrieved 28 July 2023. 
  9. ↑ Onsong, G.; Erdmann, J.; Spears, M.D. et al. (2014). "Implementation of Cloud based Next Generation Sequencing data analysis in a clinical laboratory". BMC Research Notes 7: 314. doi:10.1186/1756-0500-7-314. PMC PMC4036707. PMID 24885806. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4036707. 
  10. ↑ Afgan, E.; Sloggett, C.; Goonasekera, N. et al. (2015). "Genomics Virtual Laboratory: A Practical Bioinformatics Workbench for the Cloud". PLoS One 10 (10): e0140829. doi:10.1371/journal.pone.0140829. PMC PMC4621043. PMID 26501966. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4621043. 
  11. ↑ Navale, V.; Bourne, P.E. (2018). "Cloud computing applications for biomedical science: A perspective". PLoS Computational Biology 14 (6): e1006144. doi:10.1371/journal.pcbi.1006144. PMC PMC6002019. PMID 29902176. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6002019. 
  12. ↑ Ogle, C.; Reddick, D.; McKnight, C.; Biggs, T.; Pauly, R.; Ficklin, S.P.; Feltus, F.A.; Shannigrahi, S. (2021). "Named data networking for genomics data management and integrated workflows". Frontiers in Big Data 4: 582468. doi:10.3389/fdata.2021.582468. PMC PMC7968724. PMID 33748749. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7968724. 
  13. ↑ 13.0 13.1 Gregg, A. (5 August 2018). "Pentagon doubles down on ‘single-cloud’ strategy for $10 billion contract". The Washington Post. Archived from the original on 07 August 2018. https://web.archive.org/web/20180807051800if_/https://www.washingtonpost.com/business/capitalbusiness/pentagon-doubles-down-on-single-cloud-strategy-for-10-billion-contract/2018/08/05/352cfee8-972b-11e8-810c-5fa705927d54_story.html?utm_term=.130ed427f134. Retrieved 28 July 2023. 
  14. ↑ Mitchell, B. (8 March 2018). "DOD defends its decision to move to commercial cloud with a single award". FedScoop. https://www.fedscoop.com/dod-pentagon-jedi-cloud-contract-single-award/. Retrieved 28 July 2023. 
  15. ↑ Gregg, A. (10 February 2021). "With a $10 billion cloud-computing deal snarled in court, the Pentagon may move forward without it". The Washington Post. Archived from the original on 11 February 2021. https://web.archive.org/web/20210211065108if_/https://www.washingtonpost.com/business/2021/02/10/jedi-contract-pentagon-biden/. Retrieved 28 July 2023. 
  16. ↑ Alspach, K. (5 March 2021). "Microsoft Could Lose JEDI Contract If AWS Case Isn’t Dismissed: Report". CRN. https://www.crn.com/news/cloud/microsoft-could-lose-jedi-contract-if-aws-case-isn-t-dismissed-report. Retrieved 28 July 2023. 
  17. ↑ Nix, N. (7 March 2021). "Microsoft’s $10 billion Pentagon deal at risk amid Amazon fight". The Seattle Times. https://www.seattletimes.com/business/microsofts-10-billion-pentagon-deal-at-risk-amid-amazon-fight/. Retrieved 28 July 2023. 
  18. ↑ Miller, R. (6 July 2021). "Nobody wins as DoD finally pulls the plug on controversial $10B JEDI contract". TechCrunch. https://techcrunch.com/2021/07/06/nobody-wins-as-dod-finally-pulls-the-plug-on-controversial-10b-jedi-contract/. Retrieved 15 August 2023. 
  19. ↑ 19.0 19.1 Shepardson, D. (9 July 2021). "U.S. judge ends Amazon challenge to $10 bln cloud contract after Pentagon cancellation". Reuters. https://www.reuters.com/legal/government/us-judge-ends-amazon-challenge-10-bln-cloud-contract-after-pentagon-cancellation-2021-07-09/. Retrieved 15 August 2023. 
  20. ↑ Miller, R. (19 November 2021). "Pentagon announces new cloud initiative to replace ill-fated JEDI contract". TechCrunch. https://techcrunch.com/2021/11/19/pentagon-announces-new-cloud-initiative-to-replace-ill-fated-jedi-contract/. Retrieved 15 August 2023. 
  21. ↑ Lopez, C.T. (12 December 2022). "Department Names Vendors to Provide Joint Warfighting Cloud Capability". DoD News. U.S. Department of Defense. https://www.defense.gov/News/News-Stories/Article/Article/3243483/department-names-vendors-to-provide-joint-warfighting-cloud-capability/. Retrieved 15 August 2023. 
  22. ↑ Underwood, K. (17 April 2023). "The Joint Warfighting Cloud Capability Is Breaking Barriers". SIGNAL. https://www.afcea.org/signal-media/defense-operations/joint-warfighting-cloud-capability-breaking-barriers. Retrieved 15 August 2023. 
  23. ↑ Waibel, P.; Matt, J.; Hochreiner, C. et al. (2017). "Cost-optimized redundant data storage in the cloud". Service Oriented Computing and Applications 11: 411–26. doi:10.1007/s11761-017-0218-9. 
  24. ↑ Anderson, M.E.; Ray, S.C. (2017). "It's 10 pm; Do You Know Where Your Data Are? Data Provenance, Curation, and Storage". Circulation Research 120 (10): 1551-1554. doi:10.1161/CIRCRESAHA.116.310424. PMC PMC5465863. PMID 28495991. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5465863. 
  25. ↑ "Clean up your server instance before migration". Atlassian Support. Atlassian. 17 March 2021. https://support.atlassian.com/migration/docs/clean-up-your-server-instance-before-migration/. Retrieved 28 July 2023. 
  26. ↑ SADA Says (22 August 2019). "9 STEPS FOR MIGRATING DATABASES TO THE CLOUD". SADA, Inc. https://sada.com/insights/blog/9-steps-for-migrating-databases-to-the-cloud/. Retrieved 28 July 2023. 
  27. ↑ Mok, K. (1 December 2020). "Should we really be worried about vendor lock-in in 2020?". Protocol. https://www.protocol.com/manuals/new-enterprise/vendor-lockin-cloud-saas. Retrieved 28 July 2023. 
  28. ↑ "Cloud Communications: European Companies Show Newfound Maturity". Mitel. 20 July 2020. Archived from the original on 04 December 2021. https://web.archive.org/web/20211204082428/https://www.mitel.com/en-gb/about/newsroom/press-releases/european-companies-show-newfound-maturity. Retrieved 28 July 2023. 
  29. ↑ Paul, F. (24 July 2023). "HashiCorp State of Cloud Strategy Survey 2023: The tech sector perspective". HashiCorp. https://www.hashicorp.com/blog/hashicorp-state-of-cloud-strategy-survey-2023-the-tech-sector-perspective. Retrieved 15 August 2023. 
  30. ↑ "How to avoid cloud vendor lock-in and take advantage of multi-cloud". InformationAge. 2023. https://www.information-age.com/how-to-avoid-cloud-vendor-lock-in-advantage-multi-cloud-16437/. Retrieved 28 July 2023. 
  31. ↑ Nangare, S. (13 December 2019). "An Overview of Cloud Migration and Open Source". DevOps.com. https://devops.com/an-overview-of-cloud-migration-and-open-source/. Retrieved 28 July 2023. 


-----Go to the next chapter of this guide-----

Citation information for this chapter

Chapter: 4. Cloud computing in the laboratory

Title: Choosing and Implementing a Cloud-based Service for Your Laboratory

Edition: Second edition

Author for citation: Shawn E. Douglas

License for content: Creative Commons Attribution-ShareAlike 4.0 International

Publication date: August 2023


Retrieved from "https://www.limswiki.org/index.php?title=Book:Choosing_and_Implementing_a_Cloud-based_Service_for_Your_Laboratory/Cloud_computing_in_the_laboratory/Deployment_approaches&oldid=52907"