Implementing Network as Code, Part 2 of 3

Introduction

0:02 foreign

0:08 thanks for joining us in our second

0:11 video in a three-part series sponsored

0:14 by Juniper where we're talking about

0:17 network is code we're going to go into a

0:19 little bit more detail on implementing

0:22 Network as code we're going to cover

0:23 three topics tools and Technologies so

0:26 what's out there infrastructure is code

0:28 we're going to re uh address this topic

0:33 a little bit more detail that we did in

0:35 video one and then configuration

0:37 management web network is called this is

0:39 I think one of the best benefits of the

0:43 solution I have with me Ned bellavist uh

0:48 Ned in the cloud

0:49 are you still doing your terraform

0:51 Tuesdays I am I am thanks for asking

0:54 yeah every uh three Tuesdays a month I

0:58 do terraform Tuesdays on my YouTube

1:00 channel where I tackle the different

1:01 terraform related topic some of them are

1:04 very fundamental topics if you're just

1:07 getting started in terraform and some

1:08 cover more advanced things uh for those

1:11 who have been practicing for a while

1:13 so now let's talk about some of the

1:16 tools and Technologies as it relates to

1:18 network as code in the first video we

1:20 know we kind of separated the concept of

1:22 devops and tools we use tools to

Frameworks

1:25 implement devops types of

1:29 uh of management style or operations

1:34 let's talk about kind of the Frameworks

1:37 around Network automation

1:40 sure I mean there's certainly the vendor

1:42 specific Network automation Frameworks

1:44 uh and each vendor is going to do it

1:47 differently and those tend to be

1:48 somewhat specific to just their products

1:51 but there's also more general purpose

1:53 ones for instance a lot of folks like to

1:56 do their automation using ansible

1:58 because ansible doesn't require the

2:01 installation of an agent so you can

2:03 reach out to your networking gear as

2:06 opposed to communicating with an agent

2:08 that is already running on that Network

2:10 gear uh another popular

2:13 I won't say framework but a popular

2:15 language is python a lot of folks in the

2:17 networking Community have really latched

2:19 onto Python and I think that's in large

2:21 part because it's relatively easy to get

2:24 started with and it also has a scripting

2:26 feel as opposed to some other languages

2:29 that are more just difficult to pick up

2:32 and use right away so that's another

2:34 popular uh framework or programming

2:37 language for performing Network

2:39 Automation and then you have things like

2:42 nor near and there's a few other

2:44 Frameworks out there that can help you

2:46 with that process as well so those would

2:48 be all the sort of languages and and

2:51 Frameworks but then there's also

2:52 ancillary things that will help you with

2:55 your network automation like where are

2:58 you going to Source uh the code how are

3:00 you going to automate that code do you

3:02 have an automation pipeline that you're

3:04 plugging it into to do your CI and CD

3:07 and then what are you using from a

3:09 monitoring perspective to validate the

3:12 changes and and make sure that your

3:14 network is healthy so it all forms one

3:17 kind of large construct it's not just

3:19 one tool that's going to do the entire

3:21 thing it tends to be a collection of

3:24 tools and products and solutions

3:26 and the there's a bunch of Open Source

3:29 tools and I think it's really important

3:32 to understand the difference between

3:35 a tool and a framework

3:39 a framework can be independent of a tool

3:42 and a tool can be independent of a

3:43 framework but I think it's been pretty

3:46 consistent if you adopt a at this kind

3:50 of early stage of infrastructure code

3:52 Network as a code if you're adopting a

3:54 specific tool

3:56 from my experience you're adopting that

3:59 framework that that the tool was built

4:01 to support is that a fair assessment

4:04 I think each tool is going to have its

4:08 preferred workflow and its preferred way

4:10 for in with for interacting with the

4:13 existing Network and when you think

4:15 about actually starting to use Network

4:18 automation it's not likely that you're

4:20 moving to a green field environment

4:22 where you don't have any network devices

4:24 to start with so the first portion of it

4:27 is how do you bring your existing real

4:29 estate under management and each

4:31 framework is going to have its own way

