Merging Five Ingress Solutions into One Global based on APISIX
Software Mind was tasked with maintaining a complex and fragmented infrastructure built on top of Kubernetes. The system had evolved over time, resulting in five different ingress controllers and a tightly coupled custom authorization service – each serving a unique purpose, but collectively creating operational drag. By introducing Apache APISIX, a CNCF graduated project, we were able to unify ingress and API management under a single, extensible gateway. This shift not only simplified our architecture but also delivered significant improvements in agility, maintainability and cost-efficiency.
Challenge
The system we inherited relied on a variety of ingress technologies: HAProxy handled frontend traffic and maintenance pages, Traefik routed requests to services and monitoring tools, NGINX managed internal service-to-service communication and, a second, customized NGINX controller secured access to back-office systems for trusted users. Additionally, Istio was being piloted for service mesh functionality, though it remained only partially implemented.
To complicate matters further, request-level authorization was handled by a custom-built Scala microservice. This solution, while functional, introduced a development bottleneck. Every new requirement meant a new code change, and every change meant a round-trip to the development team – which slowed down delivery and increased the risk of regression. Managing this sprawling ecosystem was both time-consuming and error prone. Diagnosing issues often involved tracing requests across multiple systems, each with its own logging, metrics and routing rules.
Initial solution diagram with five different ingress solutions
Solution
To overcome these challenges, we turned to Apache APISIX. Its dynamic configuration capabilities, plugin architecture and deep integration with Kubernetes made it an ideal candidate for centralizing our gateway layer. Our goal was to consolidate the responsibilities of multiple ingress controllers into a single platform, move authorization logic closer to the edge and regain control over traffic routing and observability.
We began with a focused proof of concept to validate APISIX’s core capabilities. At this stage, we excluded the authorization logic to isolate and understand the platform’s traffic management features. Once we were confident in the base setup, we implemented two custom Lua plugins tailored to our business needs. The first handled JWT token validation and supported four distinct user types – each with its own set of allowed routes. The second plugin managed token renewal, which we adapted to our existing identity solution without having to make changes to either frontend or backend systems.
Implemented solution diagram with API6 in role of ingress controller
With these building blocks in place, we initiated a phased migration. Ingress controllers were gradually replaced with APISIX, starting from the less critical services and eventually covering the entire ecosystem. In parallel, we rebuilt our observability stack – integrating APISIX with Prometheus and Grafana to provide consistent metrics and dashboards. This step proved crucial in building confidence among stakeholders and ensuring that operational transparency was maintained throughout the transition.
Technical Implementation
Our deployment of Apache APISIX was managed via Helm charts on Kubernetes, which allowed us to smoothly integrate it into our existing GitOps workflow. We relied heavily on APISIX’s Custom Resource Definitions (CRDs) to manage dynamic service configurations. This approach made it easy to propagate route changes and traffic policies in near real-time, directly from version-controlled manifests.
Projects used
By the numbers
50% reduction
in implementation time
60% faster
incident investigation
1 solution
to route all ingress and internal traffic
On the authentication front, our custom Lua plugins provided the flexibility needed to support our unique requirements without disrupting other components. The JWT plugin validated tokens and enforced fine-grained access control at the gateway level, while the renewal plugin helped us extend session lifetimes without any UI or backend modifications.
We also redesigned our monitoring stack to be fully compatible with the new gateway. The previous observability solution was tightly coupled with legacy ingress tools and lacked the necessary insights for a distributed microservice environment. With APISIX, we gained consistent traffic metrics, latency breakdowns, and error rates, which significantly improved our troubleshooting capabilities.
APISIX CRD blocks and traffic flow
The Results
The migration to Apache APISIX resulted in immediate and measurable improvements. We saw a 50% reduction in the time required to implement new service routes. Incident investigation became 60% faster, thanks to unified logs and metrics. By eliminating the need to maintain multiple ingress controllers, we cut infrastructure complexity and reduced operational costs.
Beyond these quantitative gains, simplifying the architecture improved developer productivity. Teams no longer needed to understand the nuances of five different ingress systems. Instead, they could rely on a single, well-documented API gateway with centralized configuration and behavior.
Lessons Learned
One of the most important takeaways from this migration was the value of starting small. The initial proof of concept enabled us to build confidence, identify potential pitfalls and demonstrate value without disrupting production systems. Another key lesson was the importance of investing in observability from day one. Monitoring helped us operate the new system effectively and proved critical during the migration process.
We also learned that while APISIX offers great flexibility through its plugin architecture, that power comes with the responsibility of maintaining and documenting custom code. Clear documentation and team training were essential to ensure long-term maintainability. Finally, we made it a point to onboard our engineering teams to APISIX concepts early in the project. This minimized friction during the migration and empowered developers to take full advantage of the platform.
What’s Next
With the foundation in place, we’re now exploring APISIX’s more advanced features. Service mesh capabilities, deeper request tracing and integration with distributed tracing tools are all on our roadmap. We’re also considering contributing some of our custom plugins back to the APISIX community to help others solve similar challenges.
“For us as end-users, APISIX has been a game-changer. The service is now exceptionally stable and reliable, with disruptions becoming a thing of the past. Since the application responds much faster, we’re experiencing significantly improved performance. What’s more, updates and new features are deployed so smoothly that our work is never interrupted. Overall, APISIX has provided a much more dependable and enjoyable user experience.” – Cristina Jiga, Software Delivery Manager at Software Mind
About Software Mind
Software Mind is a global software engineering company founded in 1999 in Kraków, Poland. With over 1,600 experts across 14 R&D centers in Europe and the Americas, we specialize in custom software development, cloud solutions, AI, DevOps and digital transformations. We’ve delivered over 1,000 projects to 350+ clients across 35 countries. Our commitment to quality is reflected in our ISO27001 and SOC 2 certifications, and our agile, people-centric culture drives impactful results for clients across industries.
About Apache APISIX
Apache APISIX is a CNCF graduated project and a high-performance, dynamic API gateway designed for modern microservice architectures. It provides powerful traffic management capabilities including load balancing, canary deployments, circuit breaking, authentication, observability, and more. With support for dynamic configuration, custom plugins, and native Kubernetes integration, APISIX enables organizations to build resilient, scalable, and secure gateway solutions.