Vendor lock-in and how open source software has been changing the tech industry

Phil Gervasi: What's so bad about vendor lock- in. Now, those are some serious fighting words in the tech industry, but it's what we're talking about on today's episode of Telemetry Now. Rosalind Whitley, a director of product marketing at Kentik, but also a very experienced developer and sysadmin, joins me to talk about her opinions on Open Source software, vendor lock- in, and how technologies like cloud containers and now automation as well, have changed the landscape of what full stack vendor lock- in looks like. This is one of those episodes where we really get into our opinions and our experiences, and I really love that. I enjoy it very much, and I hope you do too. My name is Phil Gervasi, and this is Telemetry Now. Hey, Roz, thanks for joining today. I really appreciate you joining the podcast. I've gotten to work with you for a long time now, and actually pretty close on several projects. So I know a little bit about your background, but before we get started today, and talking about Open Source and vendor lock- in and that whole thing, can you give us a little bit about your background, how you got into tech actually, because I do love hearing that from my guests and from just friends in general, how they got into a particular field, but also your experience with Open Source before we get into the whole vendor lock- in discussion.

Rosalind Whitley: Yeah, absolutely. Thanks Phil, and by the way, thanks for having me on the show today. Let's see, how did I get into tech? It wasn't really accidental, but I would say, a lot of us have non- traditional or non- linear-

Phil Gervasi: Oh, sure.

Rosalind Whitley: ...raised into tech, and that's certainly me. So I started out when I was quite young, I was a bit of a UNIX nerd as a little one when personal computers were becoming popular, and I wanted one to watch videos and stuff at home. My father made me maintain my own computer and refuse to buy me a Windows license. So it was like, if you want to want to watch these videos, you're going to have to get it to work, which was actually hard at that time, because there wasn't a lot of support for... Anyway, blah blah. So it started out with that background, and then went on to do my regular school thing. I actually ended up getting a degree in English lit, so I wasn't doing anything tech other than side projects. And then I started with a series of low level jobs, first at a press, and then I was working actually as a receptionist at a veterinary hospital, incorporating tech into my job. So for the first job at the press, I taught myself HTML on CSS so that I could make their email marketing suck less. And then as the receptionist, I was like, "This practice management software is really old, it's really bad. I know you're going to change it. You can either hire me to implement a new system for you, and I'm really cheap, or you can spend a lot of money on that." And they actually took me up on that, and then I had software implementation on my resume and I spun that.

Phil Gervasi: There you go.

Rosalind Whitley: But anyway, I had a series of those lower level, I would say IT jobs. And then I decided that I wanted to stop asking people if they had plugged it in. I wanted to stop dealing with those types of calls. And so, I went back to school. I got a master's in information systems database and internet technologies. And while I was actually finishing up school, I got my first real tech job, which I was a sysadmin at the University of New Mexico, managing and on call forward learning management systems. And I wrote and maintained some backend code and a little bit of front end interfaces for some internal projects. And I was on call for our Blackboard Learn system. And I would say, in that job I learned what it was like working on Waterfall, working in an organization that really did things the Waterfall way, and did things a slow old school way. And I really chafed at that, and there were a lot of budget constraints in that job too, because it was New Mexico and we were really trying to keep jobs on- prem, and we were also, of course, our top priority was serving our students. And I felt that really passionately, but sometimes I would be like, if we were running this in the cloud, the students would have a way better experience, et cetera, et cetera. And that didn't always get a lot of traction. And so, when I moved to Portland, Oregon, where I live now, I switched up and got a job at Puppet. And so, that's how I got into Open Source professionally. I had always been a lover of Open Source, and used to that very curmudgeonly Open Source culture, that I think is still around, but is less of a thing now. And then I started working at Puppet, which was an Open Source infrastructure as code tool. And then let's see, after that I worked for a proprietary distribution of the Open Source tool, Spinnaker, which is a software deployment tool and developed at Netflix. So we had a proprietary disrupt, and actually I was director of Open Source there, and worked on trying to get people to contribute to Spinnaker. That was one of my KPIs and that was pretty hard, I got to say. I could tell you more about that if you want. And then I really switched gears and I started working at a platform as a service company, called Render. And that was my most recent job before Kentik. So it's been an interesting journey of looking at how people think about Open Source and how people think about their technology choices, from a lot of different angles. So I guess I have a lot of opinions about it.

Phil Gervasi: Yeah. Well, that's why you're here. And your title at one point was director of Open Source.

Rosalind Whitley: That's right.

Phil Gervasi: That is the pinnacle of Open Source curmudgeon, like you said. Yeah. You know what, and you're right, it is depending on the angle from which you analyze this question, what is vendor lock- in, is it good or bad? Because I know from the networking space it means one thing, from the infrastructure, when you're talking about data center infrastructure and servers and infrastructure as code and all that stuff, that's a different angle.

Rosalind Whitley: It is.

Phil Gervasi: But then there's also a business angle. I'm sure that you had to deal with the engineering side that had strong opinions about a particular matter, particular deployment, particular configurations on that. And then also from the business side, you had VP of whatever and C level who were like, " Yeah, okay, but let's look at the cost. Let's look at day two operations and all these other things." So there are a lot of different angles, and I think it's important to balance that out. But one thing I do want to say is that you and I have different backgrounds from a technical perspective, because I mean, me, I did start off as a CIS admin, simply because that's from going to help desk and then a CIS admin generalist stuff. But very quickly, after only a couple few years got into networking, very laser focused on networking. And in networking, unless you're in a web scale organization where you're building your own switches and you own router OS and all that kind of stuff, which some people do, some organizations do that, or all of your network gear is Cumulus, Linux or something, which is awesome. Generally speaking, you're married to a vendor, your deployment is mostly Cisco, with maybe some branch offices running this or that, or mostly Juniper, there's the anything but Cisco shop and that whole thing. That's my background, and in that, those conversations I've had over the years, were people that just loved Cisco or Juniper or Arista or whatever. Partly I think because there's an entire educational component. I took all the Cisco certifications. So of course you love it, because that's what you know and you're comfortable with and you're successful at. But then There's also those that really scoffed at that. It almost felt like there was no in between, there were people that were like anything but Cisco, I'm going to run my own distro's, and what can I buy? What kind of white box hardware can I buy and then put my own OS and that? That was a thing too. I also think it depends on the industry. I remember networking folks in the service provider space and the networking folks in the enterprise space, very different. Very different approach to Open Source. I feel like service providers were much more amenable to running, maybe not necessarily Open Source, let me correct myself. More amenable to running different vendors, other than the big two or three vendors. You know what I mean?

