DEV Community

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

 
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).