Welcome to the second in our series of posts about NetDevOps concepts! Don’t forget to go back and check out the introductory post if you haven’t already. This post is all about minimum viable product or MVP. MVP is a product management and software development concept that has made its way over into the NetDevOps world. It involves producing a product or solution that meets the minimum goals and milestones for success, then allowing for user/operator feedback to direct and inform future development. Only after delivering something focused and successful as the MVP do you build iteratively upon your previous work, guided by the received feedback, to add features or enhancements. The key to remember with this concept is that it is not just “minimum product,” it is minimum viable product.
If we are going to talk about a minimum viable product to achieve your NetDevOps goals, we need to talk about the concept of viability in a software project. Specifically for our use cases in NetDevOps, viability means a product or solution that can deliver the requested outcome consistently and in an automated fashion. For example, say that your initial goal is to programmatically manage VLAN reservation and deployment on switches in your data centers. A viable solution to this problem would not just reserve the VLAN, it would also need to deploy the configuration to the switches themselves. The solution would not be considered viable if only half of this goal is completed, perhaps just assignment of the VLAN but not the configuration.
As another example, say that your goal was to generate a report that listed all network devices with non-compliant AAA configurations. If you built a solution which generated the report, but also automatically remediated the non-compliant configurations, you have created a viable solution. However, it is not the minimum viable solution. While remediating the non-compliant devices may be the logical next step after identifying and reporting on them, it is not in the original goal. And as a result, you’ve performed work that was not scoped or planned for this stage of the project, and potentially misdirected time and effort that could be better spent elsewhere.
Many projects undertaken by engineers venturing into network automation and NetDevOps rapidly veer into the second example and attempt to “boil the ocean.” I have been guilty of this in the past, and given the chance to do some of my earliest automation projects again, I would dramatically reduce the scope and focus on delivering a concise and successful outcome for one use case. Then, once I had laid the groundwork for my MVP, I could build on that success to scale up rapidly to tackle additional use cases or workflows.
Accepting that building an MVP and iterating on it is a successful strategy to build your NetDevOps platform and tooling, one commonly asked question is “How do you scope the minimum viable product?” While every network is different in some ways, here are some simple ideas to help you determine what the minimum viable product might be for applying NetDevOps methodologies to your network infrastructure. If you are already well along with implementing NetDevOps concepts in your network, perhaps each time you look at including an additional workflow into your processes, consider the below and plan accordingly. While this is by no means an authoritative blueprint, it is meant to present the some ideas and concepts to keep in mind when thinking about minimum viable product on your NetDevOps journey.
Perhaps your network only has 50 devices in it, or maybe your network has 50,000. Either way, you must always start small. Chose a handful of network devices that you can manipulate at will. When scoping what your minimum viable product will solve for a given problem, consider what portion of the network you could live without. If the answer to the question, “What would happen if I took these devices down?” makes you sweat, probably do not start on those devices.
If your goal is, for example, to enforce a known/golden configuration on all user facing switch ports in your office environment, choose whatever qualifies as small for your environment (maybe a single office building or floor or even closet), and begin with those.
Evaluate the pieces of technology you’ll need to execute this plan, and start to build them out. Remember that just because we are “starting small” and building a minimum viable product, doesn’t mean there isn’t the potential for a considerable level of effort.
Perhaps you might need to:
These are not necessarily trivial steps, depending on your organization and the skills present there. Targeting a small group of devices in your MVP, and clearly scoping the requirements, will allow you to focus on acquiring any newly needed skills along the way as you build this infrastructure.
When you have built the tooling to successfully control the switch ports on your initial batch of devices, you can begin to expand your scope to include additional closets/floors/buildings in ever increasing batches. I have found that starting with a group of 10 to 15 devices and roughly doubling that total each time you feel comfortable to automate against more devices, can quickly bring even the largest fleets under management of your NetDevOps tooling.
Working in this iterative fashion helps build up confidence in your tooling and infrastructure, not just from yourself or your team, but from the business at large. Everyone has heard some horror story about network automation run amok and bringing down a business, and that organization swearing never to try automation again. By starting small and building a highly tested and trustworthy MVP, you can begin to build trust among even the crustiest of CIOs.
Say that you have configured tooling to automatically apply the known “golden” configuration to your users’ switch ports; however, a new version of the network device operating system utilizes a slightly different syntax. How do you know this is a problem prior to breaking network access for thousands of users? Testing, testing, testing!
Even if you are building something simple and small, you must include tests at both the code level (unit tests) as well as at the network level (integration testing). Having a well thought out, automated, and fully implemented test plan is absolutely crucial to being able to trust your NetDevOps infrastructure, processes, and workflows. Without testing in place, you are simply hoping that nothing will ever change on your network, and we all know that is simply wishful thinking.
Setting out from the beginning to build a solution as described above may be beyond your current skill set. Even if it is something you have skills or experience with, it may be more than you have time for all at once. Breaking it into deliberate, functional pieces and working towards a minimum viable product will allow you to deliver functionality quickly, and rapidly build your skill set along the way. In practice, sometimes it may not be that clean-cut, and you certainly may need to adjust your goals or targets and increase the scope of the project.
Bear in mind, even if you have to moderately increase the scope of your project outside the originally planned MVP, that you will still be delivering a focused and successful outcome with measurable value to your business. Once you have proved your NetDevOps chops to your business at large via a minimum viable product, they will be more inclined to trust you to automate larger and more impactful portions of the network environment.
If this all sounds wonderful but outside the realm of the possible, remember that everything I talked about above is completely possible. These are the kinds of problems that we at Network To Code help our customers and partners tackle every day.
-Brett
Does this all sound amazing? Want to know more about how Network to Code can help you do this, reach out to our sales team. If you want to help make this a reality for our clients, check out our careers page.
Share details about yourself & someone from our team will reach out to you ASAP!