Rosalind Whitley: Well, and does that mean a mix of vendors, or does that more just mean, going out and trying to find a different vendor who isn't in the big two or the big three? Is there more heterogeneity in the service provider equipment arsenal?

Phil Gervasi: Well, I mean I never worked in the service provider space, but obviously it's so adjacent to what I did anyway, that working with service provider, working with those folks, I know that they were, again, more amenable to other vendors. And for certain requirements on the backend, in a provider backbone, there are certain performance requirements where you might look at a specific vendor, but not because you want that vendor. Whereas on the enterprise side, you need the performance, and so that's the box that provides that, and so that's what it is, you need this many line cards or whatever. Whereas on the enterprise side, and I'm sure this is true for providers as well, but I just never observed it. On the enterprise side I have observed, both as a consultant to enterprise and then working several times within the enterprise teams, you just have whatever relationships you've already developed over time with the local sales reps at Cisco or Juniper, whoever, or Arista. And so, everybody knows their kids' names and, "Oh, your kids are with my kids on the basketball team." And so you get these, well, I'm only going to buy from this salesperson, or you have this CIO that had a bad experience with a particular vendor some years ago, and now it's in their head like a religious belief that, " I will never use that vendor again." I remember having a boss that was against specifically the Cisco 2960X switch, which is a random, yeah, it's just a layer two closet switch. There's nothing going on there, very little going on. But he had a couple of RMAs he had to do for a project once when they first came out when we were switching over from the 2960G and whatever, and that was it. That was enough for him to say, those are bad switches, blanket statement, " I'll never use them again. I don't want to use that vendor again." And I'm like, " That's not really logical." If you look at the percentage of how many of those switches shipped from their production warehouses and all that, versus how many are actually failed devices, they're actually pretty reliable. I think your perception is skewed.

Rosalind Whitley: Yeah. So not data-

Phil Gervasi: But that's for the networking side, right?

Rosalind Whitley: Yeah. I mean, I would say, just a little side note there, I think we lied to ourselves that all business decisions are somewhat logical or should be logical. That's not true. Most people's decisions that they make all the time are emotional. So that person had some really bad feelings about those switches at one point in time, and they just didn't want to revisit that. I mean, that's the stuff that sticks with you. It's a little funny when you see the way that plays out though. I think that actually comes up a lot. In thinking about this conversation, I was thinking a lot about, well, because there's vendor lock- in and then there's technology lock- in. And I think they get conflated a lot. We can talk more about that.

Phil Gervasi: Can you define both of those for me then?

Rosalind Whitley: Yeah.

Phil Gervasi: So I understand exactly what you mean.

Rosalind Whitley: Absolutely. Absolutely. It's like, vendor lock- in is truly when essentially technology choice is completely tied to vendor choice. So if you have chosen a particular technology, and I think in the networking world, that's truly what you're talking about. If there's a particular switch, and this is where I maybe will reveal a bit of that I'm still a learner in the networking world, but isn't there such a thing as open standards? You can answer that question later. But I think, true vendor lock- in is when vendor choice and technology choice are completely tied. So if you're choosing a particular technology, you must rely on licensing and probably support from a specific vendor, and if you want to make a change to that, you have to make a complete change to the technology in order to change away from that vendor relationship.

Phil Gervasi: Right. Yeah.

Rosalind Whitley: Whereas technology choice, I'm perhaps more familiar with this, but I think people think about it as lock- in a lot. So technology choices is more like, people talk about for example, in the cloud people talk about how you choose, and this was the example I was going to give, people talk about how if you choose one cloud provider, then you end up you're married to that cloud provider over time. And the more that you build in that cloud, the more what we call gravity you have in that environment, and the more money and time and disruption, like business risk, more money and time it'll take and more business risk that you take on, to migrate away from that cloud. Now I would say there's an asterisk there, because it depends on which services you're using in the cloud. If you did a classic lift and shift and all of your workloads are running on VMs, and you're using what we call commodity cloud services, which are those very foundational infrastructure as a service pieces, where you're essentially renting storage, you're renting compute. At the foundational level, that should be much, much easier. You should have much more freedom to move from cloud to cloud, if that's the type of infrastructure you're running, versus you're using DynamoDB, you're using functions as a service, one of the proprietary functions as a service, or I mean there are a ton, you're using ElasticBeanstalk if you're in, I don't know, 2014 or something. But there are a lot of those higher level services that have now been built on top of the cloud. And the theory is, that's to lock you into those clouds. And I think that's true, but maybe that verges into vendor lock- in, because if AWS shuts off your account, they can shut off your services and there's no real way to migrate those easily. But I think there's a bit of a difference there. And so this is where... But I'm curious about what that's like. And yeah, what does it look like if you need to... It seems like since it's capital expenditure that we're talking about in the networking equipment world, it seems like once you've bought it, you use it until end of life, pretty much no matter what. So that's different. You're not thinking about migrating necessarily. And when I talk to customers about this, they're not talking about, " Oh, we're migrating from Arista to Juniper" or something, but they're like, " Now we're buying more of this." So then, what does that look like when you're buying heterogeneous equipment? What does that transition look like? Does it all just work together?

