Juniper Apstra 4.0 - Sponsored

Machine-generated from the episode audio and not hand-corrected, so names and technical terms may be imperfect. The audio is authoritative.

So, Mike, for the uninformed, what is Apstra? So, Apstra is an intent-based system, which basically means we allow users to specify what they want the network to do, but not using vendor-specific syntax, and then we model out the state, what does a good network look like, and we constantly check the current network, like the actual state, against the good state, so we can tell you, is it working as intended, all of the time. So in this episode of the CTO Advisor, CTO Dose, we're going to dig into that statement, and why is it that Juniper is doing this, a bots company, how we're going to kind of handle Brownfield, and isn't this taking away from network engineers' jobs?

Stay tuned for the rest of the episode. Hey, how's it going? It's Keith Townsend, Principal of the CTO Advisor. In this sponsored podcast, we have a guest that I've known in the industry now for years, but I've not interviewed him on theCUBE, I've not interviewed him on the CTO Dose. I don't even know his title, over from Juniper Networks, Mike Bouchon. Mike, welcome to the show. Thanks for having me, Keith. It has been a while. I feel like we've been going back and forth on Twitter for years, and yeah, it's the first time we've squared off face-to-face.

So Mike, what is your title at Juniper? So I am Vice President Data Center at Juniper, I run our data center business. You know what, I love the data center, especially in concept, I just went through the process of building one. Not a big fan of boxes though, especially networking boxes. So with all the software we talk about, the challenge is until somebody figures out how to write code that's going to move packets from here to there, it turns out like all the boxes and the wires that connect those boxes are still kind of a thing.

So funny enough, I say I don't like boxes, and I was in the data center the other day and I'm cabling up some stuff, I don't get to get into the data center too often. If I'm in the data center, something went horribly wrong. I'm at that point in my career that engineers get very scared when I get it either onto the command line access, or even onto the physical underlay and racking and stacking boxes. And I think that's one of the things that I'm really challenged with.

We're talking to Juniper. You guys are a box company, that's kind of what you do, isn't it? It's kind of what you think. I would kind of describe Juniper as we are a operations company that is masquerading as a software company that is masquerading as a hardware company. So people think of us, they know us for our hardware, but we spend most of our effort on software. And then even within that software realm, we spend most of our effort on operations.

So it's a bit of an artifact of how the company was born. I'm wearing a shirt today. You can't see the whole shirt. This is 25 years. We're a 25-year-old company and a lot of our heritage where we kind of made our name, that's kind of coming through. So I think it's not uncommon that people think of us that way, but yeah, I mean, these days we are actually an operations company. So Juniper as an operations company, I think I can get that because of any of the disciplines that I've managed or participated over my career.

There's not much more, I think networking kind of puts the operations in operations. It is the center of everything that's IT. But one of the challenges that I think I'm coming along with as we look at the overall industry and we think about your role as VP of data center, and we think about the networking as part of that stack, is the relevance of networking going forward? Like what is Juniper doing to keep networking, not necessarily the center of the data center, but core to improving operations?

Well, I think from a software point of view, I mean, certainly we build switches and those switches run software and we've got to do networking things to networking packets and all of that makes sense. For us, the real big move recently, I mean, we acquired Apstra, we announced our intent to acquire in December, so just a few months ago, we closed the deal at the beginning of February and Apstra is really changing operations in a pretty foundational way compared to what we've seen historically.

So I'm fairly familiar with Apstra, but isn't that just yet another tool inside of my data center? My data center is CTO-advisor hybrid infrastructure. I have plenty of tools. I have stuff from VMware, I have stuff from EMC, which is the same company these days. I even have some stuff from some of your direct competitors. Isn't Apstra just another one of those things that complicates operating the data center? Apstra is fundamentally trying to change the way you operate a data center.

The way I think about most tools, there's usually two classes of tools. There's some tools that help you see stuff, right? There's a whole observability space. It's all the rage, right? And that's not surprising, right? The foundation for automation is basically you see something, then you do something. And so having tools to help you see something is really important. On the other side, though, there's tools that really help us do things in the data center. And here, I think there's really a split.

I think historically, the whole promise of software-defined networking, right? The whole idea of building out these centralized controllers was fundamentally to change operations, but we saw something different actually happen, right? Most tools today, they just reimagine what's the task to be done. If you wanted to do something in your data centers, you talked about racking and stacking all those boxes. As soon as you're done racking and stacking the boxes, what do you do? You got to go back up and configure and provision stuff and see if it's all working, right?

