Microservices

Microservices is a specialisation of and implementation approach for service-oriented architectures (SOA) used to build flexible, independently deployable software systems. Services in a microservice architecture (MSA)^[1] are processes that communicate with each other over a network in order to fulfill a goal. These services use technology-agnostic protocols.^[2][3][4] The microservices approach is a first realisation of SOA that followed the introduction of DevOps and is becoming more popular for building continuously deployed systems.^[5][6]

In a microservices architecture, services should have a small granularity and the protocols should be lightweight. A central microservices property that appears in multiple definitions is that services should be independently deployable.^[7] The benefit of distributing different responsibilities of the system into different smaller services is that it enhances the cohesion and decreases the coupling. This makes it easier to change and add functions and qualities to the system at any time.^[8] It also allows the architecture of an individual service to emerge through continuous refactoring,^[9] and hence reduces the need for a big up-front design and allows for releasing software early and continuously.

Details

There is no industry consensus yet regarding the properties of microservices, and an official definition is missing as well. Some of the defining characteristics that are frequently cited include:

• The services are easy to replace.
• Services are organized around capabilities, e.g., user interface front-end, recommendation, logistics, billing, etc.
• Services can be implemented using different programming languages, databases, hardware and software environment, depending on what fits best.
• Services are small in size, messaging enabled, bounded by contexts, autonomously developed, independently deployable, decentralized and built and released with automated processes.^[7]

A microservices-based architecture:

• Naturally enforces a modular structure.^[2]
• Lends itself to a continuous delivery software development process. A change to a small part of the application only requires one or a small number of services to be rebuilt and redeployed.^[2]
• Adheres to principles such as fine-grained interfaces (to independently deployable services), business-driven development (e.g. domain-driven design), IDEAL cloud application architectures, polyglot programming and persistence, lightweight container deployment, decentralized continuous delivery, and DevOps with holistic service monitoring.^[10]

History

A workshop of software architects held near Venice in May 2011 used the term "microservice" to describe what the participants saw as a common architectural style that many of them had been recently exploring. In May 2012, the same group decided on "microservices" as the most appropriate name. James Lewis presented some of those ideas as a case study in March 2012 at 33rd Degree in Kraków in Microservices - Java, the Unix Way, as did Fred George about the same time. Adrian Cockcroft at Netflix, describing this approach as "fine grained SOA", pioneered the style at web scale, as did many of the others mentioned in this article - Joe Walnes, Dan North, Evan Bottcher and Graham Tackley.^[11]

Dr. Peter Rodgers introduced the term "Micro-Web-Services" during a presentation at Cloud Computing Expo in 2005. On slide #4 of the conference presentation, he states that "Software components are Micro-Web-Services". Juval Löwy had similar precursor ideas about classes being granular services, as the next evolution of Microsoft architecture.^[12][13][14] "Services are composed using Unix-like pipelines (the Web meets Unix = true loose-coupling). Services can call services (+multiple language run-times). Complex service-assemblies are abstracted behind simple URI interface. Any service, at any granularity, can be exposed." He described how a well-designed service platform "applies the underlying architectural principles of the Web and Web services together with Unix-like scheduling and pipelines to provide radical flexibility and improved simplicity by providing a platform to apply service-oriented architecture throughout your application environment".^[15] The design, which originated in a research project at Hewlett Packard Labs, aims to make code less brittle and to make large-scale, complex software systems robust to change.^[16] To make "Micro-Web-Services" work, one has to question and analyze the foundations of architectural styles (such as SOA) and the role of messaging between software components in order to arrive at a new general computing abstraction.^[17] In this case, one can think of resource-oriented computing (ROC) as a generalized form of the Web abstraction. If in the Unix abstraction "everything is a file", in ROC, everything is a "Micro-Web-Service". It can contain information, code or the results of computations so that a service can be either a consumer or producer in a symmetrical and evolving architecture.

Philosophy

The philosophy of the microservices architecture essentially equals to the Unix philosophy of "Do one thing and do it well". It is described as follows:^[18][19][20]

• The services are small - fine-grained to perform a single function.
• The organization culture should embrace automation of deployment and testing. This eases the burden on management and operations and allows for different development teams to work on independently deployable units of code.^[21]
• The culture and design principles should embrace failure and faults, similar to anti-fragile systems.
• Each service is elastic, resilient, composable, minimal, and complete.^[20]

Criticism

The microservices approach is subject to criticism for a number of issues:

• Services form information barriers^[22]
• The architecture introduces additional complexity and new problems to deal with, such as network latency, message formats, load balancing and fault tolerance,^[23] ignoring one of these belongs to the "fallacies of distributed computing"
• testing and deployment are more complicated^[23]
• Inter-service calls over a network have a higher cost in terms of network latency and message processing time than in-process calls within a monolithic service process^[2]
• Moving responsibilities between services is more difficult. It may involve communication between different teams, rewriting the functionality in another language or fitting it into a different infrastructure^[2]
• The complexity of a monolithic application is only shifted into the network, but persists:

  You can move it about but it's still there!

  — Robert Annett: Where is the complexity?^[24]

Also, an application made up of any number of microservices has to access its respective ecosystem which may have unnecessary complexity.^[25] This kind of complexity can be reduced by standardizing the access mechanism. The Web as a system standardized the access mechanism by retaining the same access mechanism between browser and application resource over the last 20 years. Using the number of Web pages indexed by Google it grew from 26 million pages in 1998 to around 60 trillion individual pages by 2015 without the need to change its access mechanism. The Web itself is an example that the complexity inherent in traditional monolithic software systems can be overcome.^[26][27]

