​How do you manage communications between microservices in your environments?

[#1]

For decades we have broken the implementation of larger applications up into components. A hot topic at the moment is the creation of independently-deployable components that communicate via network protocols, most commonly HTTP—so-called "microservices". If two components are communicating via HTTP, you have two options. The first is to link them directly via TCP. The second is to broker the connection through an API gateway. If you broker the communication through a gateway, you will pay a performance penalty, but in return you will get API management functions such as logging and metrics for message traffic, security checks, traffic control and so on. If you allow them to connect directly, it will be more efficient, but it will be more difficult to get visibility into message traffic or to affect it.

What do you do in your environments? If you have not yet deployed microservices, what do you think you will do? Do you value the function that API gateways bring to microservices, or do you prefer "raw" TCP communication between components?

[#2]

While raw TCP could possibly be more efficient in terms of latency, adding in the overhead of designing, implementing, and maintaining a secure custom TCP protocol you are at least an order of magnitude less efficient. Ultimately "raw" still means designing things like handshakes and other insignificant (sarcasm) bits - essentially you would be creating a custom protocol. That is before you consider the additional tooling to debug your custom protocol, let alone how you interoperate with other services which perhaps have a different idea of how to build such a "raw" service. Alas, HTTP is the best answer. While there are emerging protocols, NATS for instance, which may someday compete with HTTP in interconnecting micro services, I would consider a custom TCP based protocol one of the stronger anti patterns.

[#3]

@Dallen Thanks for the answer, Dallen. Assuming we agree that HTTP is [in most cases] the best choice, we could still let the client and server connect directly, or we could go through a gateway of some sort. In both cases, HTTP defines the protocol. In the first case, it is up to the client and the server to take advantage of the structure the protocol offers. In the second case, a competent gateway would provide access control, monitoring and statistics, traffic control and other features, without you having to code these capabilities into the client and server. In your environments, do you use (or do you think you will use) a gateway, or do you (or will you) include that function directly in your microservices?

[#4]

Separation of concerns principle recommends to have a separate layer for mentioned features rather than clubbing them with business logic. Simply following this recommendation (and I don’t think why shouldn’t), in a legacy enterprise or even one having old SOA world (actually ESB world J), API gateway at the front make perfect sense. No doubt about it.

What this topic bring-forth is how to analyse this approach in the context of micro-service architecture. One of the best practice of micro-service architecture is single team owns a capability from end to end i.e. across all layers as well as across its lifecycle from requirement till deployment. A team should not have any constraint / dependency on any other team that could delay releasing their services. How this requirement can be fulfilled in the context of singleton API gateway which is being owned by separate team?

In a multi-team environment, each capability need isolation at two different dimensions: Build time and Run time. Build time concerns can be resolved by creating organization / environments, restricting access, etc. at team level even in a singleton API gateway.

For second aspect i.e. run-time isolation, only possible solution is to have separate run-time environment. One solution could be to have lightweight API gateway just enough to take care of run-time aspect. Apigee micro-gateway can be a good fit here.