Steve Cummins:
Michael Wynston is the director of Global Network Architecture at Fiserv, having previously managed networks at a number of financial institutions. Today, we'll be talking about CCIE certifications, SD-WAN, and Network Function Virtualization. Michael, thanks for joining me on the Living on the Edge Podcast.
Michael Wynston:
Thank you Steve, for inviting me. I really appreciate the opportunity to speak to you and your audience today.
Steve Cummins:
Great. So let's start with the simple stuff. Can you just give us a quick rundown of what Fiserv does and how your IT organization is set up?
Michael Wynston:
Sure. Fiserv is the combination of a company that was called First Data. We merged with Fiserv a little over 18 months ago now. We are one of the world's largest financial services or FinTech companies. We're responsible for a number of different countries, continents, everything that you do that does not involve cash. So if you're shopping online and you're buying something with a credit card, or if you're financing a vehicle, or if you're using an online banking app for some of the largest banks and some of the smallest banks. Some part of that transaction, or in some cases the entire transaction passes through Fiserv's global infrastructure. So we're the big finance company behind the curtain of all of the banking and credit card and merchant companies.
Steve Cummins:
So a lot of what Fiserv does, we rely on every day, we just don't realize it?
Michael Wynston:
Yup. That's a good way to put it, right. So when you go to the store and you put your card into the chip reader and it says not authorized, and you say, I know my card is good. Why didn't that work? That's probably a failure somewhere inside of our infrastructure, which, yeah, it's funny. I go shopping with my wife and I actually count off in my head the number of seconds it takes for that authorization to come back because I know what our SLA is for our clients. So to me, that's something that's actually really important.
Steve Cummins:
I like that. Nice bit of professional pride you're showing there. So based on that, it's obviously mission critical for a lot of companies. Just give us an idea of how the IT organization is set up of Fiserv and what your role is within it?
Michael Wynston:
Sure. So, at Fiserv we truly embrace our global nature. My team has a global network architecture team has architects located in all of the different continents. We've got architects in APAC. I have architects in India, North America, South America. So we make sure that we collaborate on different technologies that we implement. So we create a unified homogenous environment, but we still take into account the specifics of a particular region. So things like GDPR or any type of privacy legislation, because a lot of that impacts us and how, and where we store our customer's information is something that we always think about. And driving our organization on a global scope, we try to always like the best of breed technology. One of the things that we really try to emphasize is no shiny object syndrome, I'm not buying something because the vendor said is what you need it.
Steve Cummins:
Yep. The shiny object syndrome. I think we all fall foul of that. It’s whether we're buying things personally or buying them for work, there's always the new thing that's coming along, right?
Michael Wynston:
Yeah. And within my team, we call each other out when we do it, because we all fall victim to it, you know, constantly just you always hear, Oh, this is the newest best thing. And it's a hundred times better than the other thing. So you need this now. Hell, yeah. Maybe you're right. So we always make sure to call each other out on that kind of stuff too.
Steve Cummins:
Yeah. That's good. It's funny I was having a conversation with a friend of mine yesterday about the new iPads and which one to buy and he said, "Well, you know what, if you wait until March, they'll probably upgrade them again. And it's like, yeah, but there's always the next thing. Right?
Michael Wynston:
(laughs). So, you know, what's really funny about that. I kept waiting for the next iPad pro because I wanted the newer processor. I know. I said, I'm always going to be waiting for the new iPad pro with the newest processor. So on black Friday, I went out and I bought myself an iPad pro with the previous processor generation from the iPad air. Because like you said, you'll never have the latest because they're always going to announce something better the day you buy it.
Steve Cummins:
That's it that's, that's how it goes. All right. So you've inspired me. I'm going to go make the purchase now. So at the beginning I mentioned here, you've worked for a number of companies. You know, people like Cisco, Pfizer, Merrill Lynch, you've kind of got a Who’s Who, and you've been in multiple roles, right. I know we've talked about, on a previous call, in some cases you've been a consultant you've been at value added reseller, you've been on a corporate team. So, just give me some thoughts on some of the skills that you’ve developed, that made it possible to switch between those roles. And if there was anything that you see that's sort of uniquely different between them?
Michael Wynston:
Sure. So I got my start actually in this industry, not directly in this industry about 30 years ago and because... yes, I'm that old…. in a lady's handbag warehouse actually in Long Island city in Queens, where the local IT team was never able to give me the information I needed when I needed it. And I annoyed them to the point where one day they just dropped a bunch of books on my desk about FoxPro and dBase and Novel and reading those, I thought, Oh, I like this a lot better than warehouse management. Funny enough, if anyone watches the show Young Sheldon and how he spent time in Radio Shack, showing people that operate those computers, I did that. I did that, and I showed people how to operate the trashy TV and the radio shack computer.
Michael Wynston:
Anyway, so as I started out, I found that the most important piece of being in this industry is to never stop learning. And part of that mindset of never stop learning is to not pigeonhole myself into just one particular, type of infrastructure. So it's not only about the network, it's not only about the compute, not only about security. You have to look at... now, I'd like to reference the OSI model. You have to really make sure you understand all the layers to really be a subject matter expert in any one of them. You have to understand your actions. So as I've gone through my career, I've tried to always make a point of understanding, not just a layer that I'm focused on, but the layers above and the layer below, so I understand what's actually needed and what the requirements are in driving that infrastructure.
Michael Wynston:
Now, when I first started out, I actually got my start early on in my career as an instructor, which I think is probably the best thing that could've happened to me, because it gave me the opportunity to stand up every week in front of 24 new people and try to explain to them something that they had no idea, or in some cases believed they knew far, much more than I did about something to teach them something. And for me personally, it helped me develop a skillset of enrolling people into what my vision was. Enrolling folks into learning new technology and enabled me to be able to speak to all of the different levels. So whenever I talk to junior engineers or someone who says, Oh, well, what technology do I need to learn next? Or now where should I focus my energy? One of the things that I always emphasize is, don't forget your interpersonal skills, because we can always hire an engineer to lock in a closet that we have configuring devices all day or writing code all day.
Michael Wynston:
The engineer, the architect, the developer, that's really hard to find is the person that you can put in front of a customer or a consumer or the end-user, the requirements team, and actually communicate with them in a way that they understand, so that you can really make sure to deliver what's needed. And a lot of that foundational information for me came from my certifications. So my CCIE number, 5449, I got it January 9th of 2000 when I had to I actually cable my own rack. I had to know IPX, AppleTalk, BACnet ISDN, OSPF, all of those fun legacy technologies. But I still up to this day, encourage all the engineers I work with to start out with the most basic networking certification.
And for me, I think the CCNA is really a great place to start, because whether your company adopts a fully Cisco strategy or not, I have not personally seen any other networking certification path that really embraces the full end to end routing, switching, telephony, wireless. And now with the, Cisco developer certification path, all of the different things from a skillset perspective you need in order to be successful in this industry. So while I don't think certifications prove you can do what you need to do, I do believe it's a great way to open a door and a great way to start out.
Steve Cummins:
Yeah, that's interesting. So, you know, there's obviously a lot of talk these days about Cisco certification and, maybe not being as relevant as it may have been in the past. And I know they've made a lot of changes to the programs. So from your perspective, it sounds as though you see it as a good foundation for somebody and then maybe there's other areas you'd encourage people to dive into once they have the CCIE?
Michael Wynston:
Yeah, absolutely. Because when I first started in this, Cisco made routers and switches and that was it. And then when, you know, acquisitions like Selsius that they bought for IP Telephony and Arrowpoint that they got for the load balancer technology, you know, as that started to grow, it was real divergence where you could really pick a particular area and become a subject matter expert. But I think starting off with just the foundation of basic routing and switching is a really good way to get your feet wet so you can get insight into the other different pieces that are part of the network infrastructure landscape we know today. And, you know, maybe you're looking at that and you go, wow, I really like the part about writing code.
And you go into being a NetDevOps developer, or you say, well, public cloud really feels like where it's at for me, while your CCNA certification, translates very easily into some of the basic AWS or Azure certifications in the networking space, because at the end of the, all we're doing is moving IP packets.
Steve Cummins:
Yeah. That definitely makes sense. And you made an interesting point a little earlier on about, it's not just the technical certifications, it's the personal skills as well. Any particular training or experience you think is valuable to that, or is that just sort of, you know, life skills?
Michael Wynston:
I think life skills are absolutely important. One of the other things I also encourage, , you know, these strange times that we're in now, this is more challenging, is to look at things like Toastmasters, not sure, you know, every one of your listeners are familiar with that, but there are a number of places where you can go, just community things and, other engineers stand together or even the user groups that are formed for the different technology sets, where you can put yourself out there and really do your best to try to enroll and explain and convey the different thoughts and ideas that you have about the infrastructure. So you can develop your speaking skills, your interpersonal skills, that again, for me at the end of the day, that really becomes a differentiator.
Steve Cummins:
I agree, there's this stereotype of the network engineer working away in a darkened room and not talking to anybody. But I think we all know in reality, being out in the world is as valuable as having the technical knowledge. So, that makes a lot of sense. Talking of being in the real world, the podcast is called Living on the Edge, partly because of the clever play on words, partly because every network engineer has a story about when everything went wrong and they get the call at 3:00 AM and they had to fix it. So anything from your experience, any interesting or funny story you could share?
Michael Wynston:
Yeah. So if I go all the way back to November of 2001, right after 9/11 happened, I was working at Merrill Lynch at the time and they had a project to build a data center in 30 days. And this project was actually, we worked out from Staten Island and we worked in the data center literally for 30 days straight. You know, we slept in there, they gave us cots, maybe it wasn't exactly 30 days, but certainly felt that way.
Steve Cummins:
Yeah.
Michael Wynston:
And the funny story around that is quite often, we would go out for an hour or two at night, because there was a restaurant around the corner where we would eat at. And quite often we would come back and find that everything we had done, some of the electrical engineers had moved stuff around they had done cable, they had re-cabled. And what I found out at the end of the day was every time we would leave, there was someone on the structural engineering side who wanted to be a network engineer, who believed that there were better ways to do things. And he went ahead and he told them to move stuff around after we left. And that was so frustrating. But what we were able to do is find that person and talk to them. And instead of having them, I guess you could say work against us, enroll them into delivering and configuring and making sure while we were gone, nobody broke anything that we had already built.
Michael Wynston:
And it was always, you know, at the last minute, right before we were supposed to turn up some new piece of that data center and turn it over to the client that nothing would work and we'd scratch our heads and not know why. And because we were actually sitting there in the data center with our coats on, because it was always cold, we would walk over to the equipment, and go “This is not how we cabled it before what happened here?” And, yeah, you know, strange things.
Steve Cummins:
So you're thinking there’s a gremlin in the works. And it's actually somebody who just desperately wanted to be a network engineer, and you can't blame him for that.
Michael Wynston:
Yeah. Somebody who wanted to be a network engineer who thought he could rebuild it himself
Steve Cummins:
Oh, that's funny. You know, at Opengear, we're all about this idea of network resilience. But as I talk to network engineers, there is obviously, that phrase means different things to different people. So I'm just curious from, from your perspective, what does network resilience mean to you?
Michael Wynston:
So to me, network resilience means adaptability. When we look at the different ways that we try to put network resilience into the infrastructure, whether it's via the HSRP or ECMP or building redundant routers, at the end of the day all of those different features and functions are really driven towards getting the infrastructure to be able to adapt to change. And if we look at it that way, it really opens up the idea that maybe the way we're doing resilience today is not the best possible path for delivering the resilience that we need. As long as we're willing to open our mind to the idea of adaptability. And for me personally, what that means is not doing something today, simply because that's the way you did it yesterday. And having that open mind and adaptability helps us build the constantly improving, constantly evolving infrastructure that serves our clients today.
Steve Cummins:
Yeah. This idea of adaptability I think is an interesting way to look at it. You know, some of the things I hear from people is this idea of well resilience used to be redundancy, right? Because it was in the data center. So you could afford to have an extra router and an extra server and, you know, a generator and, and spare air conditioning, all that good stuff. Things move to the edge and suddenly you can't do that. So you have to adapt, right. It can't be redundancy anymore. That all of these moves with the pandemic-
Michael Wynston:
Sure.
Steve Cummins:
... same thing. Right. What, what worked a year ago suddenly it's very different. So I think that's an interesting angle, the, the idea of just making sure you're adapting your solution as the environment changes.
Michael Wynston:
And, and, you know, to speak to that point to living on the edge. Right. We have a very, very forward thinking, very future designed NFV infrastructure that we use. And one of the first things that we said was, well, we have to put two routers in front of it, so it's redundant. And then we said, well, we should really virtualize those routers because everything's about, you know, network function virtualization. And then we said, well, if we virtualize the routers on the infrastructure, that's supposed to host the virtualized routers, how do we get to the infrastructure to actually build the virtual- cutting out very chicken and egg kind of thing. So know that kind of adaptability and, and being, you know, willing to look at the ideas that you might've had about how to create the reliability in the infrastructure. And I don't like redundancy because to me, quite often redundancy, wastes money, right? Cause you're building something only in case of fire, right.
In case of emergency, break glass. I would like to build infrastructure so that in case for emergency resiliency comes into play, because there are resources that are available that could be consumed to provide that resiliency and redundancy, rather than dedicating something to just sit and wait for something else to fail. And that's really what we're driving to, you know, from an adaptability standpoint.
Steve Cummins:
Yeah. It makes a lot of sense. So it's actually funny. Because we, we hadn't talked about this prior to the recording here. But you know, one of the things we're seeing with Opengear, and our focus is really out of band management where traditionally that's been installed as emergency access. And to your point, you're really only putting it there, for that one moment when you need it. We're seeing folks now are actually spending the money to implement it and then using it as an independent management plane every day. Right. So you're not spending that money just for the once “what if”, but it becomes part of your overall solution.
Michael Wynston:
Yeah. Yeah, absolutely. Well, and especially since we've moved past, you know, ribbon cables for, for console conductivity, so. (laughs)
Steve Cummins:
See, things change. You know, something I wanted to pick up on there. You mentioned network function virtualization. Could you just give some thoughts on how you think that's impacting the way IT infrastructure is being built?
Michael Wynston:
So as we've moved more towards a dis-aggregated footprint for network infrastructure, where network infrastructure exists in public cloud, it exists inside of your colo facilities, it exists inside of your traditional data centers, it exists inside of your client environment. Building purpose-built pieces of infrastructure routers, load balancers, firewalls, and doing a one size fits all kind of footprint, quite often leaves you with a lot of abandoned infrastructure. And what that also, in addition to your abandoned infrastructure, which wastes CapEx, which no one has CapEx to waste, it also creates an environment where you can't scale quickly in the event of a change in circumstance and coming back to adaptability. So for us, we really looked at network function virtualization, not because we wanted to get rid of all of the routers and firewalls and load balancers, but because we wanted to decouple the function that they provided from the actual hardware that you use, to provide that particular function.
So when we look at NFV it's so that we can go ahead and do things like dynamically scale, and add more load balancers, ADCs or firewalls, when the resources that we need to consume are not there immediately. We have applications and monitoring and performance analysis that helps us to create this infrastructure on a predictable basis. So it makes that all infrastructure dynamic. You can't do that with a router or a firewall that you hold in front of you, you order from a provider that takes, you know, somewhere between 30 and 90 days, just to ship, let alone the time to install and put in the change request. The other advantage to NFV for us is it allows us to constantly evolve the network functions that we use. So we like vendor X today because their firewall does something that the other vendor doesn't do. And then three or six months from now, that vendor that we were using has a competitor comes along, that does it better, faster, cheaper, also its software, swapping that piece out, that virtualized software piece is a lot simpler than swapping out a physical load balancer or a router or a firewall. So it makes the infrastructure a lot more adaptable based on the features and functions that you're trying to deliver.
Steve Cummins:
Right. It continues that move away from being locked into a particular ecosystem, right? You can pick and choose from whatever the... well, the, the danger is it's the shiny object of, well, Hey, we'll switch to this-
Michael Wynston:
Yeah.
Steve Cummins:
... this vendor, but it does give you a lot more flexibility.
Michael Wynston:
Yeah. It does give you a lot more flexibility. So one of the things I always like to emphasize about NFV is that, without collaboration with your compute partners, you can't do it. And the reason why I say you can't do it is because you really don't want to. So when we went into network function virtualization, I made sure that I was joined at the hip with my peer on the compute and virtualization side, because the last thing I want any of the network engineering teams to do is own patching, So ESX hypervisor, or own patching or maintaining the Linux KVM system that's providing the ability to run all those VNFs. I also didn't want to have to, although we did, get every engineer to understand what NUMA pinning means and, and how you allocate CPU sockets.
I wanted to be able to focus our energies on how we wanted to service chain all of the different VNFs in a logical fashion. And then work with our compute partners so that they could deliver the compute infrastructure we needed in order for us both to be successful. Again, it went with what's our strength in that area, and what's your strength in that area? And that's worth the other to build this solution in a more unified way, rather than just sitting inside of our silo and saying, well, we can't do it cause the compute guys, they don't understand networking. They shouldn't have to, and the same in the other direction.
Steve Cummins:
Right. And then you and your team can focus on the parts that make sense to you and rely on the others to bring their expertise into it.
Michael Wynston:
Yeah.
Steve Cummins:
So one other subject I want to bring up when we first met, you came up with a phrase that I don't think I've ever heard before, or may never hear again. You said to me, "I love SD-WAN." So, obviously a hot topic. And one of the things you mentioned to me is that with the pandemic, a lot is changing. So maybe you could just share your thoughts on what you see happening with SD-WAN, right?
Michael Wynston:
Sure. So prior to the pandemic, SD-WAN's primary focus was enabling the branch or a campus location, the ability to deliver applications and connectivity, in a way that made more sense than hairpinning everything back to the data center or leveraging just really, really expensive private line connectivity. You know, whether you were still using TDM connectivity, or Ethernet over MPLS or Ethernet, or something like that. What SD-WAN enabled us to do was to use multiple transports that made sense and direct the applications over those different transports in a way that was actually a consumable. So I mean everybody's tried to do policy-based routing at some point in their career, and then you forget you've done it. And then the night that it's broken, somebody goes to troubleshoot and says, I don't understand.
I look at the routing table and the traffic's supposed to take this interface, but it doesn't. It takes that interface. Why is it doing it? Oh, yes, I forgot. We turned off Policy-based routing for that destination address, which because of address summarization, you don't actually see on the routing table. So you think it should go that way. Anyway, what SD-WAN enabled us to do was apply more logic to the environment. Now, what that allowed us to do, in time is because we could apply more business logic to how the infrastructure was consumed. We could get away from consuming the most expensive transports for everything because our infrastructure wasn't capable of differentiating, when what should take what path. So now, because we've migrated to a combination of MPLS and broadband or DIA, depending upon the site we can easily make sure that traffic that is internet bound, goes out to the internet instead of hairpinning from the data center out to the internet, and then back into that particular branch location.
So, it’s a wonderful thing, but it's also very complex and, and deploying SD-WAN is not simple, especially on a large global level. But then the pandemic came and once the pandemic came, everybody went home and we had all of these offices that we put SD-WAN into and, you know, we tried to figure out, well, what do we do now? And what we do now is we look at how we can leverage those same lessons we learned around SD-WAN and developing our public cloud connectivity, developing our backbone connectivity. So what's interesting is I'm starting to see a number of vendors show up that talk about public cloud infrastructure and software defined network infrastructure in public clouds with a lot of the same features and functions that you see inside of your traditional SD-WAN environment. And one of the reasons they're able to do that is because SD-WAN being purely software defined, and because you can't ship an SD-WAN box to Amazon, they won't do anything with it.
You have to solve these problems through the software. So a lot of the SD-WAN companies were actually very well positioned to transition into a public cloud network infrastructure type scenario. That's one evolution I've seen. The other one is I've seen a lot of the SD-WAN vendors start to tackle the home users. So whether it's through the executive VPN small form factor devices or through a software based VPN that has SD-WAN like functionality to a traditional VPN would create a tunnel back to the data center. And again, everything would go out via the data center. But since everything we're doing today, even this GoToMeeting, it's using the internet. My SD-WAN, executive VPN inbox that I have at home can say, Oh, this is internet bound. I can tell based on policy, this is internet traffic, I can allow it to go directly out to the internet. I just send it directly out to the internet. So it doesn't go through my data center or edge networking path first.
So again, a lot of the things that were done for SD-WAN at the branch can be easily translated to public cloud and an individual home user.
Steve Cummins:
Absolutely. And there's that word adaptability again, right? It was set up for one thing and then with everything that's happened this year, we needed to adapt. So you’re obviously a significant way through the SD-WAN journey. What's the caveat that you would give to people or the one thing that they should keep an eye on if they're just starting to look at SD-WAN?
Michael Wynston:
So if you're just starting to look at SD-WAN, make sure that you start with the understanding that you need a minimum viable product and feature set, to deploy for your first SD-WAN deployment. And the reason I say that is because if you look at the list of features and functions and stuff that comes with SD-WAN, all of them now have integrated security, layer seven firewalls. They all have application-based routing. They all have the ability to do not just quality of service and quality of experience. They all have the ability to do multiple trials. So there are so many features and functions, and you can try to deliver all of them on day zero, you're going to end up delivering nothing, simply because it's just too much to consume.
And we use this same mindset with all of the new technology we put in place, make sure you identify a feature set that at least replicates what you have today, if you're trying to transform, or at least replicate the features you need today. And then, as you become more comfortable starting to layer on the newer features and newer functions that the SD-WAN environment provides. For example, analytics. Well, I can tell now which application at any one branch or across all the branches, is most heavily utilized where it's going to the top consumers and this information is available in real-time. It's great. But one of the things that we're now focused on, now that we have it out there is how do we actually consume it? We didn't think about that when we first rolled it out, because if we had made that part of our initial minimum viable product, we would never have finished applying. Because again, there are too many features in SD-WAN to build it all at once.
Steve Cummins:
Yep. That's solid advice. And again, many features means many shiny objects. So you’ve got to focus on what you really need.
Michael Wynston:
Yes.
Steve Cummins:
So clearly, you know a lot about network engineering. You've shared a lot of your knowledge here. You've been in the industry 30 years, you said. I would imagine over that time, there was one or two people that have been a mentor or inspiration to you. Anyone you'd like to give a shout out or a hat tip to here?
Michael Wynston:
So I give a hat tip to the very first director of network architecture that I worked for back at Merrill Lynch, Vincent Patrizio. He's the one who really demonstrated to me, with his very colorful personality, that you should make sure when you talk to the vendors, you tell them what you need, rather than letting them tell you what you want. And don't be afraid to look at a vendor and go, yeah, that's not something we would ever use. And I know you've convinced senior leadership it's really important, but there's no value here. So what... we actually need results. And, really, making the team focus on what was a business requirement rather than what was the newest, coolest, most exciting thing, and how that actually translated into financial business model, is something that I've carried through with me as I moved from one position to the next, is making sure whenever I talk to someone about any technology is keeping in mind at the end of the day, someone's paying for it.
And because someone's paying for it, you've got to make sure they can clearly identify why they're paying for it and what the value is for them.
Steve Cummins:
Yeah, that is very solid advice. I like that. So one final question for people that are always looking to find the latest trends and learn more about network engineering, Where are the places that you go to keep up with what's happening in the industry?
Michael Wynston:
So I am an avid reader of SDxCentral. For me, SDxCentral and the other networking podcasts are always very helpful. But to me that's a good place to start. And that's where I get a lot of my initial reads and initial ideas into what new technologies are hot and what vendors we should start looking at on those particular technologies.
Steve Cummins:
That's great. And, and actually, strangely, the guest on our first episode of this podcast was Roy Chua. He was one of the founders of SDxCentral. So he'll be delighted to hear you recommending his old channel. Well, this has been great, Michael, thank you very much for taking some time to share your thoughts and experiences with the audience. For anyone who's interested in finding out more, Michael is available on LinkedIn. He has a couple of videos on there of some presentations that he gave at recent WAN summits. So again, thanks very much, Michael, it's been a pleasure talking to you.
Michael Wynston:
Steve, this is fun as always, as you mentioned, anyone who's interested feel free to reach out to me on LinkedIn. Happy to talk about all the different technologies that are interesting, and look forward to speaking again sometime soon. Thank you.
Steve Cummins:
Great. Thank you.
Michael Wynston is the director of Global Network Architecture at Fiserv, having previously managed networks at a number of financial institutions. Today, we'll be talking about CCIE certifications, SD-WAN, and Network Function Virtualization. Michael, thanks for joining me on the Living on the Edge Podcast.
Michael Wynston:
Thank you Steve, for inviting me. I really appreciate the opportunity to speak to you and your audience today.
Steve Cummins:
Great. So let's start with the simple stuff. Can you just give us a quick rundown of what Fiserv does and how your IT organization is set up?
Michael Wynston:
Sure. Fiserv is the combination of a company that was called First Data. We merged with Fiserv a little over 18 months ago now. We are one of the world's largest financial services or FinTech companies. We're responsible for a number of different countries, continents, everything that you do that does not involve cash. So if you're shopping online and you're buying something with a credit card, or if you're financing a vehicle, or if you're using an online banking app for some of the largest banks and some of the smallest banks. Some part of that transaction, or in some cases the entire transaction passes through Fiserv's global infrastructure. So we're the big finance company behind the curtain of all of the banking and credit card and merchant companies.
Steve Cummins:
So a lot of what Fiserv does, we rely on every day, we just don't realize it?
Michael Wynston:
Yup. That's a good way to put it, right. So when you go to the store and you put your card into the chip reader and it says not authorized, and you say, I know my card is good. Why didn't that work? That's probably a failure somewhere inside of our infrastructure, which, yeah, it's funny. I go shopping with my wife and I actually count off in my head the number of seconds it takes for that authorization to come back because I know what our SLA is for our clients. So to me, that's something that's actually really important.
Steve Cummins:
I like that. Nice bit of professional pride you're showing there. So based on that, it's obviously mission critical for a lot of companies. Just give us an idea of how the IT organization is set up of Fiserv and what your role is within it?
Michael Wynston:
Sure. So, at Fiserv we truly embrace our global nature. My team has a global network architecture team has architects located in all of the different continents. We've got architects in APAC. I have architects in India, North America, South America. So we make sure that we collaborate on different technologies that we implement. So we create a unified homogenous environment, but we still take into account the specifics of a particular region. So things like GDPR or any type of privacy legislation, because a lot of that impacts us and how, and where we store our customer's information is something that we always think about. And driving our organization on a global scope, we try to always like the best of breed technology. One of the things that we really try to emphasize is no shiny object syndrome, I'm not buying something because the vendor said is what you need it.
Steve Cummins:
Yep. The shiny object syndrome. I think we all fall foul of that. It’s whether we're buying things personally or buying them for work, there's always the new thing that's coming along, right?
Michael Wynston:
Yeah. And within my team, we call each other out when we do it, because we all fall victim to it, you know, constantly just you always hear, Oh, this is the newest best thing. And it's a hundred times better than the other thing. So you need this now. Hell, yeah. Maybe you're right. So we always make sure to call each other out on that kind of stuff too.
Steve Cummins:
Yeah. That's good. It's funny I was having a conversation with a friend of mine yesterday about the new iPads and which one to buy and he said, "Well, you know what, if you wait until March, they'll probably upgrade them again. And it's like, yeah, but there's always the next thing. Right?
Michael Wynston:
(laughs). So, you know, what's really funny about that. I kept waiting for the next iPad pro because I wanted the newer processor. I know. I said, I'm always going to be waiting for the new iPad pro with the newest processor. So on black Friday, I went out and I bought myself an iPad pro with the previous processor generation from the iPad air. Because like you said, you'll never have the latest because they're always going to announce something better the day you buy it.
Steve Cummins:
That's it that's, that's how it goes. All right. So you've inspired me. I'm going to go make the purchase now. So at the beginning I mentioned here, you've worked for a number of companies. You know, people like Cisco, Pfizer, Merrill Lynch, you've kind of got a Who’s Who, and you've been in multiple roles, right. I know we've talked about, on a previous call, in some cases you've been a consultant you've been at value added reseller, you've been on a corporate team. So, just give me some thoughts on some of the skills that you’ve developed, that made it possible to switch between those roles. And if there was anything that you see that's sort of uniquely different between them?
Michael Wynston:
Sure. So I got my start actually in this industry, not directly in this industry about 30 years ago and because... yes, I'm that old…. in a lady's handbag warehouse actually in Long Island city in Queens, where the local IT team was never able to give me the information I needed when I needed it. And I annoyed them to the point where one day they just dropped a bunch of books on my desk about FoxPro and dBase and Novel and reading those, I thought, Oh, I like this a lot better than warehouse management. Funny enough, if anyone watches the show Young Sheldon and how he spent time in Radio Shack, showing people that operate those computers, I did that. I did that, and I showed people how to operate the trashy TV and the radio shack computer.
Michael Wynston:
Anyway, so as I started out, I found that the most important piece of being in this industry is to never stop learning. And part of that mindset of never stop learning is to not pigeonhole myself into just one particular, type of infrastructure. So it's not only about the network, it's not only about the compute, not only about security. You have to look at... now, I'd like to reference the OSI model. You have to really make sure you understand all the layers to really be a subject matter expert in any one of them. You have to understand your actions. So as I've gone through my career, I've tried to always make a point of understanding, not just a layer that I'm focused on, but the layers above and the layer below, so I understand what's actually needed and what the requirements are in driving that infrastructure.
Michael Wynston:
Now, when I first started out, I actually got my start early on in my career as an instructor, which I think is probably the best thing that could've happened to me, because it gave me the opportunity to stand up every week in front of 24 new people and try to explain to them something that they had no idea, or in some cases believed they knew far, much more than I did about something to teach them something. And for me personally, it helped me develop a skillset of enrolling people into what my vision was. Enrolling folks into learning new technology and enabled me to be able to speak to all of the different levels. So whenever I talk to junior engineers or someone who says, Oh, well, what technology do I need to learn next? Or now where should I focus my energy? One of the things that I always emphasize is, don't forget your interpersonal skills, because we can always hire an engineer to lock in a closet that we have configuring devices all day or writing code all day.
Michael Wynston:
The engineer, the architect, the developer, that's really hard to find is the person that you can put in front of a customer or a consumer or the end-user, the requirements team, and actually communicate with them in a way that they understand, so that you can really make sure to deliver what's needed. And a lot of that foundational information for me came from my certifications. So my CCIE number, 5449, I got it January 9th of 2000 when I had to I actually cable my own rack. I had to know IPX, AppleTalk, BACnet ISDN, OSPF, all of those fun legacy technologies. But I still up to this day, encourage all the engineers I work with to start out with the most basic networking certification.
And for me, I think the CCNA is really a great place to start, because whether your company adopts a fully Cisco strategy or not, I have not personally seen any other networking certification path that really embraces the full end to end routing, switching, telephony, wireless. And now with the, Cisco developer certification path, all of the different things from a skillset perspective you need in order to be successful in this industry. So while I don't think certifications prove you can do what you need to do, I do believe it's a great way to open a door and a great way to start out.
Steve Cummins:
Yeah, that's interesting. So, you know, there's obviously a lot of talk these days about Cisco certification and, maybe not being as relevant as it may have been in the past. And I know they've made a lot of changes to the programs. So from your perspective, it sounds as though you see it as a good foundation for somebody and then maybe there's other areas you'd encourage people to dive into once they have the CCIE?
Michael Wynston:
Yeah, absolutely. Because when I first started in this, Cisco made routers and switches and that was it. And then when, you know, acquisitions like Selsius that they bought for IP Telephony and Arrowpoint that they got for the load balancer technology, you know, as that started to grow, it was real divergence where you could really pick a particular area and become a subject matter expert. But I think starting off with just the foundation of basic routing and switching is a really good way to get your feet wet so you can get insight into the other different pieces that are part of the network infrastructure landscape we know today. And, you know, maybe you're looking at that and you go, wow, I really like the part about writing code.
And you go into being a NetDevOps developer, or you say, well, public cloud really feels like where it's at for me, while your CCNA certification, translates very easily into some of the basic AWS or Azure certifications in the networking space, because at the end of the, all we're doing is moving IP packets.
Steve Cummins:
Yeah. That definitely makes sense. And you made an interesting point a little earlier on about, it's not just the technical certifications, it's the personal skills as well. Any particular training or experience you think is valuable to that, or is that just sort of, you know, life skills?
Michael Wynston:
I think life skills are absolutely important. One of the other things I also encourage, , you know, these strange times that we're in now, this is more challenging, is to look at things like Toastmasters, not sure, you know, every one of your listeners are familiar with that, but there are a number of places where you can go, just community things and, other engineers stand together or even the user groups that are formed for the different technology sets, where you can put yourself out there and really do your best to try to enroll and explain and convey the different thoughts and ideas that you have about the infrastructure. So you can develop your speaking skills, your interpersonal skills, that again, for me at the end of the day, that really becomes a differentiator.
Steve Cummins:
I agree, there's this stereotype of the network engineer working away in a darkened room and not talking to anybody. But I think we all know in reality, being out in the world is as valuable as having the technical knowledge. So, that makes a lot of sense. Talking of being in the real world, the podcast is called Living on the Edge, partly because of the clever play on words, partly because every network engineer has a story about when everything went wrong and they get the call at 3:00 AM and they had to fix it. So anything from your experience, any interesting or funny story you could share?
Michael Wynston:
Yeah. So if I go all the way back to November of 2001, right after 9/11 happened, I was working at Merrill Lynch at the time and they had a project to build a data center in 30 days. And this project was actually, we worked out from Staten Island and we worked in the data center literally for 30 days straight. You know, we slept in there, they gave us cots, maybe it wasn't exactly 30 days, but certainly felt that way.
Steve Cummins:
Yeah.
Michael Wynston:
And the funny story around that is quite often, we would go out for an hour or two at night, because there was a restaurant around the corner where we would eat at. And quite often we would come back and find that everything we had done, some of the electrical engineers had moved stuff around they had done cable, they had re-cabled. And what I found out at the end of the day was every time we would leave, there was someone on the structural engineering side who wanted to be a network engineer, who believed that there were better ways to do things. And he went ahead and he told them to move stuff around after we left. And that was so frustrating. But what we were able to do is find that person and talk to them. And instead of having them, I guess you could say work against us, enroll them into delivering and configuring and making sure while we were gone, nobody broke anything that we had already built.
Michael Wynston:
And it was always, you know, at the last minute, right before we were supposed to turn up some new piece of that data center and turn it over to the client that nothing would work and we'd scratch our heads and not know why. And because we were actually sitting there in the data center with our coats on, because it was always cold, we would walk over to the equipment, and go “This is not how we cabled it before what happened here?” And, yeah, you know, strange things.
Steve Cummins:
So you're thinking there’s a gremlin in the works. And it's actually somebody who just desperately wanted to be a network engineer, and you can't blame him for that.
Michael Wynston:
Yeah. Somebody who wanted to be a network engineer who thought he could rebuild it himself
Steve Cummins:
Oh, that's funny. You know, at Opengear, we're all about this idea of network resilience. But as I talk to network engineers, there is obviously, that phrase means different things to different people. So I'm just curious from, from your perspective, what does network resilience mean to you?
Michael Wynston:
So to me, network resilience means adaptability. When we look at the different ways that we try to put network resilience into the infrastructure, whether it's via the HSRP or ECMP or building redundant routers, at the end of the day all of those different features and functions are really driven towards getting the infrastructure to be able to adapt to change. And if we look at it that way, it really opens up the idea that maybe the way we're doing resilience today is not the best possible path for delivering the resilience that we need. As long as we're willing to open our mind to the idea of adaptability. And for me personally, what that means is not doing something today, simply because that's the way you did it yesterday. And having that open mind and adaptability helps us build the constantly improving, constantly evolving infrastructure that serves our clients today.
Steve Cummins:
Yeah. This idea of adaptability I think is an interesting way to look at it. You know, some of the things I hear from people is this idea of well resilience used to be redundancy, right? Because it was in the data center. So you could afford to have an extra router and an extra server and, you know, a generator and, and spare air conditioning, all that good stuff. Things move to the edge and suddenly you can't do that. So you have to adapt, right. It can't be redundancy anymore. That all of these moves with the pandemic-
Michael Wynston:
Sure.
Steve Cummins:
... same thing. Right. What, what worked a year ago suddenly it's very different. So I think that's an interesting angle, the, the idea of just making sure you're adapting your solution as the environment changes.
Michael Wynston:
And, and, you know, to speak to that point to living on the edge. Right. We have a very, very forward thinking, very future designed NFV infrastructure that we use. And one of the first things that we said was, well, we have to put two routers in front of it, so it's redundant. And then we said, well, we should really virtualize those routers because everything's about, you know, network function virtualization. And then we said, well, if we virtualize the routers on the infrastructure, that's supposed to host the virtualized routers, how do we get to the infrastructure to actually build the virtual- cutting out very chicken and egg kind of thing. So know that kind of adaptability and, and being, you know, willing to look at the ideas that you might've had about how to create the reliability in the infrastructure. And I don't like redundancy because to me, quite often redundancy, wastes money, right? Cause you're building something only in case of fire, right.
In case of emergency, break glass. I would like to build infrastructure so that in case for emergency resiliency comes into play, because there are resources that are available that could be consumed to provide that resiliency and redundancy, rather than dedicating something to just sit and wait for something else to fail. And that's really what we're driving to, you know, from an adaptability standpoint.
Steve Cummins:
Yeah. It makes a lot of sense. So it's actually funny. Because we, we hadn't talked about this prior to the recording here. But you know, one of the things we're seeing with Opengear, and our focus is really out of band management where traditionally that's been installed as emergency access. And to your point, you're really only putting it there, for that one moment when you need it. We're seeing folks now are actually spending the money to implement it and then using it as an independent management plane every day. Right. So you're not spending that money just for the once “what if”, but it becomes part of your overall solution.
Michael Wynston:
Yeah. Yeah, absolutely. Well, and especially since we've moved past, you know, ribbon cables for, for console conductivity, so. (laughs)
Steve Cummins:
See, things change. You know, something I wanted to pick up on there. You mentioned network function virtualization. Could you just give some thoughts on how you think that's impacting the way IT infrastructure is being built?
Michael Wynston:
So as we've moved more towards a dis-aggregated footprint for network infrastructure, where network infrastructure exists in public cloud, it exists inside of your colo facilities, it exists inside of your traditional data centers, it exists inside of your client environment. Building purpose-built pieces of infrastructure routers, load balancers, firewalls, and doing a one size fits all kind of footprint, quite often leaves you with a lot of abandoned infrastructure. And what that also, in addition to your abandoned infrastructure, which wastes CapEx, which no one has CapEx to waste, it also creates an environment where you can't scale quickly in the event of a change in circumstance and coming back to adaptability. So for us, we really looked at network function virtualization, not because we wanted to get rid of all of the routers and firewalls and load balancers, but because we wanted to decouple the function that they provided from the actual hardware that you use, to provide that particular function.
So when we look at NFV it's so that we can go ahead and do things like dynamically scale, and add more load balancers, ADCs or firewalls, when the resources that we need to consume are not there immediately. We have applications and monitoring and performance analysis that helps us to create this infrastructure on a predictable basis. So it makes that all infrastructure dynamic. You can't do that with a router or a firewall that you hold in front of you, you order from a provider that takes, you know, somewhere between 30 and 90 days, just to ship, let alone the time to install and put in the change request. The other advantage to NFV for us is it allows us to constantly evolve the network functions that we use. So we like vendor X today because their firewall does something that the other vendor doesn't do. And then three or six months from now, that vendor that we were using has a competitor comes along, that does it better, faster, cheaper, also its software, swapping that piece out, that virtualized software piece is a lot simpler than swapping out a physical load balancer or a router or a firewall. So it makes the infrastructure a lot more adaptable based on the features and functions that you're trying to deliver.
Steve Cummins:
Right. It continues that move away from being locked into a particular ecosystem, right? You can pick and choose from whatever the... well, the, the danger is it's the shiny object of, well, Hey, we'll switch to this-
Michael Wynston:
Yeah.
Steve Cummins:
... this vendor, but it does give you a lot more flexibility.
Michael Wynston:
Yeah. It does give you a lot more flexibility. So one of the things I always like to emphasize about NFV is that, without collaboration with your compute partners, you can't do it. And the reason why I say you can't do it is because you really don't want to. So when we went into network function virtualization, I made sure that I was joined at the hip with my peer on the compute and virtualization side, because the last thing I want any of the network engineering teams to do is own patching, So ESX hypervisor, or own patching or maintaining the Linux KVM system that's providing the ability to run all those VNFs. I also didn't want to have to, although we did, get every engineer to understand what NUMA pinning means and, and how you allocate CPU sockets.
I wanted to be able to focus our energies on how we wanted to service chain all of the different VNFs in a logical fashion. And then work with our compute partners so that they could deliver the compute infrastructure we needed in order for us both to be successful. Again, it went with what's our strength in that area, and what's your strength in that area? And that's worth the other to build this solution in a more unified way, rather than just sitting inside of our silo and saying, well, we can't do it cause the compute guys, they don't understand networking. They shouldn't have to, and the same in the other direction.
Steve Cummins:
Right. And then you and your team can focus on the parts that make sense to you and rely on the others to bring their expertise into it.
Michael Wynston:
Yeah.
Steve Cummins:
So one other subject I want to bring up when we first met, you came up with a phrase that I don't think I've ever heard before, or may never hear again. You said to me, "I love SD-WAN." So, obviously a hot topic. And one of the things you mentioned to me is that with the pandemic, a lot is changing. So maybe you could just share your thoughts on what you see happening with SD-WAN, right?
Michael Wynston:
Sure. So prior to the pandemic, SD-WAN's primary focus was enabling the branch or a campus location, the ability to deliver applications and connectivity, in a way that made more sense than hairpinning everything back to the data center or leveraging just really, really expensive private line connectivity. You know, whether you were still using TDM connectivity, or Ethernet over MPLS or Ethernet, or something like that. What SD-WAN enabled us to do was to use multiple transports that made sense and direct the applications over those different transports in a way that was actually a consumable. So I mean everybody's tried to do policy-based routing at some point in their career, and then you forget you've done it. And then the night that it's broken, somebody goes to troubleshoot and says, I don't understand.
I look at the routing table and the traffic's supposed to take this interface, but it doesn't. It takes that interface. Why is it doing it? Oh, yes, I forgot. We turned off Policy-based routing for that destination address, which because of address summarization, you don't actually see on the routing table. So you think it should go that way. Anyway, what SD-WAN enabled us to do was apply more logic to the environment. Now, what that allowed us to do, in time is because we could apply more business logic to how the infrastructure was consumed. We could get away from consuming the most expensive transports for everything because our infrastructure wasn't capable of differentiating, when what should take what path. So now, because we've migrated to a combination of MPLS and broadband or DIA, depending upon the site we can easily make sure that traffic that is internet bound, goes out to the internet instead of hairpinning from the data center out to the internet, and then back into that particular branch location.
So, it’s a wonderful thing, but it's also very complex and, and deploying SD-WAN is not simple, especially on a large global level. But then the pandemic came and once the pandemic came, everybody went home and we had all of these offices that we put SD-WAN into and, you know, we tried to figure out, well, what do we do now? And what we do now is we look at how we can leverage those same lessons we learned around SD-WAN and developing our public cloud connectivity, developing our backbone connectivity. So what's interesting is I'm starting to see a number of vendors show up that talk about public cloud infrastructure and software defined network infrastructure in public clouds with a lot of the same features and functions that you see inside of your traditional SD-WAN environment. And one of the reasons they're able to do that is because SD-WAN being purely software defined, and because you can't ship an SD-WAN box to Amazon, they won't do anything with it.
You have to solve these problems through the software. So a lot of the SD-WAN companies were actually very well positioned to transition into a public cloud network infrastructure type scenario. That's one evolution I've seen. The other one is I've seen a lot of the SD-WAN vendors start to tackle the home users. So whether it's through the executive VPN small form factor devices or through a software based VPN that has SD-WAN like functionality to a traditional VPN would create a tunnel back to the data center. And again, everything would go out via the data center. But since everything we're doing today, even this GoToMeeting, it's using the internet. My SD-WAN, executive VPN inbox that I have at home can say, Oh, this is internet bound. I can tell based on policy, this is internet traffic, I can allow it to go directly out to the internet. I just send it directly out to the internet. So it doesn't go through my data center or edge networking path first.
So again, a lot of the things that were done for SD-WAN at the branch can be easily translated to public cloud and an individual home user.
Steve Cummins:
Absolutely. And there's that word adaptability again, right? It was set up for one thing and then with everything that's happened this year, we needed to adapt. So you’re obviously a significant way through the SD-WAN journey. What's the caveat that you would give to people or the one thing that they should keep an eye on if they're just starting to look at SD-WAN?
Michael Wynston:
So if you're just starting to look at SD-WAN, make sure that you start with the understanding that you need a minimum viable product and feature set, to deploy for your first SD-WAN deployment. And the reason I say that is because if you look at the list of features and functions and stuff that comes with SD-WAN, all of them now have integrated security, layer seven firewalls. They all have application-based routing. They all have the ability to do not just quality of service and quality of experience. They all have the ability to do multiple trials. So there are so many features and functions, and you can try to deliver all of them on day zero, you're going to end up delivering nothing, simply because it's just too much to consume.
And we use this same mindset with all of the new technology we put in place, make sure you identify a feature set that at least replicates what you have today, if you're trying to transform, or at least replicate the features you need today. And then, as you become more comfortable starting to layer on the newer features and newer functions that the SD-WAN environment provides. For example, analytics. Well, I can tell now which application at any one branch or across all the branches, is most heavily utilized where it's going to the top consumers and this information is available in real-time. It's great. But one of the things that we're now focused on, now that we have it out there is how do we actually consume it? We didn't think about that when we first rolled it out, because if we had made that part of our initial minimum viable product, we would never have finished applying. Because again, there are too many features in SD-WAN to build it all at once.
Steve Cummins:
Yep. That's solid advice. And again, many features means many shiny objects. So you’ve got to focus on what you really need.
Michael Wynston:
Yes.
Steve Cummins:
So clearly, you know a lot about network engineering. You've shared a lot of your knowledge here. You've been in the industry 30 years, you said. I would imagine over that time, there was one or two people that have been a mentor or inspiration to you. Anyone you'd like to give a shout out or a hat tip to here?
Michael Wynston:
So I give a hat tip to the very first director of network architecture that I worked for back at Merrill Lynch, Vincent Patrizio. He's the one who really demonstrated to me, with his very colorful personality, that you should make sure when you talk to the vendors, you tell them what you need, rather than letting them tell you what you want. And don't be afraid to look at a vendor and go, yeah, that's not something we would ever use. And I know you've convinced senior leadership it's really important, but there's no value here. So what... we actually need results. And, really, making the team focus on what was a business requirement rather than what was the newest, coolest, most exciting thing, and how that actually translated into financial business model, is something that I've carried through with me as I moved from one position to the next, is making sure whenever I talk to someone about any technology is keeping in mind at the end of the day, someone's paying for it.
And because someone's paying for it, you've got to make sure they can clearly identify why they're paying for it and what the value is for them.
Steve Cummins:
Yeah, that is very solid advice. I like that. So one final question for people that are always looking to find the latest trends and learn more about network engineering, Where are the places that you go to keep up with what's happening in the industry?
Michael Wynston:
So I am an avid reader of SDxCentral. For me, SDxCentral and the other networking podcasts are always very helpful. But to me that's a good place to start. And that's where I get a lot of my initial reads and initial ideas into what new technologies are hot and what vendors we should start looking at on those particular technologies.
Steve Cummins:
That's great. And, and actually, strangely, the guest on our first episode of this podcast was Roy Chua. He was one of the founders of SDxCentral. So he'll be delighted to hear you recommending his old channel. Well, this has been great, Michael, thank you very much for taking some time to share your thoughts and experiences with the audience. For anyone who's interested in finding out more, Michael is available on LinkedIn. He has a couple of videos on there of some presentations that he gave at recent WAN summits. So again, thanks very much, Michael, it's been a pleasure talking to you.
Michael Wynston:
Steve, this is fun as always, as you mentioned, anyone who's interested feel free to reach out to me on LinkedIn. Happy to talk about all the different technologies that are interesting, and look forward to speaking again sometime soon. Thank you.
Steve Cummins:
Great. Thank you.
