Introduction to Network as Code, Part 1 of 3

Introduction

0:02 (mysterious intro music)

0:08 >> Hi, welcome to this video series

0:11 on the introduction of Network as Code

0:14 to our CTO advisor audience.

0:16 I have with me Ned Bellavance.

0:18 Ned is going to introduce his self in a sec,

0:21 but I wanted to preview the series.

0:23 Video one, we're going to do an introduction

0:26 to Network as Code.

0:27 Basic concepts.

0:28 What is Network as Code?

0:30 How is that related to Infrastructure as Code?

0:33 What are some of the benefits?

0:35 What problem are we trying to solve?

0:39 Video two, we're going to talk

0:40 about implementing Network as Code.

0:42 We're going to dive in to some of the tools,

0:44 technologies, Infrastructure as Code,

0:47 a little bit more configuration management

0:50 with Network as Code.

0:52 Then the third video, we're going to do advanced topics.

0:56 Talking through network test and validation,

0:59 network monitoring and analytics with Network as Code.

1:03 And then finally, security and compliance

1:05 with Network as Code.

1:08 Ned, can you go ahead and introduce yourself

1:11 to our audience?

1:13 >> Yeah, absolutely.

1:14 Thanks, Keith.

1:15 Hi, I am Ned Bellavance from nedinthecloud.com.

1:19 I've been working in IT for over 20 years now

1:22 and a large portion of that has been with data center

1:25 and cloud technologies.

1:27 And it was probably about a decade ago

1:29 that I really started working with Infrastructure as Code

1:32 which I think is, you know, important to this conversation

1:35 as we talk about Network as Code

1:37 'cause it borrows a lot of the same concepts

1:39 and terminology.

What is Infrastructure as Code

1:41 >> So before we get into Network as Code,

1:43 I love that you preference this with Infrastructure as Code.

1:47 Let's define the two.

1:48 What is Infrastructure as Code?

1:52 >> It's simply the process of defining your infrastructure,

1:56 your architecture, using some type of code,

2:01 some sort of machine readable language.

2:04 Rather than clicking around in a UI,

2:07 you're using either imperative commands

2:10 at the command line that you have all scripted out

2:12 or you could use a more declarative approach

2:15 and then have something interpret your configuration

2:18 or your code and make it so,

2:20 in whatever the target environment is.

2:23 But it does require

2:24 that whatever infrastructure you're provisioning

2:27 is able to be interacted with programmatically,

2:31 especially over some sort of API, a REST-based API.

Most Popular Versions

2:36 >> So I think the most popular version of this,

2:40 we're going to give the cloud most popular version of this

2:42 which is AWS CloudFormations.

2:45 I can take, you know, some code,

2:48 some JSON, and say what I want to build

2:51 and deploy that in AWS consistently.

2:55 However, if I don't use AWS or I want to do this on-prem

3:01 or across cloud, the more popular platform

3:05 is probably, I think the most popular platform

3:06 is safe to say is Terraform at this point.

3:09 >> It's certainly the one that I've come to know

3:11 and enjoy quite a lot.

3:14 And I actually got my start with Terraform

3:16 because I had some frustrations with CloudFormation.

3:20 That was my first real introduction

3:22 to using Infrastructure as Code on AWS.

3:25 And there were a lot of shortcomings

3:27 in the way that you could build out

3:29 a CloudFormation template

3:30 and do things like make it reusable

3:32 across multiple environments

3:34 or create multiple instances of the same thing.

3:37 And it just didn't have good constructs for that.

3:39 It wasn't really a programming language per se.

3:42 It was more of a configuration file.

3:44 And so I discovered Terraform in that process

3:47 and then quickly realized that Terraform could work

3:49 across not just AWS,

3:51 but all the other different public cloud providers.

3:54 And really, anything that you write a provider for,

3:57 it can interact with.

3:58 So it became very popular with me,

4:00 but it's just a good implementation

