Juniper Validated Design Podcast, Ep. 1

0:05 Welcome to the Juniper Validated Design Podcast.

0:07 My name is Andy Lapteff, and today I am joined by Ben Griffin.

0:11 Ben, who are you?

0:12 What do you do at Juniper?

0:13 Hi, my name is Ben Griffin.

0:15 I work at Juniper Networks on the Market Use Case and Solutions Team in the Cloud Ready

0:19 Data Center.

0:20 We build solutions that make our customers' lives easier.

0:23 Making customers' lives easier.

0:24 You?re talking my language, Ben.

0:25 I don't feel like too many people were making my life easier when I was managing production

0:30 data centers.

0:31 So thank you for the good work you're doing.

0:34 This is gonna be...

0:35 a conversation around design mostly, right?

0:38 And I'll be honest with you, I'm not great at design.

0:42 You know, I traditionally was handed designs from our architects, and they're like, hey,

0:47 here's a bunch of iron, you know, go implement the design we gave.

0:51 So you're going to be my design expert here.

0:54 So, you know, we're here to talk about Juniper validated designs.

0:58 Before we jump into that, I guess, let's just talk about design at a high level.

1:01 How, you know, a customer comes to Juniper and says, hey, I want to build this network.

1:05 How have we done that traditionally?

1:07 Well, traditionally, we basically handed them a whole bunch of technical documentation and

1:14 said, good luck.

1:16 No, that's not entirely true.

1:19 We basically gave them a baseline of how to do things.

1:24 But we didn't really put any guardrails in place.

1:27 So really, the sky was a limit to what you could do with Juniper hardware.

1:34 There's a lot of knobs, there's a lot of things to turn, and every knob and everything that

1:39 you do enable has some level of impact on other things.

1:43 So while it's great that we are very flexible and in certain times we can be very specialized

1:50 in helping our customers meet certain needs, we have not traditionally put things in place

1:58 that actually said this is the best way to do it.

2:01 Because

2:02 We wanted to give the customers the flexibility to go out and make those choices for themselves.

2:08 What we're finding is that a lot of folks, you know, in today's networks, they've gotten

2:13 very complex.

2:14 They don't necessarily even know where to start, let alone where to end.

2:17 And we're trying to give them a roadmap of how to get from point A to point B and be

2:22 successful in that delivery of that network.

2:25 That makes a lot of sense.

2:26 And I've worked in a lot of those overly complex, over-engineered, all the nerd knobs.

2:30 Right.

2:31 Dialed up and it's, it's so hard for a number of reasons.

2:34 I'm just thinking back to my own career, like even troubleshooting, right?

2:37 Something breaks, you get called in the middle of the night, you're on, you're like, Oh my

2:39 God, where do I start?

2:41 What part of the snowflake network is broken and what's, what's happening?

2:45 So there's, there's so much to be said for more of like a prescriptive, you know, overarching

2:50 design of like here, here's, which I think is where we're going with Juniper validated

2:54 design.

2:55 Right.

2:56 So

2:57 Do you have like a high level definition of what is this thing?

2:58 What are we talking about with, you know, what is Juniper Validated Design?

3:01 So a Juniper Validated Design is a well-defined, well-tested and well-described network, right?

3:08 So what we really get into is we have certain products that fulfill certain roles within

3:14 the data center and we go through a rigorous testing process to kind of one, validate that

3:21 everything functions on a network level.

3:25 But we take it to the extra step where we actually start to incorporate things that

3:28 our customers were traditionally attached to those networks.

3:31 So things like VMware or Kubernetes.

3:36 We actually start attaching third party storage vendors.

3:40 We bring in other parts of our portfolio from our security components to our WAN components

3:48 to our campus components.

3:50 And we bring those all together.

3:51 We give you a guided resource on how to get those components attached to the data center

3:56 and where they function.

3:58 Up until recently talking to you, I didn't know much about testing and what goes into

4:02 that.

4:03 So, I think it'd be helpful just briefly to kind of jump into the testing because again,

4:08 as a network engineer, I'm out there, I'm doing things, I'm pressing buttons, bad things

4:12 happen.

4:13 I'm like, oh my God, why can't vendor XYZ give me a stable, reliable, predictable network,

