Microservices

A microservice is a software development technique—a variant of the service-oriented architecture (SOA) architectural style that structures an application as a collection of loosely coupled services. In a microservices architecture, services are fine-grained and the protocols are lightweight. The benefit of decomposing an application into different smaller services is that it improves modularity and makes the application easier to understand, develop, and test and more resilient to architecture erosion.[1] It parallelizes development by enabling small autonomous teams to develop, deploy and scale their respective services independently.[2] It also allows the architecture of an individual service to emerge through continuous refactoring.[3] Microservices-based architectures enable continuous delivery and deployment.[1][4]

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:

  • Services in a microservice architecture (MSA)[5] are often processes that communicate over a network to fulfill a goal using technology-agnostic protocols such as HTTP.[6][7][8] However, services might also use other kinds of inter-process communication mechanisms such as shared memory.[9] Services might also run within the same process as, for example, OSGI bundles.
  • Services in a microservice architecture are independently deployable.[10][1]
  • 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.[1]
  • Services are small in size, messaging enabled, bounded by contexts, autonomously developed, independently deployable, decentralized and built and released with automated processes.[10]
  • The microservices work together, communicating through web APIs or messaging queues to respond to incoming events.[11]

A microservices-based architecture:

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.[16]

Dr. Peter Rodgers introduced the term "Micro-Web-Services" during a presentation at the Web Services Edge conference in 2005. On slide #4 of the conference presentation, he states that "Software components are Micro-Web-Services".[17] Juval Löwy had similar precursor ideas about classes being granular services, as the next evolution of Microsoft architecture.[18][19][20] "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 interfaces. 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".[21] 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.[22] 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.[23] 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.

Microservices is a specialization of an implementation approach for service-oriented architectures (SOA) used to build flexible, independently deployable software systems.[24] 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.[25] Microservice architectures have been used to build the software platform for many of the most disruptive, and successful, Internet startups (which are now large companies). Three examples, out of many, are Amazon,[26] Netflix [27] and Twitter.[28]

Philosophy

The philosophy of the microservices architecture essentially equates to the Unix philosophy of "Do one thing and do it well". It is described as follows:[29][30][31]

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

Linguistic approach

A linguistic approach to the development of microservices[33] focuses on selecting a programming language that can easily represent a microservice as a single software artifact. A language well suited to microservices encourages the developer to think and program in terms of microservices from the start, instead of starting with a different programming paradigm only to refactor or retrofit a finished project so it can be deployed as a microservice.[34] When effective, the gap between architecting a project and deploying it can be minimized.

One language intended to fill this role is Jolie.[35][36] The simplicity of the Jolie programming language and its easy deployability also found applications in the area of Internet of Things and Smart Buildings where microservices are a suitable architectural choice.[37][38]

Technologies

Computer microservices can be implemented in different programming languages and might use different infrastructures. Therefore the most important technology choices are the way microservices communicate with each other (synchronous, asynchronous, UI integration) and the protocols used for the communication (REST, messaging, ...). In a traditional system most technology choices like the programming language impact the whole systems. Therefore the approach for choosing technologies is quite different.[39]

Service Mesh

Microservices architectures have given rise to many approaches for making them work well at varying degrees of scale. One widely discussed pattern for large-scale microservices development and delivery is the service mesh pattern.[40]

In a service mesh, each service instance is paired with an instance of a reverse proxy server, called a service proxy, sidecar proxy, or sidecar. The service instance and sidecar proxy share a container, and the containers are managed by a container orchestration tool such as Kubernetes.[41]

The service proxies are responsible for communication with other service instances and can support capabilities such as service (instance) discovery, load balancing, authentication and authorization, secure communications, and others.

In a service mesh, the service instances and their sidecar proxy are said to make up the data plane, which includes not only data management but also request processing and response. The service mesh also includes a control plane for managing the interaction between services, mediated by their sidecar proxies. The most widely discussed service mesh architecture today is Istio, a joint project among Google, IBM, and Lyft.

Criticism

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

  • Services form information barriers[42]
  • 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[6]
  • Testing and deployment are more complicated[43]
  • Moving responsibilities between services is more difficult.[1] It may involve communication between different teams, rewriting the functionality in another language or fitting it into a different infrastructure[6]
  • Viewing the size of services as the primary structuring mechanism can lead to too many services when the alternative of internal modularization may lead to a simpler design.[44]