Nanoservices

Too-fine-grained microservices have been criticized as an anti-pattern, dubbed a nanoservice by Arnon Rotem-Gal-Oz:

[A] nanoservice is an anti-pattern where a service is too fine grained. [A] nanoservice is a service whose overhead (communications, maintenance etc.) outweighs its utility.^[28][29]

Problems include the code overhead (interface definition, retries), runtime overhead (serialization/deserialization, network traffic), and fragmented logic (useful functionality not implemented in one place, instead requiring combining many services).

Proposed alternatives to nanoservices include:^[29]

• Package the functionality as a software library, rather than a service.
• Combine the functionality with other functionalities, producing a more substantial, useful service.
• Refactor the system, putting the functionality in other services or redesigning the system.

Users

Known users of microservices principles and practices:

• Alior Bank^[30]
• Akana
• Amazon - notably AWS API Gateway and Lambda
• Apprenda^[31]
• Cloud Foundry^[23]
• Google
• GE Predix
• The Guardian
• HP Helion Development Platform
• Interactive Intelligence
• Jelastic
• Knewton^[32] (API Infrastructure at Knewton.)
• Netflix^[33] (Netflix receives nearly two-billion requests each day resulting in roughly 20 billion internal API calls.)
• Nirmata^[34] (SaaS for Microservices and Container management - also built using Microservices in Containers.)
• nearForm^[35]
• Otto.de
• Parasoft Development Testing Platform and Continuous Testing Platform
• Pivotal^[36]
• Riot Games
• Salesforce
• SAP Hybris - used for YaaS. See https://www.yaas.io
• SoundCloud
• Spotify^[37]
• Uber
• Wix.com
• Zalando

Implementations

• Baratine is an open-source JVM framework for building reactive applications. In Baratine, applications are composed of individual services. Within a service, only a single-thread is responsible for mutating data. Because of this data + thread abstraction, Baratine solves the database access bottleneck that plagues multi-threaded and multi-tier stacks. In addition, Baratine's internals provide high availability, recoverability, and thread context isolation to each service.^[38]
• Docker
• Enduro/X framework enables to build distributed microservices based applications for C/C++/Go.
• Fractalide provides a Flow-based programming language, a build system and an approach to distribution, with the aim of making efficient microservices simple to reason about. The execution environment is implemented in the Rust programming language and the build system and approach to distribution is implemented in the Nix programming language, data serialization between components is encoded using Capnproto.
• JLupin Next Server^[39] - complete and consistent microservices platform for Java and .Net applications, aiming at highest performance and stability.
• Jolie,^[40] "The first language for Microservices"
• KumuluzEE^[41] is an open-source microservice framework for Java EE (Java Duke's Choice Award winner 2015)
• MicroService4Net,^[42] an implementation that uses Windows services and self hosting web API in order to create micro services easily (C#)
• NetKernel is a uniform resource engine or operating system for developing, testing and running complex, distributed microservice architectures. It consists of a pure-Java microkernel that embodies the ROC abstraction, combined with a small core set of libraries, to provide a minimal ROC system. The system is modular and is extensible both with user modules and with off-the-shelf ready to use dedicated function modules that can be installed from NetKernel's repositories. Modules are hot-swapable allowing for zero-downtime evolution of the software configuration. Out of the box the core platform is accompanied by a comprehensive set of modules which provides a complete self-contained application server, featuring: languages, transformation-tools, integrated developer tools, operational monitoring/control etc.^[43]
• Nirmata ^[44] – Nirmata is a SaaS solution that provides microservices tooling and container management. It includes a distributed Service Gateway for ingress traffic with L4-7 load-balancing, SSL offload, version aware routing, as well as dynamic routing and load-balancing across services.
• Spring Cloud – Spring Cloud provides tools for Spring Boot developers to quickly build some of the common patterns in distributed systems (e.g. configuration management, service discovery, circuit breakers, intelligent routing, micro-proxy, control bus, one-time tokens, global locks, leadership election, distributed sessions, cluster state).
• Test tool for Microservices: Wilma^[45][46]
• Vert.x^[47]
• Zipkin - Distributed Tracing Tool for Microservices - ^[48]

See also

• Conway's law
• Cross-cutting concern
• Fallacies of distributed computing
• Representational state transfer (REST)
• Service-oriented architecture (SOA)
• Unix philosophy
• Self-contained Systems
• Serverless computing
• Web-oriented architecture (WOA)

References

http://www.imotif.net/index.php/2016/10/06/microservice/

Further reading

• S. Newman, Building Microservices – Designing Fine-Grained Systems, O’Reilly, 2015
• E. Wolff, Microservices: Flexible Software Architecture, Addison-Wesley, 2016
• I. Nadareishvili et al., Microservices Architecture – Aligning Principles, Practices and Culture, O’Reilly, 2016, http://transform.ca.com/rs/117-QWV-692/images/CA%20Technologies%20-%20OReilly%20Microservice%20Architecture%20eBook.pdf
• C: Richardson, Microservices: Decomposing Applications for Deployability and Scalability, https://www.infoq.com/articles/microservices-intro
• SEI SATURN 2015 microservices workshop, https://github.com/michaelkeeling/SATURN2015-Microservices-Workshop
• Wijesuriya, Viraj Brian (2016-08-29) Microservice Architecture, Lecture Notes, University of Colombo School of Computing, Sri Lanka