Microgateway Blog Series, Part 1 – Traffic Management

In this series of blog posts, we explain the valuable role the Microgateway plays in adopting a microservice architecture.

A single microservice is a simple concept – it’s small, isolated, easily replaceable, stateless…This all sounds straightforward, but when you have a microservice architecture you have a suite of such services, not just one or a few. Microservices run in separate processes that can be segregated across various network boundaries and physical clusters. As this architectural style grows, an explosion of complexity occurs: discovery, security, monitoring…

It has been said that in order to adopt a microservice architecture you need to be “this tall” in terms of operational maturity. The adoption of a Microgateway strategy within your microservice architecture is proof that you are tall enough!

Fig 1. Operation maturity is required in order to successfully deploy and gain the benefits and joy of running a microservice cluster.

What problems does microservice adoption bring?

One of the tenets of having a successful microservice adoption is the adherence to Conway’s Law, which results in an organization where there are independent teams creating independent microservices. The proliferation of this strategy brings challenges to operators and security personas who want the ability to assert central control and governance to API traffic flowing within the organization. If we have no way to uniformly monitor, meter and secure all of our services in a microservice ecosystem, we will quickly devolve into chaos. A hacker, for example, upon discovery of a vulnerability, will attack with impunity. If all of our services are created in small, focused and isolated teams, risk mitigation of these attacks becomes extremely difficult without a Microgateway. This is just one of the reasons we need the concept of the Microgateway.

So, what is a Microgateway?

A Microgateway (MG) is a reverse proxy that sits close to the microservice. The MG controls the ingress (inbound) and egress (outbound) traffic for a given microservice, which means if the pattern is properly implemented, no communication can be made directly to a microservice without the assistance of the MG. This pattern provides many useful benefits with minimal performance degradation. Consider that a developer is not burdened with concerns about governance, discovery, observability and stability; the operators can now control Policy Enforcement Point (PEP) and Security Controls in a centralized control panel and propagate these changes to the MG. In the end, when adopting a MG, you provide a service mesh that allows for the holy grail: service monitoring and tracing, request (version) routing, resiliency testing, security and policy enforcement, etc., in a consistent way across the services, for the application as a whole.


Every microservice will have a corresponding MG. The MG will follow the sidecar application pattern. A sidecar application is deployed alongside each microservice that is deployed. It is conceptually attached to the “parent” service in the same manner a motorcycle sidecar is attached to the motorcycle – hence the name. A sidecar runs alongside the service as a second process and provides ‘platform infrastructure features’ (see feature list below).

Traffic Management

Reliability in distributed systems is determined by the weakest component, so even a minor internal function could bring your entire system down. It’s well known that failure cracks can propagate through a system. For example, a slow database could bring down a site via cascade failure.

A microservice architecture is a distributed architecture, and as such it introduces new levels of complexity and several risks which were not commonly found in traditional monoliths. There are assumptions that programmers incorrectly make about the network. Twenty years ago, L. Peter Deutsch and others at Sun Microsystems documented the Fallacies of Distributed Computing, which are still pervasive today:

  • The network is reliable.
  • Latency is zero.
  • Bandwidth is infinite.
  • The network is secure.
  • Topology doesn’t change.
  • There is one administrator.
  • Transport cost is zero.
  • The network is homogeneous.

A Microgateway supports various stability patterns which help to reduce, eliminate or mitigate against the failure cracks that could be found in a distributed system. In order for the Microgateway to protect itself from failure, it will adopt some stability patterns:

  • Retry strategies (i.e. exponential backoff) and timeouts should be introduced.
  • Circuit breaker – stop cracks in the system spreading into cascading failures. When a failing service is detected, stop calling that API and serve fallback responses. Fallback mechanisms (e.g. cached data) ensure uninterrupted service while giving service time to recover.
  • Bulkheads – one service down could jeopardize all the rest – introduce bulkhead design pattern to mitigate risk.
  • Support non-blocking asynchronous calls – some calls to services (i.e. a logging / audit service) should not be blocking so async calls should be possible.
  • Quota enforcement – every single one of your peer services suddenly becomes a potential DOS attacker. Nobody can make any real forward progress until very serious quotas and throttling are put in place in every single service.

A Microgateway is your safety net should any of your services fall off their high wire!

Fig 3. Service Mesh provides you with a safety net which protects you when your microservice falls from its high wire.

In my next blog, I will explain the role that an Edge Gateway plays to protect the perimeter while the Microgateway protects the microservice. Stay tuned.

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

Previous articleWhere is the SalesForce acquisition of MuleSoft on the Richter scale?
Next article14 Sources Of Financial Data From U.S. Federal Government Agencies
Senior VP Engineering


  1. Nice article David.
    do you think all the regular variations of a proxy might apply here?
    -Image Proxy
    -Remote Proxy
    -Virtual proxy

    the one in your article is mostly around Protection/Governance/Control

    • Hi Vinnet
      Taking each of the proxies that you mention:

      – Image Proxy: I’m not 100% sure what you’re referring to here? Are you referring to a proxy to cache images or static content like a CDN. If so then I think the microgateway is unlikely to play a role here and really that this is something that would be done by an edge proxy (i.e. in the DMZ) or by a CDN. It’s at the edge that UI’s would be served up to browsers etc.

      – Remote proxy (https://en.wiktionary.org/wiki/remote_proxy): the microgateway controls the ingress (inbound) and egress (outbound) traffic, so as it providing security on inbound it is control access to the APIs hosted on the microservice. So if your definition of remote proxy is the same as the link above then microgateway could be considered a remote proxy to the mircoservice

      – Virtual proxy: If a microservice is been protected by a microgateway, then to the a client of the microservice would not be aware of the microgateway’s existence (i.e. it’s transparent). The client would just think they are calling the API hosted on the microservice, therefore the API could been seen to be virtualised on the microgateway (i.e. security, monitoring etc. of the API are offloaded from the endpoint to the microgateway)

  2. Thank you for the good article! There are advantages to use sidecar deployment model, but if the MG’s pattern is properly implemented at the start of development, would it be easier to have MG integrated into a microservice by default?

    • Hello Yuriy,
      I have seen two different approaches – you either use a uniform microservice platform or you use a microgateway.
      The uniform microservice platform pattern is called Microservice chassis (http://microservices.io/patterns/microservice-chassis.html).
      Chassis approach requires up front investment, it would mean a large investment in N chassis for the different programming languages at play (go, java, js etc.).
      Chassis approach means that you must have enforced architectural governance i.e. provide paved road to development teams and mandate that it’s used.
      There is also an assumption in chassis approach that you’re building all your services yourself. Do we think a microservice deployment would be 100% self-written
      services or would they use off the shelf services? Most organizations today grow organically or by acquisition of technology, so we should expect various flavours of services deployed.
      If you think you’ll have n flavors of service deployed then the microgateway is for you!


Please enter your comment!
Please enter your name here