Difference between revisions of "Journal:The growing need for microservices in bioinformatics"
Shawndouglas (talk | contribs) (Created stub. Saving and adding more.) |
Shawndouglas (talk | contribs) (Saving and adding more.) |
||
Line 54: | Line 54: | ||
|} | |} | ||
|} | |} | ||
This architecture can also allow for the improvement of application stability and security. It does so by eliminating interdependency of components, as well as handling service failures gracefully, without the need to halt an entire application. Where high-availability application architectures are required, a system health check can be run as a background task, querying the various components for their status. When a service is malfunctioning, a "watch-dog" routine can shut down the service in question and then restart it. Generally, this process can take place without degrading the performance of the application as a whole. A somewhat infamous example occurred at Netflix prior to their transition to a distributed, microservices architecture.<ref name="SBSWhyYou15">{{cite web |url=http://blog.smartbear.com/microservices/why-you-cant-talk-about-microservices-without-mentioning-netflix/ |title=Why You Can’t Talk About Microservices Without Mentioning Netflix |publisher=SmartBear Software |date=08 December 2015 |accessdate=08 august 2016}}</ref> Apparently, a semicolon in a segment of code (or rather, the lack of a semicolon) took their service offline for an extended period of time, while engineers from across the enterprise attempted to track down the source of the disruption. Security can be enforced through carefully-crafted APIs. A breach of any particular module does not expose the entirety of the application, only the limited information accessed by the particular service. By severely restricting data flow between public-facing services and elements handling sensitive data, the risk posed by intrusion can be mitigated. This segregation of services also allows for real-time security patching of individual modules as vulnerabilities are exposed, which is a large improvement over the historical method of coordinating planned downtime to patch the various vulnerable components. | |||
The widely adopted framework for microservices bundles are referred to as "containers." A container is essentially an encapsulated and immutable version of an application, coupled with the bare-minimum operating system components required for execution. Libraries for running containers are currently available for Linux and soon will be available for Windows Server 2016.<ref name="FultonTheWin15">{{cite web |url=http://thenewstack.io/the-windows-and-linux-container-era-is-here/ |title=The Windows and Linux Container Era is Here |author=Fulton, S.M. |work=The New Stack |publisher=Alex Williams Media, LLC |date=19 August 2015 |accessdate=05 January 2016}}</ref> Containers utilize a relatively small footprint and require less overhead than virtual machines; running containers requires little more than installing a light-weight program on the host. (Virtual machines require the installation of a complete operating system in addition to the host operating system. This additional operating system sequesters system resources, such as central processing unit cores and random access memory, reducing what is available to the host. In contrast, containers use the same Linux kernel as the host system and share system resources only as needed) The host and container operating systems are generally unaware of each other, allowing for disparate systems to run harmoniously on a common host. This decouples the microservice(s) from the underlying physical infrastructure, allowing development effort to be focused solely on functionality. | |||
==Source of support== | ==Source of support== |
Revision as of 21:34, 20 December 2016
Full article title | The growing need for microservices in bioinformatics |
---|---|
Journal | Journal of Pathology Informatics |
Author(s) | Williams, Christopher L.; Sica, Jeffrey C.; Killen, Robert T.; Balis, Ulysses G.J. |
Author affiliation(s) | University of Michigan |
Primary contact | Email: Available w/ login |
Year published | 2016 |
Volume and issue | 7 |
Page(s) | 45 |
DOI | 10.4103/2153-3539.194835 |
ISSN | 2153-3539 |
Distribution license | Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported |
Website | http://www.jpathinformatics.org |
Download | http://www.jpathinformatics.org/temp/JPatholInform7145-5650543_154145.pdf (PDF) |
This article should not be considered complete until this message box has been removed. This is a work in progress. |
Abstract
Objective: Within the information technology (IT) industry, best practices and standards are constantly evolving and being refined. In contrast, computer technology utilized within the healthcare industry often evolves at a glacial pace, with reduced opportunities for justified innovation. Although the use of timely technology refreshes within an enterprise's overall technology stack can be costly, thoughtful adoption of select technologies with a demonstrated return on investment can be very effective in increasing productivity and at the same time, reducing the burden of maintenance often associated with older and legacy systems.
In this brief technical communication, we introduce the concept of microservices as applied to the ecosystem of data analysis pipelines. Microservice architecture is a framework for dividing complex systems into easily managed parts. Each individual service is limited in functional scope, thereby conferring a higher measure of functional isolation and reliability to the collective solution. Moreover, maintenance challenges are greatly simplified by virtue of the reduced architectural complexity of each constitutive module. This fact notwithstanding, rendered overall solutions utilizing a microservices-based approach provide equal or greater levels of functionality as compared to conventional programming approaches. Bioinformatics, with its ever-increasing demand for performance and new testing algorithms, is the perfect use-case for such a solution. Moreover, if promulgated within the greater development community as an open-source solution, such an approach holds potential to be transformative to current bioinformatics software development.
Context: Bioinformatics relies on nimble IT framework which can adapt to changing requirements.
Aims: To present a well-established software design and deployment strategy as a solution for current challenges within bioinformatics
Conclusions: Use of the microservices framework is an effective methodology for the fabrication and implementation of reliable and innovative software, made possible in a highly collaborative setting.
Keywords: Bioinformatics, crowd sourcing, defect analysis, failure mode analysis, information technology, microservices, pathology, reliability engineering, software engineering
Introduction
The modern software ecosystem is rapidly changing. The emergence of cloud computing has spurred developers to compartmentalize applications into small, easily maintainable functional units that can be replicated on demand. This application segmentation is commonly referred to as microservices (or microservice architecture). The enabling technology for microservices was first introduced into the UNIX kernel as early as 1979[1], but this field has only recently experienced an exponential growth in popularity. Many industry leaders, dependent on their information technology (IT) infrastructure, have embraced this model, including Amazon, Capital One Financial Corp., Google, and PayPal Holdings Inc.[2], among many others.
Discussion
Microservice architecture has taken hold in application design for a number of reasons [Figure 1], but ultimately, the fundamental driver has been the opportunity for significant increase in productivity. Gains are achieved by dividing larger, more complex applications into small, manageable projects that encapsulate common functionality. Each microservice represents a "black-box" with a well-defined application programming interface (API) bundled with its own integral resources, thus eliminating external dependencies. This encapsulation simplifies the division of labor for teams of software developers and reduces the inherent overhead of multiple developers working on the same sections of code. The narrow scope of functionality of a single microservice allows for thorough testing and optimization of each component in isolation, leading to higher reliability and performance of the overall parent application. The encapsulated nature of the microservice methodology inherently allows for future reuse of existing modules with minimal effort. A portfolio of proven, production-use microservices can be valuable for accelerating the development of subsequent projects.
|
This architecture can also allow for the improvement of application stability and security. It does so by eliminating interdependency of components, as well as handling service failures gracefully, without the need to halt an entire application. Where high-availability application architectures are required, a system health check can be run as a background task, querying the various components for their status. When a service is malfunctioning, a "watch-dog" routine can shut down the service in question and then restart it. Generally, this process can take place without degrading the performance of the application as a whole. A somewhat infamous example occurred at Netflix prior to their transition to a distributed, microservices architecture.[7] Apparently, a semicolon in a segment of code (or rather, the lack of a semicolon) took their service offline for an extended period of time, while engineers from across the enterprise attempted to track down the source of the disruption. Security can be enforced through carefully-crafted APIs. A breach of any particular module does not expose the entirety of the application, only the limited information accessed by the particular service. By severely restricting data flow between public-facing services and elements handling sensitive data, the risk posed by intrusion can be mitigated. This segregation of services also allows for real-time security patching of individual modules as vulnerabilities are exposed, which is a large improvement over the historical method of coordinating planned downtime to patch the various vulnerable components.
The widely adopted framework for microservices bundles are referred to as "containers." A container is essentially an encapsulated and immutable version of an application, coupled with the bare-minimum operating system components required for execution. Libraries for running containers are currently available for Linux and soon will be available for Windows Server 2016.[8] Containers utilize a relatively small footprint and require less overhead than virtual machines; running containers requires little more than installing a light-weight program on the host. (Virtual machines require the installation of a complete operating system in addition to the host operating system. This additional operating system sequesters system resources, such as central processing unit cores and random access memory, reducing what is available to the host. In contrast, containers use the same Linux kernel as the host system and share system resources only as needed) The host and container operating systems are generally unaware of each other, allowing for disparate systems to run harmoniously on a common host. This decouples the microservice(s) from the underlying physical infrastructure, allowing development effort to be focused solely on functionality.
Source of support
None
Conflicts of interest
None
References
- ↑ Topjian, J. (13 November 2013). "Contain your enthusiasm - Part One: A history of operating system containers". Tech Radar Blog. Cybera. http://www.cybera.ca/news-and-events/tech-radar/contain-your-enthusiasm-part-one-a-history-of-operating-system-containers/. Retrieved 05 January 2016.
- ↑ 2.0 2.1 Miller, M. (5 October 2015). "Innovate or Die: The Rise of Microservices". The Wall Street Journal. Dow Jones & Company, Inc. http://blogs.wsj.com/cio/2015/10/05/innovate-or-die-the-rise-of-microservices/. Retrieved 05 January 2016.
- ↑ "GE Uses Docker to Enable Self-Service for their Developers". Docker, Inc. 2016. https://www.docker.com/customers/ge-uses-docker-enable-self-service-their-developers. Retrieved 29 August 2016.
- ↑ "Flexible, Portable, Secure". Hewlett Packard Enterprise Development LP. 2016. https://www.docker.com/customers/ge-uses-docker-enable-self-service-their-developers. Retrieved 28 August 2016.
- ↑ Ho, A. (11 November 2015). "Microservices at Amazon". Developer Blog. Apigee, Inc. https://apigee.com/about/blog/developer/microservices-amazon. Retrieved 28 August 2016.
- ↑ Piesche, S. (23 March 2015). "Microservices at Constant Contact". Tech Blog. Constant Contact, Inc. https://apigee.com/about/blog/developer/microservices-amazon. Retrieved 28 August 2016.
- ↑ "Why You Can’t Talk About Microservices Without Mentioning Netflix". SmartBear Software. 8 December 2015. http://blog.smartbear.com/microservices/why-you-cant-talk-about-microservices-without-mentioning-netflix/. Retrieved 08 august 2016.
- ↑ Fulton, S.M. (19 August 2015). "The Windows and Linux Container Era is Here". The New Stack. Alex Williams Media, LLC. http://thenewstack.io/the-windows-and-linux-container-era-is-here/. Retrieved 05 January 2016.
Notes
This presentation is faithful to the original, with only a few minor changes to presentation. In some cases important information was missing from the references, and that information was added.