the enabling technology for microservices was first introduced into the unix kernel as early as 1979 , 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 .
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 .
benefits industry leaders have attained by adopting a microservices approach 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 .
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 .
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 .
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 downtimes to patch the various vulnerable components . the widely adopted framework for microservices bundles
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 .
containers utilize a relatively small footprint and require less overhead than virtual machines ( 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 ) ; running containers requires little more than installing a light - weight program on the host .
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 .
a configuration file [ figure 2 ] describes the base operating system , build options , dependencies required for the service to run , and optional initialization scripts .
this simple text file fully defines the container and can be used to instantiate the container on any capable host without additional setup .
in contrast , traditional application deployment requires a specific build for each host and applications with conflicting dependencies will cause significant problems .
example configuration file for a simple container providing a mysql client service . adapted from https://hub.docker.com/r/gliderlabs/alpine the infrastructure described thus far allows for flexibility in scaling applications , especially when scaling across multiple nodes or even across heterogeneous networks .
well - designed containers are stateless ( stateless in the sense that output is determined solely by the current input and independent of previous inputs ) or at least having no internal state , meaning they can be aborted and restarted without losing information .
this allows for services to be created ad hoc and then deleted when they are no longer needed .
running services on an as - needed basis allow for optimal use of system resources . similarly ,
when demand fluctuates , it is possible to scale the application up , either on existing hardware or alternatively , by incorporating additional cloud resources . at a functional level , this is accomplished by spawning new containers as needed and then scaling them back when appropriate by destroying dormant containers .
this flexibility allows for a measured approach to scaling infrastructure , rather than purchasing fixed quantities of hardware to handle either typical or peak application loads .
regardless of the benefits and increasing popularity observed in the industry , the question of whether similar benefits can be reaped by the bioinformatics community by embracing this design practice remains to be answered .
we propose it can be a valuable tool and offer benefits beyond what has previously been discussed . as bioinformatics tools grow in complexity ,
it is difficult for small laboratories to maintain the in - house expertise required to modify and further develop all stages of a complete informatics pipeline . it will , however , become feasible to experiment with algorithms and use a wider variety of tools , as the services are divided into more manageable , interchangeable modules . containers also facilitate the use of cloud - based platform - as - a - service ( paas ) providers , avoiding the potentially prohibitive costs associated with buying state - of - the - art hardware , which may itself sit idle for the majority of its life as it quickly becomes obsolete .
paas providers offer access to nearly inexhaustible computing resources that can be retained for the length of an application 's execution for a reasonable fee .
an application built on containers can be constructed anew with each execution , run on a data set , output the results , and then dismantle itself , thus releasing its resources without manual intervention .
such automation significantly reduces operating costs and overhead of hardware , in addition to reducing the in - house technical expertise required .
researchers can easily share their work without worrying about replicating a specific development environment or sharing access to computing resources between institutions .
simply sharing the configuration files for each microservice allows others to create an exact replica of the original development environment .
this same method can be used to share experimental results in an entirely new way , allowing for entire algorithms and pipelines to be published alongside the dataset .
users can then easily recreate the pipeline , rerun the calculations , and validate the experimental results , and then compare those results with locally derived data run through the same pipeline .
the national institutes of health have made their desires known for improved rigor and reproducibility in research .
the methods and practices inherent to microservice architecture would seamlessly address this intent for increased transparency and reproducibility .
going further , an opportunity exists to leverage distributed source control tools , such as git or subversion , to create a shared repository of bioinformatics tools and algorithms .
such a service , if embraced by the community , would offer a hub of documented , open - source tools that could easily be shared , annotated , and enhanced by the community . while many open source tools are currently available
, these projects often rely upon specific versions of libraries and therefore may not easily interface with even a minority of other extant tools .
finally , adapting these open - source applications to a different workflow may involve a technical challenge similar in scope to the original development effort .
conversely , a curated hub of bioinformatics tools utilizing the microservices framework , being thoroughly vetted and maintained by the community , would promote reuse of these valuable resources .
developing custom in - house software in support of bioinformatics research is a resource - intensive effort requiring complementary expertise in software development and data science . those without the requisite resources are generally compelled to rely upon commercially supported software - often at significant expense and with the additional drawbacks of limited flexibility and customization
. utilization of a containerized framework lowers barriers of entry , increases development efficiency , facilitates reuse of proven code modules , and allows for simplified verification of algorithm integrity through transparency .
this is accomplished by leveraging freely available open - source tools that have been adopted by leaders in the it industry . on a more practical note , while there are multiple implementations of the container methodology in industry , the docker ( https://www.docker.com/ ) ecosystem of tools is the most widely publicized , and it can serve as a useful source of information for learning the basics of linux containers .
the concepts found in the core on - line docker documentation can be applied broadly , but such information is also helpful in support of bioinformatics projects that might make use of the docker model .
nextflow , the pancancer launcher from the international cancer genome consoritum , and basespace from illumina , are a few examples of contemporary tools that take advantage of docker to help manage associated pipelines .
there are also at least two projects aimed at sharing bioinformatics based docker images : bioboxes ( http://bioboxes.org ) and biodocker ( http://biodocker.org ) .
both contain explicit examples on how to containerize , locally - developed bioinformatics tools , and associated repositories of available tools supported by the community .
wider adoption of any of the above - enumerated services could be of great value to the research and bioinformatics communities - at - large .
while use - cases supporting discovery are certainly fertile ground for microservices realizing an immediate impact within pathology , there is certainly potential for a much broader impact in the clinical realm as well .
mission - critical services , such as billing and interface engines , could similarly benefit from the high availability capabilities afforded from this approach . in terms of healthcare production it settings , being able to distribute new communication standards , such as fast healthcare interoperability resources , by use of microservices could promote adherence to a common standard and facilitate faster adoption by the community .
large , monolithic , and proprietary applications have been the de facto standard for pathology and healthcare in general .
indeed , vendors appear to be in a continuing milieu of market forces , where they are actively incentivized to maintain the status quo , since profit margins can be effectively maintained by controlling access to the data .
however , that paradigm has been evolving rapidly outside of healthcare and there are even signs that it may be slowly starting to change within healthcare ( as well with the adoption of healthcare information exchanges ) . by gaining familiarity and expertise with microservice architecture , we believe pathologists can contain ever - expanding it costs , reduce the likelihood of it implementation mishaps and failures , and perhaps most importantly , greatly elevate the level of service conferred to our many types of customers .
 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 bioinformaticsconclusions : 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 . 
INTRODUCTION
DISCUSSION
CONCLUSIONS
Financial Support and Sponsorship
Conflicts of Interest