In this series of blog posts, we explain the valuable role the Microgateway plays in adopting a microservice architecture.
For more microgateway information, read the other blogs in this series:
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!
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 an 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.
Deployment
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!
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 information on microservices management, click here.