Phil Gervasi: inaudible expensive, first of all, because if you're talking about an entire rip and replace. And it's also dependent on the type of budget that you have. So if you have the minimal network operations budget, but you get that$ 5 million grant or that big refresh budget every 10 years, five years, whatever it happens to be. I'm thinking about government. I did a lot of New York state government, counties, a lot of universities, part of the SUNY, State University of New York, big school districts. A big school district where I'm from might have 18,000 students, just northern New York City, and their budget for the entire district might be$ 700 million. So when they have a refresh, as much as it's just quote, unquote, a school district, it's an$ 11 million project. Do you know what I mean?

Rosalind Whitley: Right.

Phil Gervasi: And so, you go in there as a reseller, and you're going to make margin on the gear that you sell. And so, though you're an engineer, you're making margin on gear just as much as you are on professional services. So yeah, you want to capture as much of that as you can. And if you're looking at the day two operations, you're also looking at the OpEx, like you mentioned. So Cisco has been really great over the past few decades of developing an educational framework through which people have learned networking. That's how I did it. And you're embedded in it, and that's awesome. I don't knock it whatsoever, because it's how I built my career. But one of the side effects is that I am much, much more comfortable on a Cisco CLI than I am on other CLIs. Not as much today at this point in my career, but for many years that was the case. I would very much shy away from other projects. I wouldn't shy away from them, I just struggle with them more, I should say, because assigned to projects. And so, therein lies the problem for a lot of enterprise. Now, from a technology perspective, let's say you implement an entire campus network at your university with locations all over the city, major campuses, you have three data centers and you're running EIGRP, is a very simple example. EIGRP is Cisco proprietary, you're not running that on other gear. And therefore, if you want to switch vendors, you need to do a major overhaul of your network architecture. And that's just a simple example. If you're using BFD as timers for your network, or anything else that's related to specifically Cisco, there's an architecture choice there, and then you start to apply that to other vendors. You don't quite see it as much, but that being said, you have to sell that operations to your customer as well. You're not just selling the$ 11 million of gear, but now you're saying you don't have any staff that can manage this, but if we go with Cisco, you do. So that's all there. I look at vendor lock- in as being locked into a particular vendor, which usually translates to a particular technology. But I have to admit though, I don't necessarily think it's all bad, I think that the industry, our tech industry, has this sense of that's evil, that's bad, I want to get away from this vendor- agnostic. I get it, that sounds good, but there's a whole slew of problems with a vendor- agnostic environment, where now you don't have consistent features across an entire end to end, or maybe you're calling up five different TACs. So you're calling JTAC and Cisco TAC, and I don't know what Arista calls their TAC. Maybe there's certain interoperability issues. You don't see that quite as much today, but maybe there are certain interoperability issues with one line card, and then bugs. I have bugs in all my Juniper gear, but not my Cisco gear. Now you're just trying to troubleshoot that. Security patching, you can't do it as easily., because you have to look at it as vendor by vendor. All of these issues in a vendor- agnostic environment. But I do get it, you have more control. So one of the things that I like to say to folks that argue with me about vendor lock- in and how they're so against it, I'm like, listen, I'm sitting here and you're sitting there, I got a MacBook, an iPhone, an iPad over here, maybe an Apple Watch, and you're doing fine, you've bought into the ecosystem for a reason. There are certain benefits. And so, when you're all Cisco, all Juniper, there are certain benefits, you get massive discounts from a business perspective, you are calling TAC, and that's it, Cisco TAC, possibly if your organization is big enough, you get special TAC where you get a special bat phone, bat line, whatever they're called, Batman's direct line. And I'm sure that's the same with other vendors as well. So I just don't see vendor lock- in as much of a negative as some technologists claim it to be. Does that make sense?

Rosalind Whitley: I mean, okay. Well, first of all, to your point about the iPhone, and maybe this is just because I'm always going to be an Open Source nerd. I bought an iPhone a few years ago. At this point it must've been, I don't know, five years ago or something. And now I'm in their web, and before that, I always had an Android phone and I loved certain things about that and I love certain things about the customization that I could do with that. But now I have this iPhone, and I feel like I'm stuck. I do have a couple of Mac Books, mostly from my employers. So I guess it's nice with that. But then they also want me to buy their, I've got to buy some software subscription to keep track of my data across devices. I really don't like that. And now actually my partner has an Android phone now, and I've been experiencing a lot of jealousy. And it's true, there's gravity, because in order to switch over, I will have to figure out how to migrate all of my data that I still care about next time I upgrade to a new phone. So there's that. But also, I think on the enterprise side, there's risk. The big risk with vendor lock- in specifically, to me, seems like you are relying on one vendor for innovation. And maybe this is where, again, you can tell me from a networking perspective this is different, but is there not a level of innovation that you're missing out on when you're tying your horse to one wagon, and does that matter in the networking world? Does that even matter from a security perspective? If you're relying on one vendor to do all of the security legwork for you, and you have essentially all of your eggs in one basket, doesn't that mean that if someone figures out what the vulnerabilities are in that vendor's implementation of the hardware, in their software, then you are left holding the bag for... I don't know. And that's why-

Phil Gervasi: It sure does.

Rosalind Whitley: Huh?

Phil Gervasi: That's totally true. That's totally true.

Rosalind Whitley: And that's why RFPs are really important, that's why analysts exist, because they're supposed to tell us who's trustworthy. We look at customer references too, but I mean to a point, do any of us really know if what we're using is totally secure? Do any of us really know what the vulnerabilities are? I think hindsight is 20/ 20 there, but maybe the innovation thing doesn't matter as much, because maybe in the networking world things move more slowly.

Phil Gervasi: Yeah, they do, especially because the idea of networking is that you touch anything, you wiggle any wire, you're directly impacting the business in the sense of application delivery and service delivery. So the key for most network people, in my opinion, based on my experience is stability, reliability-

Rosalind Whitley: Static.

Phil Gervasi: ...predictability.

