Microservices

from Wikipedia, the free encyclopedia

Micro Services are an architectural pattern of information technology , in which complex application software from independent processes is composed, among themselves with language-independent programming interfaces to communicate. The services are largely decoupled and do a small job. In this way they enable a modular structure of application software.

Philosophy and details

The idea behind microservices largely corresponds to that of the Unix philosophy (" Do One Thing and Do It Well ", loosely translated: " Do only one task and do it well"). The services should typically have the following properties:

  • The services can easily be replaced.
    • The scope of a microservice should be manageable for every team member.
    • A microservice should be able to be newly created and replaced by the responsible team (usually 5 to 7 developers) with a reasonable expenditure of time (e.g. within a month).
  • A microservice should implement a bounded context in terms of domain-driven design .
    • The services have a single business function. For example, they can include an order process, registration, or billing, but not more than one of these.
  • The focus is on the benefit for the user.
    • The core functionality should be delivered early in order to provide the earliest possible benefit.
    • Interfaces should, e.g. B. via human registries , be self-documenting. For example, Swagger for JSON-based REST services.
    • After a new version of the service has been provided, the old version of the endpoint must continue to be provided for a certain period of time.
  • A microservice is only developed by one team. The Conway law ensures that the architecture is also secured by organizational measures. A team can also be responsible for several related microservices.
    • Communication overhead and conflicts of interest between teams are avoided.
  • The interfaces hide implementation details.
    • It should not be apparent which architecture a service was implemented with. Standard methods with low overhead, such as REST , are preferably used.
    • Databases are not used by multiple services, but only ever by a single service. This also applies to access via views and stored procedures . Otherwise the architecture will be published via the database and transaction security, data integrity and versioning cannot be guaranteed.
  • Microservices are isolated from other services.
    • Each microservice can use a different programming language, database or a completely different technology stack .
    • Each microservice can be brought into production independently of other microservices. This facilitates a high degree of automation and enables continuous delivery .
    • Objects that occur in several bounded contexts are implemented separately in each service. For example, the same customer is represented in an authentication system, an ordering system, a logistics system and an accounting system in each case by different objects, since different requirements are placed on the objects.
    • Microservices are delivered in separate OS containers , virtual machines or servers . This secures the service against overloading the host system by another service.
  • Like all services, microservices must also be secure:

The size of a microservice is limited by the fact that the network communication between microservices can be resource-intensive and a separate deployment must be provided for each microservice.

Typical components of a microservice architecture

Microservices require a lot of infrastructure, which is implemented by independent services.

Load balancers are used to distribute the load of external HTTP requests from clients . Static content is delivered using a content delivery network .

The services responsible for the business requirements are supported by a number of platform or infrastructure services. These take on central tasks such as application and service monitoring , logging web services, operations databases , configuration management , encryption , authorization and authentication , as well as autoscaling , software distribution , A / B testing and fault injection testing (FIT). There are also central routing services that take care of the assignment of URLs to instances with the respective services.

In addition, there are services for data persistence , in particular caching , relational databases and NoSQL databases, as well as BLOB storage for any files.

Differentiation from SOA

Both SOA ( service-oriented architecture ) and microservices use services as architectural elements.

SOA uses services to integrate different applications. The services are combined through orchestration or choreography , and portals can provide a common user interface (UI) for all services.

Microservices structure an application through services. Each microservice can contain a user interface and implement business processes such as those found in SOA in the orchestration.

advantages

  • Because microservices can be distributed and developed independently of one another, teams can work independently of one another. This enables the scaling of agile development processes without creating a lot of communication and coordination effort.
  • Microservices are small. This keeps them clear and easy to develop. If necessary, they can be replaced by a new implementation with little to manageable effort.
  • Unwanted dependencies often creep into systems and at some point the original architecture is completely lost. The architecture of the microservices system remains stable because dependencies between microservices have to be introduced via the API. This is time-consuming and does not happen accidentally.
  • Because the microservices can be maintained and the architecture of the overall system is preserved, microservices also allow productive development of the system in the long term.
  • Microservices can be scaled independently of one another.
  • Microservice systems can be secured against the failure of other services so that the overall system is robust.
  • Continuous delivery is easier because of the size of the microservices.
  • Each microservice can be implemented with a different technology. This simplifies experiments with new technologies and prevents the technology stack from becoming obsolete.
  • Microservices can also be used to expand legacy systems without having to make too many changes to the old code base.
  • Once key services have been identified, non-critical services can be reduced or switched off in the event of an overload in order to free up resources for critical services.

