A telecom network management monolith, rebuilt as microservices

The problem

The Spidernet EMS was a network management system for large telecom deployments: it configured, monitored and collected telemetry from tens of thousands of nodes. It had grown for a decade as a single JAX-RS/Jetty application with a JPA data layer and a dated, rigid web interface. It worked, but it had become difficult to maintain, builds were manual, and it was slow to evolve.

It also couldn’t simply be switched off. Operators depended on it, so a big-bang rewrite was never an option.

Drawing the service boundaries

I led the decomposition, working across backend, frontend, infrastructure and DevOps. The monolith was split along domain lines into focused Spring Boot services for Auth, Admin, Devices, Events and Configuration, each with its own REST interface and data access layer in place of the shared JPA/JAX-RS structure, plus shared authentication and configuration services that every other service builds on.

The migration was phased, with CI/CD processes built out to support it, so new services could take over one area at a time without service downtime.

High availability, designed rather than bolted on

A network management system that goes down stops being able to see the network, so the cluster needed real failover. I designed and implemented it:

• Active/standby behaviour driven by a custom HA state machine, with leader election and heartbeats.
• Cluster coordination so exactly one node acts as primary.
• MariaDB primary/replica replication, orchestrated alongside the application failover.
• DNS-based failover so clients follow the active node.
• Observability for failover events, so a switchover is explainable afterwards.

Performance at tens of thousands of nodes

Loading and presenting that many nodes was slow. I reduced load latency by improving API throughput, reworking query strategies, and adding in-memory caching where the data allowed it.

Security and upkeep

• Secure service-to-service communication, with automated TLS certificate rotation.
• Remediation of dependency vulnerabilities across the Java, Node and Docker layers.
• Structured logging and better tracing across services.

A front end that could keep up

The old web UI was replaced with a React and Redux Toolkit application, built on a modular component system with type-safe API clients, so the front end could evolve at the same pace as the new services.

Delivery and the team

Manual builds were replaced with Jenkins, Maven and Docker pipelines, which made deployments consistent and cut build times significantly. Alongside the code, I led design reviews, mentored junior and mid-level engineers, and set coding standards, guiding the architecture through hands-on prototyping rather than diagrams alone.

Where it is now

The rebuilt platform is now sold as the Airspan Management System (AMS), and it has taken off. Tier-1 US carriers are running it or bringing it into their networks, one of them as a managed service, and major automakers and large enterprises have signed on or are signing on to manage the nodes of their distributed antenna systems (DAS) with it: the networks that carry cellular signal through large buildings and campuses. The feedback from the people who run those networks day to day has been enthusiastic.

That’s the real test of a rewrite. Not whether the architecture diagrams look cleaner, but whether the product becomes something new customers want to buy.

What carries over

Big-bang rewrites of systems like this usually stall. This one moved forward because it was incremental: shared foundations and delivery pipelines, then one domain at a time, with the system in production throughout. That’s the approach I’d bring to any monolith that has to keep running while it changes.