Rosalind Whitley: Yeah.

Phil Gervasi: Innovation happens, sure, but how many network engineers running the network at a university, even very high level multiple CCIEs, JNCIEs are coming up with new networking concepts. I mean, they're maintaining the network. Maybe they're designing architecture. I'm not saying that, that's not a heavy lift and very interesting and intellectually stimulating and difficult work, but they're not necessarily innovating in the sense that they're coming up with new protocols and new things like that.

Rosalind Whitley: And there would be theory if they did, I guess.

Phil Gervasi: What's that?

Rosalind Whitley: That would be scary if they were doing that.

Phil Gervasi: Yeah. And I do believe in the concept of being an engineer though. I like to look at the technology landscape that's before me and say, " How do I solve this particular problem?" I don't immediately say, " Well, we need to buy a new box that'll do this." Well, that's not necessarily going to fix... I got this bandwidth issue over here and this choke point and blah blah blah. Okay, well, let's just buy a bigger box and call up our sales rep and buy a bigger box with bigger bandwidth. Well, hold on a second. Let's analyze the traffic. Are we doing this inefficiently? What's going on? So I do believe in being an engineer, and I also agree with your point about the whole security concept, because if you are completely in bed with one vendor, and then there is a vulnerability that comes out, which happens from time to time, yeah, you're vulnerable across your entire organization. So how do you mitigate that? How do you decrease your blast radius from a security perspective or from a functionality perspective? Which for me, I've always looked at it as this concept of having different degrees of vendor lock- in. It's not that everything I own is Cisco or Juniper, or I only own one device from each vendor, so I can have as much variety as possible. I don't really look at it at two extremes. Those are the two walls, right?

Rosalind Whitley: Yeah.

Phil Gervasi: And then I find that there's a good place to be in the middle. Does that make sense?

Rosalind Whitley: Yeah.

Phil Gervasi: Yeah. So let's say my perimeter firewalls are all Palo Alto. And my inline IDS IPS, I find that I'm getting better performance with a different vendor, or whatever. Let's say I offload certain things to some CASB for my branch offices, yet a third vendor. All my switching is Cisco, because I'm comfortable with them for whatever reason. So all my IDF MDF switching is Cisco, my cores are Cisco, and then my SD-WAN is Silver Peak. I'm connecting with Silver Peak. So I have these layers or blocks of networking, and within the realm I might go with a vendor. I don't have an interop problem or feature problem, but then when I go outside of that, I'm just moving packets, like you said. I think you mentioned it earlier, isn't this stuff industry standard? So I'm just moving packets, and then I'm not relying on features at that point. That's how I look at it as far as the degrees of vendor lock- in. You know what I mean?

Rosalind Whitley: Yeah, I mean I think that's a really smart way to look at it, is to divide up. And it sounds like what you're talking about is being strategic. You mentioned you're actually looking at, and that's engineering too, looking at I'm getting better performance out of this, or I have this particular gotcha with these types of devices, and I'm going to steer clear of that. And you did make me back to as a salesperson, someone's saying, " Oh, I'm having this weird problem with this box." It's very easy as a salesperson to come in there and be like, " Well, you just need this latest thing." So I think that goes back to my question earlier is, how do you know when it's time to replace part of your fleet, even if you are doing that vendor, I guess what you're talking about, which is dividing parts of your architecture among different vendors. There's got to be a point where you know that it's time to throw a bigger box at the situation. And I think, understanding that can be hard. And I guess, that depends on the use case though. If you're doing high frequency trading or something, that's different than managing email, managing a school district, which a lot of the workloads are going to be office software and email and remote learning these days.

Phil Gervasi: Yeah. And I get it, it's different when you start talking about, there are differences in how open one can be, and how vendor lock- in plays into the equation when you talk about networking, compute, storage, cloud, those are different realms of technology. So I get that there are differences. For example, it would be hard- pressed to go to, let's say a mid- size school district. I would be hard- pressed to find the IT staff be comfortable with managing eight different vendors. So an SPN from one vendor, switching from another vendor. They do it, because the budget is the budget and it's your job, so you do it. And so, there is that benefit of having everything from one vendor, and so you can get the help that you need, because you're not necessarily going to talk about having a staff of, again, the highest level engineers, as an example, at a small, mid- size organization, which always boggles my mind how some of the networking vendors consider small and medium- sized organizations. I remember doing projects and whatever. I'm doing projects, I'm with VARs and I'm working on my Cisco certifications. And you read in the textbook, they'll say something like, " A small organization with 10,000 users" and I'm like, " What? On what planet?" So the perspective is a little different, but who can afford three CCIEs, a JNCIE, these Linux gurus, and they cost hundreds of thousands of dollars each. You're not going to necessarily see that at a small organization.

