Network Automation Trade-offs: Build, Buy, or Blend?

In a recent discussion thread, Roman Dodin posed a question to the Network Automation Forum (NAF) community about a framework he had seen in Nokia presentations: DIY (Do It Yourself), DSY (Do Some Yourself), and DNY (Do Nothing Yourself).

This article summarizes the ensuing conversation where community members shared their personal experiences and perspectives on this topic.

The DIY Challenge

Many organizations create dedicated Network Automation teams with the expectation that these teams will build automation solutions in-house rather than purchasing vendor products. As one community member noted, there's a sentiment of "We pay you to not pay others."

This approach presents several challenges:

1. Resource constraints - Unlike hyperscalers who can assign dozens of developers to a problem, most network automation teams are small (under 10 engineers).

2. Sustainability concerns - As one participant colorfully put it, "The distance between 'let's have our own X' to 'who's gonna maintain our own X when John is out' is not that big."

3. Scale limitations - In-house solutions often start as small scripts but struggle to scale as requirements grow.

4. Expertise mismatch - "Somehow some orgs thought that having networkers with scripting background means that they can build platforms. This may be the case in some situations, but building platforms is not a small feat."

The Middle Ground: DSY

Many NAF members advocated for a balanced approach where organizations:

1. Buy off-the-shelf when appropriate - "We buy off-the-shelf if the price is correct like that we have the vendor support. But the glue and smaller projects remain DIY."

2. Focus on integration - In-house teams can create the most value by combining platforms and tools rather than building everything from scratch.

3. Leverage low-code/no-code tools - "On the DSY side the Locode/Nocode space is pretty vibrant now... with different options with different pros and cons."

4. Use existing frameworks - Several participants mentioned workflow systems like Temporal as promising foundations for network automation.

The Open Source Factor

Open source is often seen as a "free" alternative to commercial products, but NAF members highlighted important considerations:

1. Maintenance burden - "The beginning with open source is easy but over time you need to maintain which brings also a cost and challenges."

2. Abandonment risk - Several mentioned instances where key dependencies were abandoned by maintainers, creating significant risks.

3. License changes - Recent examples like the NATS project controversy show how licensing changes can disrupt dependency plans.

Vendor Lock-In Reality

A particularly insightful observation challenged the notion that building in-house escapes vendor lock-in:

"What I think is a terrible misnomer is that doing something in house (all or some) is some defeat of vendor lock-in. It's just a different kind. So a business case that claims it's escaping the gravity of vendor lock-in is kinda dangerous. You're locking yourself as the vendor."

Licensing and Business Case Challenges

The discussion revealed why making the business case for purchased solutions can be difficult:

1. Licensing models - Per-device or per-seat licensing often doesn't scale economically for large networks.

2. OpEx vs CapEx tensions - "Vendors want ARR, which means subs. Mid to large businesses want CapEx, not OpEx."

3. Quantification challenges - "We are great at comparing real numbers and less so with imaginary ones. And I can see how quantifying two approaches is nearly impossible to make the sought-after business case for the leadership to invest in the network automation."

Practical Recommendations

From the collective wisdom of the NAF community, several practical recommendations emerged:

1. Be realistic about in-house capabilities - "When you want to DIY/DSY, put your own team up as a 'vendor' for side by side and be realistic about the capabilities."

2. Consider critical path dependencies - "You shouldn't blindly buy any vendor solution but you need to see the value it brings to you and do risk management. Anything that can break and cause customer impact is for us a reason to go for something from a vendor."

3. Evaluate the total cost of ownership - Including maintenance, upgrades, and opportunity costs of having your team build versus focusing on other initiatives.

4. Use vendor solutions for device-specific functions - "Vendors are mostly the best on doing things on their devices but rarely on other vendors."

Conclusion

There's no one-size-fits-all approach to network automation strategy. The right balance of DIY, DSY, and DNY depends on your organization's scale, capabilities, budget, and business requirements.

As one NAF member succinctly put it: "Somewhere you need people with clue gluing stuff together."

Whether you build, buy, or blend, successful network automation requires skilled practitioners who understand both the technical and business dimensions of your automation challenges.

---

Contributions to the Slack thread that lead to this post came from NAF community members: Roman Dodin, Tyler Bigler, Scott Whyte, John Howard, Kurt Wauters, Steinn Örvar, Urs Baumann, Ivana Duvnjak, Ryan Shaw, Dan Peachey, Mark Prosser. These perspectives represent individual viewpoints rather than official positions of any organization.

Join the NAF Slack to jump into the conversation today!