4:18 right?

4:19 Now I may be, you know,

4:21 If we're coming to a vendor saying, I want to do these certain things, please enable

4:24 me to do that.

4:25 Sure, we'll let you design whatever you want, right?

4:28 But you mentioned to me when we talked before about, that's not all tested, right?

4:33 The downside of doing bespoke or letting the customer design anything they want and turn

4:37 any nerd knob is, it's not realistic that vendors like ourselves can test all those

4:42 scenarios, right?

4:43 All right, well, we go through what we call functional testing.

4:47 So this is where we start.

4:49 So when a new feature gets released,

4:51 we go through one, making sure the feature works, right?

4:55 And that is subjective to the hardware that it's on.

4:58 So it's kind of like in an isolated case, does it function, does it not?

5:02 When what we do beyond that is we go into something called multifunctional testing where

5:07 we bring in other products that would fit in that same portfolio scope.

5:13 So things like leaves would interoperate together when we turn on this feature.

5:17 It works across different platforms.

5:20 And then we take it to the next level where we do scale and performance testing.

5:24 So to make sure that the feature meets the scale requirements that were put forth, you

5:28 know, based on that request.

5:30 And then finally, we do something called PDT or product delivery testing, which is more

5:36 of a use case scenario testing where we use spirents and other things.

5:41 Obviously, we've done this prior in the scale testing, but now we're doing more of.

5:47 what people would see is traffic generation, things like that to where we're actually making

5:50 sure that things function relatively well over a period of time.

5:55 And then finally, what the JVD does, we take all that testing that's happened beneath it

6:00 and we layer on top an actual real world data center.

6:04 We actually bring it into where we have real world traffic.

6:07 We are using real world applications.

6:10 We have real world storage components.

6:11 So we take all these pieces that traditionally were kind of left off.

6:16 Because it is a big uplift for us, right?

6:17 I mean, you got to remember, like we effectively have to have experts in VMware.

6:22 We have to have experts in Kubernetes.

6:23 We have to have experts in storage that basically help bring this to fruition.

6:28 So we have to put a lot of effort and investment in those resources, just like our customers

6:35 do.

6:36 And then once we put all those things together, we validate that they work as expected, right?

6:42 It does the thing that it's supposed to do.

6:45 And that there's no issues.

6:47 So what we're really trying to do is before the product leaves the factory to ensure that

6:52 there are, there are no issues and that when the, our customers go ahead and adopt these

6:57 models, they can have a high level of confidence that from day one to day 100 things will work

7:02 just as expected.

7:04 That sounds awesome and not my experience in prod.

7:08 So I'm really, that's, that's why I get so excited about this and that multifunctional

7:12 testing and.

7:13 That really opened my eyes when you described that to me because yeah, you can create a

7:17 feature, spin it up in some software version and say, oh yeah, it works great.

7:21 Ta-da, there's the hello things or there's the neighbors that come up.

7:23 Yay.

7:24 But then when you start plugging all the pieces in and all the systems that, you know, exist

7:27 in the data center, that's really where the rubber meets the road to me.

7:31 So, you know, when I was managing prod, you know, I want a predictable data center.

7:36 I want my network just to run.

7:37 I want it to be reliable.

7:38 I do not want to be called every single time I'm on call, right?

7:43 And from what I'm understanding from you, I mean, that's what JVDs help deliver, right?

7:47 So now we're kind of pivoting into the benefits of, if you follow this prescriptive, tested

7:54 design that we're calling JVDs, Juniper Validated Designs, what are some of the benefits you

7:58 get?

7:59 So, I mean, I guess reliability is one of the biggest ones you have to touch on, right?

8:02 Right, so what we're really trying to do is enhance our customer experience.

8:08 So nobody wants to go through the process of opening up cases and trying to figure out

8:13 what's going on from a network perspective.

8:16 And a lot of times, let's be honest, it's not necessarily a network issue.

8:21 It's just an issue somewhere in the ecosystem of a data center.

8:26 So we want to do two things.

8:27 One, we want to make sure that everything functions as it should properly function,

8:32 and that it's easily achievable for our customers.

8:35 So we're going to do

8:37 basically give you a point A to point B. Like you start with nothing, you end with a completed

