At the beginning of we do the Digital Transformation, we find API Gateway is an excellent component to help us extract common functionalities and our services could keep their details and just expose one host to consumes.
But it is the final solution?
- Shield services' details as one of the results after involving API Gateway, will it becomes a new blocker to hinder the velocity of delivery business value?
- It decoupled of the service consumer and provider, but will it add new dependency between service and gateway?
- After all services are hidden behind the API Gateway, how do we make sure the service can be well designed?
Happy to discuss.
IMHO, API gateway is bind to micro service, if your crew is going to split single server into micro services , then API gateway is really important，and congratulations，you seem to be in a big company。
and it might bring chanllenges，since you have API gateway micro services, you have to maintain a multi-set of enviorments, dev/test/prod ...，which means new complexity。
Yep, we used API gateway for several different projects/companies.
But in this case, I'm just thinking about the Anti-Patten scenario. Currently, all of our services are deployed on cloud server and managed by k8s. If we want to split different environments like dev/test/prod, we can handle it easily by using Route 53 and Kubernetes.
Actually I would like to find out some suitable pain points of Micro-Service Architecture and then we can have a good time to engage an API Gateway.
if you simply clone micro services via k8s, how do you solve the upcoming version difference problem.
you see, you mgiht have serviceA@v1.1、servicesB@v2.1、servicesC@3.2 on prod, but serviceA@v1.2、servicesB@v2.3、servicesC@3.2 on test