4:32 of doing that some are going to be

4:34 slightly more painful to do than others

4:37 and then once you actually do bring it

4:39 into the network automation framework

4:41 what's the preferred workflow for

4:44 pushing changes to the environment

4:46 what's the way that you go about testing

4:49 those changes and what's the process for

4:51 rolling back if a change goes wrong each

4:54 one is going to have a slightly

4:55 different process for doing that and I

4:57 think the Frameworks can be pretty

4:59 opinionated in terms of how that's done

5:02 so this goes into some key principles

Principles

5:05 around infrastructure's code in general

5:08 I think the promise the ultimate promise

5:12 of any infrastructure is code project is

5:16 that it abstracts the infrastructure

5:19 from the intent the design intent like

5:23 there's what I want to do and then

5:26 there's what I'm doing it on so whether

5:28 it's Amazon AWS Google Cloud Azure

5:34 on-premises a specific Network vendor

5:38 there's the intention and then there's

5:43 the

5:45 configuration of the intention and I

5:48 think a great tool I don't know if we're

5:51 there a great tool will allow me to

5:54 uh apply that intention no matter what

5:58 infrastructure I'm pointing to

6:01 I think there's a spectrum because

6:03 that's a very interesting point you're

6:04 pulling out is I know what I want mm-hmm

6:09 but each Cloud vendor each Network

6:11 vendor is going to implement that

6:13 feature a little bit differently

6:15 and so different infrastructure is code

6:18 tool sets approach this at varying

6:21 levels of abstraction so you could have

6:23 one infrastructure as code tool that

6:25 works across all the different vendors

6:26 but it doesn't try to abstract away the

6:30 underlying components of that particular

6:32 vendor it's saying yes I can configure a

6:35 VPC in AWS I can set up your VMware

6:39 Networking but the way that I do it is

6:41 I'm going to expose those Primitives to

6:43 you you tell me how they should be

6:45 configured and I just make it go happen

6:46 for you so you declare what you want

6:49 I'll go do the hard work but I'm not

6:51 abstracting away the underlying core

6:55 pieces of that technology

6:57 but there's other infrastructures code

6:59 tools that take the approach of we have

7:01 a layer of common functionality across

7:04 all these different platforms

7:06 so what I'm going to expose to you is

7:08 that commonality of features you

7:11 describe where you want it deployed and

7:14 what you want deployed and I will

7:16 interpret that

7:18 through that abstraction layer into how

7:20 it's actually implemented on the

7:22 platform that you're pointing me at

7:24 that can be very difficult to do and you

7:26 do lose a certain level of

7:28 specialization that exists on those

7:30 different platforms if that

7:32 specialization is important to you then

7:34 you're going to go with a tool that

7:35 doesn't hide the abstractions but if

7:37 you're like a server as a server as a

7:39 server I don't care about the underlying

7:42 Specialties that each cloud or platform

7:45 brings to me then you can go with one

7:47 that does abstract those things and it's

7:50 not uncommon for like a platform

7:52 engineering team in an organization

7:54 to work with the tool that has no

7:57 abstractions that is just working down

8:00 in in the deeps but then what they

8:02 present up through like an internal

8:03 developer portal to the application

8:06 teams is something that is highly

8:08 abstracted because the application teams

8:10 don't care and they don't want to know

8:12 exactly how it's implemented in each

8:14 platform so the platform team absolutely

Examples

8:17 cares and I think we can give two

8:20 different examples we want one from the

8:22 server world and another one from the

8:25 networking world

8:27 in the server World whether we're

8:30 dealing with AMD Xeon arm Nitro

8:34 Etc we want the benefits of accelerators

8:37 of low efficiency

8:40 Etc we don't want to deal with the

8:42 details of how that's achieved the cloud

8:44 providers hide that from us but we do

8:48 have to have the minimum select the

8:50 right instance type so while the

8:53 developer might just want t-shirt sizes

8:55 the platform team specifically knows hey

9:00 I want Xeon Amex uh uh acceleration for

9:04 AI because that's the type of workload

9:07 that we do and these are the types of