8:42 data center.

8:43 And if you follow the model, everything that we've done, you'll end up with the exact same

8:48 configuration pieces that we've put together.

8:51 This does two things for you.

8:53 One, obviously this is what we test against.

8:55 So again, we're removing obstacles before you even get there.

9:01 The second part is now we have a well-defined network.

9:04 So we know exactly what it should look like.

9:07 And let's say you call in one day and I've got a problem and things aren't working.

9:10 Well, it gives us an easy place to start from.

9:13 So we don't necessarily think that people will 100% stay within what is the end result

9:19 of the JVD.

9:20 I mean, we expect some level of modification.

9:24 People are going to attach different things.

9:27 Things are going to happen from that perspective.

9:28 We can't test everything.

9:30 But we do expect some level of change.

9:33 The problem is, is how do you identify that change?

9:36 And since we know what it should look like in the pristine state, it's easy for us to

9:42 identify drift.

9:44 And then we can focus on those items that are really drift related.

9:48 The other piece is, let's say it wasn't the data center, or it's not at least the network

9:54 in itself.

9:55 It's, again, easier for us to identify this all looks good.

9:59 So let's focus on what the problem with the application is.

10:03 And maybe that's where the issue lies.

10:05 So that mean time to innocence is greatly reduced.

10:07 That's amazing.

10:08 I want to say that almost every support case I ever opened with any vendor started with

10:13 me sending them over a drawing of this thing we built, and then a bunch of show techs of

10:17 the stuff that we like.

10:19 Because we had to teach them what the network design was every single time we opened a case.

10:24 And that took a lot of time.

10:26 And it increases the MTTR, that mean time to innocence, as well.

10:30 So.

10:31 that, yeah, if everybody's using this perscriptive design, here's what it should look like, here's

10:34 what the config should do, and it's much easier to, I guess, find deviations from that.

10:40 And I love the customer experience driven stuff.

10:44 You're right, nobody wants to open a support case.

10:48 And the meantime, the innocence, right?

10:50 Everybody blames the network.

10:51 So if we can get to that innocent state earlier, which it sounds like one of the things that

10:58 JVDs

10:59 can do for us.

11:00 Like, yeah, when stuff breaks, it stinks, but JVDs enable support to get to a solution

11:03 quicker.

11:04 What's the weird thing that happened?

11:05 Because we have a prescriptive model.

11:07 And then when somebody calls in and says, hey, my app isn't working, okay, well, we

11:11 have this prescriptive model.

11:12 We can see what's working and what isn't.

11:13 And help me say, it's not the network, much faster, because I've spent days, if not, I

11:21 remember spending four days on this.

11:25 big problem, right?

11:26 And at the end it wound up being like an expired certificate on a server.

11:29 Now, they didn't even tell us.

11:31 Like, hey, whatever happened to that outage, such and such, like, oh yeah, that was a certificate

11:35 on a server.

11:36 I'm like, where they gonna tell us?

11:37 Like, we're still testing, you know?

11:39 So there's just, you know, so much stuff that can happen.

11:42 So we're driving reliability.

11:43 I, you know, I was talking to a friend when we were talking about JVDs and he mentioned

11:48 something about, you know, boring operations, right?

11:50 I kind of love, like I always think of the Maytag repair man who's just sitting around

11:54 and...

11:55 Those Maytag appliances are so reliable, built so well, right?

11:58 That, you know, he just sits around and has, has nothing to do.

12:02 So I love that thought of, you know, if you follow JVDs and the prescriptive model and

12:08 all the testing behind it, operating a network will be less dramatic.

12:13 You know, my, my, my days have been fraught with, you know, as a network engineer in prod

12:19 with just endless drama.

12:22 So I kind of like the thought of, you know, the network just runs.

12:26 And when something weird happens, it's much quicker and easier to.

12:30 To, to, to find it.

12:31 Um, is so for JVDs, I guess, is this just for greenfield?

12:35 Like if you're building something new, you would follow a JVD.

12:38 Let's say I have a network.

12:40 How, how do I get, if I have a Brownfield, how do I get to JVD?

12:44 Is it, is it iterative as I replace end of life gear?

12:47 I start to go toward this design.

12:49 How does that work?