Rosalind Whitley: Yeah, that came to mind. I think talent and staffing costs is a huge part of this conversation that sometimes gets talked about and sometimes doesn't. And I don't know if this is controversial, but maybe... Well, okay, I'll go back, and I think when I was talking about the emotional based decisions before, I always think about this project that I did pretty recently while I was at Render, interviewing a lot of different startup founders or CTOs of different startups, people who are in our ICP, our ideal customer that we were going for. And we would ask them, because what we were trying to figure out, how to sell more Render. Which if you're not familiar with Render, it's similar to Heroku, but it's a cloud native and built for the container sphere. And we would ask people, why did you choose, how did you start using? A lot of them are using AWS or maybe they've got their workloads mostly on Google Cloud, or maybe they are using Digital Ocean or Heroku. And we would ask them, why did you choose that? And this came to mind when you were talking about evaluating which vendor to go with for a particular type of networking equipment. And I expected them to say, " Oh, well, we looked..." at least say, " We priced out what this would be as we scaled and what this would be, and we decided that this would be better or we wanted the features, we really liked this high availability database available from this provider and we wanted to go with that. And then it made sense to have everything in that same network." People almost never said that. They would say, and maybe this is just startup world, but they would say, " Well, one night we were working on building this, and my buddy was really comfortable with using this particular service in AWS, or they had used Google Cloud before at their last job, and that was what they were most familiar with most recently, and we built it in that." And they would say, and it would be like, " Well, what would it take for you to switch?" And same with Heroku. People would've started running something on Heroku, and even though Heroku support has gotten pretty bad after the company was acquired by Salesforce, it was really hard for them to switch. On the one hand, I think staffing is a huge part of it. And I don't know if this is where DevOps engineers, infrastructure engineers are a bit different, like is it easier to ask a network engineer to switch to learn something new or use a different vendor or a different framework than what they're used to? Is that easier than asking a DevOps or infrastructure engineer? Because one of the other things I know, infrastructure engineers are very scarce. I don't know how scarce network engineers are. I think they are, but maybe they're less scarce. And what it also seemed like is like, " Well, this is what our CTO is really comfortable with, and we don't really want to poke him too hard. We don't really want to take our engineers out of their comfort zone." And we find this at really big companies too, that happens with acquisitions, mergers and acquisitions. A huge company will buy a company, it becomes a subsidiary, and they have a choice. They could make the engineers running the workload, migrate or use their standards that they already had, or they can let them continue doing business as usual. Part of the reason that they oftentimes don't force standardization on newly joined engineering teams, is that if it's a moneymaking workload, they want to keep it in place. But even when that's not the case, even when those engineers are building new applications, I found that they are often it's like, " Well, we wanted to let them use what they wanted to use, because we didn't want their productivity to go down." And it's also, I think the subtext there is, " We didn't want to make them mad, because we didn't want them to quit, because it's hard to hire these people." So I think, that's where people's feelings about different frameworks and different tools, and also their comfort level and what they know, is really important. I mean, staffing is the most expensive part of all of this. Paying engineers is way more expensive than paying your cloud provider. And I don't know if it's more expensive than paying Cisco for all your equipment. Maybe it is, maybe it isn't. Is that-

Phil Gervasi: Well, I mean the thing is that a lot of these vendors make it easy for you to stay with them, or they incentivize the crap out of it. So for example, oh, you have all, I'll stick with Cisco, but you have all Cisco gear, and it's time for your refresh. You're starting that email chain with your AM, or whatever they're called, the salesperson. And they're like, " Oh, great, we have a buyback program, we'll get rid of that. We'll recycle it for you. We'll purchase that, and we'll give you this much off of whatever the price is, the list price on all your gear", and all of a sudden it becomes very attractive to just always stay with the vendor as a result, as opposed to switching vendors. But that's the thing, it's almost like going from one vendor lock- in to another vendor lock- in.

Rosalind Whitley: Right.

Rosalind Whitley: You know what I mean?

Phil Gervasi: Yeah.

Phil Gervasi: So it's like, "Oh, I'm going to get away from vendor lock- in, so I'm going to get rid of all my Cisco and go to all Juniper." It's like, " Well, wait, hold on a second, you didn't absolve the problem, you just changed from one vendor to another." So for me, this idea of vendor lock- in, is getting away from relying on a vendor for all of it in the first place. And again, it's harder to do on the network side than a lot of what you're experiencing and what you've been talking about, except for maybe cloud. Because once you start to build out your entire application delivery service and workloads in AWS, which by the way, they have 75% of the market share, it is what it is, you're stuck there. And the idea where people are in seven different clouds and on- prem, I mean, I don't see that quite as much. I think the reality is, I got to keep the lights on. I can't keep always try to win these religious arguments and wiggle wires to make things a little bit more efficient, or to take advantage of this feature over here that we don't really need, because everything is working fine now. Try convincing your VP or whatever of that, and then get the budget to do it. It's very, very difficult. But that begs the question, is vendor lock- in really that bad? Is it just a negative connotation we've attached? I mean, lock- in sounds ugly. Should we call it something like vendor dedication? No, that's dumb. Vendor loyalty, I don't know.

Rosalind Whitley: You just want to reframe it so that people... See, you want to reframe it so people will feel better about it. Right now people-

Phil Gervasi: I have a degree in English lit as well, that's what I went to college for. I taught high school English for five years. So I believe other people have disagreed with me over the years in our space, in our tech industry. I believe that words are extremely powerful, extremely powerful. The connotation is so different than a denotation in circumstances, that you can cast a completely different tone and feel and emotion based on just your diction, which words you use to convey the same exact thing that you could do very differently. And so, isn't that what we do in marketing and all?

Rosalind Whitley: That's what I was going to say, that's how I ended up in product marketing. I like to talk about the tech, I like to think about why people are using it and what they care about and what are the drivers that make people succeed or fail with it. But it's really about how you talk. I mean, one of the things I'm doing this week, is thinking up tags for our booths at different events. And do you know how hard that is to think, how do I say exactly what I want to say in five words that people are going to understand? They're not going to misunderstand, it's going to stand out. I mean, it's really, really hard. It's one of those things that doesn't look like work, but it is work.

Phil Gervasi: It is so much more difficult to say something briefly, concisely and still accurately, correctly to convey that meaning, than it is to write it like a treatise for page after page after page where you're just going on and on. It's much more difficult to be concise and retain clarity, accuracy and retain the message that you're trying to convey, which maybe that's the problem. We use the term vendor lock- in, and we've absorbed that into the industry as a negative thing, and therefore there's just this subtext, this presupposition that having one vendor is bad, but is it? Do we need to go deeper? And that's my argument, is that I don't think it's that bad. I really think that you have to analyze it like an engineer and say, all right, all my switching gear is from this one vendor, all my front end is going to be in AWS, all my backend is going to be in Azure. And what you do is, you mitigate that, the blast radius first of all, from a security or a failure, your failure domain is shrunk. So now if my front end goes down, it's not my entire infrastructure. If I'm doing a lift and shift or if I'm doing a rip and replace on the network side, I am just doing it on just my switching. And you can do that in pieces, closet by closet, or just my firewalls or something like that. And so, it keeps things more manageable. It also reduces, like you said, the expectation of staff to know everything that exists. I do believe that there are engineers out there, for sure, network engineers in particular, that are willing to learn the next thing, because that's who they are. But that is to say, oh yeah, all network engineers are like that. I obviously can't say that. There's all sorts. There's network admins that just, they're punching the clock, and then there's network engineers that can't stop learning. And again, there are folks that are just grounded in the fundamentals more than they are in a particular vendor CLI.

