Don't Use REST for Your Micro-Services(blog.moodio.co.uk)
blog.moodio.co.uk
Don't Use REST for Your Micro-Services
https://blog.moodio.co.uk/dont-use-rest-for-microservices/
1 comments
I think the issue is the definition of a microservice isn't really set, while those are good candidates for microservices, you can even design them for core functionalities, such as for example in some challenger banks, i've seen the architecture of one or two who would have a service for different functionalities,such as one for card transactions, one for dealing with the account balances, etc.
But in my experience atleast, one of the biggest issues with microservices is the speed impact. Even a difference of 100ms on a consumer facing application can be an issue. 200ms is a noticable delay, and if something is 1 second slower users will actually get pretty frustrated. As for speed, the difference in speed can be massive, and JSON serialization/deserialization (the way it is commonly implemented atleast) is very compute heavy especially if it relies on reflection. So the speed difference can sometimes be 5-10x and in microservices is a bigger concern then network latency. When you're dealing with larger dataset this becomes even more obvious.
Using gRPC for example, instead of JSON, the difference can be a couple of hundred milliseconds, which changes the conversation entirely on whether or not splitting it into a microservice is worth while and if the end user will notice the impact.
But in my experience atleast, one of the biggest issues with microservices is the speed impact. Even a difference of 100ms on a consumer facing application can be an issue. 200ms is a noticable delay, and if something is 1 second slower users will actually get pretty frustrated. As for speed, the difference in speed can be massive, and JSON serialization/deserialization (the way it is commonly implemented atleast) is very compute heavy especially if it relies on reflection. So the speed difference can sometimes be 5-10x and in microservices is a bigger concern then network latency. When you're dealing with larger dataset this becomes even more obvious.
Using gRPC for example, instead of JSON, the difference can be a couple of hundred milliseconds, which changes the conversation entirely on whether or not splitting it into a microservice is worth while and if the end user will notice the impact.
I agree, but gRPC has its own set of issues.
It all boils down to the boring, but real dilemma of finding the least bad solution ;-)
See also: https://www.google.com/search?rls=en&q=cap%27n+proto+vs+grpc...
It all boils down to the boring, but real dilemma of finding the least bad solution ;-)
See also: https://www.google.com/search?rls=en&q=cap%27n+proto+vs+grpc...
A microservice should be a self-contained, understandable and on-its-own usable component.
For example, a service which resolves zip codes to cities is a microservice by this definition.
Another example: a service which generates PDFs from URLs by rendering them in a browser like chrome-headless.
Another example: a service which gathers statistics from a git repository.
A microservice, from my POV, is not:
- something you use in tight loops
- something which provides only an abstract value, like for example a aggregation of min/max/avg/median values of a list
- something which either doesn't deliver a value of non-trivial complexity nor is useful to the general public on its own
In other words, if the choice of protocol (in this case REST) matters in terms of speed, you shouldn't talk about a microservice but more of a component. This may be a component communicating using TCP, or whatever protocol you choose. But I'd call something like that not a microservice, but a component. In most languages you'd use a "library", a "jar" or something of this scale.
Terminology matters (at least to me in this regard :) )