Nokia EDA Under the Hood with Erwan James – Tech Talks Interview
Ensuring your data center automation journey doesn’t come to an abrupt end means you need to plan for your path and have the right way to get there. Standards-based approaches ensure that success will not only come quickly but also persist through staffing changes and industry advances. Tom Hollingsworth talks with Erwan James of Nokia about how Nokia Event Driven Automation (EDA) is helping operations teams move forward with their automation goals while also ensuring that future teams can understand the approach and continue to thrive.
For more information about Nokia EDA, make sure to check out Networking Field Day Exclusive with Nokia here: https://techfieldday.com/event/nfdxnokia24/
Transcript
Welcome to Tech Field Day. I'm Irwin and I'm a product manager at Nokia in our data center automation, uh, business unit. And I'm Tom Hollingsworth Irwin, it's great to meet you again.
Okay. Um, we had a great day here at Nokia Learning about event-driven automation, and we had a lot of great discussions with our networking field day exclusive delegates, but I was hoping maybe you could, uh, tell our audience out there what is Nokia event driven automation? So, Nokia IIDA is our next generation infrastructure automation platform where we're tackling the data center, uh, network management as a first use case.
Uh, so it's essentially our data center fabric controller. That's, uh, a very important step in the way that data centers are put together. I know we've been down this road many times, uh, you know, do we need a fabric?
Is it important to be able to have software control of it? So I think there's a lot of things out there that maybe people are saying, well, I've heard this before, but obviously for noia to develop this today in 2024, it's, it's kind of valuable to your vision for things. What is it about, uh, Nokia IDA that makes it a different solution for what people are trying to accomplish?
Yeah, sure. So I like to break it down in like three pillars. Um, three things that we really kind of focused on when we developed this, uh, product starting a couple years ago.
Uh, the first one is our use of abstractions and in a declarative MA manner. So we're truly, uh, declarative, which means that we tell the system what is the end state we're wanting. So we're wanting a data center fabric with certain set of parameters, protocols you want to use, and we expect the system to take care of that.
Getting from not having a fabric deployed to having a deployed or changing from IPV four, say to IPV six. So we are, we are telling the system in, in a declarative way what we want. And part of that is also the abstraction piece of it.
So part of that is you want to tell the system, uh, that you want a fabric, not necessarily how to implement the fabric on say, our SR Linux switches or another vendor switches. You just wanna tell it. You want a fabric and these are the protocols you want to use.
And so there has to be some sort of abstraction level that accepts those inputs without having an implementation detail and understanding. So that's the first pillar. Uh, the second pillar is all around reliability and predictability of change management.
So that's around, we wanna make a change in the network. We're going to, uh, ask the system to potentially dry run those changes. So generate all the configs, make sure that they will get accepted by the nodes.
Give me as a human operator the chance to review the changes you're about to make on my network and then make the change. And if the change were to fail, make sure you can revert that change back. And so we also support something called, uh, network-wide transactions, where if you make a set of changes and any of them were to fail, we roll back the entirety of the changes.
So the network is never in a limbo state where it's partially configured with one of the nodes not configured. It's always able to revert itself back to Alaska known state. If for whatever reason there were, there was a failure in, uh, in transacting the change on onto the network.
And the final piece of that is, uh, that we have a very extensible system. So the concept of of abstractions is not necessarily that new in itself. Um, you know, the concept of intent-based networking is really founded in those abstractions.
However, uh, when we have abstractions as a vendor, it typically tends to be a very opinionated abstraction. So what I decided as a fabric is what I'm imposing on my customers, a fabric should be, right. Um, what we wanted to make sure we had was an extensible solution.
So that my opinion of what a fabric is, is actually, uh, consumable and extendable. So someone can come in and say, well, actually I don't agree with your opinion of what a fabric should be. I actually wanna enable these knobs.
Maybe I'm using PCF for my AI fabric. And so we need to make sure the system is not only opinionated with our views of what an abstraction should be, but that it's also extensible. So the operator can make changes to the, the fabric that they want, or potentially the, the, the virtual networks or the VPCs they want to add to the system.
And that extends itself all the way up to the ui. So there's a fully extensible ui. They can build their own dashboards, uh, they can build their own set of views that they want to expose to their, uh, no team.
It sounds like you've taken a lot of the principles that people have, uh, loved about things like cloud computing and kind of moved them into the data center to give them more of that experience that is leading them to want to develop more there, but also giving them the feature set for say, workloads that can't move, or for large more complicated projects that are going to kind of be future concerns for a company. Yeah, that's right. And our target was really, uh, you know, kind of twofold in terms of, uh, of, of our customer base and their skillset.
The, the one side of the, the customer base is gonna be a, uh, UI focused, uh, traditional network engineer looking to start their automation journey. Uh, and then you have the full other spectrum, which is we're dealing with cloud engineers, right? People are used to dealing with Kubernetes, those types of constructs.
And so we wanted to make sure that the platform was consumable by both of those types of people. Uh, and so really we, we made sure that no, the whole, the entirety of the platform is, uh, is consumable using for, for instance or Kubernetes, API if you wanted to, or entirely using the UI if you wanted to. And so we really kind of address the full market in terms of the person who's going to use the platform.
Well, it sounds like there's a lot of great information out there that you guys are putting together to make this a reality for a lot of organizations. If people wanna learn more, where can they go to find that? com has a lot of the information that we, uh, uh, that we've, we presented, uh, today with you guys.
com for more details. And we will be back with more great content around this topic very soon. So stay tuned.