Restless Microservices: Part 1

Atharva Chauthaiwale 7:37 PM No comments
Over the last few years, REST has been a de-facto standard for building platform independent web services. REST along with JSON provides a lightweight protocol for building web services which can be seamlessly consumed by browser, mobile applications and desktop clients. Whether it is a web service exposed to customer or a backend service, REST is the preferred choice of application developers. However, with the advent of microservices architecture, there are a new set of challenges in the inter-microservices communication. REST can still be the best option when we want to expose APIs to customers. However, when we have dozens of independent microservices communicating with each other, is REST/JSON the most efficient protocol for exchanging messages across services running in the same context, same network, and possibly the same machine? Are there any alternative protocols/frameworks available ? Are these options being used at very high scale by giants like Google, Facebook , Twitter and LinkedIn etc?

In this series of blog posts, we will try to answer the above questions. We will discuss and evaluate different alternative frameworks developed and/or used by internet giants Facebook, Google Twitter and Amazon .Part 1 covers the motivation behind not using REST and gives a short summary of the different alternatives such as RPC , Asynchronous Message broker communication, Serverless microservices etc. In the upcoming blog posts, we will in detail, evaluate microservices frameworks developed and open sourced by Facebook, Twitter and Google etc.

Why RESTless

Although, REST/JSON provides a very lightweight protocol for communication, following factors motivated software industry to find better alternatives for microservices.

a] Lack of schema

In microservices environment, number of services can grow rapidly with each exposing multiple APIs. Lack of schema in REST/JSON poses a big integration challenge in this case. In such environment, it is a good idea to maintain a well-defined interface for every call. Interface Definition Language ( IDL ) such as Thrift or Protobuff forces service owners to publish strict interface definitions, which streamlines the process of integrating with services. IDL based frameworks provide built-in schema validation which is another plus point over REST.

b] REST modeling can be unwieldy sometimes

Sometimes it is difficult or unwieldy to map certain APIs to the REST model of Resources and methods. In other cases the mapping may require client to make several serial calls, hurting performance in the datacenter.

c] Binary protocols are more efficient than JSON

There is a performance impact due to cost of serializing objects to a large JSON string. Keeping data in binary both in memory and on the wire by building eliminates cpu and memory required for string encoding schemes such as Base64 or JSON. In monolithic architecture this overhead was negligible as we had to perform this serialization only a few times. With dozens of microservices talking to each other, this overhead can be significant.

d] Advent of HTTP2

HTTP2 protocol was published in 2015 and still in the phase of early adaption by browsers and application servers. Following new features added in HTTP2 proves to be very suitable for microservices.
  • Binary protocols: At the core of all performance enhancements of HTTP/2 is the new binary framing layer(, which dictates how the HTTP messages are encapsulated and transferred between the client and server.All the HTTP semantics, such as verbs, methods, and headers remain same, but the way they are encoded while in transit is what’s different. Unlike the newline delimited plaintext HTTP/1.x protocol, all HTTP/2 communication is split into smaller messages and frames, each of which is encoded in binary format. 
  • Bidirectional streaming and multiplexing: In HTTP/1.x, if the client wants to make multiple parallel requests to improve performance, then multiple TCP connections must be used. The new binary framing layer in HTTP/2 removes these limitations, and enables full request and response multiplexing. Using this feature multiple requests and responses can be interleaved without blocking on anyone. 
  • Server Push : Another powerful new feature of HTTP/2 is the ability of the server to send multiple responses for a single client request. This means, in addition to the response to the original request, the server can push additional resources to the client without the client having to request each one explicitly! 
All the above limitations of REST/JSON force us to look for better alternatives for microservices communication. So, Let's explore the different alternatives available.

Alternatives

Over the past few years, many new approaches/frameworks built to mitigate the problems of REST discussed in the previous section. Some of the popular ones are listed below. These approaches/frameworks are used by many internet giants for developing highly scalable services. 

a] RPC frameworks

RPC stands for "remote procedure call". The concept of RPC is not new . However with the advent of HTTP2 and new binary protocols, some promising frameworks have come up which provide better performance over REST. Some of the more popular open source frameworks are Thrift ( Facebook), GRPC ( Google ), Spring RPC, Finagle ( Twitter).
 

b] Async Messaging ( AMQP , task queues)

For microservices architecture, Asynchronous messaging with tasks queues can be a very good alternative. Especially, when we have chain of calls ( MS1 -> MS2 -> MS3 ) among microservices, async messaging provides better decoupling. This approach also avoids the HTTP issues like timeout, connection reset, load balancing etc. 

c] Extended/Improved REST framework

In spite of some limitations, many people are not willing to abandon the REST completely. So, they came up with some extended / improved version of REST. Rest.li from LinkedIn and Netflix Ribbon are some of the examples where they tried to improve REST by adding features like type safety, client side load balancing etc. 

d] Server less architecture ( FaaS )

Serverless architecture or Function as a Service, is becoming a very popular alternative for building scalable microservices. The idea is to trigger a Function ( Code ) based on the event such as file upload, notification etc. Cloud providers like Amazon ( Lambda ), Microsoft ( Azure functions )  provide FaaS where we just need to upload the code and define the event to trigger the code. Rest of the server management, scaling etc is taken care by providers. 

Conclusion

After discussing so many approaches, the million dollar question is which one is the best ? As usual the answer is, it depends on the use case, application and scale requirements. Even internet giants like FB, LinkedIn have different experiences and opinions. FB/Google developed their own RPC frameworks, while LinkedIn started with RPC but later abandoned it to chose REST [3]. In the upcoming posts of this blog series, we will try to evaluate these options with the hope that we will be able to make an informed choice. So stay tuned !
References

[1] HTTP2: https://hpbn.co/http2/

[2] Protocol Buffers vs JSON : http://blog.codeclimate.com/blog/2014/06/05/choose-protocol-buffers/

[3] REST vs JSON : https://www.linkedin.com/pulse/rest-vs-rpc-soa-showdown-joshua-hartman

No comments :

Post a Comment

Subscribe to: Post Comments ( Atom )

Subscribe