WTF is Software Defined Networking with IBM’s Andrew Coward
- As banking moves to the cloud, it's getting harder to understand and control what's happening on banks' networks.
- IBM's head of its software networking business, Andrew Coward, joins us on the Tearsheet Podcast to explain how software can help mitigate the issues.
Building on top of a bank – the way Banking as a Service enables a tech company to do – has some interesting side effects. Who controls the traffic in the network? Regulators are increasingly interested in sorting out how financial institutions partner with tech firms, and that means understanding how all these constituent parts fit together.
Today’s guest is Andrew Coward, general manager of IBM’s software networking business. His team works with financial institutions on SDN – or Software Defined Networking – to bring control and policy management back into their infrastructure regardless of where their application lives.
Andrew explains what SDN is and how we got here in history. We discuss how SDN plays into the future of financial services, too. I ask Andrew about the rollout of 5G and how that impacts banks and traditional FIs.
Andrew Coward is my guest today on the Tearsheet Podcast.
Subscribe: Apple Podcasts I SoundCloud I Spotify I Google Podcasts
The following excerpts were edited for clarity.
Path to here
Andrew Coward, IBM: The software networking business unit is a reasonably new business unit at IBM. I joined and I started the business unit just under two years ago.
I've been in networking for pretty much my entire career. I started out working in the government in the UK, and realized there was slightly more money to be made working for vendors. Who would have guessed? I spent about 12 years in Asia, bouncing between Hong Kong and Tokyo. I spent almost 10 years at Juniper and moved across the US. I did a couple of startups, the last one was called Lumina Networks – we made the Open Daylight SDN controller, that was supplied very widely today in many of the large telcos.
Then I got the call from IBM, who said, we really think networking is going to be important to us, and we want to start a new business unit. It's been like 20 years since IBM had exited the hardware networking business. We don't intend to be in the hardware business for networking – we think it's all software. It was a great opportunity to start something and really operate as a startup within IBM.
Running in multiple clouds
If you think about the problem of moving packets around the world, to a large extent, we kind of figured out how to do that. And it actually works rather well. However, today it's about what traffic is allowed to go where, particularly in this realm where we've got so many applications that are running in all the different clouds. When you go and you talk to enterprises, you say, well, how many clouds are you in? It's not one or two – it's three, four or five. And nobody seems to think there's a limit to how many different clouds you can use for different applications in different places.
I think what you'll hear from many network managers is they've lost control of the network. And so a lot of the way we want to apply Software Defined Networking is to bring control and policy management back into that infrastructure, regardless of where the application lives, regardless of what networking connectivity is required – so that you can drive the connectivity and the automation and bring some order back to what's a pretty chaotic environment right now.
Behind the chaos
If you think about how networks have been built historically by large banks, they built these global MPLS networks, they buy their own fiber, they're very much in control of where every packet goes. The security policies don’t work anymore, because the applications have moved into different clouds. Things like COVID and working from home – you're not on the company's intranet anymore in the same way. And so increasingly, network managers feel like they've lost control of the network.
Many times I end up in what I call ‘therapy sessions’, where we sit down with heads of networks, and they say, “You wouldn't believe what happened last weekend! This group moved this application into the cloud on Amazon. And now I've got no control over it, but it's still my responsibility.” When you hear things like, ‘I don't know where my traffic goes anymore’ from senior network leaders in the industry, you think about how that context of that conversation would play out in front of a regulator. These are really complicated and difficult problems to resolve. But in fact, some banks have decided to try and avoid putting stuff into the cloud until they can resolve these issues. So it's actually holding us back.
SDN and the migration to the cloud
First of all, from a tooling perspective, how are you going to get visibility into what's actually going across these infrastructures? What kind of packets are going where? What kind of applications? What kind of performance are we expecting? In the old days, when something broke, a red light came on, or it just stopped working, and that doesn't happen anymore.
Think about how load balancers are deployed to distribute load to the website or the major organization. Now, if one of those goes offline, nothing bad appears to happen. Now it takes an extra couple of seconds for a transaction to go through. Those things are very nuanced. And so understanding holistically how the whole network works from a visibility perspective is very important. As we started putting the strategy what we're doing at IBM together, we said, okay, let's make visibility of the network infrastructure.
You need to get that visibility to understand how your applications are performing from a network perspective. So that was kind of the first element. And then if you're going to do that, to give you control where web traffic goes and what kind of policies can be put in place and automate that end to end connectivity of that sequencing.
What I've seen and what I get told by the banking community, they’re like, yeah, that's happened, but we are still going to hold your feet to the fire and what you have to deliver. If you think about a bank having to be open 24x7, if the mobile network goes down in a particular country, or you've got a major outage, it's still the bank's fault. It's like shutting the doors and not opening your bank in the morning. I've seen banks try and own more and more connectivity all the way up to the edge of these mobile networks to appease regulators – to say, look, we've done everything we can but actually run the 5g network ourselves to make sure that customers can reach us. So I think regulators may understand some of the nuances of this, but there's no give in what's required here.
SD-WAN and Network Automation
First of all, there's a premise that these locations have to be connected all the time and always on and that may be a given right. And historically, we would put fiber in the ground and we do what we call ‘diverse paths’ – a banking branch would have two connections, one going one way and one going the other. I think what's interesting now is the telcos are blanketing cities like New York with incredible high performance 5g networks.
And it's not just for banks, of course. I’m thinking about retail, for example. Retailers historically said, I need to be resilient in case the network's not there. So, I'm going to make sure that I've got enough compute on premise, so if somebody comes to the door, I can give them a burger or a chicken wing or whatever it is, and I don't rely on anything else to make that happen. Now, of course, what's happened is that things like COVID turned everything around. Particularly because now we don't just walk into a burger store, right? We order it on our app. And if we try and order it on our app and it doesn't work, we'll go to a different store. We'll vote with the app.
Connectivity has completely changed the paradigm. Connectivity for retail is as important as it is for a bank branch. That creates some interesting opportunities. So how much compute do you actually need on premises anymore? And how much can you push back into the cloud? The telcos see there's a huge opportunity for edge compute. In repurposing this incredible real estate they've got all around the country – around the world, actually – which used to be for these big telephone switches, is now a prime location to put general x86 compute. So there's a kind of pullback of compute that's going to get going to go into these Edge locations. And it's going to be about if I can remove equipment from on premise and put it back somewhere, then it's a much better proposition.
Data security and privacy
What's happened is that people have gone back to working in their banking branch, and they're using video calls. Now, the way banks connect their networks today, all that traffic is being sent back to some central data center, getting pushed through firewalls, and then going out to Zoom or WebEx or whatever. And so you can imagine that the volume of traffic now is very significant, which just didn't exist before COVID. And so the question becomes, well, why would you push all that traffic back through some central data center? And the answer is because you want to make sure that there's no data being exfiltrated from that bank branch, and you want to put all those security policies in place.
But it still doesn't make any sense to push it 1000 miles across the country. And in fact, of course, the users are complaining. They're saying, I have a much better WebEx experience or Zoom experience when I'm in my home than when I'm in my banking branch. So it is kind of the worst of both worlds, right? So what we're looking at then is technology – SD-WAN is one example of that – where you can say I'm going to split the traffic in a secure way. I'm going to still securely move it from the banking branch to a location, but now I don't have to bring it all back to my central data center – I'm going to bring it to places where I can do inspection, but I'm going to ensure a much better experience for my customers. And for my users, and I'm not going to take all the bandwidth out just to do video traffic, where my banking applications don't work anymore.
So there's a lot more nuance in the types of traffic and where the traffic needs to go. And again, it comes down to policy management. Essentially, we can think of SD-WAN products as just being intelligent about where packets go, but then take the path diversity piece and say, okay, well, historically, we had two circuits coming into a bank branch. I also have a 5g backup. And so I don't really care how the traffic leaves my branch, as long as I can encrypt it, I can secure it.
5G rollout and prioritizing consumers vs. device manufacturers
I think telcos have bet the farm basically on 5G being an enterprise play, and that hasn't really happened yet. So all that 5G has really done is make our phones a little bit faster. Has anybody noticed the difference? Nobody can really tell. Of course, there was huge spectral savings and efficiencies and so on by moving to 5G, but it's still costing tens of billions of dollars here in the US and elsewhere for each telco to go through this migration. So enterprise said, this is how we're going to get the next billions of devices on the network. And that's the value. And so for companies like Verizon and AT&T, the reason that they're blanketing cities like New York or Vegas with 5G is that they want to be able to get into all those retail locations, all those branches, and make that ubiquitous from the business connectivity perspective. That's one angle.
But also think about how many different types of devices are showing up, whether it's in a bank branch, or whether it's like a burger store, or any other location. We think about the connectedness of things that have traditionally been on WiFi – so you buy a printer, or there's a coffee machine or an ice cream maker. Now, historically, it was connected to WiFi, and WiFi is just really hard to manage. It requires programming and development, and you have to set it up right. I have a washing machine in my home that's connected to my WiFi network and it's in a place where I don't have good WiFi reception. It doesn't tell me anything particularly useful. But for the manufacturer, this information is absolutely critical. And so if you can put 5G into those devices, wherever it ships, the consumer or the business isn't going to have to set it up. It's just going to work out of the box.
So now you've got this overlapping interest between the device manufacturer who's just sold a printer that's gone into a bank branch that now has 5G connectivity and the network administrator for that bank saying, well hold on a second, this has got its own connectivity – what does that mean for my security? This is going to be this fight going on. It hasn't happened yet around the control and management of these devices. There was a brilliant example of it: I think it was John Deere, or certainly a US tractor manufacturer. They were selling tractors into Ukraine, and some Chechen fighters decided that they quite liked these tractors, and they shipped them back to their farms in Chechnya. So, tractors get loaded on the train, and they end up in Chechnya. Now, these tractors were then subsequently shut down, using satellite network connectivity, so that they get rendered useless. And so we've got this interesting thing where so much of the value in a machine is in the software now. Having that constant control in the hands of the manufacturer of that equipment, but not in the hands of the consumer or the business.
And so you can think about the population of devices: the fryer is now connected, so that it knows and tells me when the oil needs changing. Ice cream machines are going to complain when they haven't been cleaned out properly. All of these things are network connected, and they may not even live on the network that belongs to that enterprise. And that's a scary proposition if the two networks don't overlap, and what that looks like and how that gets managed as a problem hasn't been resolved yet.
IBM and SDN
The strategy I'm running is kind of twofold. One: last year, we acquired two companies. We acquired Turbonomic. It was actually two companies in one. One was a product that basically looked at the performance and management of compute. And the other product was a product called Set One, which looks at network performance under management – Service Assurance, if you like. So that product was added to my portfolio. So that's giving us this huge visibility of all the stuff that's in the network that's deployed in about 30 of the top 100 banks globally. And obviously with IBM behind that, we're working on the other 70 out of the top 100 with that product.
We also acquired a company called Volta Networks. That's given us a distributed routing management line. We have orchestration and management products that we've applied today into telco, because the 5G problem of orchestrating a global networking infrastructure is a hard one. We're applying that now into what I call the ‘multi cloud networking problem’, which is how I control and manage connectivity in between the clouds and allow my network team to really set the rules about what a development team is allowed to do. So yes, you can go deploy an Amazon, but you have to take these network goals with you when you do that, and bring that kind of control management system together.
So these are products that we have in market and we're delivering today, with a lot more things that we're building organically. They're going to be in the market next year, particularly tuned around this multi cloud networking area. It is a hot market – there are probably six or seven startups in this space already that are very well funded. We think as IBM, because of the cloud presence that we have, because the trust is given to us by the financial community, that we're very well placed to connect the compute together with the networking to bring those two things together in a very meaningful, controlled environment.
When we started out, I think it was just me, 18 months ago. We're at about 450 people on our team right now. So we're a very fast growing organization within IBM.