Well, if all you do from a control point of view is you imagine what's the job to be done, then you change or trade typing into each individual box for doing all that same typing, but in a controller. And if we're clever, maybe we give you a wizard to make it easier. That's kind of controllers' job to be done. What Axtra is trying to do is change that. It's around what's the decision to be made. It's not merely about executing some well-known command.

It's like, what do you want to happen? How do you know if it's working? How do we look at the dependencies that exist in that data center? And then allow you to make those decisions faster, primarily because the amount of time that passes between when you want something and when you actually get something, it's not dominated by the fingers on keys. It's dominated by the time it takes to go through reviews, the time it takes to plan things out, waiting for change windows.

If you could get rid of that, you can get rid of the elapsed time, and that's fundamentally what Axtra is trying to do. So you're speaking to kind of the enterprise architect in me. I was talking to my data center engineer the other day, and I was very descriptive in what it was that I wanted him to accomplish from a networking perspective. I'm at the point in my career that I still remember the things that I want my network to do and how that should work, but I'm no longer at the point where I can go to a CLI and get that done in 15 minutes.

I need a layer of translation. One of the values the engineer brings to me is that he understands all of the underlying equipment. So whether it's a Juniper switch or an Arista switch or a load balancer or a firewall, it doesn't really matter. I'm telling him my intent, and then he goes to execute that. Then, you know, on top of that, there's the other things that you talked about, the change management, et cetera. He understands how my organization operates, so he's able to do that.

Unfortunately, that doesn't scale, and one of the challenges I'm struggling with is, you know, Juniper is Juniper. You guys have data center switches. You have a wide variety of portfolio that could meet most of my needs. So when I talk to a Juniper salesperson, they're selling me Juniper, but what you're describing is more of what my data center engineer does, and I'm having a tough time reconciling Juniper, the place that sells me firewalls, switches, et cetera, now selling me software to orchestrate my data center.

That's fair. I think when you look at the architect, right, the architect, there's a distinction here between whether the architect is like a network engineer or whether the architect is like a Cisco engineer or an Arista engineer or a Juniper engineer, right? I like to play with folks who have kind of been identified by the vendor they support because the real question is, you know, how much of the network do you know versus how much of the vendor-specific syntax were you forced to memorize?

What we're really trying to do is elevate operations above the device, right? The future of data center cannot be, you know, going in, rote memorization of esoteric, you know, knowledge. It takes a PhD or a Harry Potter to go and make everything work. Like what you got to do is elevate above that. You want to understand what are the protocols and what are the absolute requirements of the data center. Ideally, specify those in abstract terms because as a business leader, if you can abstract the operations from the device, then it allows you to get some choice and flexibility in the underlying network.

You're not fixed from an operational perspective to a single vendor, a single, you know, device type. And so then as the industry is moving, and I think most of us would agree at this point, you know, things are changing pretty fast. If things are changing fast, but it takes you like an act of God to try to swap things out because the operations are so difficult, you have to rehire, reskill, retrain, like then you can't keep up with the rate of the pace of change in the industry.

And so everything has to be abstracted above the devices. That's what Juniper is doing here, right? We picked up Apstra, but Apstra sits over the top. You mentioned Cisco, Arista, Juniper. I would add, you know, Enterprise Sonic coming out of Dell, Cumulus. What Apstra does, it sits over the top of all that. You specify what you want, and then it's Apstra's job to translate what you want into the device specific configuration that sits underneath it so that your operations can be uniform, even if your underlying infrastructure is quite diverse.

So what I'm hearing from you is that it's in Juniper's best interest as an operations company to solve this problem, which is that of, I like to say, nothing ever dies in enterprise IT. I saw a stat that even I couldn't believe the other day. I had to Google it to find the background, but 70% of the Fortune 500 depend on IBM Z. For those of you not familiar, that's IBM's mainframe for mission critical applications. The numbers, I Googled it, and actually the number's like 71%.

So with that said, nothing ever dies. We implement core switches, and we implement designs from an enterprise perspective. These things to change out are super high risk. So even if Juniper is better than the solutions I have in-house, me changing it is more difficult. So I think I buy the whole idea that Juniper's bought into being an operations company and needing to keep Apstra kind of vendor agnostic. But let's go back to my data center engineer role, and this is where I run into resistance and automation again.

I'm telling my engineer what I want to happen. He doesn't care if it's Cisco, Dell, Cumulus, doesn't matter to him. He has a job because he has this knowledge that I don't have and that I cannot do. Isn't this a way to just eliminate his role? Should the network engineer be worried about their job? So there's like this subtext in our industry, which is crazy unhealthy. We all hear it, we're going to adopt automation because the goal is to lay off two-thirds of all the network operators.

