title: Should Kubernetes Ingress lives together with a Spring Cloud Gateway?
body: <p>Small architecture and design question please.</p>
  <p>Question:
  Should Kubernetes Ingress lives together with Spring Cloud Gateway? If not, which one should be preferred?</p>
  <p>First, with a Spring Webflux / Spring Cloud Gateway project, I managed to have working route-based forwarding. Meaning, all my clients only need to know this one and only Spring Cloud Gateway endpoint, and the Spring Cloud Gateway will forward to serviceA if the URL contains serviceA, to serviceB if serviceB, etc, straightforward.</p>
  <p>I added some more “software level features” such as dynamic configuration (to change the routes at runtime), circuit breaker, rate limit, bulkhead, and few others features, very cool, but really, I ended up using the route forwarding as a main feature.</p>
  <p>Then couple of weeks back, I spent time studying Kubernetes, and more precisely Kubernetes Ingress.
  I managed to learn Kubernetes Ingress is a very cool and strong thing. I managed to perform at least the route based forwarding.
  Meaning, clients needs to only know this one and only Ingress endpoint, and the Ingress will forward to underlying services within the Kubernetes cluster. Where as of now, it forwards everything to Spring Cloud Gateway, which will forward to everything else. I tried, and it could have forwarded to the real business services in the first place).</p>
  <p>And this is the moment where I am having doubts.</p>
  <p>Did I just duplicate work? (I mean in terms on functionally, I had fun learning both).</p>
  <p>Should I consider an architecture where the Spring Cloud Gateway (only him) is really doing the gating?</p>
  <p>Should I consider an architecture where both the Ingress and the Software Gateway have full importance, configuring features in both? (Accept the duplicated work?)</p>
  <p>Should I remove the Spring Cloud Gateway entirely?</p>
  <p>Thank you</p>