{"id":33,"date":"2019-06-29T18:29:11","date_gmt":"2019-06-29T10:29:11","guid":{"rendered":"http:\/\/mayanknauni.com\/?p=33"},"modified":"2019-06-29T18:29:11","modified_gmt":"2019-06-29T10:29:11","slug":"netdevops-introduction-and-a-working-reference-model","status":"publish","type":"post","link":"https:\/\/mayanknauni.com\/?p=33","title":{"rendered":"NetDevOps: Introduction and a working reference model"},"content":{"rendered":"<p><em>Disclaimer: &#8211; This note was written by me (Mayank Nauni)\u00a0in my personal capacity. The opinions expressed in this article are solely my own and do not reflect the view of my employer or my preference towards any of the OEMs.<\/em><\/p>\n<p>&nbsp;<\/p>\n<p>\u201cNetDevOps\u201d, another buzz word in the town, the real question is, is it yet another unicorn trotting on a stage with confetti flying around it?<\/p>\n<p>Let us ponder on some fundamentals questions from the network engineers.<\/p>\n<p><strong>My network works just fine, why do I need to change my ways of working? <\/strong><\/p>\n<p>Well, there are a few points I would like to share before we even start discussing what is NetDevOps.<\/p>\n<p><strong>What are our current network infra challenges? <\/strong><\/p>\n<ul>\n<li>We have a never-ending tussle between Agility vs Availability, the application developers have adopted the DevOps methodologies long back and hence are much more agile in the application development &amp; operations now but the title of weakest or slowest link in this end to end delivery chain has been passed on to the IT infrastructure. If we push changes to infrastructure quickly without performing a proper evaluation, we end up breaking production. Rings a bell?<\/li>\n<li>We have been Copy-pasting and hand-crafting configurations at the command line, which: &#8211;<\/li>\n<\/ul>\n<p>\u2022\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0is extremely error-prone<\/p>\n<p>\u2022\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Leads to inconsistencies across the network<\/p>\n<p>\u2022\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Validation \/ Assessment on CLI configs takes a long time<\/p>\n<p>\u2022\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Does not scale and not meant to support Agile methodology<\/p>\n<ul>\n<li>Matching pace due to Agility at other component layers (application) can result in massive outages due to less time for review<\/li>\n<\/ul>\n<p>In short, with the existing ways of working, network changes will fail because of the growing scale, complexity and rate of change.<\/p>\n<p>&nbsp;<\/p>\n<p>Because of all these agility related demands, more of the enterprises decided to go towards the cloud only to realize later that cloud is not an answer to all IT infra woes. With partial workload migration to cloud, application owners had experienced the benefits cloud brings to them, agility was noticeable difference besides cost and scalability. As I have mentioned in my earlier articles that not all applications can go over to cloud so now we have two infra components in most of the network, cloud and on-premise infra, there is a visible difference between both, on-premise infra and the associated OEMs had no choice but to step up their game, bring the same level of agility to the on-premise infra which always had better control than a public cloud.<\/p>\n<p><strong>Okay, I know the challenges now, but what are goal of our future Networks?<\/strong><\/p>\n<p>Most of the changes in the network today are recurring in nature, in most of the enterprises seldom engineers build something which is totally new and had no relevance to the earlier changes in the same network; so, the future network should:<\/p>\n<ul>\n<li>Use templates to ensure standardization, accuracy and predictability<\/li>\n<li>Handle bulk changes at faster pace that too error free, reduce the chances of human error by following an \u201cidiot-proof\u201d stencil<\/li>\n<li>Help us to achieve configurational consistency in repetitive changes<\/li>\n<li>Enable engineers to bypass CLI<\/li>\n<li>Be able to run repetitive automated tests<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p>Good news, software world had similar challenges and they have already addresses these issues by using <strong>DevOps methodologies<\/strong> which is: &#8211;<\/p>\n<p>\u2022\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Continuous Integration and Delivery (CI\/CD)<\/p>\n<ul>\n<li>Frequent individual integrations into master repository<\/li>\n<li>Automated build, test, deploy<\/li>\n<li>Identify errors as quickly as possible<\/li>\n<li>Many tools already available like Git, Jenkins, Ansible etc.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p><strong>Hold on, are you asking me to start my network engineering journey afresh again, from scratch? <\/strong><\/p>\n<p>In a way, Yes, but it will be quick and safe, how about following a working model rather than reinventing the wheel?<\/p>\n<p>Just because we have learned to do things a certain way doesn\u2019t mean we can keep doing it the same way to eternity, the usual ways of doing network changes are failing because of the growing scale, complexity and rate of change.<\/p>\n<p>Different teams have been speaking different languages in an enterprise environment, but not to mention they all have a common goal (though road towards the goal may be different), but disparity in the ways of working will always be a hindrance which often creates confusions and misunderstanding between the application and infra world.<\/p>\n<p><em>Wouldn\u2019t it be fantastic if we could find a common platform for all teams to collaborate, so that they could understand each other better? Well that is what I am going to talk about in rest of this document. <\/em><\/p>\n<p>&nbsp;<\/p>\n<p>&nbsp;<\/p>\n<p><strong>Can you tell me what is NetDevOps already?<\/strong><\/p>\n<p>Well gone are the days when we had fixed definitions in the IT industry, now experts coin new terms and rest of the world (another bunch of experts) interpret those terms the way they want, hence it is very difficult for me to define NetDevOps in a standard way, but the best possible standard explanation is: &#8211;<\/p>\n<p><em>\u201cNetDevOps brings the culture, technical methods, strategies, and best practices of DevOps to Networking.\u201d<\/em><\/p>\n<p>NetDevOps builds and manages a network that enables network services to be consumed in a DevOps approach, it is adopting \u201cContinuous Development\u201d approach to network changes.<\/p>\n<div class=\"slate-resizable-image-embed slate-image-embed__resize-full-width\"><img decoding=\"async\" src=\"https:\/\/media.licdn.com\/dms\/image\/C5112AQHheMxGkdX48g\/article-inline_image-shrink_1500_2232\/0?e=1567036800&amp;v=beta&amp;t=OEoK5Uve_dTxtmYyUAvpwGriWxbMm1mlz55apHWdmdA\" data-media-urn=\"\" data-li-src=\"https:\/\/media.licdn.com\/dms\/image\/C5112AQHheMxGkdX48g\/article-inline_image-shrink_1500_2232\/0?e=1567036800&amp;v=beta&amp;t=OEoK5Uve_dTxtmYyUAvpwGriWxbMm1mlz55apHWdmdA\" \/><\/div>\n<p><strong>What skills do I need to learn to become a NetDevOps engineer?<\/strong><\/p>\n<p>NetDevOps is so easy that even an average network engineer like me could set it up easily with little help from Google, I would like to simplify it for my fellow infra friends. We can start reading about these tools: &#8211;<\/p>\n<p>\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Git \u2013 Source Control Management<\/p>\n<p>\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Jenkins \u2013 Workflow Management<\/p>\n<p>\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Ansible \u2013 Configuration Management<\/p>\n<p>\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0EVE &#8211;\u00a0The Emulated Virtual Environment for Network, Security and DevOps<\/p>\n<p>\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Jinja2 \u2013 Configuration Template<\/p>\n<p><strong>1.\u00a0\u00a0\u00a0\u00a0\u00a0Git &#8211; source control manager<\/strong><\/p>\n<p>Git can be simply defined as a source control manager (SCM) or simply known as revision control. It manages changes to the configuration files, it can manage versioning for collections of information as well.<\/p>\n<p>The real question is that why is it so relevant to network engineers. The answer lies in the current practice of dealing with config files, left in some local directory, some remote disk or external disk and that is it.\u00a0Refer to these fantastic blogs: &#8211;<\/p>\n<p><a href=\"http:\/\/ipengineer.net\/2015\/04\/git-for-network-engineers\/\" target=\"_blank\" rel=\"nofollow noopener noreferrer\">http:\/\/ipengineer.net\/2015\/04\/git-for-network-engineers\/<\/a><\/p>\n<p><a href=\"http:\/\/onenetworkguy.com\/2016\/05\/17\/git-for-network-engineers\/\" target=\"_blank\" rel=\"nofollow noopener noreferrer\">http:\/\/onenetworkguy.com\/2016\/05\/17\/git-for-network-engineers\/<\/a><\/p>\n<p>Besides these wonderful blogs, I saw a bunch of videos on YouTube to understand how Git works (my favorite one is this by Kevin Wallace <a href=\"https:\/\/www.youtube.com\/watch?v=chzW0Zrlg44\" target=\"_blank\" rel=\"noopener noreferrer\">https:\/\/www.youtube.com\/watch?v=chzW0Zrlg44<\/a>) .<\/p>\n<p>The crux is: &#8211;<\/p>\n<p>1.\u00a0\u00a0\u00a0\u00a0\u00a0We have a master repo containing all production configurations<\/p>\n<p>2.\u00a0\u00a0\u00a0\u00a0\u00a0We create branches which are analogues to sub folders and test config changes in the branch<\/p>\n<p>3.\u00a0\u00a0\u00a0\u00a0\u00a0Once network engineer has tested his branch repo, he can merge it with the master repo which may be pushed to network devices later<\/p>\n<p>4.\u00a0\u00a0\u00a0\u00a0\u00a0Team can collaborate efficiently with Git<\/p>\n<p>5.\u00a0\u00a0\u00a0\u00a0\u00a0Git can be on cloud or on-premise, you get free public repo on GitHub and you get private repo by paying a bit every month; practice caution while you are using public repos, the whole world can see it.<\/p>\n<p>&nbsp;<\/p>\n<p><strong>2.\u00a0\u00a0\u00a0\u00a0\u00a0Jenkins &#8211; Workflow Management<\/strong><\/p>\n<p>So, we have two kinds of workflow in every environment i.e. documented and undocumented. Irrespective of reactive or proactive change, we must follow some process to implement the change and get the desired outputs.<\/p>\n<p>Workflow management software like Jenkins help us to achieve\u00a0<a href=\"http:\/\/en.wikipedia.org\/wiki\/Continuous_integration\" target=\"_blank\" rel=\"nofollow noopener noreferrer\">Continuous Integration<\/a>, which is a pillar of DevOps culture. It is very helpful to automate repetitive tasks (i.e. firewall changes, routing changes etc.), and create a feedback loops, so that future repetitions can be done more efficiently while insuring less errors. With the plethora of awesome plugins on it, Jenkins can interact with other vital components in the DevOps like, Git, Ansible, Spark etc.<\/p>\n<p>The tool is very intuitive and quite easy to install (I personally used a docker for it); I would recommend free videos on YouTube to understand Jenkins better.<\/p>\n<p><a href=\"https:\/\/www.youtube.com\/watch?v=Lxd6JMMxuwo\" target=\"_blank\" rel=\"noopener noreferrer\">https:\/\/www.youtube.com\/watch?v=Lxd6JMMxuwo<\/a><\/p>\n<p>A good read on Jenkins: &#8211;<\/p>\n<p><a href=\"https:\/\/www.infoworld.com\/article\/3239666\/devops\/what-is-jenkins-the-ci-server-explained.html\" target=\"_blank\" rel=\"nofollow noopener noreferrer\">https:\/\/www.infoworld.com\/article\/3239666\/devops\/what-is-jenkins-the-ci-server-explained.html<\/a><\/p>\n<p><strong>\u00a0<\/strong><\/p>\n<p><strong>3.\u00a0\u00a0\u00a0\u00a0\u00a0Ansible \u2013 Configuration Management <\/strong><\/p>\n<p>Ansible is the most popular network configuration automation tool, it is very popular among the network engineering ecosystem since it doesn\u2019t need an agent to operate. It can run playbooks, which are essentially new way of representing network configuration in YML format.<\/p>\n<p>In short, all repetitive work in your day to day tasks can be automated by using Ansible playbooks. Very hard to explain Ansible in words, here are some very interesting videos to learn more about Ansible: &#8211;<\/p>\n<p><a href=\"https:\/\/www.youtube.com\/watch?v=lUBPAGI9W6U&amp;t=1063s\" target=\"_blank\" rel=\"noopener noreferrer\">https:\/\/www.youtube.com\/watch?v=lUBPAGI9W6U&amp;t=1063s<\/a><\/p>\n<p><a href=\"https:\/\/www.youtube.com\/watch?v=6oG7SCX-q4A\" target=\"_blank\" rel=\"noopener noreferrer\">https:\/\/www.youtube.com\/watch?v=6oG7SCX-q4A<\/a><\/p>\n<p><a href=\"https:\/\/www.youtube.com\/watch?v=VYEVjKvMKqU\" target=\"_blank\" rel=\"noopener noreferrer\">https:\/\/www.youtube.com\/watch?v=VYEVjKvMKqU<\/a><\/p>\n<p><a href=\"https:\/\/www.youtube.com\/watch?v=_3XIp6bw58s&amp;t=471s\" target=\"_blank\" rel=\"noopener noreferrer\">https:\/\/www.youtube.com\/watch?v=_3XIp6bw58s&amp;t=471s<\/a><\/p>\n<p>&nbsp;<\/p>\n<p><strong>4.\u00a0\u00a0\u00a0\u00a0\u00a0EVE \u2013 The Emulated Virtual Environment for <em>Network<\/em>, Security and DevOps<\/strong><\/p>\n<p>EVE can create virtual networks which are very similar or almost equal to production networks. This has huge advantage for those who want to ensure that their solution will work before they go online. EVE practically supports nearly all device\u2019s virtual OS images.<\/p>\n<p>Testing your configuration prior to production deployment is one of the main pillar of DevOps culture.<\/p>\n<p><a href=\"http:\/\/www.eve-ng.net\" target=\"_blank\" rel=\"nofollow noopener noreferrer\">http:\/\/www.eve-ng.net<\/a><\/p>\n<p>&nbsp;<\/p>\n<p>&nbsp;<\/p>\n<p><strong>5.\u00a0\u00a0\u00a0\u00a0\u00a0Jinja2 \u2013 Configuration Template<\/strong><\/p>\n<p>Using\u00a0Python and Jinja2 to\u00a0automate network configuration templates is a useful way to simplify\u00a0repetitive\u00a0network tasks. In using this alternative method to\u00a0automate\u00a0recurring network changes we can remove the common error mistakes experienced in the copying\/pasting of commands into the CLI (command line interface).\u00a0You can find more details in the links below: &#8211;<\/p>\n<p><a href=\"https:\/\/blogs.cisco.com\/developer\/network-configuration-template\" target=\"_blank\" rel=\"nofollow noopener noreferrer\">https:\/\/blogs.cisco.com\/developer\/network-configuration-template<\/a><\/p>\n<p>&nbsp;<\/p>\n<p><strong>Okay, thanks for the overwhelming theory, but does it work?<\/strong><\/p>\n<p><strong>\u00a0<\/strong><\/p>\n<p>Well, yes it does. I am using a simplified NetDevOps deployment in my lab and would be more than happy to answer any queries regarding the same.<\/p>\n<p>\u2022\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0All config playbooks (.yml) are on a repo at GitHub<\/p>\n<p>\u2022\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Network engineer does modification in Dev branch<\/p>\n<p>\u2022\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Dev branch modified code can be tested on EVE \/ VIRL \/ GNS3<\/p>\n<p>\u2022\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Merge into master branch post validation<\/p>\n<p>\u2022\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Merge triggers the web-hook to Jenkins, triggers pipeline<\/p>\n<p>\u2022\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Jenkins downloads the repo from Github<\/p>\n<p>\u2022\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Ansible plugin on Jenkins fires the .yml file to deploy the playbook across the environment<\/p>\n<p>\u2022\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Jenkins Spark plugin sends success \/ failure notification to Spark chat room.<\/p>\n<div class=\"slate-resizable-image-embed slate-image-embed__resize-full-width\"><img decoding=\"async\" src=\"https:\/\/media.licdn.com\/dms\/image\/C5112AQGc-o1Vi1v1sg\/article-inline_image-shrink_1000_1488\/0?e=1567036800&amp;v=beta&amp;t=g_2qhW3dgkqXGveZyEHc6O33X6cCpyM1CnpirfX08zI\" data-media-urn=\"\" data-li-src=\"https:\/\/media.licdn.com\/dms\/image\/C5112AQGc-o1Vi1v1sg\/article-inline_image-shrink_1000_1488\/0?e=1567036800&amp;v=beta&amp;t=g_2qhW3dgkqXGveZyEHc6O33X6cCpyM1CnpirfX08zI\" \/><\/div>\n<p><strong>\u00a0<\/strong><\/p>\n<p><strong>That was cool, so are you telling me I am going to have NetDevOps in my organization without any major challenges? <\/strong><\/p>\n<p>Just like any other new methodology NetDevOps has its own bunch of challenges: &#8211;<\/p>\n<p>\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Cultural change may not be easy<\/p>\n<p>\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0NetDevOps requires network engineers to think differently, new set of skills are required i.e. Familiarity with source control, Ansible, Jenkins, Git etc.<\/p>\n<p>\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0The value of NetDevOps is only visible when it is 100% templated, so we have to be patient enough to see the value NetDevOps brings to an organization.<\/p>\n<p>\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Network Platform APIs not standard yet, so it is quite challenging in a multi-vendor environments. Most of the products in the network may not have all functionalities exposed via APIs which can be quite challenging from templating\u2019s perspective.<\/p>\n<p><strong>\u00a0<\/strong><\/p>\n<p><strong>Are there any NetDevOps learning portals I can refer to, to begin my NetDevOps journey?<\/strong><\/p>\n<p>Yes, plenty of them.<\/p>\n<p><strong>Cisco <\/strong><\/p>\n<p><a href=\"https:\/\/devnet.cisco.com\/\" target=\"_blank\" rel=\"nofollow noopener noreferrer\">https:\/\/devnet.cisco.com\/<\/a><\/p>\n<p>Ciscolive Presentation<\/p>\n<p>BRKDCN-2602<\/p>\n<p>Plenty of hands-on labs and videos by NetDevOps Genius, Hank Preston.<\/p>\n<p><strong>F5<\/strong><\/p>\n<p><a href=\"https:\/\/super-netops.askdelphi.com\/\" target=\"_blank\" rel=\"nofollow noopener noreferrer\">https:\/\/super-netops.askdelphi.com\/<\/a><\/p>\n<p><strong>GitHub<\/strong><\/p>\n<p>Ready to use codes from Hank Preston<\/p>\n<p><a href=\"https:\/\/github.com\/hpreston\" target=\"_blank\" rel=\"nofollow noopener noreferrer\">https:\/\/github.com\/hpreston<\/a><\/p>\n<p>&nbsp;<\/p>\n<p>I hope it was helpful.<\/p>\n<p>Mayank Nauni ( mayanknauni@gmail.com)<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Disclaimer: &#8211; This note was written by me (Mayank Nauni)\u00a0in my personal capacity. The opinions expressed in this article are solely my own and do not reflect the view of my employer or my preference towards any of the OEMs.&#46;&#46;&#46;<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_exactmetrics_skip_tracking":false,"_exactmetrics_sitenote_active":false,"_exactmetrics_sitenote_note":"","_exactmetrics_sitenote_category":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[4],"tags":[5],"class_list":["post-33","post","type-post","status-publish","format-standard","hentry","category-netdevops","tag-netdevops"],"aioseo_notices":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/mayanknauni.com\/index.php?rest_route=\/wp\/v2\/posts\/33","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mayanknauni.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mayanknauni.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mayanknauni.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mayanknauni.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=33"}],"version-history":[{"count":1,"href":"https:\/\/mayanknauni.com\/index.php?rest_route=\/wp\/v2\/posts\/33\/revisions"}],"predecessor-version":[{"id":34,"href":"https:\/\/mayanknauni.com\/index.php?rest_route=\/wp\/v2\/posts\/33\/revisions\/34"}],"wp:attachment":[{"href":"https:\/\/mayanknauni.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=33"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mayanknauni.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=33"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mayanknauni.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=33"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}