disadvantage

Microservices have been criticized for a few characteristics:

  • The distributed architecture creates additional complexity, especially network latencies, load distribution or fault tolerance (see also: Fallacies of Distributed Computing ).
  • Since there are more systems that can fail than with monolithic services, the probability that at least one component will fail also increases. It should be noted that the failure of a microservice does not affect the entire system, which normally compensates for this disadvantage.
  • The variety of services makes software distribution and testing more complex.
  • The effort involved in migrating existing systems is considerable and, as a rule, also means adapting the communication culture in the organizations involved.
  • Logging and monitoring becomes more complex because several systems are involved, which may use different logging and monitoring technologies. Therefore, in addition to decentralized logging and monitoring solutions, central logging, monitoring and OpsDB services should be used.
  • Since this is a potentially globally distributed system, not only different time zones of the client applications, but also different time zones of the hosts have to be taken into account. Time synchronization between the hosts (e.g. using NTP or, even better, PTP ) and the use of suitable time libraries (e.g. Joda Time or Noda Time ) are therefore absolutely necessary.
  • Since microservices are a distributed architecture, based on the CAP theorem, a choice must be made between the availability of the application and the data consistency. On the other hand, however, a monolithic service is not always available in the event of an error, such as overload. In addition, no consistency can be guaranteed for data once it has been displayed to the user.
  • Since the services can be implemented in different programming languages ​​and software stacks, the requirements for development tools and platform management increase. In addition, the functionality of libraries has to be partially duplicated.

Examples

The following internet services are known to use microservices:

Implementations

Each microservice can be developed in a different programming language with a different technology. So the technology for the implementation of the individual microservices is nowhere near as important as the overarching technologies for integration and communication.

See also

Web links

literature

  • Eberhard Wolff: Microservice Architectures. July 28, 2015, accessed December 17, 2015 .
  • dotnetpro No. 4/2015, pp. 12–31
  • James Lewis, Martin Fowler: Microservices. March 25, 2014, accessed November 9, 2015 .
  • Sam Newman: Microservices: Concept and Design . mitp, 2015, ISBN 978-3-95845-081-3 (English: Building Microservices: Designing Fine-Grained Systems . 2015. Translated by Knut Lorenzen).
  • Christian Horsdal: Microservices in .NET . Manning Publications, 2016, ISBN 978-1-61729-337-5 .

Individual evidence

  1. ↑ Eberhard Wolff: Microservices: Basics of flexible software architectures , 2nd edition, ISBN 978-3-86490-555-1 .
  2. ↑ Sam Newman: Microservices: Concept and Design , ISBN 978-3-95845-081-3 .
  3. ↑ Microservices . In: In: Jens Fromm and Mike Weber, eds., 2016: ÖFIT Trend Show: Public Information Technology in the Digitized Society. Berlin: Competence Center Public IT. ISBN 978-3-9816025-2-4 .
  4. ^ Noah Sussman: Falsehoods programmers believe about time. In: Infinite Undo! Retrieved April 12, 2017 .
  5. ↑ Noah Sussman: More false hoods programmers believe about time; “Wisdom of the crowd” edition. In: Infinite Undo! Retrieved April 12, 2017 .
  6. ↑ a b c d Todd Hoff: Deep Lessons From Google And EBay On Building Ecosystems Of Microservices. In: High Scalability. December 1, 2015, accessed March 11, 2017 .
  7. ↑ Microservices at Amazon .
  8. ↑ Microservices at Netflix .
  9. ↑ Microservices at Guardian .
  10. ↑ Microservices at SoundCloud .
  11. ↑ Schedule Thursday (3rd Dec.) - conference .
  12. ↑ From Monolith to Microservices, Zalando's Journey .
  13. ↑ Guido Steinacker: From monoliths and microservices. In: Informatik Aktuell. June 2, 2015, accessed April 28, 2016 .
  14. ↑ Vertx .
  15. ↑ Eberhard Wolff: Das Microservices-Praxisbuch , ISBN 978-3-86490-526-1 .