DEV Community

Discussion on: Microservices communications. Why you should switch to message queues.

Collapse
 
orubel profile image
Owen Rubel

In security you didn't even discuss security (CORS, Tokens, 2FA) and REST IS ASYNC by default. There are so many things wrong with this article I don't even know where to begin.

Collapse
 
matteojoliveau profile image
Matteo Joliveau

In order:

  • CORS don't apply here since we are not in a browser. We are talking about microservices talking to each other.
  • there are many ways to authenticate microservices with each other. Tokens are one way, however since we have a middleman between services (the message broker) which already requires them to authenticate, you can trust messages you receive (to some degrees).
  • what does 2FA even have to do with microservices? We are not talking about users authenticating with an application, this article is about inter-service communications.
  • REST is NOT async, as it's just a pattern built on top of HTTP which is synchronous (you open a connection, you send a request, you wait for a response, you close the connection). The fact that languages like JavaScript allow you to perform request asynchronously doesn't mean that the protocol itself is asynchronous. Otherwise everything could be considered async.

If you have specific points you wanna discuss, possibly with some real arguments to back them up, I'd be more than happy to do so. Otherwise please refrain from submitting such pointless comments again.

Collapse
 
orubel profile image
Owen Rubel • Edited

I was just throwing CORS, 2FA out as examples. API's use LOTS of security and authorization. And that is implemented on the backend.

If you are saying AMQP is better than HTTP then you are saying it is a replacement for HTTP based API's.

So, how are you going to implement alot of the protocols that you will need to implement LIKE CORS, 2FA, Authorization? :)

Fill in the gaps that you want to replace. Thats a huge gap you don't have solutions for.

... and yes, REST API's can be async. Check it out sometime.

Thread Thread
 
matteojoliveau profile image
Matteo Joliveau

I already answered to all of you points and I'm starting to believe you are not interested in having a fair, healthy discussion but to just start some flame.
As I already stated, this article is about inter-service communications, not public facing APIs to be consumed by a user. So you don't have CORS, you don't have 2FA and you don't need microservices to authenticate with each other directly because this stuff simply doesn't apply in this context.
I really don't see where you're going with this discussion.

And again no, REST is not async on its own as I already said. You can use asynchronously, you can do funny stuff with webhooks and Websockets to make it behave like an async process, but REST itself does not provide any primitive for async message passing. And just saying "check it out sometime" without actually explaining your self or linking some resources says a lot about your way of managing discussions.
Now if you have some actual constructive feedback to give please be my guest, otherwise I will not continue with this pointless conversation

Thread Thread
 
orubel profile image
Owen Rubel

You haven't answered anything. You dodge. You merely state 'this is not an api' but neglect to answer how AMQO provides equivalent services to what HTTP provides

Thread Thread
 
dkbrummitt profile image
Delicia Brummitt • Edited

Hi Mateo,
Great article. Addressing the security aspect for any future readers exploring messaging for their Microservice architecture.

About REST

  1. REST is an architectural pattern that is by convention used over HTTP but does not have to be over HTTP.
  2. A RESTful Web API is an API over HTTP that follows the REST architectural pattern.
  3. In theory, you could have a RESTful SOAP (but OMG why would you do that to yourself???). Here is an example of a RESTful UDP RFC coap.technology/

About Security

  1. IMO it is probably best practice to secure your Microservice even when communicating with other microservices. Why? The safest possible stance is to assume that incoming data is harmful; so you authenticate, authorize, and scan for an attack.
  2. Do most microservices do this? I don't know. But I would be willing to bet that any multi-billion dollar company that deals in personal identifiable information(PII) or financial data does. If they didn't I would avoid them like the plague.
  3. How to do it? Here are a few ways:
    • some type of firewall and/or ACL combined with
    • place some services on the private network (no access to public network)
    • entire message is encrypted with a shared secret between the services. Each service has its own unique secret.
    • single-use, short-lived token used in headers or a part of the body. (usually when there is money involved, credit cards etc)
    • signed certificates (with passwords)
  4. Would I secure every microservice? Probably not.
  5. When would I definitely secure a micros service? Any service that touches PII/financial data, OR tangentially touches PII/financial data. For example:
    • Service A deals with credit cards (secure it).
    • Service B talks to Service A (secure it).
    • Service C does not talk to Service A nor Service B (may not secure it).
    • Service E talks to Service B but not Service A (secure it)
    • so on and so forth.

Can this approach lead to a slower microservice? Yes, but there are occasions where security is more important than latency.

NOTES:
- The methods discussed above are top of mind solutions and not specific to any type of transport(HTTP, AMQP, SQS, etc) between microservices...
- Google "defense in depth microservices" for more info on item 5 of About Security.
- Checkout what OWASP has to say about security.

Lastly, I love using messaging for my microservices. Especially where high volume is a concern.

Happy Coding!!

Thread Thread
 
matteojoliveau profile image
Matteo Joliveau

Very good points. In light of the main topic (AMQP-based microservices), advanced brokers like Rabbit do have ACL systems that can and should be used to restrict what each service can do. Maybe you have a topic where sensible data are exchanged and only some services can access them, with Rabbit you can set up ACL rules to block read access to those topics.

Or even segregate them on their own virtual hosts (kinda like namespaces or tenants) so that they are completely separated. Services don't need to know that this kind of access control is happening, it's enforced by the broker itself (which I prefere compared to security-aware microservices).

Collapse
 
zir093 profile image
Muntazir Fadhel

To add to this, the fact that message queues are natively based on asynchronous protocols allow them to be more efficient and scalable. Sure you might be able to implement async patterns over HTTP, but the cost of setting creating the TCP connection and negotiating SSL/TLS for every request creates significant overhead on your system.

I also feel like the word async gets misunderstood so often because it can take on different meanings depending on the context when discussing microservices. For those who are interested, I've tried to outline some of these different meanings here.