A flexible testing framework for comparing service-based architectures

Abstract

Die Entwicklung Service-orientierter Architekturen (SOAs) wurde im vergangenen Jahrzehnt populär. Dabei wurden ganze Anwendungen in eine Reihe kleiner, lose gekoppelter Komponenten aufgeteilt, um eine einzelne spezielle Funktionalität über ein Netzwerk zur Verfügung zu stellen. In der Theorie besteht eine solche Architektur aus einem sogenannten Service provider, der diese Funktionen bereitstellt, einer Service registry, welche die Adresse des Providers kennt, sowie dem Service requestor, der die bereitgestellte Funktionen des Providers nutzt, nachdem die nötigen Informationen von der Registry abgerufen wurden [HS05]. In der Praxis wurde hingegen oft ein sogenannter Enterprise Service Bus (ESB) zur Integration diverser Services genutzt. Hierbei wird jedes verwendete Service mit einem zentralen Knoten - dem ESB - verbunden. Der ESB ist hierbei sowohl für die Weiterleitung eingehender Nachrichten an die richtigen Empfänger verantwortlich, als auch für die Umwandlung dieser in die korrekten Formate, um vom Kommunikationspartner weiter verarbeitet werden zu können. In Folge sinkt die Abhängigkeit verschiedener Dienste voneinander - Adresse, Protokoll, Formate, oder ähnliches sind für den Austausch zwischen Komponenten nicht notwendig [PTDL07, Men07]. Im Gegensatz dazu entstand in den letzten Jahren ein neuer Ansatz zur Entwicklung verteilter Systeme namens Microservices [Thö15]. Wie der Name vermuten lässt, handelt es sich hierbei um sehr kleine Services, welche untereinander kommunizieren und beispielsweise nur eine einzelne Aufgabe erfüllen. Neben der kleineren Größe und dem einzigen Zweck findet - anders als beim ESB - der Nachrichtenaustausch untereinander direkt statt. Wie bereits erwähnt ist beim Senden eines Requests nur die Adresse des ESBs bekannt, der letztendlich für die gesamte Übermittlung zum korrekten Empfänger verantwortlich ist. Im Gegensatz dazu weiß ein Microservice genau, wie und mit welchen anderen Diensten es kommunizieren muss, um die jeweiligen Aufgaben durchführen zu können, was von Martin Fowler und James Lewis als 'smart endpoints and dump pipes' bezeichnet wurde [FL14]. Aufgrund der zuvor erwähnten konträren Wege, wie diese Architekturen aufgebaut sind bzw. arbeiten, werden Unterschiede in deren Leistung erwartet. Das Ziel dieser Arbeit ist die Implementierung einer Testumgebung um diese Unterschiede messen zu können. Zusätzlich werden Gemeinsamkeiten und Unterschiede analysiert und diskutiert

In the last decade, Service-Oriented Architectures (SOA) became popular. Applications were splitted into loosely coupled components that have been made available over a network to provide some specific kind of processing functionality. In theory, this architecture consists of a Service provider that offers some functionality, a Service registry that knows the address of the provider and a Service requestor that learns about the provider by the registry and uses the provided functionality [HS05]. However, in practice a so called Enterprise Service Bus (ESB) was often used to integrate various services. Using an ESB, each service is connected to a central node called ESB. The ESB is responsible to route incoming messages to the correct recipients and to transform the data so that it can be understood by the target service. As a result, services depend even less on each other since they don¿t have to know the address, protocol or message format how to interact [PTDL07, Men07]. However, a rather new approach for building distributed applications are the so called Microservices [Thö15]. As the name implies, communicating services are very small, e.g., they perform just a single task. Besides the restriction to a smaller scope and to just one purpose, probably the main difference to ESBs is the communication to other services. As already mentioned, when using an ESB and requesting a resource, the sender only knows the address of the ESB, which is responsible for forwarding it to the right destination. However, in a Microservice architecture, a service knows the address of every other service it is communicating with. Martin Fowler and James Lewis denoted this characteristics ¿smart endpoints and dumb pipes¿ in contrast to ESBs [FL14]. Due to the difference how these previously mentioned architectural styles communicate and are built, performance differences are expected. The aim of this work is to implement a testing framework in order to evaluate these expected differences. Additionally, based on an evaluation, commonalities and differences will be analyzed and discussed in this thesis.