Rosalind Whitley: Yeah. I mean, so again, on the software side, I think there's this wisdom that's floated around. I mean, it's been a while, but I'm trying to remember what the name of the guy who did this original talk, but it's Choose Boring Technology. His argument is predisposed on the fact that we are all engineers. Most of us like to tinker. I am an ideas person. I like to imagine the way that something could be architected the way that a new platform or new service could change or improve the way that something works. I love thinking about that, and there are a lot of engineers also who love building, and it's fun to build stuff, and it's hard, but you feel really good when you get it to work and all of that. I mean, I think we all have these, we like doing that. That's why we came into this field. And when you take those skills to a company, that can be good and that can be bad, because you actually don't always want to be using the newest, most exciting thing that you want to play with. A lot of times, that's not actually your job. Your job is to, as you said, keep the lights on with what you got, or your job is to choose the most reliable, most known pieces of technology that you can put together. Every technology has its downsides. There are things that really suck about every piece of technology, even stuff that we think is really cool and exciting. So I think there's this wisdom that you have to suppress that desire to always re- architect things or always explore the newest things, and sometimes you have to use the boring stuff that maybe is not your favorite. I don't know, when it comes to vendor lock- in is really that bad, I mean I think what you're pointing to is that it also depends on what area of technology we're talking about. In networking, it's different, and database stuff comes to mind for me there too. When I was a CIS admin at UNM, we used Oracle, had Oracle licensed for Blackboard Learn and other apps. And so, I ended up learning a lot about specifically Oracle Database 12c, and what were some of the things that I needed to pay attention to with that. And I mean, that was a very locked- in situation, that's not Postgres.

Phil Gervasi: But did that have negative effects on your ability to deliver the services and applications, did it have a negative impact? You know what I mean?

Rosalind Whitley: Yeah. I mean, I think, yes, a bit. I think that there were times when there would be this one problem. I would get a page in the middle of the night and I would be like, " Oh, there's a 90% chance that it's this one problem that I've seen before." And because it's on the database side, there's nothing that when this connection gets reset, and this is also partly because the application I was using was not something that I had architected, for this particular Blackboard Learn, this particular application was not something that I could really rewrite the code on. So there was this one thing that when we upgraded to 12c, when a particular connection would reset, it would crash the application. And there was nothing that we could do about that. Maybe, yeah, but I think what's interesting about it, is that if you look at what's happened in database technologies in the last decade or decade plus, I mean there's been a lot of interesting innovation. I mean, there's a lot of interesting stuff that's happened, from Hadoop that ages me, no SQL stuff. Now we have, I think the way that we think about rows and columns has both stayed the same and changed a lot over the last 10 years. But I think what's interesting is that companies like ClickHouse and Snowflake are super successful now. I don't know about ClickHouse, but I know Snowflake, all their data's in a proprietary format, that's a completely proprietary solution. So I think, the tolerance for vendor lock- in or even technology lock- in varies in different areas. So I think when it comes to data, but Hadoop was really exciting once upon a time, that was 2009 to 2013 about. People were really excited about this Open Source solution that had been developed at Google. And I mean, around that time, people were also just really excited about data lakes. Like, " Oh, I can put this unstructured data into a data lake, and then I can do anything with it. And I don't have to figure out how to translate what's in my Oracle database to this other place, this other type of application that I want to use that same data." And I mean, that was an annoying problem. But the thing is, no matter how you slice it, your staff either has to be really good at doing one thing, that they have limited ability to change how it works, and so they're locked- in in that way, or your staff has to understand how to use a bunch of different kinds of things, which is never going to be perfect, and there're going to be problems. I think there's problems on either side, I guess, is what I'm thinking.

Phil Gervasi: Yeah. Oh, there totally are, because if you're looking at, hey, here are the constraints that I'm locking myself into, because I'm purchasing this vendor. And so, here are the constraints that are inevitable, because that's the vendor, these are the things that, these are the limitations, that's the framework. But then you look at that and you say, is the trade- off worth it, because here are the benefits. Well, let's weigh that out, so you make a decision as an engineer, maybe the answer is, " Yeah, those limitations, I can live with them, because my goodness, look at all the benefits that I get." Or maybe the answer is no. It's like, " Geez Louise, the benefits are nice, but I am really limited in what I can do here, and I don't know if that's going to be good for the future." I mean, just as an example, I did consulting for a very large organization, as in hundreds of thousands of employees global. And I'll leave the name off, because they have multiple BUs, some of them being nuclear energy and things like that. And so, they had a relationship with one of the biggest networking vendors in the world. That was the standard. They only bought from them, everything. And the reason was not necessarily because they loved the vendor, but because at that level of purchasing power, they were able to work with the vendor to scrub the code, to scrub the operating system code of all the different network devices, and to have a special pathway at that level with the networking vendor, so they could ensure the benefits, that's right, that's weighing this out, they could ensure a certain level of security robustness and features and whatever. So if they needed something, they can get literally their own code versions to accommodate. Now, that is an exceptional example though. I mean, that's not what most people are going to be weighing. So in that sense, they don't have vendor lock- in, we just told the vendor what we want. So theoretically they don't have vendor lock- in, they have just the purchasing power to do anything they want. And other organizations that operate at that scale, instead of working with a network vendor to do that, have chosen to just build their own OSs and write their own rich code or their own... Google did this with containerization. Look at Kubernetes and what we have now with that. But that makes me wonder, what is your opinion about how things have gone, you mentioned 10 plus years, let's shrink that down to the past few years with the cloud is ubiquitous, containerization is pretty ubiquitous now as well. And this concept of Open Source is different than in 2005. It's much more prolific and common today. So do you think that the Open Source community, and just in general technology has changed to embrace more of this vendor- agnostic concept in the past few years?

