|
|
| (2 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| ===4.3 Deployment approaches=== | | <div class="nonumtoc">__TOC__</div> |
| 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.<ref name="AgilentCloud19" /> In some cases, like most software, the deployment choice will be relatively straightforward, but other aspects of laboratory requirements may complicate that decision further.
| | {{ombox |
| | | type = notice |
| | | style = width: 960px; |
| | | text = This is sublevel23 of my sandbox, where I play with features and test MediaWiki code. If you wish to leave a comment for me, please see [[User_talk:Shawndouglas|my discussion page]] instead.<p></p> |
| | }} |
|
| |
|
| 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.<ref name="AgilentCloud19">{{cite web |url=https://www.agilent.com/cs/library/whitepaper/public/whitepaper-cloud-adoption-openlab-5994-0718en-us-agilent.pdf |format=PDF |title=Cloud Adoption for Lab Informatics: Trends, Opportunities, Considerations, Next Steps |author=Agilent Technologies |publisher=Agilent Technologies |date=21 February 2019 |accessdate=28 July 2023}}</ref> 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.<ref name="AgilentCloud19" />
| | ==Sandbox begins below== |
| | |
| 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.<ref name="AgilentCloud19" /> 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."<ref name="AgilentCloud19" /> It also has easy scalability, enables remote access, and simplifies disaster recovery.<ref name="AgilentCloud19" />
| |
| | |
| 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.<ref name="VyasCloud20">{{cite web |url=https://planetinnovation.com/perspectives/cloud-vs-on-premises-solutions/ |title=Cloud vs. on-premises solutions – 5 factors to consider when planning the connectivity strategy for your healthcare instrument |author=Vyas, K. |work=Planet Innovation: Perspectives |date=September 2020 |accessdate=28 July 2023}}</ref> 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."<ref name="APHLBreaking17">{{cite web |url=https://www.aphl.org/aboutAPHL/publications/Documents/INFO-2017Jun-Cloud-Computing.pdf |format=PDF |title=Breaking Through the Cloud: A Laboratory Guide to Cloud Computing |author=Association of Public Health Laboratories |publisher=Association of Public Health Laboratories |date=2017 |accessdate=28 July 2023}}</ref>
| |
| | |
| 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.<ref name="VyasCloud20" />
| |
| | |
| 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====
| |
| [[File:Devuan GNU-Linux - tty login as root in an ownCloud instance - server rack.jpg|right|350px]]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<ref name="MaurerCloud20">{{cite web |url=https://carnegieendowment.org/2020/08/31/cloud-security-primer-for-policymakers-pub-82597 |title=Cloud Security: A Primer for Policymakers |author=Maurer, T.; Hinck, G. |publisher=Carnegie Endowment for International Peace |date=31 August 2020 |accessdate=28 July 2023}}</ref>:
| |
| | |
| <blockquote>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.</blockquote>
| |
| | |
| 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<ref name="LeviteCloud20">{{cite web |url=https://carnegieendowment.org/2020/11/09/cloud-governance-challenges-survey-of-policy-and-regulatory-issues-pub-83124 |title=Cloud Governance Challenges: A Survey of Policy and Regulatory Issues |author=Levite, A.; Kalwani, G. |publisher=Carnegie Endowment for International Peace |date=09 November 2020 |accessdate=28 July 2023}}</ref>:
| |
| | |
| <blockquote>... 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.</blockquote>
| |
| | |
| To be sure, interoperability and portability are important concepts, not only in cloud computing<ref name="LeviteCloud20" /><ref name="RamalingamAddress21">{{cite journal |title=Addressing Semantics Standards for Cloud Portability and Interoperability in Multi Cloud Environment |journal=Symmetry |author=Ramalingam, C.; Mohan, P. |volume=13 |at=317 |year=2021 |doi=10.3390/sym13020317}}</ref> but also in laboratory [[Information management|data management]], particularly with clinical data.<ref name="ASPEShield">{{cite web |url=https://aspe.hhs.gov/shield-standardization-lab-data-enhance-patient-centered-outcomes-research-and-value-based-care |title=SHIELD - Standardization of Lab Data to Enhance Patient-Centered Outcomes Research and Value-Based Care |author=Office of the Assistant Secretary for Planning and Evaluation |publisher=U.S. Department of Health & Human Services |accessdate=28 July 2023}}</ref><ref name="FutrellCOVID21">{{cite web |url=https://www.mlo-online.com/information-technology/lis/article/21210723/covid19-highlights-need-for-laboratory-data-sharing-and-interoperability |title=COVID-19 highlights need for laboratory data sharing and interoperability |author=Futrell, K. |work=Medical Laboratory Observer |date=22 February 2021 |accessdate=28 July 2023}}</ref> 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."<ref name="ASPEShield" /> 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.<ref name="OnsongoImplem14">{{cite journal |title=Implementation of Cloud based Next Generation Sequencing data analysis in a clinical laboratory |journal=BMC Research Notes |author=Onsong, G.; Erdmann, J.; Spears, M.D. et al. |volume=7 |at=314 |year=2014 |doi=10.1186/1756-0500-7-314 |pmid=24885806 |pmc=PMC4036707}}</ref><ref name="AfganGenomics15">{{cite journal |title=Genomics Virtual Laboratory: A Practical Bioinformatics Workbench for the Cloud |journal=PLoS One |author=Afgan, E.; Sloggett, C.; Goonasekera, N. et al. |volume=10 |issue=10 |at=e0140829 |year=2015 |doi=10.1371/journal.pone.0140829 |pmid=26501966 |pmc=PMC4621043}}</ref><ref name="NavaleCloud18">{{cite journal |title=Cloud computing applications for biomedical science: A perspective |journal=PLoS Computational Biology |author=Navale, V.; Bourne, P.E. |volume=14 |issue=6 |at=e1006144 |year=2018 |doi=10.1371/journal.pcbi.1006144 |pmid=29902176 |pmc=PMC6002019}}</ref><ref name="OgleNamed21">{{cite journal |title=Named data networking for genomics data management and integrated workflows |journal=Frontiers in Big Data |author=Ogle, C.; Reddick, D.; McKnight, C.; Biggs, T.; Pauly, R.; Ficklin, S.P.; Feltus, F.A.; Shannigrahi, S. |volume=4 |at=582468 |year=2021 |doi=10.3389/fdata.2021.582468 |pmid=33748749 |pmc=PMC7968724}}</ref>
| |
| | |
| 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<ref name="LeviteCloud20" /> (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.<ref name="GreggPent18">{{cite web |url=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 |archiveurl=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 |title=Pentagon doubles down on ‘single-cloud’ strategy for $10 billion contract |author=Gregg, A. |work=The Washington Post |date=05 August 2018 |archivedate=07 August 2018 |accessdate=28 July 2023}}</ref> 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.<ref name="MitchellDoD18">{{cite web |url=https://www.fedscoop.com/dod-pentagon-jedi-cloud-contract-single-award/ |title=DOD defends its decision to move to commercial cloud with a single award |author=Mitchell, B. |work=FedScoop |date=08 March 2018 |accessdate=28 July 2023}}</ref> This has inevitably led to a number of lawsuits before and after Microsoft was awarded the contract, which has dragged on into the first quarter of 2021. With legal battles raging and an overarching "urgent, unmet requirement" by the Defense Department still not being realized because of the litigation, the government is 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.<ref name="GreggWithA21">{{cite web |url=https://www.washingtonpost.com/business/2021/02/10/jedi-contract-pentagon-biden/ |archiveurl=https://web.archive.org/web/20210211065108if_/https://www.washingtonpost.com/business/2021/02/10/jedi-contract-pentagon-biden/ |title=With a $10 billion cloud-computing deal snarled in court, the Pentagon may move forward without it |author=Gregg, A. |work=The Washington Post |date=10 February 2021 |archivedate=11 February 2021 |accessdate=28 July 2023}}</ref><ref name="AlspachMicro21">{{cite web |url=https://www.crn.com/news/cloud/microsoft-could-lose-jedi-contract-if-aws-case-isn-t-dismissed-report |title=Microsoft Could Lose JEDI Contract If AWS Case Isn’t Dismissed: Report |author=Alspach, K. |work=CRN |date=05 March 2021 |accessdate=28 July 2023}}</ref><ref name="NixMicro21">{{cite web |url=https://www.seattletimes.com/business/microsofts-10-billion-pentagon-deal-at-risk-amid-amazon-fight/ |title=Microsoft’s $10 billion Pentagon deal at risk amid Amazon fight |author=Nix, N. |work=The Seattle Times |date=07 March 2021 |accessdate=28 July 2023}}</ref> The success of the CIA's C2E cloud-based program, which was awarded to five cloud providers, may prove to be a further catalyst.<ref name="GreggPent18" />
| |
| | |
| 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.<ref name="WaibelCost17">{{cite journal |title=Cost-optimized redundant data storage in the cloud |journal=Service Oriented Computing and Applications |author=Waibel, P.; Matt, J.; Hochreiner, C. et al. |volume=11 |pages=411–26 |year=2017 |doi=10.1007/s11761-017-0218-9}}</ref> 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.<ref name="AndersonIts10_17">{{cite journal |title=It's 10 pm; Do You Know Where Your Data Are? Data Provenance, Curation, and Storage |journal=Circulation Research |author=Anderson, M.E.; Ray, S.C. |volume=120 |issue=10 |pages=1551-1554 |year=2017 |doi=10.1161/CIRCRESAHA.116.310424 |pmid=28495991 |pmc=PMC5465863}}</ref> 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.<ref name="AtlassianClean21">{{cite web |url=https://support.atlassian.com/migration/docs/clean-up-your-server-instance-before-migration/ |title=Clean up your server instance before migration |work=Atlassian Support |publisher=Atlassian |date=17 March 2021 |accessdate=28 July 2023}}</ref><ref name="SADASaysNine19">{{cite web |url=https://sada.com/insights/blog/9-steps-for-migrating-databases-to-the-cloud/ |title=9 STEPS FOR MIGRATING DATABASES TO THE CLOUD |author=SADA Says |publisher=SADA, Inc |date=22 August 2019 |accessdate=28 July 2023}}</ref> 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."<ref name="AgilentCloud19" />
| |
| | |
| 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.<ref name="MokShould20">{{cite web |url=https://www.protocol.com/manuals/new-enterprise/vendor-lockin-cloud-saas |title=Should we really be worried about vendor lock-in in 2020? |author=Mok, K. |work=Protocol |date=01 December 2020 |accessdate=28 July 2023}}</ref> 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% of respondents [said they] want the ability to change provider quickly if the service contract is not fulfilled."<ref name="MitelCloud20">{{cite web |url=https://www.mitel.com/en-gb/about/newsroom/press-releases/european-companies-show-newfound-maturity |archiveurl=https://web.archive.org/web/20211204082428/https://www.mitel.com/en-gb/about/newsroom/press-releases/european-companies-show-newfound-maturity |title=Cloud Communications: European Companies Show Newfound Maturity |publisher=Mitel |date=20 July 2020 |archivedate=04 December 2021 |accessdate=28 July 2023}}</ref>
| |
| | |
| 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<ref name="IsmailHowTo20">{{cite web |url=https://www.information-age.com/how-to-avoid-cloud-vendor-lock-in-advantage-multi-cloud-16437/ |title=How to avoid cloud vendor lock-in and take advantage of multi-cloud |work=InformationAge |date=2023 |accessdate=28 July 2023}}</ref>:
| |
| | |
| <blockquote>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.</blockquote>
| |
| | |
| 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.<ref name="RamalingamAddress21" /> 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.<ref name="NangareAnOver19">{{cite web |url=https://devops.com/an-overview-of-cloud-migration-and-open-source/ |title=An Overview of Cloud Migration and Open Source |author=Nangare, S. |work=DevOps.com |date=13 December 2019 |accessdate=28 July 2023}}</ref> 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.
| |
