Juniper Apstra 4.0
Transcript
>> So Mike for the uninformed, what is Apstra? >> So Apstra's 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 box company.
How are we going to kind of handle brownfield? And isn't this taken away from network engineer's jobs? Stay tuned for the rest of the episode. (tense music) Hey, how's it going? It's Keith Townsend, principal of the CTO Advisor. In this sponsor podcast, we have a guest that I've known in the industry now for years, but I've not interviewed him on the CUBE. I've not interviewed him on the CTO Dose. I don't even know his title over from the Juniper Networks, Mike Bushong.
Mike, welcome to the show. >> Aw, thanks for having me, Keith. It has been awhile. 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.
(Mike laughs) >> So, well, the software we've talked about, the challenges 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 on to 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, right? What 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 what we spend most of our effort on software, and then even within that software realm has been most of our effort on operations. So it's a bit of a, kind of an artifact of how the company was born. I'm wearing a shirt today, you can't see the whole shirt, but it says 25 years, and we were a 25 year old company, and a lot of our heritage where we kind of made our name like 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 is 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 pitch the operations an 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 or we think about your role is 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 Astra 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, and it's out of my data center. In my data centers, 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's fundamentally trying to change the way you operated data center.
The way I think about most tools, there's like 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 really important. On the other side though, there's 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 this fundamentally to change operations, but we saw something different actually happened, right? Most tools today, they just re-imagined what's the task to be done? If you wanted to do something in your data center. As 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 as job to be done. What Apstra's 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 are 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 keys on or fingers on keys, it's dominated by the time it takes to go through like reviews, it's 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 Apstra's 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 low balance or a firewall, it doesn't really matter. I'm telling him my intent, and then he goes to execute that, then 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 scaled.
And one of the challenges I'm struggling with is 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 architecture, the architect, there's a distinction here between whether the architect is like a network engineer and 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 identified by the vendor they support, because the real question is, 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 about the device, right?
The future of a data center cannot be going in rote memorization of esoteric knowledge. It takes a PhD or a Harry Potter to go and make everything work. What you got to do is elevate above that. You want to understand what are the protocols? What are the actual 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 device type, and so then as the industry is moving, and I think most of us would agree at this point, and 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, re-skill, retrain, 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. And you mentioned Cisco, Arista, Juniper. I would add enterprise SONiC coming out of Dell, Cumulus. What Astra 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 defined the background, but 70% of the Fortune 500 depend on IBM Z. For those of you not familiar with that IBM's mainframe for mission critical applications the numbers, I Googled it, and I believe the numbers 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 this solution I have in house meet changing it is more difficult. So I think I buy the whole idea that Juniper is bought into operate main operations company in 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, it 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 the subtext in our industry, which is crazy, unhealthy, right? 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 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 methods 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 they're 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 and increase their OPEX, so they can get some longterm 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? But 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 the 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, get more people focused on not the business of, 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 will they need? And then you're still going to need underlying experts. I mean, 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 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, some people will actually get more valuable to 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 Apstra side is allow people to spend more time on data center architecture, a little bit less time on vendor specific configuration, and then when things actually do go wrong, like I don't always know what the solution is going to be. You're looking for 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 that the fear that's there and 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 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, if people stand to gain by everything pausing, 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.
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. " 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 apps or again, doesn't displace my data center engineer that I called it, his name is Edwin and we call it, EPI Edwin Program well, Interface, I tell him why I want, he goes in and does it.
I need him doing different things, than that, he's a immense talent, and I absolutely agree with you with 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 @CTOAdvisor, DMs are open, love to engage in conversation, until then talk to you next CTO Dose.
