If you find yourself looking at a bunch of end-of-life notifications, then you may be wondering what to do. In this article we’ll explore your options and help you to make a good decision for your network.
Depending on the precise model numbers in your network, an EOL notice means one or more of the following:
- You can’t purchase any new hardware of this type, including additional spares.
- New software versions won’t run on your hardware (e.g. V9.3.20 is the last version of the CFS/UMG software to support the 2510 / 3510 systems) so you won’t have access to any new features after this release.
- You will reach a date when no software patches will be available for your hardware.
- Eventually (November 2023 for many parts) we’ll reach a date when you won’t be able to receive replacement cards in the event of hardware failure – even if you have a hardware warranty contract.
On the other hand, it’s worth noting that you’re perfectly at liberty to continue using your current hardware as long as you like – you’re not required to upgrade, it’s just that you won’t be able to get much support from Metaswitch for your equipment.
If I want to upgrade what are my options?
You can go in three directions, or use a combination of the these approaches.
- Upgrade to ATCA hardware for all your equipment
- Purchase the Metaswitch vNow package to create a “done-for-you” mini virtual deployment.
- Build your own virtual deployment based on the Metaswitch Virtual Deployment Design Guide.
What are the pros and cons of each?
ATCA Pros & Cons:
- If you need TDM you can’t help but have an ATCA media gateway at least.
- This follows the traditional model vendors have used for decades. Metaswitch sell you a box that provides a certain function and they’re responsible to support both the hardware and the software.
- ATCA is pretty simple to set up and doesn’t require any new expertise on your team.
- BUT… ATCA hardware will also be retired at some point – so you’ll eventually need to go through this replacement process again.
vNow Pros & Cons:
- It feels similar to the traditional model (you purchase equipment from Metaswitch that does a certain thing) but you’re actually running a virtual deployment on Dell servers.
- While these Dell servers will obviously need to be replaced at some point you have broken the link to dedicated custom hardware, so they can be replaced with whatever Dell’s latest and greatest server is in 2025 (or whenever).
- BUT… you’re paying for the convenience of Metaswitch handling this all for you.
Build-your-own virtual deployment Pros & Cons:
- If you know what you’re doing, this gives you much more control over the scale and configuration of the deployment, and brings you fully into the NFV age.
- BUT… you take on a lot more responsibility for your infrastructure. Metaswitch are now providing you simply with software products (a set of VMs), and any issues with the hardware or VMware are all your responsibility.
Argh this is all too much – how do I decide?
Luckily for you, I’ve created a simple decision chart to help you decide. Of course in real-life it’s a little more complicated than this chart would have you believe, but this will help you to see some of the core elements that factor into your decision.
As I’ve written about before, this would all be a lot simpler if we could remove TDM entirely from our networks – as then you could deploy a genuinely virtualized network, using Media Resource Servers (MRSs) for announcements, with no custom hardware requirements. If you’re considering that path then read my linked article for some ideas on how to get started – otherwise you will inevitably be left with an ATCA media gateway in your network to handle your SS7 links and ISUP trunks.
However, your network is more than just the switch. Even if you still need a UMG, and maybe decide that you may as well keep that as an integrated CFS & UMG on ATCA, you can still move all your application servers (MetaView, SAS, EAS, N-series, Perimeta, etc) onto virtual machines, which will help you become familiar with the technology over the coming years while you wait for TDM to finally disappear.
A cautious approach
In fact, even if you’re able to move fully to a virtual architecture, there’s still a lot of sense in taking a phased approach. There’s no hurry here – so why not start by moving the less critical elements of your deployment, such as your MetaView and SAS, and then gradually expand your virtual network to include the N-series and EAS application servers, thereby giving you time to build confidence and expertise running a virtual network before you take the biggest risk in moving your CFS and/or MRS to VMware.
There’s a lot of hype about NFV, and it’s easy to get the impression that everyone’s doing it, and you’re a laggard if you aren’t fully virtualized. That’s simply not true – there are a lot of service providers who are looking at virtualization with some trepidation and some skepticism, which is entirely understandable. So you’re not alone.
If you’re feeling very trepidatious (no, that’s not a word…) and skeptical then it’s totally fine to move to ATCA for the next phase of your network evolution. But if you’re ready to head towards virtualization then you can feel comfort in knowing that you’re not the first, and in knowing that it’s entirely possible to create a cautious, step-by-step plan to gradually migrate your network to a virtual architecture, and that there’s no harm in taking things slow.