If you manage or plan a network, this means you very often need to scale out your infrastructure in one of two ways:
- Scaling out capacity
- Scaling out services
Scaling out capacity can occur in any part of the network and can result from growing demand for existing services and/or introduction of new services.
To scale out, you typically need to add resources such as line cards, fabric cards, chassis as well as racks, power, cabling etc. But adding resources is not always that simple. In many cases with a chassis-based infrastructure, when you reach the limit of one of the resources in your existing chassis you then need to perform a forklift upgrade – hence the headache.
Such an upgrade is not only time consuming (as it is traffic affecting and needs to be performed in a predefined maintenance window), it is also expensive and usually calls for some heavy-lifting procedures, laterally.
Scaling out services is a different kind of headache, as this has to do with business growth and the operator’s competitiveness. The need to scale out services comes from the needs for introducing new services to existing and new target markets and generating new revenues streams.
This is why scaling out services is often an urgent task, and the fast time-to-market (TTM) goal makes a new service deployment, well, a headache. Such service introduction usually requires the planning, procurement, deployment and commissioning of new network elements (hardware and software) in various parts of the network. This takes time – usually too much time.
Scaling smart with DriveNets Network Cloud
Here is where the cloud-native, software-based architecture of DriveNets Network Cloud kicks in. This architecture completely separates (disaggregates) hardware from software, allowing the scaling of each of those planes separately.
Moreover, building the network with clusters of basic white boxes means you can scale out capacity by simply adding a white box according to the required resource to be scaled. This could be a packet-forwarding white box (the NCP) or a fabric white box (the NCF).
Most importantly, there are no practical limitations to such scaling. You can add white boxes as needed. There is no chassis to be exhausted and you never need to run a forklift upgrade.
Even if local rack space, power supply, cabling space or other resources are limited, you can simply locate the new white box in another rack.
Using the same type of white boxes across the network also means that the planning and procurement phases usually associated with such an upgrade are simplified (if not eliminated).
When it comes to scaling out services, the task is even simpler. Any network function – whether from DriveNets or a third-party networking or security vendor – can be introduced to the network by a simple procedure of software installation in a (new) container on top of the (already existing) infrastructure.
This means that when it comes to launching a new service, there is usually no need for new hardware introduction in your network. This shrinks TTM from months to days, and makes your headache, well, disappear…
Heavy Reading: A Radical Network Change to Cloud