Implementing Network as Code (Video 2 of 3)
Transcript
>> All right, thanks for joining us in our second video in a three-part series sponsored by Juniper, where we're talking about network as code. We're going to go into a little bit more detail on implementing network as code. We're going to cover three topics, tools and technologies. So what's out there, infrastructure ass code. We're going to re-address this topic a little bit more detail that we did in video one. And then configuration management with network as code. This is I think, one of the best benefits of the solution.
I have with me, Ned Bellavance, Ned in the cloud. Ned, are you still doing your Terraform Tuesdays? >> I am, I am. Thanks for asking. Yeah, every three Tuesdays a month I do Terraform Tuesdays on my YouTube channel where I tackle a different Terraform related topic. Some of them are very fundamental topics if you're just getting started in Terraform and some cover more advanced things for those who have been practicing for a while. >> So Ned, let's talk about some of the tools and technologies as it relates to network as code.
In the first video we know we kind of separated the concept of DevOps in tools. We use tools to implement DevOps types of management style, or operations. Let's talk about kind of the frameworks around network automation. >> Sure I mean, there's certainly the vendor specific network automation frameworks and each vendor's going to do it differently. And those tend to be somewhat specific to just their products. But there's also more general purpose ones. For instance, a lot of folks like to do their automation using Ansible, because Ansible doesn't require the installation of an agent.
So you can reach out to your networking gear as opposed to communicating with an agent that is already running on that network gear. Another popular, I won't say framework, but a popular language is Python. A lot of folks in the networking community have really latched onto Python, and I think that's in large part because it's relatively easy to get started with and it also has a scripting feel as opposed to some other languages that are more just difficult to pick up and use right away.
So that's another popular framework, or programming language for performing network automation. And then you have things like Nornir, and there's a few other frameworks out there that can help you with that process as well. So those would be all the sort of languages and frameworks. But then there's also ancillary things that will help you with your network automation. Like where are you going to source the code? How are you going to automate that code? Do you have an automation pipeline that you're plugging it into to do your CI and CD?
And then what are you using from a monitoring perspective to validate the changes and make sure that your network is healthy? So it all forms one kind of large construct. It's not just one tool that's going to do the entire thing. It tends to be a collection of tools and products and solutions. >> Yeah, and there's a bunch of open source tools and I think it's really important to understand the difference between a tool and a framework. A framework can be independent of a tool and a tool can be independent of a framework.
But I think it's been pretty consistent if you adopt a, at this kind of early stage of infrastructure as code, network as a code, if you're adopting a specific tool, from my experience you're adopting that framework that the tool was built to support. Is that a fair assessment? >> I think each tool is going to have its preferred workflow and its preferred way for interacting with the existing network. And when you think about actually starting to use network automation it's not likely that you're moving to a greenfield environment where you don't have any network devices to start with.
So the first portion of it is, how do you bring your existing real estate under management? And each framework's going to have its own way of doing that. Some are going to be slightly more painful to do than others. And then once you actually do bring it into the network automation framework, what's the preferred workflow for pushing changes to the environment? What's the way that you go about testing those changes? And what's the process for rolling back if a change goes wrong?
Each one is going to have a slightly different process for doing that. And I think the frameworks can be pretty opinionated in terms of how that's done. >> So this goes into some key principles around infrastructure as code in general. I think the promise, the ultimate promise, of any infrastructure as code project is that it abstracts the infrastructure from the intent, the design intent. Like there's what I want to do and then there's what I'm doing it on. So whether it's Amazon, AWS, Google Cloud Azure on-premises, a specific network vendor, there's the intention and then there's the configuration of the intention.
And I think a great tool, I don't know if we're there, a great tool will allow me to apply that intention no matter what infrastructure I'm pointing to. >> I think there's a spectrum, because that's a very interesting point you're pulling out, is I know what I want. But each Cloud vendor, each network vendor is going to implement that feature a little bit differently. And so different infrastructure as code tool sets approach this at varying levels of abstraction. So you could have one infrastructure as code tool that works across all the different vendors, but it doesn't try to abstract away the underlying components of that particular vendor.
It's saying, yes, I can configure a VPC in AWS, I can set up your VMware networking, but the way that I do it is I'm going to expose those primitives to you. You tell me how they should be configured and I just make it go happen for you. So you declare what you want, I'll go do the hard work, but I'm not abstracting away the underlying core pieces of that technology. But there's other infrastructure as code tools that take the approach of, we have a layer of common functionality across all these different platforms.
So what I'm going to expose to you is that commonality of features. You describe where you want it deployed, and what you want deployed. And I will interpret that through that abstraction layer into how it's actually implemented on the platform that you're pointing me at. That can be very difficult to do. And you do lose a certain level of specialization that exists on those different platforms. If that specialization is important to you, then you're going to go with a tool that doesn't hide the abstractions.
But if you're like a server is a server is a server, I don't care about the underlying specialties that each cloud or platform brings to me, then you can go with one that does abstract those things. And it's not uncommon for like a platform engineering team in an organization to work with a tool that has no abstractions that is just working down in the deeps. But then what they present up through like an internal developer portal to the application teams it's something that is highly abstracted, because the application teams don't care and they don't want to know exactly how it's implemented in each platform.
>> So the platform team absolutely cares. And I think we can give two different examples. One from the server world and another one from the networking world. In the server world, whether we're dealing with AMD, Zion, ARM, nitro, et cetera we want the benefits of accelerators, of low efficiency, et cetera. We don't want to deal with the details of how that's achieved. The cloud providers hide that from us. But we do have to at the minimum select the right instance type.
So while the developer might just want T-shirt sizes, the platform team specifically knows, Hey, I want Zion Amex acceleration for AI because that's the type of workload that we do. And these are the types of instances in AWS that supports that. That detail, the developer doesn't need to know. The platform team absolutely needs to know and they need to work with the infrastructure as code platform that delivers that level of granularity. Now, even getting more granular than that and it's networking.
If I'm configuring a VXLAN underlay, or overlay, and I want to configure the physical network, the number of overlays a platform when they switch supports matters, or may matter. If I can only support 500 overlays and I'm building thousands, I'm a multi-tenant organization, and I'm building thousands of overlays, I want that capability exposed. I want to know if I can do packet level inspection, et cetera, et cetera. Whatever feature switch levels we feature, it can even be a switch within the same family of switches.
They're going to have different features, and it matters when we're talking about the underlay. >> Right, and that's why you have things like, you know, platform as a service, where someone has basically built a solution that gives you, the developer, or the consumer, the T-shirt sizes, it gives you the silver, bronze and gold classes of performance or whatever. And underneath they're concerning themselves with the actual hardware and software that's running directly on those systems and just giving you a template that you can consume to get the service that you want.
So, you know, whether you buy that platform from a vendor, or you're just renting it through a subscription, I think it's fairly common for us to now consume things in an abstract way and rely on a platform team, or a third party vendor to give us that shim, that abstraction that's between the physical hardware and low level operating system and how we actually want to consume it. >> So let's talk about configuration management. Let's give something, we talked about in kind of, you know, the application developer, the platform team.
But as we know, operations is what keeps the world moving like the knock. And one of the most frustrating aspects of managing a large network, or even a small network is configuration management. We have plenty of tools on the, I think storage and server side and even VM side to manage configuration. But the network side has been kind of lax, 'cause we have these different, you know, we can have a hundred different switches and network devices with slightly different configurations and understanding that there's not like a really gold image that stays in every single server.
And we're doing diffs between that gold image. They're kind of, it's like wrangling cats >> Can be, yeah, that's certainly the case. Someone could go, "Oh, there's a problem. And so I'm going to go troubleshoot that problem on the network. And so I'm going to log into these two switches and add some additional monitoring. " No. >> Oh yeah. Why is this switch CPU running so high? Oh, I turned on monitoring two months ago and I forgot to turn it off.
>> Exactly, right. So the idea behind configuration management is being able to declare how you would want ideally a particular device, or set of devices to be configured. And then it's up to the software to do the imperative portion, which is actually go out and make it so. And usually that imperative portion has three different functions in it, get, set and test. And I've had to write these tests myself, or write these functions myself in different cases. The test simply looks at what you've declared and the actual state of that device and goes, do those two match, yes or no.
The get is what allows it to actually go out and get that information from the device to run the test in the first place. And then the set is, okay, I've determined that they're different and now I want to take what's in the configuration and push it to that device. And so that would be the set function. So that's basically what all these configuration management tools do is you define something declaratively, they get the config, they test the config, and then if there's a difference, they set the config.
>> So that sounds a lot like the CICD process over in the development side. Like there's the existing code that's running, there's the code that we want to deploy, and there's the detecting if there's a delta between it, and then there's a bunch of other tests. How should we think about kind of of this advanced topic of CICD when it comes to network automation network as code? >> I think there's a key difference between the software development, the application deployment lifecycle and the update and management of network configuration.
And probably the biggest thing is you can deploy multiple versions of your application side by side, and you can do something like blue-green testing. You can do something like canary rollouts. So you can over time move to a newer version of the application, while keeping the previous version up, and easily roll back if something goes wrong. And modern tool sets like what we have in Kubernetes, where you can do that sort of phased rollout and roll back if you need to make it really easy to do that with applications.
I highly doubt that most organizations run two of every network device so that they can do this. So when you are talking about the continuous integration, continuous delivery and deployment process of your network configuration, there needs to be a ton of testing in that pipeline to thoroughly vet the updated configuration to do a plan, or some sort of dry run to determine the actual changes that are going to be applied. And then do some sort of, as it rolls out testing, to verify that the network is functioning properly as it rolls out and have a way to roll back.
Because this isn't like an application where I can have two versions run at the same time. I've got one version of my network and that's the one that's carrying everything else. >> Yeah, the network is definitely a pet. Even if we borrow some of these concepts from the software development world the network itself is a pet. I have one internet connection to AT&T. I have one internet connection to my business partner. Even if I have multiple switches there are many single points of failure.
And quite frankly, you know, if I update the version of OS on my switch and I need to roll back, that switch is going to be down for the time that I need to roll back. So a lot of this, a lot of the CICD process we may borrow from software development, but the way that we test it is very different. And some of the simplest things, such as validating a configuration change makes sense. Like, I can't tell you the number of times that I went to make a configuration change on a switch, the commands made sense in my mind.
I made the change and they were accepted, but they broke the network. We can't test for every scenario yet, but that basic check needs to be part of our version of CICD in the network world. >> Absolutely. >> All right, so that wraps up the video in the three-part series. We talked about tools and technologies, infrastructure as code, some basic principles. And we even gave our operations folks some candy by talking about configuration management, slapping the hand of those folks who try to make changes directly.
Remember, use the infrastructure as code tool to make all changes, otherwise, the next time you go to deploy. " The tools that you select should be able to do all of that or you have processes to do that stuff. In the next video we're going to talk about advanced topics and network as code, network testing and validation. So we're going to dive a little bit deeper into configuration management, CICD, network monitoring and analytics. And then finally the most important topic, security and compliance.
I promise you that section, for those of you who've ever had to answer audit requests, you want to see that module in the next video. Talk to you soon.
