CODEWITHSUNDEEP
performancehttpmicroservicesamqplatency
Vladimir Nabokov
Vladimir Nabokov

Reputation: 1907

Microservices and low latency transport

I know only two popular transport protocols in micro-services world: REST/HTTP and AMQP.

And I sense two problems with that:

1) Do not you think they are pretty slow? If you disagree with that claim (yes, yes, I have no benchmark about AMQP, although HTTP is widely considered as a slow one, you can find in internet articles without my help), then I can tell you that with a scarce choice of 2 you always can imagine a lot of faster protocols are not represented. 2 is a very small number, meaning, in practice - no choice.

2) HTTP looks like not intended to be a server-to-server protocol, but widely used in this role.

What you think about that and can you suggest some alternative (supported by frameworks, I mean something that I do not need write from scratch myself)?

Upvotes: 0

Views: 2112

Answers (2)

Aydin Homay
Aydin Homay

Reputation: 325

First, please isolate architectural topics from implementational topics. One side is architecture and the other side is implementation. Microservices Architecture is talking about a new paradigm in SOA. Now in the implementation phase, you can use several protocols to implement your microservice size service. You can use UDP, TCP, HTTP, etc. The HTTP protocol used widely in microservices where there are certain concerns like statelessness, this does not necessarily mean that all microservices in implementation phase need to use HTTP. They may/could use HTTP or any other transport protocols like UDP, or even CoAP.

Following are a set of articles that published about microservices in code-project, you can read and comment on your questions if you like.

https://www.codeproject.com/Articles/1264113/Dive-into-Microservices-Architecture-Part-I

https://www.codeproject.com/Articles/1264113/Dive-into-Microservices-Architecture-Part-II

https://www.codeproject.com/Articles/1264113/Dive-into-Microservices-Architecture-Part-III

Upvotes: 1

Oswin Noetzelmann
Oswin Noetzelmann

Reputation: 9555

It all depends on your domain scenario, its requirements and how much you can invest into the development for a lower latency, smaller bandwidth, etc.

Today there is a whole spectrum of options for server communication. Https just happens to be the most common one and good enough for a lot of applications.

Given you have both ends of the communication under control, nothing prevents you from investing more effort and building your own binary protocol based on a UDP socket or go even lower in the OSI layers. For example Google is using QUIC and has proposed to make it a successor to http/2. So http/3 may actually become a lot more efficient.

Or you can try to implement existing standards that are more optimized for latency and even real time applications. One example from the industrial domain is profinet.

A lot of times the payloads are what creates slow connections though. JSON is a great example for a format that takes a lot of time to de-/serialize in large quantities. And to improve that you can use a different transport format, for example flat buffers (another google invention) from the gaming domain.

In general if you do some research about how networking is done in gaming you will find a lot interesting technologies.

Upvotes: 3

Related Questions