Jump to content

Microservices

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 85.255.235.221 (talk) at 13:19, 22 August 2015 (→Users: added another provider). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

In computing, microservices is a software architecture style in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs.[1] These services are small, highly decoupled and focus on doing a small task,[2] facilitating a modular approach to system-building.[3]

Details

Properties of microservices architecture:

  • 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
  • Architectures are symmetrical rather than hierarchical (producer - consumer)

A microservices-based architecture

History

The term "Micro-Web-Services" was first introduced during a presentation at CloudComputing Expo in 2005 by Dr. Peter Rodgers. On slide #4 of the conference presentation he states that "Software components are Micro-Web-Services. 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." [4] The motivation behind this design, which originated in a research project at Hewlett Packard Labs, is to make code less brittle and large-scale, complex software systems robust to change.[5] 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.[6] 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", then 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.

The term "microservice" was discussed at a workshop of software architects near Venice in May, 2011 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 presented some of these ideas as a case study in March 2012 at 33rd Degree in Krakow 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" was pioneering the style at web scale as were many of the others mentioned in this article - Joe Walnes, Dan North, Evan Botcher and Graham Tackley.[7]

Philosophy

Philosophy of microservices architecture:[8][9][10]

  • The services are small - fine-grained to perform a single function (similar to the Unix philosophy of "Do one thing and do it well").
  • The organization culture should embrace automation of deployment and testing. This eases the burden on management and operations.
  • The culture and design principles should embrace failure and faults, similar to anti-fragile systems.
  • The services are elastic, resilient, composable, minimal, and complete.

Criticism

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

  • services form information barriers[11]
  • the architecture introduces additional complexity and new problems to deal with, such as network latency, message formats, load balancing and fault tolerance,[12] ignoring one of these belongs to the "Fallacies of Distributed Computing"
  • testing and deployment are more complicated[12]
  • 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?[13]
    At the same time it is also true that a microservice and the ecosystem it has to access are riddled with unnecessary complexity. This kind of complexity can be reduced by standardizing the access mechanism.[14] The web handles this part very well since around 60 trillion pages indexed by Google can be reached without much more overhead it required to access 26 millions of pages when the company got started in 1998.[15]

Languages

Users

Known users of the Microservices architecture (alphabetically):

Implementations

See also

References

  1. ^ Martin Fowler. "Microservices".
  2. ^ Sam Newman. Building Microservices. ISBN 978-1-4919-5035-7.
  3. ^ Miller, Joseph B. (2014). Internet Technologies and Information Services. Library and Information Science Text Series (2 ed.). ABC-CLIO. p. 269. ISBN 9781610698863. Retrieved 2015-08-04. As with many complex information technologies, there are two general architectural options: a monolithic, layered system that embodies all the needed functionalities within one large-scale solution or a modular approach based on microservice architecture (MSA). [...] MSA is a more flexible, modular strategy.
  4. ^ Rodgers, Peter. "Service-Oriented Development on NetKernel- Patterns, Processes & Products to Reduce System Complexity". CloudComputingExpo. http://sys-contv.sys-con.com. Retrieved 19 August 2015. {{cite web}}: External link in |publisher= (help)
  5. ^ Russell, Perry; Rodgers, Peter; Sellman, Royston (2004). "Architecture and Design of an XML Application Platform". HP Technical Reports. p. 62. Retrieved 20 August 2015.
  6. ^ Hitchens, Ron (Dec 2014). Swaine, Michael (ed.). "Your Object Model Sucks". PragPub Magazine. Pragmatic Programmers: 15.
  7. ^ James Lewis and Martin Fowler. "Microservices".
  8. ^ Lucas Krause. Microservices: Patterns and Applications. ASIN B00VJ3NP4A.
  9. ^ Lucas Krause. "Philosophy of Microservices?".
  10. ^ Jim Bugwadia. "Microservices: Five Architectural Constraints".
  11. ^ Jan Stenberg (11 August 2014). "Experiences from Failing with Microservices".
  12. ^ a b c d e "Developing Microservices for PaaS with Spring and Cloud Foundry". Cite error: The named reference "infoqbook" was defined multiple times with different content (see the help page).
  13. ^ Robert Annett. "Where is the complexity?".
  14. ^ "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."
  15. ^ Zurb http://zurb.com/quips/705. {{cite web}}: Missing or empty |title= (help)
  16. ^ "Jolie".
  17. ^ "Vertx".
  18. ^ "AnyPresence Launches a New API Platform for Mobile and IoT Developers".
  19. ^ "How Enterprise PaaS can add Critical Value to Microservices".
  20. ^ Wilma documentation
  21. ^ Wilma source code
Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Microservices&oldid=677321563"