The Rules of Network Automation - Interop/NYC 2014
8 likes3,757 views
The document discusses network automation, noting that while network operations are currently very painful, automation can provide business benefits like velocity, agility, stability and lower costs. It evaluates options for automation, from vendor products to building from scratch, and advocates learning from other fields like DevOps that have successfully adopted automation. The document concludes by urging readers to start planning their network automation initiatives now while keeping in mind that culture change and seeing results will take time.
More Related Content
Similar to The Rules of Network Automation - Interop/NYC 2014 (20)
The Rules of Network Automation - Interop/NYC 2014
- 1. The Rules of Network Automation … more what you’d call guidelines than actual rules … Jeremy Schulman @nwkautomaniac
- 2. Automation for Network Operations Why should you care? How painful is automation today → future? What are your options? Who can we learn from? When will you take action?
- 3. Why should you care?
- 4. Does your business fail when your network fails?
- 5. ... knowing you must automate your network operations
- 6. Business Value ⇔ Automation ● Velocity ● Agility ● Stability ● Lower Costs ● Reduce Risk ● Improve Service
- 7. Velocity How quickly can you service existing market demands? ● Instant gratification ● Customized experience
- 8. Agility How quickly can you address new and changing market opportunities?
- 9. Stability Can you balance continuous operation while supporting velocity and agility?
- 10. Automation ⇔ Make IT or Break IT Server + Cloud is agile and automated Network is the bottleneck “unicorn” companies everyone else
- 11. How painful is automation today → future?
- 12. Network Operations is Very Painful Missions: Deploy Network Services High Risk Complex Tasks Low Risk Simple Tasks Configuration Management “config” Situational Awareness “show” Distributed (blast radius ≥ 1) Isolated (blast radius = 0)
- 13. Tool Choices Today are Painful Vendor Lock-In Build from Scratch
- 14. Operations → More + Painful + Complex Switching Firewall Routing Load balancer Multi-Vendor APIs Cloud Networking Virtual Networking Network Infrastructure
- 15. NetOps Caught in the Chasm ● Not programmers ● Frustrated ● Disenfranchised
- 16. What are your options?
- 17. Automation is like Ice Cream ● Everyone wants it ● Everyone wants something different ● No one wants to make it ● No one wants to clean up the mess
- 18. Mission: Banana Split For kids birthday party Factors: ● Buy vs. build ● Customized experience ● Instant gratification
- 19. Option 1: Vendor Product Ice cream shoppe ● Instant gratification ● “As Is” ● Vendor builds ● Vendor cleans-up
- 20. Option 2: Framework Product Self service froyo shoppe ● Near instant gratification ● Vendor provides a lot ● Customer builds too ● Customized experience ● Limited by options ● Assembly can get messy
- 21. Option 3: Build from Components Grocery store ● Customer “shops” and “builds” ● Delayed gratification ● Good customized experience ● Lot of effort to build ● Lot of clean-up
- 22. Option 4: Build from Scratch Do it yourself ● Very delayed gratification ● Make exactly what you want ● Best customized experience ● Maximum effort ● Maximum clean-up
- 23. Choice & Control vs Time & Effort Choice & Control Time & Effort Product Scratch Framework Component
- 24. Cooks | Chefs Must NetOps be Programmers?
- 25. People who Eat Food Home Cooks Professional Chefs ● Cook: career is making food for others ● Passion: cooking ● Formal training: yes ● Cook: they need to eat ● Passion: family, hobbies, ... ● Formal training: no
- 26. Home Cooks Home Cooks Chefs focus on family for others too Skills and Expertise Can only use a microwave - pizza, chicken nuggets Competes at national level Hosts dinner parties w/friends < 1%
- 27. Professional Chefs Cooks Professional Chefs focus on food on business too graduated chef school executive chef owns restaurant Iron Chef Skills and Expertise < 1%
- 28. Lessons Learned ● Network Engineering is a craft ● Software Engineering is a different craft ● Both take years to develop for expertise ● People | Process | Environmental factors ● Culture change takes a long time
- 29. Who can we learn from?
- 30. Study the past if you would define the future. -- Confucius
- 31. Code | Culture | Community ● Application developers and server operations ⇒ Tools ● Codify tribal knowledge into collective reuse and sharing ● Empower culture change and build communities (“DevOps”)
- 32. Developer + Operations (DevOps) Missions: Deploy Applications Application Lifecycle Management Application Performance Monitoring Server Config Management (Puppet, …) Server Monitoring Tools Configuration Management “config” Situational Awareness “show” Developers (blast radius ≥ 1) Operations (blast radius = 0)
- 33. Lessons Learned ● 25% - DevOps coverage for NetOps ● Networking ⇒ distributed, API orchestration ● Need better tools for NetOps (inspired by DevOps) ● Need better Vendor-provided components ● Culture change takes a long time
- 34. When will you take action?
- 35. When to Automate Networking? Emerging Technology and Products committed projects now or very soon
- 36. Considerations ● You must plan your automation initiatives ● Invest in your team that embrace change ● Make automation part of your team’s bonus ● Invest in equipment built for automation ● Invest in new software tools for your team ● Be patient, results take time
- 37. Summary ● Start planning network automation now ● Review existing manual processes ● Apply 80 / 20 rule ● Watch for new frameworks and technology