| The article seems to describe a system which has funnel-shaped dataflow (narrow inlet, spread to services), which is also a side-effect of the 'API Gateway' approach you mention. Three useful definitions[1] for microservices are: 1) collaborating 2) independently deployable (Martin Fowler [2]) 3) globally-aware Having an API Gateway makes them follow none of these meaningfully, as: 1) the services are collaborated _upon_ rather than doing so with each other (see Clump[3], not itself a bad idea) 2) updating a microservice will many times require a redeploy of the API gateway and for everyone to update their connections to it 3) any functionality you put in the gateway becomes encapsulated in a way tailored to application-global needs, which is pretty inimical to modular components, so you'd better not talk through the gateway except where you absolutely must! Having orchestration/aggregation services as buro9 mentions in a sibling post is one good solution, satisfying all of those three points much more cleanly. The danger arises when you start to think of your gateway(s) as layers in front of your system rather than just more microservices in it. [1]: (context) https://vimeo.com/118895501#t=48s [2]: http://martinfowler.com/articles/microservices.html [3]: http://getclump.io/ |