Thanks for the article. One question: do you think inter-service call should also done through the API gateway? For example, should the Ruby service call the Golang service via the gateway in this case?
Great question Bobby. There are no hard and fast rules. It is a matter of choice if you want any of the functionalities from your api gateway or not.
For instance, for services that aren't exposed to the outside world, the authentication/security can be done either at the application layer or at the network layer or both. We are good with the security at the network layer and as a result, we don't route the inter-service calls through our api gateway as of now. (We use kong)
Having said that, let's say, if we need metrics for inter-service calls going forward, we might rethink about this and route the inter-service calls through Kong.
One microservice should not call another microservice. This introduces coupling and is worse than the monolith – actually it creates a distributed monolith. Instead the services should use publish/subscribe event log to exchange data.
So do you mean in such systems there would no longer be a request-response communication model between the services? I am currently having a hard time imagining such kind of systems (especially for customer-facing SaaS apps), but it might just be because I haven't seen it yet.
Yes. The most important property of a well designed distributed architecture is that individual services are operationally completely independent of each other. That is if one service goes down the rest will continue to function and the system stays available. When services query each other monolith’s coupling is still there with the added ‘benefit’ of distribution faults. Why not stay with the monolith in first place?
For an infra composed of hundreds of very chatty microservices, most of which are interdependent, and where RMQ cannot handle the traffic, what do you recommend for handling eventing? We're using Kafka now, but curious for your thoughts.
Thanks for the article. One question: do you think inter-service call should also done through the API gateway? For example, should the Ruby service call the Golang service via the gateway in this case?
Great question Bobby. There are no hard and fast rules. It is a matter of choice if you want any of the functionalities from your api gateway or not.
For instance, for services that aren't exposed to the outside world, the authentication/security can be done either at the application layer or at the network layer or both. We are good with the security at the network layer and as a result, we don't route the inter-service calls through our api gateway as of now. (We use kong)
Having said that, let's say, if we need metrics for inter-service calls going forward, we might rethink about this and route the inter-service calls through Kong.
One microservice should not call another microservice. This introduces coupling and is worse than the monolith – actually it creates a distributed monolith. Instead the services should use publish/subscribe event log to exchange data.
So do you mean in such systems there would no longer be a request-response communication model between the services? I am currently having a hard time imagining such kind of systems (especially for customer-facing SaaS apps), but it might just be because I haven't seen it yet.
Yes. The most important property of a well designed distributed architecture is that individual services are operationally completely independent of each other. That is if one service goes down the rest will continue to function and the system stays available. When services query each other monolith’s coupling is still there with the added ‘benefit’ of distribution faults. Why not stay with the monolith in first place?
For an infra composed of hundreds of very chatty microservices, most of which are interdependent, and where RMQ cannot handle the traffic, what do you recommend for handling eventing? We're using Kafka now, but curious for your thoughts.
We use Kafka too. For not so overwhelming loads and Ruby based services I would consider Eventide with PostgreSQL store.