Cascaded services

One possibility to deploy Microgateway is to cascade the service in front of back-end services. Generally, this leaves two possible options:

Single Microgateway with multiple services

When cascading the Microgateway in front of the back-end service, the idea could come up, to protect more than one service with the same Microgateway.

Microgateway-manual-architecture-cascaded-services-single

If services or applications are stateful or depend on each other, e.g., because they share a common session, one option is to combine them on a single Microgateway. The common state is then managed on the single Microgateway. However, state synchronization is also possible with separate Microgateways, e.g., by connecting them to the same Redis service, as outlined in the section on Session handling.

Sharing a Microgateway is only recommended if few services are involved. With lots of services, this quickly evolves towards the anti-pattern of replacing an Airlock Gateway appliance with a single Airlock Microgateway instance.

Separate Microgateway for each service

Following best practices for microservice deployments, each service should be protected by its own Airlock Microgateway. This guarantees that the back-end services can be operated independently. That is, service configurations can be updated without affecting eachother.

Microgateway-manual-architecture-cascaded-services-multiple

Comparison

The pros and cons of the different approaches are summarized in this table:

Approach

Pros

Cons

Single Microgateway with multiple services

  • no state synchronization between deployments necessary
  • less containers required
  • complete configuration in single file
  • no deployment separation between services

Separate Microgateway for each service

  • deployment separation between services
  • best practice for microservice architectures
  • best possible configuration for the protected service
  • possible state must be synchronized between deployments
  • more containers required

Conclusion

Which architecture should be chosen depends on the properties of the protected services and on how strictly your organization follows the microservice paradigm.

For stateless microservices, the best practice is to use one separate Microgateway per service. This allows maximum deployment separation and single-purpose Microgateway configurations.

While sharing a Microgateway may have its benefits, it is only recommended as long as few services are involved. If many services share the same Microgateway, the deployment starts having more and more characteristics of a central gateway deployment. Airlock Microgateway has been designed to be deployed close to services, and not for central infrastructure tasks. We envision the Airlock Microgateway as a complement to the Airlock Gateway, not as a replacement.