How can network engineers make virtualization platforms easy to use?

Choosing the right virtualization platform is key for network engineers to ensure ease of use. The platform should align with the organization's specific needs and existing infrastructure. For instance, VMware vSphere is a popular choice for its extensive features and robust ecosystem, ideal for complex environments. In contrast, Microsoft Hyper-V might be more suitable for Windows-centric environments. Simplicity, scalability, and compatibility with existing systems are crucial factors. In my experience, using VMware in a mixed operating system environment streamlined operations significantly. The chosen platform should have a strong community or vendor support, which can drastically reduce the learning curve and enhance usability.

As a Linux enthusiast, I tend to lean towards Proxmox, which utilizes the Qemu and LXC combination. Even the free community version is fully functional, offering features like the ability to build an HA cluster. While it may not excel in resource management, it can still be used at a service provider level. However, as we know, a virtualization platform runs on a server, and it must provide accessibility to various resources. Whether we like it or not, this is the essence of the entire concept: What options do we have for this? For instance, under Linux, I can use the native virtual bridge of the base operating system or even the Open vSwitch device manager -> meaning the complexity of the environment is scalable.

In the context of a social network, network engineers can enhance the usability of virtualization platforms through a user-centric approach. Simplify the user interface by providing intuitive controls and a straightforward setup process. Offer comprehensive documentation and tutorials to guide users in deploying and managing virtualized resources seamlessly. Implement automation features to streamline routine tasks, reducing manual efforts. Foster an engaged user community, encouraging collaboration and sharing of best practices. Regularly gather user feedback to iteratively improve the platform's usability, ensuring that it aligns with the specific needs of a social network environment.

Explore the GitOps approach and its methodologies. While it wasn't originally designed for building virtual networks, what you can achieve through the command line can be declaratively implemented with proper automation. This not only saves a considerable amount of time but also results in a more stable and error-free system if done skillfully.

Documentation is probably the most overlooked aspect of any network deployment scenario. Typically the initial design is well documented, but the as built system is rarely a 100% match for the initial design. Make sure that the as-built system gets documented. Documentation should not only include how to work with the as-built system but also should include design decisions (i.e. capture the tribal knowledge around decisions). Someone at some point in the future is going to have to change, enhance or extend the system. When documenting the system make sure you document not from a system designer standpoint but from the prospective of the user of the system. Don't assume a level of knowledge equal to your own.

GitOps again: since the infrastructure is declaratively described, it essentially documents itself. If not, you might have done something wrong. Moreover, if you are clever, the meaningful part of the documentation can be generated based on the raw code. Also, because the automation triggered by code changes modifies the infrastructure, adding documentation generation to the automation is not a big task. This ensures that the documentation of the infrastructure created with the GitOps approach is always up-to-date under all circumstances. And yes, I am lazy.

To understand how I work: let's say I have an infrastructure description in a Git repository with three main branches: main, devel, and release. Suppose I want to do something on the current devel branch. In this case, I create a feature branch, work on it, and push the changes. This triggers the infrastructure to be built in a devops-dev namespace with an f123 prefix. The validation tests run, and if successful, the entire setup is deleted. Only bug-free code can merge into the devel branch. So, I can experiment and attempt to achieve the right configurations without falling into the trap of forgetting to document something or missing a step during one of those 625 clicks... :D