| dc.description.abstract | The microservice pattern is a new alternative to architecting back-end systems. Instead of building large, monolithic systems that lead to issues related to scalability, maintainability and extensibility, systems are built as a set of small, independent services -- microservices. Even though these services operate independently to a certain degree, there is often communication between them. Going from a monolithic system to a distributed system, the networking communication becomes a challenge.
Representational State Transfer (REST) is a commonly used architectural pattern for designing service interfaces. While REST promotes generalization of endpoints through uniform interface, this leads to more overhead when transferring documents. This thesis discuss issues of REST and discusses them in context of microservices through a literature review. Some of the discussed issues relates to how concepts under REST should be approached where much discussion relates to how the linking between representations should be approached. There are also other issues relating to service discovery, transactions, security, and reliability.
HTTP is often being used as a fundamental transfer protocol to implement a system following the REST architectural pattern. Other protocols have been explored in this thesis to determine their behavior in a microservice architecture. HTTP/1.1, HTTP/2 without encryption, and Constrained Application Protocol (CoAP) were tested under different latencies (0ms, 5ms, 10ms) as the messaging protocol between microservices in the AcmeAir benchmarking system. Results show that HTTP-\slash 1.1 was able to provide higher throughput compared to HTTP/2, whereas CoAP had a lower request throughput under all latencies. The differences in the latencies did, however, even out between the protocols under higher latencies. Considering bandwidth, HTTP/2 used least bandwidth followed by CoAP and HTTP/1.1. Some of the behavior of the CoAP protocol can be explained by framework limitations. This has resulted in contributions to the Californium Java CoAP framework by avoiding thread creation during request processing and introducing asynchronous APIs in the framework for HTTP messaging. Furthermore, CoAP required some request headers to be implemented as they were not present in the framework or the protocol. It is argued this leads to higher coupling compared to the other protocols. | |