Rosalind Whitley: That's a good question. I actually think the Open Source community itself has always been really against the idea of vendor lock- in, almost as a libertarian ideal. And so, that hasn't changed, but I think honestly, a lot of those people who were part of the early, well, proliferation of Unix into different operating systems and also into the mainstream participation in the economy, I think that a lot of those people who were involved in that, there's a new generation of people who doesn't connect with that as much. And I think that, that has changed. But I also think that the way that companies have thought about, because this capitalism, so the way that companies have thought about making money off of Open Source, there's been a lot of trial and error along the way. You've got Red Hat Enterprise Linux, that was the original dream. And I think that not that many companies have been able to replicate that as a revenue model. And as you're talking about just in the last five years, well, I think about from my personal experience, I worked at Puppet, and at a certain point, Puppet was used in more than 90% of the Fortune 500, that's Open Source puppet.

Phil Gervasi: Sure.

Rosalind Whitley: Puppet really changed ops, and they really weren't the first infrastructure as code company, but they really popularized infrastructure as code and made it what it became. And they were never able to monetize. They were never really able to successfully monetize it. And they were acquired last year by Perforce, and the original participants in that didn't make much money off of it. And even despite what you might consider a huge success, they changed the world. They changed the world of a large scale computing operations, but that wasn't enough, or it wasn't modeled correctly for them to make money off of it. And Docker is another great example of that. And this is less than five years ago, the rise and fall of Docker. So Docker, again, containerization is a very old idea, and Docker didn't start it certainly, but they had a great UX, and they had great integration with other technologies, and they also had really good marketing and it really caught fire and everybody started using it. We still use it, I still use it. And they were never able to monetize it. And it's sad when you think about the ingenuity. We talked about innovation earlier. When you think about the innovation that went into that and how it really did make these big shifts, but monetizing it is tricky. And when I worked at Puppet, I remember they were saying, we were working on releasing a new product and we were talking about, well, should we make this open core or closed core? And I think a lot of folks have moved to the place where they want to have a proprietary closed core. And then on top of that, I think that the dream now for these, not for a big company like AWS or Google, AWS and Google, and particularly Google, it is in their best interest to invest in an open... They'll hire a whole team of engineers to work on an Open Source product. And that's what happened with Kubernetes. Kubernetes is not like some people holding hands, working together for free on a piece of software in their spare time. That is not what it is. It was a bunch of huge companies, realizing that they had a unique shared interest in this Open Source project, and that they could make it something special together and that they could share resources essentially through this. And so, I think that for those smaller companies who maybe don't have that same ability or impetus to invest in an Open Source product like that, where they have a whole team of people just working on this stuff that maybe doesn't directly benefit the company's bottom line, a closed core model is really popular. And so, they'll do a marketplace where people can create their... And Puppet tried to do this a bit, but they'll have a marketplace where people can build their own modules or things on top of the closed core, and that gives it an Open Source vibe where people are contributing, and you're getting the benefit of diverse expertise. But the company itself, their investment is protected. And there's been some other interesting, so MongoDB. There's some different licensing stuff that's gone on. What's that license called where it's SA, it's the licensing where another company can use your... It's written into the license that if another company is going to use your solution to monetize a product, then they have to release a version of that into Open Source. So it's preventing really the cloud providers, I think primarily, from eating the lunch of these smaller startups that have poured a lot of money into this Open Source project, and then AWS is able to throw a ton of money at marketing the product and making it more usable. So it I guess, detracts or makes it less attractive for companies to do that innovation. So I think there've been some interesting things, but I think how we monetize Open Source, is still a bit of an open question, because economic factors are always at play with how companies succeed. There are always a lot of factors, I don't think there's a model that definitely works. And I think that, that impacts enterprises as they make these decisions. I think enterprise decision makers want to go to a meeting and say, " Vendor lock- in is bad, let's do something else." I think that you're right, we have a negative association with that and people want Open Source, but which products to use and which products to make a bet on, is still a difficult decision. And in the end, it's those highly paid engineers who are really making it happen and hooking all the LEGOs together, and they'll need to sometimes knock those LEGOs down and hook them together again. And that's really expensive, and that hasn't changed.

Phil Gervasi: Yeah. One of the things that I'm teasing out from what you said is that things in the past five years, 10 years, more, it's just progressive and iterative, so I can't really say the last five years, but especially in the last few years, application delivery, I'm going to use that term very broadly. So that means the backend workloads, the networks, cloud, SaaS, containers, all the advancements going on in networking, data center networking, wireless technology, everything, all the way down to the endpoint, all that stuff is basically getting a human being to their data, usually delivered as an application, has become so complex and big. Think about the system. If I were to say, how do I get this? Think about all the components involved with storing the data, creating the data, making it accessible to you, getting you to it, securing it. There are so many components across the tech stack, that it's got so complex that interoperability and multi- vendor is the default. And so, if we want to manage this system efficiently, effectively, successfully, we have to be managing these multi- vendor environments. But that's multi- vendor among technologies, not necessarily within networking and within the cloud, it's the connection of them. Nevertheless, I feel like, okay, I want to automate that, because it's so complex, we have to move the operations needle forward and make this easier, so let's automate it. So infrastructure is code, network automation, Puppet, Chef, Ansible. I can drop into a Python prompt in my Nexus switches now. You can do all that now, because I believe that the complexity that we are now seeing in, again, service application delivery, has forced vendors' hands into making this a little bit, like I just mentioned, you can drop into a Python prompt in Nexus. You have Cisco DevNet, you have Juniper and Arista being very open to being able to use your own tools to manage infrastructure and to manage connectivity between your Silver Peak SD-WAN, and making it very easy to connect to your AWS workloads, because they know that's what you're going to do. So we're forcing the hand of vendors to be more interoperable, because the nature of what we do now is by definition vendor- agnostic. Or at least it's not completely heterogeneous, I should say, across the entire tech stack. Now that being said, I believe that one of the ways that engineers moving forward that perhaps want to get away from vendor lock- in within a specific niche of the tech stack, so just networking for example, I know I go back to networking so much, Roz, but that's who I am.

