Best Practices for Internal service to service communication?

[#1]

Situation

• Break up a monolith JSP web application into modular architecture and eventually into micro-services over the course of 2 years.
• Going with completely decoupled microservices initially is not an option because of budget / time constraints and business risks.
• Apigee edge in cloud is used to expose limited functionality to third parties today.
• Internal service communication is largely point to point.
• Rabbit MQ was introduced lately for some queuing and notifications functionality.

Future state.

• Angular based frontend talking to APIs hosted in Apigee in addition to serving APIs to third party
• Apigee will be on-premisis.
• The backend (Java) will be slowly decomposed into microservices over time.
• Internal service to service communications needs to be asynchronous in some case and also may be event driven.
• Low latency is important in internal service communication.

Question

• What's the best practices/options for internal services to service communication and how does Apigee fit in. Should Rabbit MQ or another broker/esb be used for internal service communication and limit Apigee to serve APIs to angulari client and other third parties?

[rmishra · Accepted solution]

There are very few absolute best practices and most practices are highly contextual, but here are some aspects to consider :

1. Explore if differentiating pure internal traffic (operating in the intranet) vs external traffic (traffic coming from the internet) is helpful. Configure internal traffic to bypass some non functional policies(such as threat protection) . The overhead/latency Apigee adds on your traffic is upto you.You can implement this distinction in many ways(hint: Separate question)
2. Expose AMQP/Rabbit MQ Brokers over HTTP. This simplifies client adoption of Async behavior - clients do not have to bind to AMQP/Rabbit MQ Clients, they can bind to HTTP
3. Financial considerations aside, I always prefer to route all the traffic through Apigee. Having a single gateway for internal and external API's is really useful (for many reasons). But sometimes, it may be an uphill task to keep financial considerations aside.
4. Despite the flavor of Event Driven Architecture you choose, expose your integrations as HTTP endpoints and route them through Apigee.
5. If and when Apigee adopts HTTP/2, GRPC with protobuf, the latency of API's should begin to reduce even further
6. Don't overthink latency, or if you are thinking latency , run a performance test with and without Apigee in the stack. Look at the difference of your numbers and determine if it's worth bypassing/ignoring Apigee Edge.

Apigee Edge is an API Gateway, modeling your platform interactions over HTTP is highly recommended.

[#3]

Thanks so much for the pointers.