9:09 instances in AWS that supports that that

9:12 detail the developer doesn't need to

9:15 know the platform team absolutely needs

9:17 to know and they need to work with the

9:18 infrastructure as cold platform that

9:21 delivers that level of granularity now

9:25 even getting more granule than that is

9:26 networking if I'm configuring a vxlan

9:31 underlay or overlay

9:33 and I want to configure the physical

9:34 Network the number of overlays a

9:39 platform on a switch

9:41 supports matters or may matter right if

9:45 I can only support 500 overlays and I'm

9:48 building thousands I'm a multi-tenant

9:51 organization and I'm building thousands

9:53 of overlays

9:54 I want that capability exposed I want to

9:59 know if I can do packet level inspection

10:04 etc

10:05 etc whatever feature switch levels

10:07 featuring we it can even be a switch

10:09 within the same uh family of switches

10:12 they they're going to have different

10:13 features and it matters when we're

10:16 talking about the underlay

10:18 right and that's why you have things

10:20 like uh you know platform as a service

10:22 where someone has basically built a

10:25 solution that gives you the developer or

10:28 the consumer the T-shirt sizes it gives

10:31 you the silver uh bronze and gold

10:34 classes of performance or whatever and

10:37 underneath they're concerning themselves

10:39 with the actual hardware and software

10:42 that's running directly on those systems

10:44 and just giving you a template that you

10:46 can consume to get the service that you

10:49 want so you know whether you buy that

10:52 platform from a vendor or you're just

10:54 renting it through a subscription I

10:56 think it's fairly common for us to Now

10:59 consume things in an abstract way and

11:01 rely on a platform team or a third-party

11:06 vendor to give us that that shim that

11:08 abstraction that's between the physical

11:11 hardware and low level operating system

11:13 and how we actually want to consume it

Configuration Management

11:17 so let's talk about configuration

11:20 management let's give something we

11:22 talked about and kind of you know the

11:23 the application developer the platform

11:25 team but as we know operations is what

11:28 keeps the world moving like they're not

11:32 and one of the most frustrating aspects

11:36 of managing a large Network or even a

11:40 small network is configuration

11:42 management we have plenty of tools on

11:45 the

11:47 I think storage and and server side and

11:51 even vmsi to manage configuration but

11:54 the network side has been kind of

11:56 relaxed because we have these different

11:57 you know we can have a hundred different

12:01 switches and network devices with

12:03 slightly different configurations and

12:06 understanding that there's not like a

12:07 really gold image that stays in every

12:10 single server and we're doing diff

12:13 between that gold image they're kind of

12:15 it's like wrangling cats

12:18 can be yeah that's certainly the case

12:20 someone could go oh there's a problem so

12:23 I'm going to go troubleshoot that

12:24 problem on the network and so I'm going

12:25 to log into these two switches and add

12:27 some additional monitoring don't worry

12:28 I'll remember to turn it off later

12:30 oh yeah the the wireless switch CPU

12:33 running so high oh I turned on

12:36 monitoring two months ago and I forgot

12:37 to turn it off exactly right so the the

12:40 idea behind configuration management is

12:42 being able to declare

12:45 how you would want ideally a particular

12:47 device or set of devices to be

12:50 configured and then it's up to the

12:52 software to do the imperative portion

12:55 which is actually go out and make it so

12:57 and usually that imperative portion has

13:00 three different functions in it get set

13:03 and test and I've had to write these

13:05 tests myself or get write these

13:07 functions myself in different cases the

13:09 test simply looks at what you've

13:11 declared and the actual state of that

13:13 device and goes do those two match yes

13:16 or no

13:17 the get is what allows it to actually go

13:20 out and get that information from the

13:22 device to run the test in the first

13:24 place and then the set is okay I've

13:27 determined that they're different and

13:28 now I want to take what's in the

13:30 configuration and push it to that device

13:33 and so that would be the set function so

13:35 that's basically what all these

13:36 configuration management tools do is you

13:39 define something declaratively they get

13:41 the config they test the config and then

13:43 if there's a difference they set the

