How can you get the most out of a next-generation network investment? Well, first of all, transformation cannot happen overnight. It has to be a step by step process. Secondly, it needs to be automated.
Tip # 1: You cannot manage what you cannot see
Real time discovery will provide you with a complete network understanding and will prepare your network to be in a transition-ready state.
Discovery should include the topology of both your physical and logical network resources. In the discovery phase you should map your network in order to understand: How many servers? How many devices? Etc.
The discovery phase is the basis of a network transformation process as it will allow you to understand and analyze your current inventory and future steps you should take with it. Good discovery will be conducted in multi-dimensional mode – just like when someone undergoes an MRI . Discovery should not only identify devices and links but also network resources.
By conducting the discovery phase properly, you will be able to decide which of existing “brown-field” service parts you might want to transition to new technologies and which not.
- By specifying IP Address range(s) via UI or REST NBI, you can scan and automatically discover the network elements, build a network map and inventory off all network resources and services.
- Perform network analysis using next generation PM and Service Chain Verification SW, identify unused resources, links and capacity bottleneck.
- Execute the cleansing/optimization activities and bring the network to transition-ready/optimal state.
Tip # 2: Eliminate vendor dependency
Average data accuracy of a legacy inventory system is 50-60% (or even lower), so moving the existing database to include virtual elements in your inventory system might result in dragging inaccurate and irrelevant data from legacy infrastructure. The solution is to implement a holistic vendor-agnostic discovery engine to:
- Capture all the real data directly from the network
- Independently control networks as well as adding appropriate models that will be aligned with actual network needs without any vendor interaction.
- Export up-to-date network data to the new inventory system to ensure error-free execution of fulfillment and assurance processes.
Avoid vendor specific adaptors in your discovery phase and automate the process via vendor agnostic API’s to ensure saving money, time and resources. If you choose a vendor with a ready-made library it will even ease the process further, promising fast error-free execution.
Tip # 3: Evolution vs. revolution
There are few ways to add new system control to your existing network. One way (the expensive one) is to delete all your past investments with a reboot, and create(?) your NFV network from scratch. This will require heavy infrastructure investments.
There’s another way though – a way that enables you to control the process. You can connect the NFV with your legacy infrastructure and make the most out of your legacy before removing it. The process can be done gradually and is recommended in a graduation mode. Evolution and not Revolution in order to save money, resources and be more efficient.
Tip # 4: Flexibility and agility
You need to make sure you can easily add more elements to your network with no need to write new code and avoid scripts. Like with Lego blocks you should be able to modify in a simple way in order to allow rapid and reliable network migration.
The migration’s runtime execution environment should be open and flexible to ensure fast onboarding of new devices and services and simple definition of migration mapping, logic and rules. Even if something unpredictable occurs during the migration, planning or the migration execution itself (something that usually happens), with a few mouse clicks, it can be promptly mapped/fixed in migration models without changing code and entering a prolonged software delivery cycle.
Tip # 5: Comprehensive automation
Automation is not an option, but rather a must in today’s world. When we talk about automation, we don’t mean strictly hardware, but services should be part of it too. Migration can be done by moving one part/end-point/block of a service chain from one PNF to a new deployed VNF, or by replacing several network functions with new ones, etc. Regardless of the specific use-case, it is important to rely on advanced modeling to instruct the automation engine on how to migrate the configuration from the old to the new.
Through GUI-based Self-service DevOps/NetOps Design Tools you can allow SDN-based network abstraction and real-time multivendor service automation across any traditional and legacy networks.
The higher the level of flexibility and automation, the faster you can introduce new services and enable new features.
Interested to get this demonstrated? Feel free to contact us, request a demo or a free trial – more information can be found on Atrinet’s website (https://www.atrinet.com/).