4:03 of some of the key concepts

4:04 that make up any Infrastructure as Code product

4:07 and it brings the same benefits

4:08 that any of those other products would.

Benefits

4:11 >> And we typically see these tools and movements

4:14 or operating models such as DevOps,

4:18 SREs use these to build or manage systems at scale.

4:22 So these are the tools that is, you know,

4:26 you're not buying DevOps when you buy

4:29 a Infrastructure as Code solution,

4:31 but it's a tool and a methodology that we use

4:35 to implement DevOps types of operating models, correct?

4:40 >> Yeah, certainly.

4:41 The real thing is to take a step back and go,

4:44 what is the benefit to the business

4:46 of me introducing something

4:48 like Infrastructure as Code into the environment?

4:51 How is that making things better for the stakeholders?

4:55 And armed with that, you got to figure out,

4:57 what are the things we're trying to do?

4:59 Are we trying to make our environment more stable?

5:01 Are we trying to automate the provisioning

5:04 of environments so that we can test out new features?

5:07 Once you know kind of what the end goal is,

5:10 now you can select the tooling

5:12 and solutions that allow you to actualize that benefit.

5:16 And Infrastructure as Code is often one of those things

5:18 where before every environment was manually provisioned,

5:22 your development didn't match your staging,

5:25 didn't match your production.

5:26 When you tried to do code progression

5:29 from those environments,

5:30 something that worked perfectly in staging

5:32 now breaks in production

5:34 because of an infrastructure problem.

5:36 So in that case, you're trying to solve for consistency

5:39 'cause consistency allows you to accelerate

5:41 your software development,

5:42 which then, in turn, hopefully helps you sell more widgets

5:45 or gain more customers or whatever it is

5:48 the business is actually focused on.

5:50 >> In the most simplest, you know, form of this type

5:53 of benefit is when we talk

5:54 about fat fingering the configuration,

5:57 when we have to build the same, you know.

5:58 I'm a Windows admin so I have to think about this

6:01 in the Windows context is when we build a Windows server,

6:06 the two different people will build it differently.

6:10 The same image, even if they're taking it

6:12 from an image file,

6:13 they may build a server differently than any given time.

6:19 Not just two different people, the same person.

6:21 I may not build this server

6:22 the same way I built it yesterday or the next day.

6:25 I may have found new practices, new best practices,

6:29 to build a server.

6:32 And Infrastructure as Code is the most simplest construct,

6:37 is a way to be consistent

6:38 and for me to track how I change building servers,

6:42 et cetera, et cetera.

6:43 So even if you're not talking about code repositories

6:47 and all these other abstracted benefits

6:52 of Infrastructure as Code,

6:53 it's just a really great practice.

6:55 And I think it's the accepted norm now.

6:58 >> It's the consistency, it's the reusability.

7:01 And I'll be honest, Keith.

7:02 In the same document,

7:03 I will spell the same word three different ways

7:06 because sometimes, I just do that.

7:09 I'm inconsistent, I'm a human being.

7:11 And if that's the way you're building servers, then yeah,

7:13 you're going to have three differently configured servers.

7:16 If that's the way you're provisioning

7:18 your network environments,

7:19 you're going to have four different network switches

7:21 that should all be basically identical,

7:24 but you've accidentally configured them slightly different

7:27 in a way that might not be immediately obvious,

7:30 but six months down the line,

7:32 ends up breaking something on your network.

7:34 So being able to apply that consistency

7:36 and rigor to your infrastructure

7:39 just makes it that much more robust.

7:41 >> So would it be safe to say that Network as Code

7:46 is a subset of Infrastructure as Code?

7:50 >> I think that would be a fair approximation.

7:52 Networking brings its own challenges with it, right?

7:56 Because that was not traditionally the approach

7:59 to configuring network gear.

8:00 The traditional approach was,

8:02 I'm going to connect into each switch in each router

8:05 and I'm going to run a series of commands against it.

