Thinking back to when I was little, nothing made me freeze up like getting conflicting advice from authority figures: Keep quiet, but speak up if you have something to say. Don’t give up, but know when it’s time to throw in the towel.
As communication service providers (CSPs) progress with their digital transformation journeys, they’re constantly bombarded with advice. Much of that guidance is self-explanatory. But, I can see how some of the guidance might seem confusing—even outright contradictory. Let’s dig into some of these apparent paradoxes and get to the truth.
Paradox 1: You need to disaggregate, but you also need to unify.
Few concepts are more central to service provider transformation than disaggregation. That is, breaking up previously monolithic applications into smaller parts. And yet, the same people pitching disaggregation also argue for unification—bringing together siloed network layers and operations. What gives? Aren’t “disaggregation” and “unification” opposite concepts? Not necessarily. Here, they just refer to different parts of the transformation journey, different steps towards the same destination.
Right now, most operators still rely on legacy environments that are both very monolithic and very siloed. They’re monolithic in that the software stack for one part of the network (say, radio base stations) is a self-contained system. It addresses everything needed for that part of the network but only that part of the network. These monolithic stacks are inflexible and slow to change. You can’t really tweak one part of an application; you have to take or leave the whole thing. But service provider environments are also heavily siloed. Different parts of the network use their own self-contained monolithic stacks. And none of those stacks talk to each other—at least, not in any kind of automated way.
One key goal of transformation is to break down those silos. Ideally, you would want a single horizontal platform, with a single operating model, from core to cloud to customer. But to get there, we first have to break up these monolithic stacks into their constituent parts. Then, we can regroup and reassemble the various pieces in a more consistent, unified way.
Think of it this way: If you were running a restaurant, you could order a bunch of meal kits from Blue Apron or Hello Fresh. Sure, each box would have everything you needed to make that one dish, but it would be an incredibly inefficient way to run a commercial kitchen. (Not to mention that, the minute anyone wanted something customized, you’d be out of luck.) Wouldn’t it be smarter to just keep a common set of ingredients you could use to make any dish on the menu? In a nutshell, that’s what you’re doing when you disaggregate and unify a service provider environment.
Paradox 2: You need to be open, but you also need to be secure.
This apparent paradox seems to be receding into the past, thankfully. Today, more organizations recognize that openness and strong security are not mutually exclusive. Previously though, it was a fairly common misconception. People would hear the term “open” and assume that meant exposing your environment to threats you otherwise wouldn’t face. The truth is, there are several reasons why open standards and open multi-vendor ecosystems make it easier to secure your environment. Certainly, more so than relying on closed, vertically integrated systems.
The first reason ties back to the previous paradox. When you have a unified, standards-based environment that can run software and network functions from multiple vendors, you can use one consistent security approach across all of them. You no longer have to worry about how this vendor handles data privacy or how that part of the stack manages access. Now, you can define a single set of policies at the software layer. And you can apply them consistently across your entire environment.
Openness also means visibility. When you’re using an Open RAN framework, for example, you can inspect every layer of the stack. Contrast that with closed, proprietary systems that insert “black boxes” into your environment. Now, you have to rely on your vendor to keep things secure, because there’s no way to see what’s happening inside. Finally, with an open multi-vendor environment, you can respond to threats more quickly and easily. If a critical vulnerability is discovered in one vendor’s product, for instance, it’s now relatively trivial to swap out that component with another vendor’s.
Paradox 3: Going cloud-native makes your network more complex, but also simpler.
This final paradox is one I can sympathize with. Here, it can seem that the industry is talking out of both sides of its mouth. The truth is, entering the cloud-native world of microservices and containers does add complexity. You are, after all, exponentially increasing the number of distinct entities and interactions in your environment. So how do things end up simpler? We need to return again to our first paradox. Once you’ve broken applications up into microservices, you can now control all applications across all parts of your network in the same way. That consistency is valuable in itself, but it’s also a core enabler of automation. And automation always goes hand-in-hand with cloud-native transformation.
We also need to compare apples to apples. It’s not really useful to contrast one small slice of your operations in a legacy monolithic system with the same operation in a cloud-native environment. To see the real value, compare building a new service in the old world versus the new. Previously, you’d have to build (or implement) a complete vertically integrated system from the ground up. There’d be very little in the existing environment you could reuse. Almost every component would be inextricable from its monolithic stack.
OK, so what happens when you have cloud-native components running on an open horizontal platform? Now, most of the work for anynew application is already done. You can essentially use templates to create new services. Just plug in the prebuilt components you need, and you’re most of the way there. In this way, cloud-native microservices make it much easier to continually update services and create new experiences for your customers. Considering that those things could take literally years to accomplish before, I’d say that counts as simplification.
Bottom line, most of these paradoxes really aren’t paradoxes. I’d compare it to an adage like, “You have to spend money to save money.” The words may sound contradictory on the surface. Look closer though, and they’re absolutely true.
To learn more about how VMware platforms enable service provider transformation, please visit telco.vmware.com.
