Using APISIX to Stabilize Architectures and Enhance User Experience

Companies across sectors are increasingly turning to microservices due to increased scalability and flexibility. Along with facilitating secure, independent development and deployment of solutions, microservices empowers companies with the agility that speeds up software delivery. These benefits helo explain why the global microservices architecture market size, valued at $4.2 billion USD in 2024, is expected to reach $13.1 billion USD by 2033, according to research.

But a microservices-based architecture on its own does not solve everything. Engineering teams need to manage microservices to ensure it performs as desired, is secure and provides the scalability an organization wants. An increasingly viable option for enhancing microservices is Apache APISIX, a gateway whose traffic management features support load balancing, dynamic configuration of upstreams, canary releases and circuit breaking that improves system resilience and fault tolerance. Additionally, APISIX Gateway also provides security plugins for identity authentication, API verification and observability.

But what does implementation look like in practice? This article will present a real-world use and share best practices.

Overview: playing an active role in cloud native computing

As a member of the Cloud Native Computing Foundation (CNCF) – an open source, vendor-neutral hub that provides support for cloud native projects, especially those dealing with Kubernetes, Envoy and Prometheus Software Mind has the opportunity to contribute to driving the development of universal and sustainable cloud computing.

Recently Software Mind made a submission to CNCF’s graduated project program, which documented how Software Mind had been helping a client. 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.

Overcoming development bottlenecks

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

Merging ingress controllers into one unified 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.

What does technical implementation look like?

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.

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 

Migrating to Apache APISIX delivers real-world impact

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.

APISIX best practices

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.

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.

Teaming up with an experienced cloud partner

Given the dynamic evolution of cloud computing, continuous innovation and development are key to understanding and applying powerful new cloud technologies. A dedication to increasing competences – and diverse experience integrating cloud solutions into wide-ranging ecosystems – is just one of the reasons companies across sectors turn to Software Mind. Learn how we can support your organization by contacting our experts using this form.

Learn more about our DevOps consulting services.