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.
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.
Comparison
The pros and cons of the different approaches are summarized in this table:
Approach | Pros | Cons |
|---|---|---|
Single Microgateway with multiple services |
|
|
Separate Microgateway for each service |
|
|
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.