Microgateway Blog Series, Part 2: Edge to Internal

The season finale for Game of Thrones (GoT) seems a long way off. So, in this entry, let’s keep the hype going by equating the roles and responsibilities of the Edge Gateway and the Microgateway to various events and happenings within Westeros.
The Machiavellian fight for who will sit on the Iron Throne of Westeros is largely fought between the ruler in the North and the incumbent ruler in the South. Traditionally, in a networking context, north-south traffic describes the client-to-server traffic that moves between the datacenter and a location outside of the datacenter network. The term north-south comes from network diagram drawings that usually depict wide area network (WAN) traffic vertically.

In the GoT context, the North would be “The Wall” and the South would be represented by the various kingdoms that the wall protects. If we extend this idea and apply it to a microservice architecture, north-south traffic is the external traffic which comes from external clients across the DMZ and arrives at some endpoint behind the DMZ. An Edge Gateway plays a major role in governing north-south traffic. The Edge Gateway is The Wall and Castle Black – it is the fortification which projects your infrastructure/world from the deadly White Walkers.

The Wall blocking threats from entering Westeros

The Edge Gateway provides authentication and authorization, allowing only appropriate requests to cross the boundary. In addition, the Edge Gateway will provide the capability of API firewalling, whereby messages containing threats cannot enter. The Gateway provides mediation in terms of protocol, message and security content, which allows for the Edge Gateway to provide the routing (L4/L7) that would typically be found in application load balancers. Finally, since the Edge Gateway controls all inbound traffic, everything can be logged, which allows for visibility, reporting and analytics services to be applied.

Now that we have explored the analogy between The Wall and The Edge Gateway, let’s switch gears and talk about the actual microservices running within the Network and how they inter-operate.

Your microservices, which scale in and out within your infrastructure, are just like the number of Westeros Houses (House Stark, House Lannister, House Martel, House Tyrell, etc.). Just like the blood baths in Westeros, you will see that services grow, evolve and die.

The houses and characters in Westeros represent the complexity of a microservices architecture.

In order to communicate between the houses within Westeros, each house will have dedicated ravens that are used as dispatchers to carry messages to specific houses. If we apply this idea of inter-house communication to our microservice networking example, it would be known as East-West traffic. In a networking context, East-West is the transfer of data packets from server to server within a data center. The term East-West, for this type of traffic, comes from network diagram drawings that usually depict local area network (LAN) traffic horizontally.

How do you know that a raven has made it to its destination? How do you know that you can trust the source and content of the message that it’s carrying? This is where the Microgateway comes into play. The Microgateway is deployed beside your microservice or “house” and provides guarantees that the ravens get their message to the destination, the message can be trusted and you’re aware that the message made it! The Microgateway, as a reverse proxy, is responsible for controlling all traffic inbound and outbound for its parent service. The Microgateway acts as a Policy Enforcement Point (PEP) and enforces policies which will allow / disallow requests and responses. Policies could include AuthN, AuthZ and content validation.

North-South, East-West

The Edge Gateway and Microgateway provide a microservice architecture with a sense of order, much like The Wall and Ravens assist Westeros. A microservice architecture that does not employ these concepts will quickly find itself in a state of chaos, much like the Dothraki.

Find Part 1 of the Microgateway Blog Series here.

For more microgateway info, read the other blogs in this series:

Previous articleBlockchain APIs for a stronger performance
Next articleHybrid Integration Platform meets Content Collaboration
Senior VP Engineering


  1. Hi David.
    It makes much easier to understand a concept when we can relate it to something that we know/like. Excellent article, please keep them coming – specially with this kind of analogy 🙂

  2. Hi David,
    For East-West communication more and more message-driven approaches are used to avoid latency and direct dependency between MS.
    Can you perhaps explain how do you see the role of such a MG when using such message-driven MS architecture?

    • Hello Chris,
      At a high level a message-driven approach, with Kafka or RabbitMQ, and a Service Mesh appear to be similar in that they manage the communication between a set of services. Queues having the advantage of providing support for asynchronous messaging and allowing for multiple consumers on topics. Queues are providing the backbone of event drive architecture style.
      What we’ve seen in our customer base is a combination of both most microservice communication has moved to REST and the newer strongly typed IDLs such as Thrift and gRPC. Developers have favored simplicity via direct networking calls rather than adopting message-driven MS architecture. However we do see more mature customers moving to message-driven MS architecture to gain the advantage mentioned above.
      A key role of the MG is to take some of the infrastructure work out of the hands of developers, the developer doesn’t have to write code for many common functions, i.e. implement common network functions like routing and load balancing, resiliency functions like retries and timeouts, security functions like authentication, authorization and service level monitoring and tracing.


Please enter your comment!
Please enter your name here