13:45 config

13:46 so that sounds a lot like the CI CD

13:50 process over in the development side

13:51 like there's the existing code that's

13:55 running

13:56 there's the code that we want to deploy

13:59 and there's the detecting if there's a

14:02 Delta between it and then there's a

Advanced Concepts

14:04 bunch of other tests how should we think

14:07 about

14:08 kind of this Advanced topic of cicd when

14:11 it comes to network automation network

14:13 is code

14:15 I think there's a key difference between

14:17 the software development the application

14:19 deployment life cycle and the update and

14:22 management of network configuration and

14:24 probably the biggest thing is you can do

14:27 you can deploy multiple versions of your

14:29 application simult side by side and you

14:32 can do something like blue green testing

14:34 you can do something like canary

14:36 rollouts

14:38 so you can over time move to a new newer

14:41 version of the application while keeping

14:43 the previous version up and easily roll

14:45 back if something goes wrong and modern

14:47 tool sets like what we have in

14:49 kubernetes where you can do that sort of

14:51 phased rollout and roll back if you need

14:52 to make it really easy to do that with

14:55 applications

14:56 I highly doubt that most organizations

14:58 run two of every Network device so that

15:01 they can do this

15:02 so when you are talking about the

15:05 continuous integration continuous

15:07 delivery and deployment process of your

15:10 network configuration there needs to be

15:12 a ton of testing in that pipeline to

15:16 thoroughly vet the updated configuration

15:19 to

15:21 do a plan or some sort of dry run to

15:24 determine the actual changes that are

15:26 going to going to be applied and then do

15:29 some sort of as it rolls out testing to

15:31 verify that the network is functioning

15:33 properly as it rolls out and have a way

15:36 to roll back because this isn't like an

15:39 application where I can have two

15:40 versions run at the same time I've got

15:42 one version of my network and that's the

15:44 one that's carrying everything else

15:47 yeah the network is definitely a pet the

15:50 even if we we take borrow some of these

15:53 Concepts from the software development

15:55 world the network itself is a pet I have

Conclusion

15:59 one internet connection to a T I have

16:02 one internet connection to my business

16:05 partner even if I have multiple switches

16:08 there are many single points of failure

16:11 and quite frankly you know if I update

16:15 the version of OS on my switch and I

16:19 need to roll back

16:20 that switch is going to be down for the

16:22 time that I need to roll back so a lot

16:26 of this a lot of the cicd process we may

16:29 borrow from software development but the

16:32 way that we test it is very different

16:34 and some of the simplest things such as

16:37 validating the configuration change

16:40 makes sense like I can't tell you the

16:44 number of times that I went to make a

16:46 configuration change on a switch the

16:51 commands made sense in my mind I made

16:54 the change and they were accepted but

16:56 they broke the network we can't test for

16:59 every scenario yet but that basic check

17:03 needs to be part of our version of CI CD

17:06 in the network World absolutely

17:09 all right so that wraps up this uh

17:13 the video on the three-part series we

17:16 talked about tools and Technologies

17:17 infrastructure is code uh some basic

17:20 principles and we even gave our

17:23 operations folks some candy by talking

17:27 about configuration management slapping

17:29 the hand of those folks who try to make

17:32 changes directly remember use the

17:34 infrastructures code tool to make all

17:37 changes otherwise the next time you go

17:40 to deploy you're going someone's going

17:42 to come to you and say hey we saw you

17:45 logged into the switch left we tried to

17:47 deploy and there was a different

17:49 different configuration the tools that

17:52 you select should be able to do all of

17:53 that or you have processes to do that

17:55 stuff

17:56 in the next video we're going to talk

17:58 about we're going to talk about Advanced

18:00 topics and network as code Network

18:02 testing and validation so we're going to

18:04 dive a little bit deeper into

18:07 configuration management CI CD network

18:09 monitoring and analytics and then

18:12 finally the most important topic

18:14 security and compliance I promise you

18:18 that section for those of you who've

18:20 ever had to answer audit requests you

18:23 want to see that module in the next

18:26 video talk to you soon