12:50 Yeah, so basically we see kind of like two avenues for insertion for a JVD.

12:56 One is obviously new networks, new projects that you can isolate and put off to the side

13:03 and basically start building towards the new architecture, right?

13:08 The other model is obviously like a full-on migration.

13:11 So we have a lot of customers that are upgrading from previous versions of Junos.

13:17 So this is kind of like an opportune time to

13:20 make that transition because you're already going to go through some level of transition.

13:25 One, what that does help you with if you're actually coming from a previous version of

13:28 Junos to a newer version, on the JVD, we have a very regimented release schedule that we

13:35 follow.

13:36 So effectively, we're going on hardened releases or extended end-of-life releases.

13:40 So that puts our customers in a better position right there.

13:44 The other part is that if, for the most part, the features align,

13:50 you kind of take the guesswork out of, is the problem Junos, or is the problem that

13:54 I've transitioned to this new modern design and something's amiss there.

14:02 So we kind of take that hesitation or the reluctance to one, get to a modern data center

14:12 fabric, or two, get up to the modern operating system.

14:18 we do go through that entire process.

14:20 We go through use case testing.

14:22 The one thing I want to really highlight is, if you're on a JVD, effectively you are on

14:28 what we would call a customer use case, right?

14:31 So customer use cases inside of our organization are basically custom test beds that are built

14:37 that emulate some of our larger customers networks.

14:40 So these are typically cloud providers and folks like that that we send through like

14:45 extensive testing.

14:47 that emulates what they look like.

14:48 Well, by moving to a JVD, every single one of our customers get that experience because

14:55 you go through that same level of regression and you go through that same level of testing

14:59 and also that same level of validation to ensure that all the products work in conjunction

15:05 with each other and that everything just functionally flows.

15:10 And again, we support any model.

15:13 So basically, if a feature is supported on a platform, it's supported on a platform.

15:17 It doesn't matter if you're on a JVD or not.

15:20 What the JVD does is we take it to the next level.

15:23 We give you that extra confidence that when you go and enable these functions and these

15:30 features, everything will just work smoothly because we've done the extra testing to get

15:38 you to that next level.

15:40 So we've kind of taken some of that burden off the customer.

15:42 Yeah, I guess there's an endless number of variations that you could build and features

15:48 you could deploy and knobs you could turn.

15:51 And it's just statistically probably near impossible to test all that, but because of

15:55 this prescriptive model and it's all built in the interoperability and to me, it's just

16:01 about the testing.

16:02 You go through all this vigorous testing.

16:03 So when you deploy a JVD, we have beaten the heck out of that solution in our, you know,

16:09 in our, in our labs and our, uh,

16:10 in our customer test beds and stuff to make sure that you're getting a reliable, prescriptive,

16:18 expected operation.

16:19 I don't know what people are going to do with themselves if they're not working outages

16:23 and getting called in the middle of the night on call anymore, Ben.

16:28 What are we talking about here?

16:29 So if somebody wants to learn more about JVDs, I know I have a link we can put in the show

16:34 notes.

16:35 I mean, is this like an ask your SE thing?

16:38 Do you just go to our...

16:39 to our documentation site and start reading?

16:41 What do we tell customers who are interested?

16:44 So really it's what they're most comfortable with.

16:47 So from a perspective of where to find it, on the Juniper website, we have an area called

16:54 the Data Center Design Center.

16:57 And within there, we have JVDs that are listed.

17:01 So as we publish new ones or what we have out, those will be covered.

17:06 We have roughly what we consider the four core

17:09 JVDs, which are three stage fabric, a five stage fabric, an IP fabric, and a collapsed

17:15 fabric.

17:16 And then everything else that would attach to a data center is considered an extension.

17:20 So again, third party vendor, VMware storage, even some subsets of how do you connect a

17:28 firewall properly to the data center to get the best performance out of it.

17:33 Those pieces are covered within those JVD extensions.

17:36 So they just attach.

17:37 to any one of the four core.

17:39 So they're portable across.

17:42 And for the most part, your configurations will be exactly the same, depending on which

17:47 one you're going into, but they will closely align to each other.

17:53 What we didn't cover like is like, what is a JVD made of?

17:57 So what we do from a perspective, like sometimes our customers don't know where to start.