8:08 And I had all kinds of hacks back in the day.

8:10 I had a Excel spreadsheet

8:12 that would have the commands in it

8:14 and then I would merge the commands into like a big body

8:17 and dump that out to a text file

8:19 and then copy and paste it, right?

8:20 Like there were ways to automate

8:23 your networking configuration,

8:25 but it was very, you know, duct tape and spit together.

8:28 It was not a a cohesive thing

8:31 and it wasn't something that you could easily transfer

8:34 to someone else to take over management.

8:37 Everything was very bespoke.

8:39 And I think network automation and Network as Code,

8:42 the idea is to get away from that,

8:44 but you still need to interact with these network devices

8:48 in the traditional way because a lot of them

8:51 don't have an API front end

8:53 that you can make REST calls against, right?

8:56 They're expecting you to connect via SSH

8:59 and start issuing commands.

9:01 And that's not how a lot

9:03 of the Infrastructure as Code products work.

9:06 So you need something in the middle

9:07 that does some kind of interpretation

9:09 of the way that Infrastructure as Code wants to work

9:13 versus the way that the device wants to work.

Network Automation

9:15 >> So let's talk about network automation a little bit.

9:20 You know, we know the disadvantages

9:23 of manually configuring the network.

9:26 It is, you know, we introduce authentication,

9:31 centralized authentication, into network switches.

9:34 So we know who logged into a switch.

9:36 We may not necessarily know

9:38 who changed the configuration of a switch

9:40 or what configuration changes were made.

9:43 We can't, you know, revert back to a known good state

9:46 because what's a known good state

9:48 of 1,800 different switches?

9:51 Like we don't know that.

9:53 There's no centralized management of it.

9:55 There's been tools in the past that's kind of helped us

9:58 do configuration management,

10:01 but not in a way that's, in my opinion,

10:07 that smooth the needle.

10:09 So let's talk about some of the benefits

10:11 of automation and some of the motivations you've seen

10:14 for people to automate the network specifically.

10:18 >> I mean one of the the primary motivations

10:21 is just removing that manual aspect

10:24 of going to each switch and pushing a configuration to it,

10:27 then going to the next one.

10:29 That's fine when you're a small medium business

10:31 and you've got 20 switches in your environment.

10:34 When you've got 100 switches or 500 switches

10:39 in your environment, all of which need to be configured

10:42 in very specific ways to work with each other,

10:44 that becomes untenable for the manual process.

10:49 The other portion of automation

10:50 is you usually do introduce some sort of control plane.

10:53 And that control plane has a holistic view

10:58 of your networking environment

11:00 that no one switch or router has.

11:03 So that has the additional benefit of being able to see

11:06 what is the possible impact of a change

11:10 that I'm proposing to the environment

11:12 before that change is applied

11:14 because it has that more holistic view.

11:16 And typically, because you're managing things in code,

11:21 or at least the automation platform is,

11:24 a rollback actually is possible

11:27 because it is aware of what the previous version

11:29 of the code looked like.

11:31 And if something goes wrong, it can move back

11:35 to that previous version of the code

11:37 and apply it through some sort of out of band management

11:40 to those network devices.

11:42 So I think the biggest benefits of automation

11:45 is removing that manual process,

11:47 making things consistent, making rollback possible,

11:51 and being able to preview the changes

11:54 or the impact of your changes

11:56 prior to them actually being applied.

11:59 >> All right, Ned, thanks a lot

12:01 for helping me dissect the introduction

12:05 of Network as Code from a concept perspective.

12:08 In the second video, we're going to talk

12:10 about implementing Network as Code.

12:12 And then in the third video, we're going to talk

12:14 about advanced topics and networking code.

12:17 That's going to be the meaty one.

12:19 So if you think you already have a handle

12:22 on the industry and the concepts,

12:24 you can go ahead and skip on to that,

12:26 but I guarantee you,

12:27 you're going to enjoy the second video in the series.