How and why was MATRIXX so early with cloud native solutions?
The way we initially designed the platform set us up very nicely to transition to cloud native principles. When NFV was in vogue, we had already solved the issues virtualization was trying to solve by creating our own tech stack that took advantage of low-cost hardware and could scale linearly. As cloud native principles came to light, we realized more immediately how we and the industry as a whole could take advantage of the architecture.
Looking at it through the lens of the three issues with telco monetization we discussed in part 1 (lack of business agility, immediacy, and flexibility), here’s how we were able to shift to cloud native so easily.
In terms of agility, cloud native enables the deployment of best-in-class solutions for particular functions while avoiding vendor lock-in. Instead, telcos can build truly differentiated networks based on their portfolios and target markets. Since we were already deployable without custom code and built for easy integration into heterogeneous environments both for IT and networks, we were key in helping operators make this transition.
Cloud native networks and 5G design also enabled a shift to centralized monetization through the CCS, opening up new ways to measure network resources and deliver value. Shifting core revenue-generating functions into the network layer gives operators the ability to monetize 5G’s new capabilities.
Finally, our services-based architecture easily evolved into a platform that could support cloud native principles. We didn’t have to start from scratch. Because we already had a path to Kubernetes and auto-healing and -scaling, the platform could scale up and down elastically just like other core network functions. Operators don’t need to oversize deployments to account for peak network loads. Instead, they can leverage cloud environments to scale up and down as network usage changes.
How is MATRIXX’s cloud native approach/solution different from anything else on the market?
A lot of it comes back to modularity and the services-based architecture we started from. Legacy vendors provide their solutions through monolithic sets of code that are too intertwined to ever evolve to cloud native. Though they’ve been moved to the cloud, they still can’t take advantage of the automation and efficiencies provided by Kubernetes, so they’re just as expensive in the cloud as they were on premises.
Many vendors also didn’t benefit from the same design advantages that we had, which I discussed above. Because they couldn’t evolve from OCS to CCS, they are inherently behind us in terms of product maturity and functional footprint.
What has the MATRIXX team learned along the way?
Because of how early we were to cloud native principles and services-based architecture, the market wasn’t completely ready for us when we launched and it took a few years to gain traction. Now as the pace of change continues to increase, our foundational core of pushing boundaries and trying new things is paying off. Our openness to investing in new paradigms while sticking to our original design principles has also been crucial to our growth.
What’s next for the company?
Our early adopters primarily used MATRIXX for digital brands and new mass market offerings. Now, we’re seeing the shift to dedicated industry solutions and enterprise offerings from our customers in terms of monetization. As a result, we’re deploying a lot of exciting new models around value-based monetization, multi-party offerings, and network as a service.
It’s an exciting time to be in telecoms as the industry continues growing and changing, and clearly a pivotal time for companies like MATRIXX as cloud native technology and principles become ubiquitous. Thanks again for your insights and time, Jennifer!