18:05 And if you don't know where to begin, you just kind of fall back on the things you know.

18:12 So what I traditionally knew was a three tier architecture and a data center.

18:17 So I had a core, I had an aggregation, and I had an access layer.

18:20 So that's kind of where I want to stay.

18:23 The problem is that the world's moved on.

18:25 We've all moved to basically modern fabrics at this point.

18:30 And

18:32 if you don't have the information, you don't know where to begin, it can it can be very

18:36 complex.

18:37 It can you know be a little overwhelming.

18:39 So what a JVD provides is a great place to start from.

18:44 Now what we put in the document of a Juniper validated design is kind of our prescriptive

18:53 what we see for the most part everywhere.

18:56 Now what we also do is we replace

18:59 certain platforms and certain roles.

19:00 So we change up border leafs and leaves and spines to achieve certain performance goals

19:07 and feature capability that's typically required within the data center based on customer need.

19:12 So it is a little bit flexible from that aspect, but for the most part, what we're doing is

19:18 we're giving you where to start from, and then how do you achieve a fully functional,

19:26 well-tested, well-designed

19:29 well-documented network.

19:31 And what's kind of neat is we pull in other components that are part of our portfolio.

19:36 So things like management, that's a key piece of our solution.

19:42 And the main reason why is because it's basically self-documenting.

19:46 So it keeps track of what's changing inside of the network.

19:50 If you need a network diagram, if you need to know where something's at, it's already

19:53 built into the solution and makes it a lot easier for our customers to adopt these models.

19:58 And then also troubleshoot or even operate from, from day one to day 100.

20:04 That hits home for me.

20:05 I came up with core, distribution, access and the data centers I managed were, were

20:10 built that way as well.

20:12 And then we went through a merger, two companies merged and the company we merged with, you

20:16 know, they were, they were ahead technologically, you know, and they had, you know, a clos architecture

20:21 and like, what is this and what's going on and what are these configs and what the hell

20:26 is EVPN VXLN?

20:27 So

20:28 I can really appreciate what you're saying that, yeah, if you come from, you know, the

20:32 legacy for lack of a better term design that we were all told was the way to go forever,

20:35 right?

20:36 And now, you know, that was based on North, you know, North South traffic being 80% and

20:39 it's flipped and now it's East West, you know, all that technical stuff, but there are very

20:43 valid, you know, useful reasons to, to go with the three stage, five stage, you know,

20:48 clos architectures and I wouldn't know where to start, so I can really appreciate Juniper

20:52 validated design giving me like, Hey, okay.

20:55 Okay, Mr. Dinosaur Andy, here's what you're used to.

20:58 But here's where the technology, here's where it's headed, here's where you should be and

21:02 here's how you can do it.

21:04 Is there anything else we should touch on before we wrap it up?

21:07 I'm pretty excited about this.

21:08 I really appreciate all the work Juniper's done to, I keep going back to boring operations.

21:14 If you follow this, your network's just going to run.

21:16 It's going to be reliable.

21:17 You're going to have a good experience.

21:19 It's all been tested, right?

21:20 Did we miss anything?

21:23 No.

21:24 You hit it home.

21:27 What we're really going for is customer experience.

21:30 We actually consider ourselves in the solutions team customer one.

21:34 So we're the first customer, we go through the same exact processes of setting up a data

21:39 center as our customers do.

21:41 We go through the exact same processes of attaching these third party products to our

21:46 fabrics and then ensuring that everything functions properly.

21:50 So.

21:51 We get to find stuff before it actually leaves the factory.

21:55 We get to address it before it gets to the customer.

21:57 And ultimately what we're looking to do is take the guesswork out of how to build a network,

22:04 how the network should operate.

22:06 And then not only from an operational standpoint of I got it in and working from the deployment,

22:13 but how do I operate it at day 100, day 200.

22:17 I like the customer one concept.

22:19 Your team goes through all that pain.

22:21 so that our customers don't have to.

22:24 Ben, thanks so much.

22:25 This has been very informative for me.

22:28 I'm really excited for what the Juniper Validated Designs can do for our customers.

22:31 Thanks so much for joining us on the Juniper Validated Design podcast, and we'll catch

22:35 you next time.