If you are a fan of Game of Thrones (GoT), this post will make sense to you. I will be equating the roles and responsibilities of the Edge Gateway and the Microgateway to various events and happenings within Westeros.
In GoT, 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 data center and a location outside of the data center network. The term north-south comes from network diagram drawings that usually depict wide area network (WAN) traffic vertically.
Edge Gateway is “The Wall”
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.
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.