Cognitive load

The architecture introduces additional complexity and new problems to deal with, such as network latency, message formats, load balancing and fault tolerance.[45][43]

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?[46]

Also, an application made up of any number of microservices has to access its respective ecosystem, which may have unnecessary complexity.[47] 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.[48][49]

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.[50][51]

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:[51]

  • 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.

See also

References

  1. 1 2 3 4 5 6 Chen, Lianping (2018). Microservices: Architecting for Continuous Delivery and DevOps. The IEEE International Conference on Software Architecture (ICSA 2018). IEEE.
  2. ↑ Richardson, Chris. "Microservice architecture pattern". microservices.io. Retrieved 2017-03-19.
  3. ↑ Chen, Lianping; Ali Babar, Muhammad (2014). Towards an Evidence-Based Understanding of Emergence of Architecture through Continuous Refactoring in Agile Software Development. The 11th Working IEEE/IFIP Conference on Software Architecture(WICSA 2014). IEEE.
  4. ↑ ceracm (2017-01-04). "Microservices-based architectures enable continuous delivery/deployment". Eventuate.IO. Retrieved 2017-03-19.
  5. ↑ Nicola Dragoni, Saverio Giallorenzo, Alberto Lluch Lafuente, Manuel Mazzara, Fabrizio Montesi, Ruslan Mustafin, Larisa Safina. "Microservices: yesterday, today, and tomorrow" (PDF). arXiv:1606.04036. Bibcode:2016arXiv160604036D. Retrieved 2 May 2017.
  6. 1 2 3 4 5 Martin Fowler. "Microservices". Archived from the original on 14 February 2018.
  7. ↑ Newman, Sam. Building Microservices. O'Reilly Media. ISBN 978-1491950357.
  8. ↑ Wolff, Eberhard. Microservices: Flexible Software Architectures. ISBN 978-0134602417.
  9. ↑ "Micro-services for performance". Vanilla Java. Retrieved 2017-03-19.
  10. 1 2 Nadareishvili, I., Mitra, R., McLarty, M., Amundsen, M., Microservice Architecture: Aligning Principles, Practices, and Culture, O’Reilly 2016
  11. ↑ "Understanding Microservices". NGINX. NGINX Inc. Retrieved 27 September 2018.
  12. ↑ "IFS: Microservices Resources and Positions". hsr.ch. Retrieved 28 December 2016.
  13. ↑ Nicola Dragoni, Schahram Dustdar, Stephan T. Larsen, Manuel Mazzara. "Microservices: Migration of a Mission Critical System" (PDF). arXiv:1704.04173. Bibcode:2017arXiv170404173D. Retrieved 2 May 2017.
  14. ↑ Nicola Dragoni, Ivan Lanese, Stephan Thordal Larsen, Manuel Mazzara, Ruslan Mustafin, Larisa Safina. "Microservices: How To Make Your Application Scale" (PDF). arXiv:1702.07149. Bibcode:2017arXiv170207149D. Retrieved 2 May 2017.
  15. ↑ Manuel Mazzara, Kevin Khanda, Ruslan Mustafin, Victor Rivera, Larisa Safina, Alberto Sillitti. "Microservices Science and Engineering" (PDF). arXiv:1706.07350. Bibcode:2017arXiv170607350M. Retrieved 14 November 2017.
  16. ↑ James Lewis and Martin Fowler. "Microservices".
  17. ↑ Rodgers, Peter. "Service-Oriented Development on NetKernel- Patterns, Processes & Products to Reduce System Complexity Web Services Edge 2005 East: CS-3". CloudComputingExpo 2005. SYS-CON TV. Retrieved 3 July 2017.
  18. ↑ Löwy, Juval (October 2007). "Every Class a WCF Service". Channel9, ARCast.TV.
  19. ↑ Löwy, Juval (2007). Programming WCF Services 1st Edition. pp. 543–553.
  20. ↑ Löwy, Juval (May 2009). "Every Class As a Service". Microsoft TechEd Conference, SOA206. Archived from the original on 2010.
  21. ↑ Rodgers, Peter. "Service-Oriented Development on NetKernel- Patterns, Processes & Products to Reduce System Complexity". CloudComputingExpo. SYS-CON Media. Retrieved 19 August 2015.
  22. ↑ Russell, Perry; Rodgers, Peter; Sellman, Royston (2004). "Architecture and Design of an XML Application Platform". HP Technical Reports. p. 62. Retrieved 20 August 2015.
  23. ↑ Hitchens, Ron (Dec 2014). Swaine, Michael, ed. "Your Object Model Sucks". PragPub Magazine. Pragmatic Programmers: 15.
  24. ↑ Pautasso, Cesare (2017). "Microservices in Practice, Part 1: Reality Check and Service Design". IEEE Software. 34 (1): 91–98. doi:10.1109/MS.2017.24.
  25. ↑ "Continuous Deployment: Strategies". javacodegeeks.com. Retrieved 28 December 2016.
  26. ↑ "Amazon (company)". Wikipedia. 2018-05-19.
  27. ↑ "Netflix". Wikipedia. 2018-05-19.
  28. ↑ "Twitter". Wikipedia. 2018-05-18.
  29. ↑ Lucas Krause. Microservices: Patterns and Applications. ASIN B00VJ3NP4A.
  30. ↑ Lucas Krause. "Philosophy of Microservices?".
  31. 1 2 Jim Bugwadia. "Microservices: Five Architectural Constraints".
  32. ↑ Li, Richard. "Microservices Essentials for Executives: The Key to High Velocity Software Development". Datawire. Datawire, Inc. Retrieved 21 October 2016.
  33. ↑ Claudio Guidi. "What is a microservice? (from a linguistic point of view)".
  34. ↑ Claudio Guidi, Ivan Lanese, Manuel Mazzara, Fabrizio Montesi (2017). "Microservices: a Language-based Approach". arXiv:1704.08073 [cs.PL].
  35. ↑ Jolie Team. "Vision of microservices revolution".
  36. ↑ Fabrizio Montesi. "Programming Microservices with Jolie - Part 1: Data formats, Proxies, and Workflows".
  37. ↑ Dilshat Salikhov, Kevin Khanda, Kamill Gusmanov, Manuel Mazzara, Nikolaos Mavridis (2016). "Microservice-based IoT for Smart Buildings". arXiv:1610.09480 [cs.CY].
  38. ↑ Kamill Gusmanov, Kevin Khanda, Dilshat Salikhov, Manuel Mazzara, Nikolaos Mavridis (2016). "Jolie Good Buildings: Internet of things for smart building infrastructure supporting concurrent apps utilizing distributed microservices". arXiv:1611.08995 [cs.SE].
  39. ↑ Wolff, Eberhard. Microservices - A Practical Guide. ISBN 978-1717075901.
  40. ↑ "What Is a Service Mesh? - NGINX". NGINX. 2018-04-03. Retrieved 2018-05-21.
  41. ↑ "Production-Grade Container Orchestration - Kubernetes". kubernetes.io. Retrieved 2018-05-21.
  42. ↑ Jan Stenberg (11 August 2014). "Experiences from Failing with Microservices".
  43. 1 2 "Developing Microservices for PaaS with Spring and Cloud Foundry".
  44. ↑ Tilkov, Stefan (17 November 2014). "How small should your microservice be?". innoq.com. Retrieved 4 January 2017.
  45. ↑ Pautasso, Cesare (2017). "Microservices in Practice, Part 2: Service Integration and Sustainability". IEEE Software. 34 (2): 97–104. doi:10.1109/MS.2017.56.
  46. ↑ Robert Annett. "Where is the complexity?".
  47. ↑ "BRASS Building Resource Adaptive Software Systems". U.S. Government. DARPA. April 7, 2015. "Access to system components and the interfaces between clients and their applications, however, are mediated via a number of often unrelated mechanisms, including informally documented application programming interfaces (APIs), idiosyncratic foreign function interfaces, complex ill-understood model definitions, or ad hoc data formats. These mechanisms usually provide only partial and incomplete understanding of the semantics of the components themselves. In the presence of such complexity, it is not surprising that applications typically bake-in many assumptions about the expected behavior of the ecosystem they interact with."
  48. ↑ Alpert, Jesse; Hajaj, Nissan. "We knew the web was big". Official Google Blog. Google.com. Retrieved 22 August 2015.
  49. ↑ "The Story". How search works. Google.com. Retrieved 22 August 2015.
  50. ↑ Services, Microservices, Nanoservices – oh my!, Arnon Rotem-Gal-Oz
  51. 1 2 Practical SOA: 1.1: Nanoservices, Arnon Rotem-Gal-Oz, 2010

Further reading

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.