Developing the Guidelines for Migration from Restful Microservices to Grpc
Total Page:16
File Type:pdf, Size:1020Kb
Masaryk University Faculty of Informatics Developing the guidelines for migration from RESTful microservices to gRPC Master’s Thesis Michal Štefanič Brno, Spring 2021 Masaryk University Faculty of Informatics Developing the guidelines for migration from RESTful microservices to gRPC Master’s Thesis Michal Štefanič Brno, Spring 2021 This is where a copy of the official signed thesis assignment and a copy ofthe Statement of an Author is located in the printed version of the document. Declaration Hereby I declare that this paper is my original authorial work, which I have worked out on my own. All sources, references, and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Michal Štefanič Advisor: RNDr. Josef Spurný i Acknowledgements I would like to thank my advisors, RNDr. Josef Spurný for his time and valuable consultations, and doc. Mouzhi Ge, Ph.D. who left the university, but still found a time for thesis consultations. I would also like to thank the colleagues from Kiwi.com, especially Matouš Dziviak with whom I consulted a lot of technical questions related to the thesis. And Tomáš Gerich for proofreading the thesis. ii Abstract With the rising popularity of microservice architecture, Google de- cided to revive the "Remote procedure call" (RPC) concept to facili- tate effective communication between single services and developed their own framework (gRPC) for RPC service communication. gRPC became quickly popular and many famous companies as Netflix, Mi- crosoft, Slack integrated it into their systems. However, there is not a clear, step-by-step guide on when and how to migrate your services to gRPC architecture. Therefore, the goal of this thesis is to explain differences between RESTful and gRPC concepts, detect when itis effective to migrate to gRPC, and describe migration procedure in single steps without affecting business logic. For validation of the proposed guidelines, the thesis applies the gRPC architecture to one well-known online travel agency Kiwi.com, by migrating some of their microservices to gRPC with the proposed guidelines. iii Keywords gRPC, microservices, REST, API, migration, guidelines, ... iv Contents 1 Introduction 1 Introduction 1 2 Background 4 2.1 Microservices . .4 2.1.1 Monolith vs microservices . .4 2.1.2 Core microservices components . .6 2.2 Containerization . .7 2.2.1 Docker . .8 2.2.2 Kubernetes . 10 2.3 HTTP . 10 2.3.1 HTTP vs HTTPs . 11 2.3.2 HTTP/1.1 vs HTTP/2 . 12 2.4 REST API . 13 2.4.1 Usage of REST APIs . 13 2.4.2 Stateless character of the REST architecture . 14 2.4.3 The client-server architecture . 14 2.4.4 REST vs SOAP . 15 2.4.5 REST API challenges . 17 2.5 gRPC as RPC framework . 19 2.5.1 Remote Procedure call . 19 2.5.2 gRPC . 20 2.5.3 Protocol buffers . 21 2.5.4 gRPC communication . 23 2.5.5 RPC types in gRPC . 23 2.6 Technical migrations . 24 2.6.1 Migration from the monolith to the microservices 25 2.6.2 Migration from SOAP to REST . 26 2.6.3 Key concepts of these migrations . 28 3 Decision process and migration guidelines 30 3.1 Decision process . 30 3.1.1 Benefits of gRPC . 30 3.1.2 Downsides of the gRPC . 34 3.1.3 gRPC vs REST . 37 v 3.1.4 Optimal architecture . 39 3.1.5 When to migrate . 41 3.2 How to migrate . 44 3.2.1 Key concepts . 44 3.2.2 Protocol buffers management . 47 3.2.3 Protocol buffers best practices . 49 3.2.4 HTTP/JSON gateway . 52 3.2.5 Define API endpoints . 53 3.2.6 Interceptors . 54 3.2.7 Error handling . 54 3.2.8 Authentication . 55 3.2.9 Testing . 55 3.2.10 Deadlines and retries . 56 3.2.11 Load balancing . 56 3.2.12 Monitoring . 59 3.2.13 Summary . 59 4 Case study in Kiwi.com 60 4.1 Kiwi.com . 60 4.2 Architecture . 60 4.3 Decision process . 61 4.3.1 Optimal architecture . 61 4.3.2 API contract . 62 4.3.3 Performance boost . 62 4.3.4 Drawbacks . 63 4.3.5 Decision . 63 4.4 Migration process . 64 4.4.1 Proto buffers structure . 64 4.4.2 Proto buffers linter . 66 4.4.3 gRPC gateway . 66 4.4.4 Error handling . 67 4.4.5 Authentication . 67 4.4.6 Load balancing . 67 4.4.7 Monitoring . 68 4.5 Experience report . 68 4.5.1 What went well . 69 4.5.2 What went wrong . 70 4.5.3 What is next . 70 vi 5 Conclusion 72 Bibliography 74 vii List of Tables 2.1 Table of references linked to concepts they describe. 29 3.1 gRPC and REST comparison 38 viii List of Figures 2.1 Monolithic vs microservices architecture. 5 2.2 Docker components. 9 2.3 HTTP vs HTTPs 11 2.4 REST vs SOAP. 16 2.5 RPC mechanism. 19 2.6 Simple gRPC message defined in proto language 21 2.7 Simple gRPC service defined in proto language 22 2.8 Steps for migration from SOAP to REST. 27 2.9 Mapping between SOAP-based operations and resources to HTTP methods. 28 3.1 Microservices architecture with gRPC. 40 3.2 Enum example in proto language 50 3.3 Deprecation of the field in proto language 50 3.4 grpc-gateway demonstration. 52 3.5 grpc-gateway proto example 53 3.6 Look-aside load balancing. 58 4.1 Proto repository structure. 65 4.2 gRPC metrics of one anonymized service 68 4.3 gRPC(blue) vs HTTP(red) execution time comparison 69 ix 1 Introduction Microservices architecture pattern is becoming one of the leading architectural styles for modern applications, and there is a fair as- sumption it will be the first choice for the design of many applications in upcoming years. There are several reasons for it, such as support for agile development, the architecture that allows businesses to develop and deploy new services and features faster, in a small iteration with short lead time, but at the same time ensure high system’s scalability, reliability, and security. These advantages are being more and more important especially in the upcoming post-covid engineering world, when location-agnostic remote work and team’s decentralization are being accelerated. The best approach for running microservices architecture is the containerization of applications. Containers encapsulate the whole application together with its lightweight runtime environment and present it as a consistent software environment that allows you to run the application consistently everywhere - from the developer’s machine, through the testing environment, to production deployment. Containers can run on on-premise physical machines and at the same time virtual cloud machines, while using their full potential with- out wasting resources, which give us both - economic benefits for companies and environmental and ecology benefits for the world. While containerized microservices are becoming a very popular architectural pattern, the standard of how single services communicate and share information with each other did not change much and is usually handled with REST APIs over HTTP/JSON messages. Despite the fact that REST endpoints are a perfect solution for communication and data transfer, there are several issues with them. One of the main problems is that the REST does not have strictly required standards. Standardization is an optional, defined via best practices agreed bythe community, but at the same time, implementation and maintenance of REST API endpoints is usually non-trivial task. In practice, many APIs that are referred to as REST, do not meet RESTful standards. And even when API follows RESTful standards at the beginning, they often being 1 1. Introduction abandoned after some time of production iterative development. There is another alternative way how to handle communication between services. Alternative for the REST and HTTP/JSON communication are Re- mote Procedure Calls (RPC). RPC is not a new mechanism and was described many years ago, but the previous RPC solutions as SOAP or CORBA disappeared from modern application and were replaced by HTTP/JSON. However, in 2005 Google introduced open-source RPC framework called gRPC [1] that resolves most of the issues of its predecessors. gRPC provides high-performance RPC solution that can run in a variety of environments and is supported by the majority of popular programming languages. gRPC uses protocol buffers for data and RPC service definition. Messages are transferred over HTTP/2 protocol only. It secures faster data serialization, more strict API con- tract, and overall performance boost while maintaining steady and persistent connections between services. In addition, gRPC supports multiple types of streaming mechanisms. The goal of this thesis is to address the downsides of REST APIs, introduce the gRPC technology, and compare the advantages and disadvantages of both options for microservices communication. The next goal is to define a decision process that helps engineers to decide when it is efficient to think about gRPC as an alternative to REST and propose high-level guidelines on how to migrate REST microservices to gRPC. The proposed decision process and guidelines will be used for a case study to integrate gRPC in a popular online travel agency based in Brno, called Kiwi.com. The thesis begins with a chapter describing all necessary methodol- ogy and theory needed for understanding a given topic. It describes concepts of microservices and containerization and why it become so popular, goes over REST and problems of REST development, in- troduces gRPC and its basic concepts, and mentions two examples of technical migrations.