3

REST APIs can be exposed using an API Gateway and is considered to be a good practice. (at least when they are exposed to internet)

However there are a lot of microservices inside an enterprise which are not exposed outside and they are used to communicate with each other.

Wonder what are your experiences in terms of microservice to microservice communications ? Via an internal API Gateway , direct link between microservices?

How a mesh of an increased number of microservices which communicate direclty with each other can be avoided without an internal Api Gateway ? (microservices are in the same network) I am not looking for best solution just some opinions about some architectural design possibilities of using an Api Management tool and API

Thanks

closed as unclear what you're asking by Robert Harvey, Christophe, 8bittree, BobDalgleish, gnat Nov 30 '17 at 21:12

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    You don't appear to have a specific enough problem statement in your question to make it reasonably answerable. The only detail you have provided is that you have microservices communicating with each other, and that this communication will not be exposed to the public. There are several ways to accomplish this; the way that works best for you will depend on the specifics of your particular situation. – Robert Harvey Nov 23 '17 at 20:19
  • I am looking to see if there are scenarios or patterns when internally is well suited to use a Api Gateway. Direct links can create a mesh hard to administer if number of microservices increases.I will rephase then asking how you can avoid the mesh – Cris Nov 23 '17 at 20:26
  • Are the microservices distributed, or are they located in the same place? – Robert Harvey Nov 23 '17 at 20:34
  • 1
    So you can be much less formal with the API boundaries then, since you are in complete control of the channel. – Robert Harvey Nov 23 '17 at 20:55
  • 1
    You are probably missing the Service Discovery. The API gateway is reasonably useful in some cases but it can be replaced by http servers and reverse proxies. The Service Discovery is a master piece in any "decent" microservices architecture not so easy to replace as the gateway. I would dare to say that it's a must. – Laiv Nov 23 '17 at 21:10
5

There are different aspects to avoid the mesh:

  • the API gateway isolates clients from microservices, by ensuring protocol interoperability between different front-ends and different back-ends, and by defining a network channel (e.g. fixed address for back-ends changing dynamically address, controlled access via firewall, etc...).

  • the service registry allows a discovery process to keep the binding between microservices dynamic: clients and servers find each other dynamically when needed instead of pre-wiring the relations.

If you have an homogeneous technical stack for your internal microservices, and unless you have high network security requirements, you do not necessarily need the API gateway. But you'd certainly need the service registry for mastering the microservice variety (i.e. kind of service) and the scalability (i.e. several instances of the same service).

Not the answer you're looking for? Browse other questions tagged or ask your own question.