Rosalind Whitley: That's why we're here.

Phil Gervasi: Yeah. Is to start looking at how can I move away incrementally and say, let's go with this vendor for our perimeter, this vendor for our security CAS, we're going with CASB for our security for branch offices, whatever, and here we're using this for our closet and MDF switches. So I think we can look at it in those blocks, and that's a good pathway forward that doesn't require spending all the money in the world, that doesn't require restaffing and retooling all your engineers, at least not to the extent that it would if you replaced everything. And so, the things that you were just talking about when you were just talking about the changes that cloud vendors have been doing, and also coming together to create this new environment of application, workload creation and maintenance, I think that's where we are, is that we have to have all these things working together. And so, it just requires that we have a little less vendor lock- in. I mean listen, back in the day I had my computer, and there was some Cat 3 or Cat 5 going down the hall. There were some switches, maybe a router at the end, and my DNS server was local, my DHCP server was local, my actual directory server was local. Our applications were either in the building or maybe in some data center in the basement, but everything was very local. And so, you could have a lot more uniformity. I don't think that's the case. It's just not the case.

Rosalind Whitley: It's just not the case, and that's not going to go away. And I think some people say they think that ultimately the cloud providers are going to stick more to selling those commodities, because they end up, they can... So Snowflake's renting EC2 servers to which, I mean, definitely abstracting away network and compute servers, that's where we're moving. And I think, that change is here to stay, but I think some people say that the cloud providers, or even if we think about the cloud providers aren't the only ones who, like Equinix. So Equinix and the cloud providers maybe own that commodity space. And then it's really these smaller companies. So yeah, Snowflake, they're running their workloads on EC2, and then they are essentially selling that service at a higher price point. Render does the same thing, not on EC2, but they're running things on GKE, and then they're selling that as a service at a higher price point. And in the end, AWS or Google Cloud, they still get money from that. They're still getting money from the commodity from selling those commodities to Snowflake, to Render, and then Snowflake's taking on the marketing costs, the staffing costs for building it, all of that. It's almost like outsourcing those top level services like the DynamoDB or the services that they're selling, outsourcing that to other companies. And in the end, that may not be a bad business model for them. But I think, yeah, the key is, if we have this landscape where it's all of these different vendors selling all of these small services that are really good at doing what they do, and then we have to link all of those up, those are the LEGOs that we combine to make our applications and our services work for our customers, I think yeah, everything has to be interoperable, and it's in particularly those smaller software vendors beyond the big three, it's in their best interest to make everything interoperable and to cooperate. But I think organizing that cooperation and making it good, is also a hard job. That's probably for another episode to talk about what it's like to get involved with the Cloud Native Computing Foundation and the Linux Foundation itself. But I don't think that's a totally solved problem. Is like, what's the best way for people to collaborate in the open domain and who governs it, and what does governance look like? But I think it's important, because impacts us. It impacts all of us, from the software that we use, to you and me, our jobs trying to help enterprises get a handle on their networks. And we're nowhere close to that time when the cloud providers own all of the networks and we don't have to care about it. I mean, we're nowhere near that, and thank goodness, because that's why they need Kentik, to be able to be able to understand all of that.

Phil Gervasi: Roz, I think that's actually a great place for us to end, because on what better note than to mention that, that's one of the goals that we do at Kentik, is to be able to provide visibility, regardless of the vendor that you're running in your network.

Rosalind Whitley: Yeah.

Phil Gervasi: So anyway, Roz, thank you so much for joining today. I really appreciate it, and the conversation, and really just fleshing this out. What our audience doesn't know is that we have next to no show notes today, because I really just wanted to talk to Roz and pick her brain and get her thoughts on this whole vendor lock- in thing, primarily because I thought we disagreed. But here we are at the end, and I think we agree more than we disagree.

Rosalind Whitley: I'm sorry I didn't fight with you at all, Phil. I tried a little.

Phil Gervasi: That makes a good podcast.

Rosalind Whitley: I tried to fight with you. We can do a part two, and I'll fight real hard. But I think your ending point is, or at least the way I always put it is, the network is the common language that all of these resources communicate on. And they're all built on top of that as a primitive, and it's a primitive that still really matters, because that's what all of our traffic traverses. And I think, being able to understand that is really important, and that's not going away. And yeah, that's why we're here. But yeah, I learned a bit from you about vendor lock- in in the networking space, and yeah, I've got some homework to do to find some stuff to dig in my heels on, I guess.

Phil Gervasi: Yeah, very good. Well, I'm glad to hear it. So if folks have a question for you, if they want to reach out, maybe they have a comment for you, how can they do that, how can they find you?

Rosalind Whitley: Yeah, sure. You're welcome to look me up on LinkedIn and I will happily talk with you there. Or if you'd like to send me an email, you can send me an email at my first name, rosalind @ kentik. com and I will happily field your questions or chat with you.

Phil Gervasi: Great. And you can still find me on Twitter at network_Phil. You can search my name in LinkedIn as well. My blog, networkphil. com. Now, if you have an idea for a show or you would like to be a guest on Telemetry Now, please reach out at telemetrynow @ kentik. com, I'd love to hear from you and chat about that. And until next time, thanks for listening very much. Bye- Bye.