I just, I think it's false. I don't think that's actually what's going to happen. First, like imagine the companies whose primary objective is to cut OpEx, right? They're going to tell their engineers, you know what, I want you to go learn automation or to adopt some tool or new method for doing whatever. And then at the end of this, what we're going to do is lay you off, even if they don't say it explicitly. What you'd have to believe is that they can run their current operations, which are probably running lean anyway.

If their goal is to cut expense, they're already as lean as they can be. Now if you pick up something new, you got to do the new thing alongside the old thing, which means in the short term, your OpEx actually goes up. I don't think it's likely that these people are going to hire a bunch of folks in, increase their OpEx so they can get some long-term return out of it. If they care only about OpEx right now, then they're going to care about OpEx all the time.

On the other side, look, if you're running a profitable business, the key isn't like, oh, how do I reduce my staff? The key is how do I grow profitably, which means I can't grow the number of people on my team linearly with the amount of revenue that I have, right? It doesn't make sense. So what I want to do is get just a better growth curve out of it. That's where I think automation is going to play a role. Companies that are growing fast, companies that have new needs, maybe they have new applications, new users, new services that they're offering.

What you want to do is pick up tools and technology that allows you to do that in a way that's more efficient. You know, get more people focused on, you know, I'm not the business of, you know, what's Cisco's configuration. It's like, what's the business of the business? And that's why the only path forward is to get them out of the weeds, get them focused on kind of what's happening at a business level, what are the applications, what do they need? And then you're still going to need underlying experts.

I mean, we're, we are just delusional. If you think that you're going to get by without having experts in this stuff, right? It's great not having an expert. As soon as something breaks, though, what are you going to do? Right? You still need people who know what's going on underneath because there's not always a tool that's going to fix that for you. So I just think that the whole, like this whole meme in our industry that the people are going away, I don't see it.

I think what happens is people get, you know, some people will actually get more valuable if you play it right, by the way, it's a huge career builder. And so I think what we're trying to do on the extra side is allow people to spend more time on data center architecture, a little bit less time on vendor specific configuration. And then when it, when things actually do go wrong, look, I don't always know what the solution is going to be. You're looking for the, the proverbial needle in the haystack.

If we can remove the haystack entirely and just give you the needle, then you can get onto your business of figuring out like, what do you have to do about it? That's where I think things go. And I think the over, the fear that's there, I think the fear is cultivated. I know why you do it. I mean, it makes total sense. It gets people's attention, but I just don't think it serves us very well. And I think what we've done is we've created an environment where people are a little bit paralyzed unnecessarily.

And that's what that's going to do is that's ultimately going to pause the market. And the question I would ask is like, who is that good for? Right. And it's a very limited number of people. And frankly, like if people stand to gain by everything pausing, like then we need to get those people to move forward. So I can co-sign this message from a practical perspective. I only have resources for so many smart people. I need those smart people.

When those smart people come to me and tell me that they're spending their time doing undifferentiated things, it makes me as a business owner not upset, but just challenged, you know, the other just in a parallel discipline. It's time for us to upgrade our vCenter and VMware. In the world of HCI and all that, all of this should be push button easy. I don't have that stack in my data center. So my engineer came back to me and I said, you know what, I need to deploy VMware Tanzu.

He said, Keith, sorry, I'm about to spend 20 plus hours of engineering effort designing the upgrade to the next version of vSphere. And I'm thinking, wow, that's a complete waste of my of his time and my resources. I need to move the ball forward. I only have so many smart people. So I can easily see how a tool like Apstra, again, doesn't displace my data center engineer that I, you know, I called it his name is Edwin and we call it EPI, Edwin programmable interface.

I tell him what I want. He goes in and does it. I need him doing different things than that. He's a missed talent. And I absolutely agree with you. This narrative that automation displaces knowledge workers specifically in our area is just a false narrative. These tools, when they're used, and this is the challenge I'm putting towards my audience. Do you believe tools like Apstra are additive to your environment and that they help to do that 80% of keeping the lights on while you're enabled to do smart things?

Or is it just another tool? Check it out. Check out the announcement. We appreciate Juniper for sponsoring the CTO Advisor CTO Dose. com. You can follow me on Twitter at CTO Advisor, DMs are open. We love to engage in conversation. Until then, talk to you next, CTO Dose.