Following on their success in the data center, virtual firewalls are now being deployed to protect the North-South links in your private network. If you automate both the conversion of your physical firewalls to virtual ones and the on-going creation and removal of virtual firewalls as network needs change, the advantages of going this route are very compelling. Automated firewall virtualization with a turnkey platform promises lower Total Cost of Ownership (TCO) and faster time to deployment when you convert your physical firewalls to virtual ones (you can check out the TCO analysis here).
But, many organizations still try a do-it-yourself (DIY) approach when it comes to virtualizing their firewalls, as they believe their deployment will be different. Aside from the fact that a DIY approach is an intensive drain on scarce engineering resources, there are three pitfalls that should be factored in when you consider a DIY project: technical debt, deployment and configuration errors, and the lack of ongoing support.
DIY Virtualization: The Steps
DIY virtualization of your network firewalls —while it may seem a straightforward exercise for a single firewall—doesn’t scale and is not easier, quicker or cheaper. There are a significant number of steps and workflows required to create a system that automatically converts your physical firewalls to virtual equivalents, and then orchestrate, manage and support them as your network evolves over time. Let’s recap the main ones here:
- Specification and purchase of server hardware optimized for network security
- Configuration and optimization of hypervisor software for firewall virtualization
- Orchestration and automation to Bootstrap and initially configure NGFW VMs
- Integration of licensing from vendors into the orchestration and automation
- Provisioning of configuration and policy settings to the VMs in a zero-touch way
- Health check mechanisms to monitor VM & system performance
- Automation of firewall configuration migration
- Single-pane-of-glass VM orchestration & monitoring GUI
- Testing and validation of firewall VM platform
- Maintenance of platform compatibility with firewall VM revisions
The list is definitely long and don’t forget that each step requires development from a whole team of experts in network engineering, security, systems integration and DevOps. That’s a lot of engineering expertise and person hours.
DIY Virtualization: The Pitfalls
If this development process isn’t intimidating enough, there are three other considerations which IT leaders may be forgetting when it comes to choosing between DIY and an automated solution.
1. Technical debt
Also known as design debt or code debt, technical debt is the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach in the first place. While you may be opting for DIY because you think it’ll give your organization exactly what you need, or you’re convinced it’s going to be a quick project, you need to recognize that today’s scripts and playbooks are tomorrow’s technical debt. The challenge is not only developing the scripts but also testing, validating and maintaining them. You’ll need a greater headcount and level of expertise, especially if you have multiple devices to manage. DIY might feel like you’re getting ahead quicker now, but ask yourself: what’s the long-term cost?
2. Deployment and configuration errors
With DIY there is much more room for human error. Finger defined networking, or “the use of the command line on network devices for configuration and operations” lets more bugs through. As Greg Ferro, host of Packet Pushers Podcast who coined this term, explains, “CLI won’t be able to scale as the number of devices increases.” It might be fine to choose DIY for one device or a small network, but when you’re dealing with a large, complex, distributed network and multiple vendors and architectures, it becomes inefficient. You end up stitching together different pieces and come away with a messy patchwork. Plus, DIY deployment can take longer—due to those bugs which need fixing—and require more staff members and longer working hours. This raises stress, lowers morale, and lead to higher turnover. It can also contribute to a risk-averse culture where engineers are reluctant to try innovative approaches, for fear of being the cause of deployment or configuration problems.
3. No ongoing support
DIY also means traditional network engineers not only need to have expertise in new software and DevOps but also support services. While developing and when deploying, there’s no support from a vendor; you are the support team. It’s your engineers who have to fix the bugs at 2am. This also exacerbates stress and lowers morale.
But, here’s the real breaking point for DIY: Operationally, you can only make changes in very limited maintenance windows and it’s tough to know that your DIY tweaks will actually make it in and not be riddled with bugs.
How to avoid these DIY pitfalls
In contrast to DIY virtualization, a turnkey platform democratizes automation. It removes the technical complexities and stumbling blocks of a DIY approach, making it accessible for everyone in the team. It’s low, or no-code. You no longer have to worry about and manage every single device. You don’t have to master all the different types of scripts, frameworks, databases. You don’t need rock stars to make it work; everyone can be a power user.
Which also means you can spend your time, energy, resources, and mental bandwidth on strategic digital transformation initiatives instead of maintaining and supporting a DIY project. It solves the ‘time to value’ equation, meaning you spend your time on the most valuable activities, thereby increasing efficiency and ROI. You’re going to pay for virtualization one way or another, either in manpower (and all the other unaccounted costs) by going DIY, or by investing in an automated platform. An investment which will significantly reduce your TCO, speed time to deployment and free up your time. You choose.