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

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. Raslyn Whitley, a director of product marketing at Kentech, but also a very experienced developer and SIS admin, joins me to talk about her opinions on open source software, vendor lock in, and how technologies like cloud containers and and now automation as well have sort of 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 Philip Gervasse, and this is telemetry now.

Hey, Ross. 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 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 from my guests and from, you know, just friends in general, how they got into a particular field. But also your experience with open source, before before we get into the whole vendor lock and discussion.

Yeah. Absolutely. Thanks, Dylan. By the way, thanks for having me on the show today. I, let's see. How did I get into tech? It wasn't really accidental, but, I would say a lot of us have nontraditional or linear.

I was raised into tech, and that's certainly me. So I started out, when I was quite young. I, I was like a bit of a unix nerd, as a 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 sort of maintain my own computer and refuse to buy me a Windows license. So it's like if you wanna know, if you wanna watch these videos, you're gonna 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 I 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 you know CIDR projects and then I started with a series of like, low level jobs first at a press, and then I was working actually as a receptionist at a veterinary hospital, doing, like, 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 gonna change it. You can either hire me to implement a new system for you or, and I'm really cheap.

Or you know, you can spend a lot of money on that and they they actually took took me up on that and then I had, you know, software implementation on my resume and I sort of fund that.

But anyway, I had a series of those kinda like lower level, I would say IT jobs or and then, I decided that I wanted to stop telling 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 I got a master's in in information systems database and internet technologies.

And, while I was in, while I was actually finishing up school, I got my first real tech job, which, I was a SIS admin at the University of next of New Mexico, managing and, on call for learning management systems. And I wrote I wrote some wrote and maintained some back end code, and a little bit of front end for a kind 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 I learned what it was like kind of working on waterfall working in an organization that really did did things the waterfall way and did things a slow old school way.

And I, really chaffed at that. And there are a lot of budget constraints in that job too because this was New Mexico and we're really, trying to keep jobs on prem, and we were also, you know, of course, our top priority was serving our students. And I felt that really passionately, but sometimes I would be like, you know, if we were running this in the cloud, students would have a way better experience, etcetera, etcetera, and that 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 kind of got back into that's how I got into open source professionally. Like, I had always been sort of an open source a lover of open source.

Yeah.

And used to that very curmudgeonly open source culture that, that I think is still around, but is less of a thing now. And, yeah, then I started working at Puppet, which is, was a 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, a software deployment tool and, developed at Netflix.

So we had a a proprietary disrupt that And I worked actually, I was director of open source there and worked on trying to get people to contribute to Spinnaker that was one of my that was one of my KPIs, and that was pretty hard. I gotta say. I'm I could tell you more about that if you want. And then, 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 Kentech. So it it's really been, It's 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.

Well, that's why you're here. And your title at one point was director of open source.

That's right.

So that is like the pinnacle of open source cur curmudge in like you said. Yeah.

Get you know what? And you're right. It is depending on the angle from which you analyze this question. What is vendor locking? Is it good bad because I know from the networking space, it means one thing from the infrastructure, like, you know, when when you're talking about data center infrastructure and, you know, just servers and and, infrastructure as code and all that kind of stuff, that's that's a different, that's a different angle.

Yes.

But then there's a business angle.

I'm sure that you had to deal with the engineering side that had strong opinions about, particular matter, particular deployment, the particular configurations, all that.

And then also from the business side, you had VP of whatever and 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's there are a lot of different angles, and I think it's important to balance that out. But one thing I I would do wanna say is that you and I have different backgrounds from a technical perspective because, I mean, me, I was I did start off as a cis admin simply because that's, from going to help desk and then a cis admin generalist kind of stuff.

Very quickly after only a couple couple few years got into networking, very laser focused on networking. And in networking, unless you're in a kinda like a web scale organization where you're you're building your own switches, right, and your own, like, router OS and all that kind of stuff which some people do. Some organizations do that. And you're or all of your your your network gear is like, cumulus Linux or something.

Which is awesome. Generally speaking, you're married to a vendor. Like, you're, you know, your your your deployment is mostly Cisco with maybe some, like, you know, some branch offices running this or that or mostly Juniper, you know, there's anything but Cisco shop, and and that whole thing. So So that's that's my background.

And and in and in that, those conversations I have I've had over the years that were people that just loved, Cisco or Juniper or Rista or whatever. Partly, I think, because there's an entire educational component. Like, I took all the Cisco certifications. So, of course, you're 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 that really scoffed at that. So it was really they they was it almost felt like there was no in between. There were people that were like anything about Cisco. I'm gonna run, you know, my own distros and and what what can I buy?

Like, what kind of white box, how 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. Right. I feel like service providers were much more amenable to to to running. Maybe maybe not necessarily open source.

Let me correct myself. More amenable to running different vendors other than like the big two or three vendors. You know what I mean?

Well, and does that mean a mix Does that mean a mix of vendors, or does that more just mean like going out and trying to find a different vendor who isn't in the big two or the big three? Like, do you is there like more heterogeneity in the service provider, sort of equipment arsenal?

Well, I mean, I never worked in the service provider space. But I, obviously, it's it's so adjacent to what I did anyway that, you know, working with service provider, working with those folks, I know that they were, again, more amenable to other vendors. And And for certain requirements on the back end, like in a like in a provider backbone, you need there are certain performance requirements where you might look at a specific vendor, but not because you you you want that vendor. Whereas on the enterprise, right, you need the performance, and so that's the box that provides that.

So that's what it this many line cards or the 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 know, you just have whatever whatever relationships you've already developed over time with the local sales reps at Cisco or Juniper, whoever, Arista.

And so, you know, you everybody knows their kids' names, you know, all your kids are with my kids on the basketball team. And so you get these while I'm only gonna buy from this salesperson.

Mhmm.

Or I'm only gonna or or you have the CIO that had a bad experience with a particular vendor, you know, some years ago, and now it's in their head as, like a religious belief that I will never use that vendor again. I remember I remember, having a boss that was, against specifically the Cisco two thousand nine hundred and sixty x switch, which is just random. Yeah. It's just like a layer two closet switch. It seems like nothing going on there. Very little going on. But he had like a couple of RMA's he had to do for a project once when they first came out when we were switching over from, like, the two thousand nine hundred and sixty G and s, right, whatever.

And, and that was it. That was enough for him to say those are bad switches. Blank statement. I'll never use them again.

I don't wanna use that vendor again. And and so and I'm like, that's not really logical. Like, if you look at the, the percentage of how many of those switches switch, or shipped from their production warehouses and all that versus how many are actually like failed devices that they're actually pretty reliable. I think your your perception is skewed.

So not But that's where the networking sign in. Right? Yeah. Yeah. I mean, I would say just a little side note there.

I think, we lie to ourselves that, all business decisions are 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 a, you know, 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, that's the stuff that sticks with you. It's a it's a little funny when you when you, when you see the way that plays out though. I think that actually comes up a lot, like, so in thinking about this conversation, I was thinking a lot about sort of, well, cause there's there's vendor lock in and then there's technology lock in. I think they get Okay.

I think they get conflated a lot. We can talk more about that.

Can you can you define both of those for me then?

Yeah.

So I understand my problem.

Absolutely. Absolutely.

So it's kind of like vendor locking is truly when essentially like 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 that's truly what what you're talking about. Like, if there's a particular switch and and this is where I So I maybe will reveal a bit of my, that I'm still a learner in the, in the networking world. But, like, isn't there such a thing as open standards? You can answer that question later. But I I think, like, vend true vendor lock in is when is 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 change to a complete change to the technology in order to change away from that vendor relationship.

Right. Yeah.

Whereas technology choice, I'm 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 in the cloud, people talk about how, you know, you choose and this was the the example I was going to get. Like, people talk about how if you choose one cloud provider, then you end up you're kind of 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 disrupt 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 sort of an asterisk there because it depends on which services you're using in the cloud. If you did like a classic lift and shift, and all of your workloads are running on VMs, and you're using, like, what we call commodity cloud services, which are those very foundational I infrastructure as a service pieces where you're essentially renting, like, you're renting storage, you're renting compute. At 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 know, 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 of, you're using elastic bean stock if you're in I don't know, two thousand and fourteen or something. But, you know, there's a lot of, there there are a lot of those higher level services that have now been built top of the cloud, and the theory is that's to lock you into those clouds. And I think that's that's kind of truth. But that's still that maybe that verges into vendor lock in because, like, you know, if AWS shuts off your account, they're shut off. 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 kind of what that's like. And yeah, are there are there open? Like, 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. Right?

So that's kind of different. You're not thinking about migrating necessarily.

And when I talk to customers about this, they're they're not talking about, oh, you know, we're migrating from Arista to Juniper or something, but they're like, we're we're now we're buying more of this. So then, like, what does that look like when you're buying heterogeneous equipment, what does that transition look like?

Like, does it all just work together?

First of all, because if you're talking about an entire rip and replace, right? And it's also dependent on the type of budget that you have. So if you're using if you have the minimal network operations budget, but you get that five million dollar grant or that big refresh budget every ten years, five years, whatever it happens to be. I'm thinking about, like, government.

I did a lot of New York state government, counties, a lot of universities, public, you know, part of the SUNee State University of New York, school districts, big school districts. Yeah. You know, a big school district where I'm from might have, eighteen thousand students, just north of New York City. Right?

And they have a their budget for the entire district might be seven hundred million dollars. So when they have a refresh, as much as it's just quote on air quotes, a school district, it's a it's a eleven million dollar project. You know what I mean? And so you go in there as a reseller and you're gonna make margin on the gear that you sell and so though, you know, you're an engineer, you're you're making margin on gear, just as much as you are on professional services.

So, yeah, you wanna capture as much of that as you can. And if you're looking at the day two operations, you're also looking at the, you are looking at the OpEx like you mentioned. So, you know, Cisco was being really great over the past few decades of developing an educational framework through which people have learned networking.

Yeah.

That's how I did it. And you're and you're embedded in it. And that's awesome. I I don't knock it whatsoever because it's how I built my career.

But, you know, it's one of the side effects is that I am much, much more comfortable on a Cisco CLI than I am in on other CLI set. Not as much day, you know, at 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 you're assigned to projects.

Right.

And and so and so you know, therein lies the problem for a lot of enterprise. Now from a technology perspective, right? Let's say you 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.

This is a very simple example. ERGRP is Cisco proprietary. You're not running that on other gear. And therefore, you know, you if you wanna switch vendors, you need to do a major overhaul of your network architecture.

And there there are that's just a simple example. If you're using BFT, as a timers, for your network or or anything else that's related to, specifically Cisco, you know, there's an architecture choice there. Yeah. And then you start to apply that to other vendors, you don't quite see it as much.

But that being said, you you have to sell that that operations to your customer as well. You're not just selling the eleven million dollars of gear, but now you're saying, you don't have any staff that can manage us. But if we go with Cisco, you do.

Yeah.

So That's all that's all there. So so I I look at vendor lock in as being locked into a particular vendor, which usually translates to a particular technology.

But but I I have to admit though. I don't necessarily think it's all bad. I think that the industry or or tech industry has this sense of like that's evil, that's bad. I want to get away from this vendor agnostic.

I'm like, I get it. That sounds good. But there's a whole slew of problems with a with a vendor agnostic environment where now you have, like, you don't have consistent, features, you know, across an entire end to end, or maybe you're you're calling up five different tax Right? So you're calling JTAC and Cisco TAC and, you know, I don't know what a risk to 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, with one line card, and then bugs. Right? I have bugs in all my my Juniper gear, but not my No. You're just, like, trying to troubleshoot that. Security patching. You can't do it as easily because you have to look at it as vendor by vendor.

Right.

All of these issues in a in a vendor agnostic environment, but but I do get it. You have more control. So, you know, one of the things that I like to to say to folks that that kind of 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, iPad over here, maybe an Apple Watch, and it's like, you're doing fine. Like, you 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 get you are calling TAC, and that's it, Cisco TAC.

Possibly if your organization is big enough, you get like special TAC where you get a special, like, you know, bat phone, bat line, whatever they call, you know, batman's direct line.

And and I'm sure that's the same with other vendors as well. So I don't I just don't see vendor locking as as much of a negative as some technologists claim it to be.

Oh. Does that make sense? I I I mean okay. Well, first of all, to your point about the iPhone, and maybe this is just because I'm always gonna be an open source nerd.

I bought an iPhone a few years ago. At this point, it must have been I don't know, five years ago or something. And now I'm now I'm in the, like, I'm in their web. And before that, I always had an Android phone and I loved I loved certain things about that and I love certain things about the customization that I do with that, but now I have this iPhone and I feel like I'm stuck.

I do have I do have, you know, a couple of macbooks.

That I've, that I've, mostly through, mostly from my employers, you know. But, so, so I guess it's kind of nice with that. But then they also want me to buy their, you know, I've gotta buy some software subscription to sort to to keep track on my data across devices.

I really don't like that and now actually I've been My partner has a has an Android phone now, and I've been experiencing a lot of jealousy about, like, but then what in and it's 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.

Yeah.

But also I think I think, like, on the enterprise side, there's risk like the the big risk with vendor lock in specifically to me seems like you're you are relying on one vendor for innovation.

So, and and I don't maybe this is where, like, Again, you can you can tell me from a networking perspective this is different, but like is there not a level of innovation that you're missing out on when you're tying your when when you're sort of tying your horse to one wagon.

And does that matter in the net world. Like, does that even matter from a security perspective? So if if you're if you're relying on one vendor to do all of the security like work for you and and you have essentially like all of your eggs in one basket, like, doesn't that mean that if someone figures out what the vulnerabilities are in that vendor's in that vendor's implementation of the hardware or in their software, then you are, like, left holding the bag for, like, what? I don't know.

And and that's why There does.

It's totally good. Totally true. And that's why RFPs are really important. That's why analysts exist, right? Because they they're supposed to tell us they're supposed to tell us who's trustworthy.

We look at customer references to but, I mean, to to a point, like, do any of us really know? Like, 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 I think hindsight's twenty twenty there.

And I think But maybe the innovation thing doesn't matter as much because, like, maybe in the networking world things move more slowly.

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 like, you know, application delivery and service delivery. Yeah. So the the key for most network people in my opinion based on my experience is stability, reliability, predictability.

Yeah. Innovation happens sure, but how many network engineers running, you know, the network at a university, even very high level, multiple CCIEs, Jan CIEs are like coming up with new networking concepts. I mean, they're maintained network, maybe they're designing architecture. I'm not saying that that's not a a heavy lift and and very, interesting, and and intellectually stimulating and difficult work, but they're on this really innovating in the sense that they're coming up with new protocols and and new things like that.

And that would be scary if they did. I guess it's that that would be kind of scary if they were doing that.

Yeah. And there's always I do believe in the concept of being an engineer though. So I like to look at the technology landscape that's before me and 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 that's not necessarily gonna fit. I got I got this, you know, bandwidth issue over here in this choke point and blah blah blah. Okay. Well, let's just buy a bigger box and and call up our sale, sales rep and and buy a bigger with bigger bandwidth.

Well, hold on a second. Let's analyze the traffic. Are we doing this inefficiently? Like, what's going on?

So I do believe in being an engineer. Yeah. But this 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, right, which happens from time to time, you know, yeah. You're 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 I don't really look at it at the two extremes. Those are the two walls. Right?

Yeah.

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

Yeah.

Yeah. Yeah. So, like, let's say my perimeter firewalls are all Palo Alto. Mhmm. And my inline IDSI I find that I'm getting better performance with a different vendor, right, or whatever.

Yeah. Let's say I offload certain things to some Casby, you know, from my branch offices. You had 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. Yeah.

So I'm connecting with silver peak. So I have these layers or blocks of networking, and And within the the realm, I might go with a vendor. So I had that interop. I don't have an interop problem or or a feature problem.

But then when I go outside of that, I'm just moving packets like you said. Right? You I think you mentioned it earlier as in this stuff, you know, industry standard. So I'm just moving packets And then, I'm not relying on features at that point.

So that's kind of how I look at it as far as, like, the degrees of vendor lock in. You know what I mean?

Yeah. I mean, I think that's a really I think that's a really smart way to look at it is to kind of, is to dev divide up and and it sounds like you're what you're what you're talking about is being strategic. So you mentioned like, you know, you're actually looking at, and that that's engineering too, right? That's looking at like this I'm getting better performance out of this or or, you know, I have this particular gotcha with these types of devices and I'm going to I'm gonna, you know, steer clear of that.

And you did make me to, you know, as a salesperson, someone's saying, oh, like, you know, I'm having this 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 like you just need this latest thing. So I think that goes back my question earlier is like how how do you know when it's time to replace part of your fleet, even if you are doing that like sort of vendor I guess what you're talking about, which is like dividing parts of your architecture among different vendors, there's gotta be a point where you know that where you know that it's time to time to throw like throw a bigger box at the situation.

And I think understanding that is hard can be hard. And I guess that depends on the use case though. Like if you're doing high frequency trading or something, that's different. Than, you know, managing like email for, like, managing a school district, which a lot of the workloads are gonna be like, office software and email and, and, you know, remote remote learning these days. Yeah.

Yeah. Yeah. And I I get it. It's different when you start talking about the, you know, the the there are differences in, how open one can be and how vendor lock in, you know, plays into the equation when you talk about networking, compute storage, cloud, you know, those are different realms of technology. So I get that there are differences.

For example, you know, it would be hard pressed to go to a, let's say, a mid sized school district. I would be hard pressed to find the IT staff, be comfortable with managing eight different vendors. So an s from one vendor, switching from another vendor, They do it because, you know, the budget is the budget and you, you know, it's your job. So you do it.

And and and so it there is that benefit of having everything from one vendor and so can get the help that you need. Because, you know, you're not necessarily gonna talk about, you know, having a staff of, again, you know, the highest level engineers that let as an example at a small midsize organization. Yeah. Which always follows my mind how some of the vendors, the networking vendors consider small and medium sized organizations.

I remember doing, you know, projects and, you know, whatever. You know, I'm doing projects. I'm I'm with VAR And I'm working on my Sysco certifications and you read in the textbook, you know, they'll say something like a small a small organization with ten thousand users. And I'm like, what?

In what on what planet? So it's like the perspective is is a little different. Yeah. But, you know, who who can afford three CCI's a JN CIDR these, like, Linux gurus that and they cost hundreds of thousands of dollars each.

You're not gonna necessarily see that at a small organization.

Yeah. So that that came to mind. I think like talent and staffing costs is a huge part of this conversation that, that sometimes gets sometimes gets talked about and sometimes doesn't. And I don't know if this is controversial, but it's like maybe Well, okay. I'll go back to sort of 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 kind of in our ICP, our ideal customer that we're going for.

And we would ask them How because our our what we're trying to figure out, you know, how to sell more render, which if you're not familiar with render, it's, it's it's similar to heroku.

But it's sort of built for the container, the cloud native and built for the built for the container sphere.

And We would ask people like why did you choose like how did you start using a lot of them are using AWS or maybe they're they've got their workloads mostly on Google Cloud or maybe they are using digital ocean or heroku and we would ask them like 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.

Oh, and I expected them to say, oh, you know, what we looked, you know, at least say we priced out what this would be as we scale them, what this would be, and we decided that this would be better, or we wanted the features, like, we wanted we 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 startup world, but they would say, well, you know, one night, we were working on building this. And, my buddy was really comfortable with using this particular service in AWS or my, or, you know, they had used Google Cloud before at their last job and that was what they were most familiar with most recently.

Yeah.

And we built it in that. And they would say, you know, and it would be like, well, what would it take for you to switch? Right? And same with heroku. Like, people would people would have started running something on heroku. And even though support, Heroku support has gotten pretty bad after the company was acquired by Salesforce.

Like, it was really hard for them to switch and On the one hand, that's that is like, I think staffing is a huge part of it. Right? And I don't know if this is where, like, Dev ops engineers, infrastructure engineers are a bit different than, like, is it easier to ask a network engineer to switch to learn something new or use a different 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 that I know like infrastructure engineers are very scarce. 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 wanna poke him too hard. Like, we don't really wanna take we don't want to take our engineers out of their comfort zone. And we find this at really big companies too. Like you'll get that happens with like, acquisitions merges and acquisitions.

Right? Like, a huge company will buy a sub buy a buy a company. It becomes a subsidiary and they have a choice. Like, they could they could make the engineers running the workload.

My 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 don't that they oftentimes don't like for standardization on on newly joined engineering teams is that they, want the workload, you know, if it's a money making workload, they wanna keep it in place. But even when that's not the case, like even when those engineers are building new applications, I found that they are often it's like, well, we let we wanted to let them use what they wanna to use because we didn't want their productivity to go down.

And it's also I think like the subtext there is we didn't wanna make them mad because we didn't want them to quit because it's hard to hire these people. So I think I think that's where like people's feelings about different frameworks and different tools and also their comfort level and what they know is really important. And, I mean, staffing is the most expensive part of all of this. Like, high paying engineers is way more expensive than paying your cloud provider or and and I don't know if it's more expensive than paying Cisco for all your equipment.

Maybe it is, maybe it isn't.

And is that Well, I mean, the things that a lot of these vendors make it easy for you to stay with them, or they 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 kinda starting that email chain with the, with your AM or whatever they're called, the the the the salesperson.

And they're like, oh, great. We have a buyback program. We'll get rid of that. Cycle it for you. We'll purchase that and we'll give you this much off of, you know, the, the, whatever the price is.

The list price on all your gear, and all of a sudden, it it becomes very attractive, to just always stay with with the vendor as a result.

As opposed to switching vendors, but that's the thing. It's like it's almost like going from one vendor lock into another vendor lock. Great. You know what I mean?

It's like, oh, let me get away from vendor lock in. So I'm gonna get rid of all my system and go to all juniper. It's like, well, wait. Hold on a second.

Yeah. You didn't you didn't love the problem. You just changed from one vendor others. Right.

So for me, this idea of vendor locking is it locked 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 than a lot of what you're experiencing, what you've been talking about, except for maybe cloud, because once you start to build out your in higher application delivery service and workloads in AWS, which, by the way, they have like seventy five percent of the market share. So, you know, it's what it is.

You're you're kinda stuck there. And, you know, the idea where people are, like, in seven different clouds and on prem, I mean, I I don't see that quite as much. I think the reality is, like, I gotta keep the lights on. You know, and I can't I can't keep always trying to, like, win these religious arguments and wiggle wires to make things a little bit more efficient, or to take advantage of feature over here that we don't really need because everything is working fine now. Try convincing, you know, your VP of whatever of that and and then get the budget to do it. It's very, very difficult.

Yeah. But, you know, that that begs the question. Is is vendor lock in really that bad?

Is it just a negative connotation, we'd have a we've attached. I mean, lock in sounds ugly, you know.

Should we call it something like, vendor dedication? No. That's dumb.

You know, vendor loyalty. Oh, I don't know.

That's that's You just wanna reframe it so that people see, you won't wanna reframe it so people will feel better about it.

Right now, people.

I have a degree in English as well. That's what I want to call school. I taught high school English for five years. So I agree I believe Other people have disagreed with me over the years in our space and our tech world, our tech industry.

I believe that words are extremely powerful extremely powerful. And you can cast into their connotation, is so different than a denotation from from in in circumstances that you can cast a completely different tone and and feel and and emotion based on just your diction, you know, which words used to convey. The same exact thing, that you could do very differently. And so, isn't that what we do in marketing at all?

That's what I was gonna say. That's how I ended up in product marketing.

I, you know, I, I like to talk about the tech. I like to think about, you know, why people are using it and what they care about and what are the drivers that that make people success, you know, succeed or fail with it. But, like, it's really about how you talk. I mean, One of the things I'm doing this week is thinking up thinking up tags for our for our booths at different events and like do you know how hard that is to think that, you know, how do I say exactly what I wanna say in five words that people are gonna understand they're not gonna misunderstand.

It's gonna stand out. I mean, it's really, really, it's really hard. It doesn't it's one of those things that doesn't look like work, but but it is work.

And Oh, 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 kinda going on and on.

It's much more difficult to be sites and and retain clarity accuracy and, and and retain the message that you're trying to convey.

Which, you know, may maybe that's maybe that's the problem. You know, we use the term vendor lock in, and we, absorb that into the industry as a negative thing. And, and therefore, there's just this subtext this presupposition that having one vendor is bad, but is it to go deeper? And and that's my argument is that I don't think it's that bad.

I I really think that we you have to analyze it like an engineer and say, alright. All my all my switching gears from this one vendor. All my front end is gonna be in AWS. All my back end is gonna be in Azure.

And And and what you do is you men you mitigate that, the blast radius, first of all, from a security or a failure, your failure domain is is shrunk. So now if my front end goes down, it's not my entire structure. 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, you know, just the just my switching. And, you know, you you can do that in in peace as if by closet or just my firewalls or something like that.

And so It it keeps things more manageable. It also reduces, like you said, the expectation of staff to know everything that exists.

I 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. Right. But that that is a to say, oh, yeah, you know, all network engineers are like that. I don't, you know, I obviously can't say that. There's all sorts. There's network admins that just, you know, they're they're punching the clock, and then there's network engineers that can't stop learning.

And it, again, that's there are folks that are just grounded in the fundamentals more than they are in a particular vendor, CLI. Yeah. Right.

I mean, I think that's so on the, again, on the software side, I think there's this, there's this sort of wisdom that's that that's floated around.

I mean, really, it's been a while, but this choose I'm trying to remember what the name of the guy who did this original talk. But it's choose boring technology. Right? So his his argument is is pre predisposed on the fact that, you know, we're all engineers.

Most of us like to tinker We like to I'm an ideas person. I like to imagine the way that something could be architected, the way that a new new platform or new service could could change or improve the way that that that something works. Like, I I love thinking about that. And, there are a lot of engineers also who love building, and it fun to build stuff and it's hard, but you feel really good when you get it to get it to work and all of that.

I mean, I think we're all we all have these Like, we like doing that. That's why we came that's why we came into this field. And taking that to when you take those skills to a company, that can be good and that can be bad, right? Because you actually don't always wanna be using the newest most exciting thing that you wanna play with that's not that a lot of times that's not actually your job.

Your job is to is to as you said keep the lights on with, what you got.

Your job is to, or your or your job is to choose the most reliable most known pieces of technology that you can put together. Some every every technology has its downsides. Like there are things that there are things that really suck about every piece of technology, even stuff that we think is really cool and exciting. So I I think there's yeah, this wisdom that like you kinda have to suppress that desire to always re architect things or always explore the newest thing, and sometimes you have to use the boring stuff that maybe is not your favorite.

Yeah. I don't know. When it when it comes to if vendor lock in is 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. So in so in networking, it's different in, like, database database stuff comes to mind for me there too. And when I was a SIS admin at UNM, we used we used Oracle had Oracle licensed for Blackboard Learn and and other apps. And so I ended up learning a lot about, learning a lot about I mean, specifically like Oracle twelve C, Oracle database twelve C, and what were some of the things that I needed to to, pay attention to with that And I mean, that was a very locked, that was a very locked in situation.

That's not that's not postgres, right?

And But did 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? Yeah.

I mean, I think I think it I think there there were things that were I think yes a bit. I think that, there were times when, like, there there would be like this one problem. Like, I would get a page in the middle of the night and I would be like, Oh, you know, there's like a ninety percent chance that it's this one problem that I've seen before. And because it's on the database side, There's nothing that, like, like, when 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 I could really rewrite the code on.

So there was this one, there was this one thing that when we upgraded to 12c, it would it would when it when a particular connection would reset, it would crash the application. And there was, like, nothing that we could do about that. And, so I mean, maybe yeah. That's a that's a really but I think like 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 there There's a lot a lot of interesting stuff that's happened from hadoop that's that ages me.

You know, equal, no sequel stuff.

Now we have I think like the way that we think about about rows and columns has both stayed the same and changed a lot.

Over the last ten years, but I think that what's interesting is that companies like Clickhouse and Snowflake are super successful now I don't know about Click House, but I know Snowflake, like, it's their all their data is in a proprietary format. Like, that's a completely proprietary solution. So I think, like, the tolerance for, vendor lock in or even technology lock in kind of varies from different in different areas. So I think, like, when it comes to data, But, you know, the, like, hadoop was really exciting once, once upon a time. That was two thousand nine to two thousand thirteen about. People were really excited about this open source solution that had been developed at Google.

And, and, I mean, around that time, people were also just really excited about you know, like data lakes. Like, oh, like, I can put this unstructured data into a data lake and then I and then I can do anything with it. I and that and I don't have 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 wanna use that same data. And I mean, that was an annoying problem. But the thing is, like, no matter how you slice it, there's that like your staff either has to be really good at doing one thing that that they have limited ability to like change how it works, and so they're kind of locked in in that way, or your staff has to understand how to use a bunch of different kinds of things, which is never gonna be perfect and like they're going to be problem. I think there's problems on either side, I guess, is what I'm thinking.

Yeah.

Oh, there totally are because if you 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 benefit. 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 or maybe the answer is no. It's please, you know, the the benefits are nice, but I have I'm really limited in what I can do here, and I don't know if that's gonna be good for the future.

I mean, just as an example, wide, consulting for a very large organization as in hundreds of thousands of employees, right, global. And, I'll leave the the name off because they have multiple BUs, some of them being like 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 code to scrub the operating system code of all the different network devices and to have a a special pathway to, like, at that level with the networking vendor so they could ensure, you know, the fits. Right? That's we're weighing this out. They could ensure certain level of of security, robustness and, features and whatever, you know, They needed something. They can get their own literally their own code versions to to accommodate.

Now, that is an exceptional example, though. I mean, that's not what most people are gonna be weighing.

So in that sense, they don't have vendor lock in. They have we just told the vendor what we want. So it it it, like, theoretically, they don't have vendor lock in. They have just purchasing power to do anything they want.

And and other organizations that operated that scale instead of working with a network vendor to do that have chosen to just build their own OS and write their own, which code or, you know, with their own, you know, Google did this with containerization, right? Look at Kubernetes and what we have now with that.

But that that kind of makes me wonder what is your opinion about how things have gone? You you mentioned ten plus years. Let's let's shrink that down to the past few years. Right?

The cloud as ubiquitous containerization is is pretty ubiquitous now as well. And this concept of open source is is, you know, that's it's different than in two thousand five. It's 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 more embrace more of this vendor agnostic concept in the past few years?

I mean, I actually think that's a good question. I actually think, like, the the open source community itself has always been really a, like, against the idea of vendor locking. I'm a as like a libertarian ideal. Right?

And so that's pretty that's that hasn't changed, but I think, like, honestly, a lot of those people who, were part of the early kind of UNix, well, sort of proliferation of UNix into into different operating systems and also into the main mainstream participation in the economy. I think that that a lot of those people who are involved in that, like, aren't really There's a new generation of people who doesn't connect with that as much. And I think that that that has changed, but I also think that the way that companies have thought about, because this capitalism, right? 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.

I mean, you've got you've got Red Hat enterprise Linux, like, that's that's sort of the that was the original dream. And, I think that not that, not that many companies have been able to replicate that as a as a revenue model.

And so I mean, just as you're talking about just in the last five years, while I think about from my personal experience, Puppet, right? So I worked at puppet and, at a certain point, puppet was used in more than ninety percent of the Fortune five hundred. That's open source puppet.

Sure.

Puppet tried really and and it was a I mean, it really changed ops. And it and they really they weren't the first infrastructure as code company, but they really popularized infrastructure as code and made it what made it what it became.

And they were never able to monetize. Like, they were never really able to successfully monetize it and you were acquired last year by Perforce and, the original, you know, original participants and that didn't didn't make much money off of it. And even despite like the what what you might consider like a huge success. Like, they changed the world.

They changed the world of of a large scale computing operations, but that wasn't enough or was it modeled correctly for them to make money off of it and Docker is another great example of that. And this is this is probably yeah. This is less than five years ago, right? Like, the the rise and fall of Docker.

So Docker, again, what 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, you know, really good really good marketing and just 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, and it's kind of sad when you think about, like, the ingenuity that went, like, we talked about innovation earlier. Like, when you think innovation that went into that and how it really did make these big shifts.

But monetizing it is tricky. And when I worked at it. 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 the the dream now for these not for big company like AWS or Google.

AWS and Google and particularly Google. It is in their best interest to, like, invest in an open like, they'll hire a whole team of engineers to work on an open source product, and that's what happened with Kubernetes. Like, Kubernetes is not, like, some you know, like people holding hands working together for free on a piece of software in their spare time. Like, that is not what it is.

It was a bunch of huge companies realizing that if they that they they had a unique shared interest in this open source project and that they could that that they could make it something special together and that they could share resources essentially through this.

And So I think that 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 like to have they'll do like a marketplace where people can create their and Pupupit 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 of diverse expertise.

But the company itself, their investment is protected. And there's been some other interesting like so MongoDB. There there's some different licensing licensing stuff that's gone on. What's that what's that license called where, it's it's SA It's like the licensing where you another company can use your, like, if another, it's written into the license that if another company is going to use your solution to, to, to monetize a product, then they have to release a version of that into open source.

So it's sort of preventing preventing really the cloud providers, I think, primarily, from, you know, eating the lunch of these smaller startup that have poured a lot of money into this open source project and then it, and then it, then like AWS is able to throw a ton of money at at marketing the product and making it more usable.

And then, so it's sort of like like, I guess, detracts, or makes it makes it less attractive for companies to do that innovation. So I think there've been some interesting things, but I think, like, how we monetize open source, has it is still a bit of an open question because economic factors are always at play when 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, you know, vendor lock in is bad. Like, let's let's do something else. I think that that you're right.

We have a negative association with that and people want open source, but but, which which products to use and which products to make a bet on?

Is still kind of a difficult decision. And in in the end, it's it's those high paid and highly paid engineers who are really, like, 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.

Yeah. You know, what I one of the things that I'm teasing out from what you said is that things in the past five years, ten years more. It's just pro it's progressive and iterative. So I can't really say the last five years.

But especially in the last few years, application delivery, I'm gonna use that term very broadly. So that means the back end 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 of that stuff is basically getting, a human being to their data usually delivered as an application. Right? 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, nevertheless, I feel like, okay, so 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, you know, I can drop into a Python prompt in my in my nexus switches now. Right? We can do.

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 I just mentioned, you can drop into a Python prompt in nexus, you know. You have Cisco devnet. You have Juniper and and Arista being very open to being able to use your own tools to manage infrastructure and to manage connectivity between your silver silver peak SD WAN and making it very easy to connect to your AWS workloads because they know that's what you're gonna do.

So they're we're forcing the hand of vendors to be more interoperable because we have their the the the nature of what we do now 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 a tech stack. Right? So just networking, for example.

I know I go back to networking so much, RAS, but that's who I am.

That's why we're here.

Is to start Yeah, is to start looking at, like, how can I move away incrementally and say, let's go with this vendor for our perimeter? This vendor for our security caz, you know, we're going with the cazbee for our security for branch office and whatever. And here, we're using this for our closet and and and MDF switches. So I I think we can look at it in those kind of blocks, and that's a good pathway forward that doesn't require spending all the money in the world that doesn't require you know, re staffing 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 in in, you know, when you were just talking about, the changes that, cloud vendors have been doing and and also coming together to create this you know, new environment of of application workload creation and and maintenance. I think I think that's I think that's where we are is that we have to have all these things working together. And so it it just requires that we we have a little less vendor lock in. I mean, listen, back in the day, I had like my computer and there was some cat three or cat five going down the hall.

There were some switches, you know, maybe a router at the end. Right? And my DNS server was local. My DHCP server was local.

My active directory service was local. Our applications were either in the building or maybe, you know, in some data center Yeah. Basement. Everything was very cool.

And so you could have a lot more, uniformity. Yeah. I don't think that's the least. It's just not the case.

It's just not the case and that's and that's not gonna go away. And I I think like, you know, some people say they they think that ultimately the the cloud providers are gonna stick more to selling those commodity selling those commodities.

Because they end up, like, they can so snowflake, like snowflakes renting EC two servers to which I mean definitely like abstracting away network and and compute servers. Like that's that's where we're that's where we're moving. And that I think that change is here to stay, but I think, you know, some people say that, like, the cloud providers or even, like, if we think about it's not there are the cloud providers aren't the only ones who like Equinix, right? Like so Equinix and the cloud providers maybe own that commodity space. And then it's really like these smaller companies. So, yeah, Snowflake, they're running their workloads on EC two, and then they are essentially, like selling that service at a at a higher price point, render does the same thing, not on EC two. But they're running things on on Gke.

And and then they're selling that selling that as a service at a higher price point. And in the end, like AWS or Google Cloud, like, they still get money from that. Right? Like, they're still getting money from the commodity from from selling those commodities to snowflakes to to render.

And then, you know, snowflakes taking on the marketing cost, the the staffing cost for building and all of that. And they're kind of like it's almost like outsourcing those top level services like the dynamo DB or the 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 it it yeah. Everything the the key is if if we have this landscape where it's all of these different vendors selling all 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 to make our, 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 I think organizing that cooperation and making 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, with the cloud native computing foundation and the Linux Foundation self.

But, you know, that's I don't think that's a totally solved problem. It's 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 it impacts us, you know, it impacts all of us.

From the software that we use to to you and me, our jobs, you know, trying to help enterprises.

Get a handle on their networks. And we're nowhere close to that. Like, we're nowhere close to that time when the cloud providers own all of the own all of the networks and we don't have to care it. I mean, we're nowhere nowhere near that. And thank goodness because that's why that's why they need Kente. Right?

Be able to understand all of that. Yeah.

Yeah. Ross, I think that's actually a great place for us to end because, you know, on on what better note than to to mention that, yeah, that's kinda one of the goals that we do. It can take to be able to provide visibility regardless of the vendor, you know, that that you're running in your network. So anyway, Ross, thank you so much for for joining today. I really appreciate it. And, the conversation and really just kind of fleshing us out, you know. What our audience doesn't know is that we have next to no show notes today because I really just wanted to talk to Ross pick her brain and get her get her thoughts on this whole vendor locking thing, primarily because I thought we disagreed.

But here we are at the end, and I think we agree more than we disagree.

I'm sorry. I didn't I didn't fight with you at all, Phil.

I I tried a little That makes a good podcast.

I I tried to I tried to fight with you. We can do a part too, and I'll I'll fight I'll fight real hard. But I think your ending point is like is at least the way I always put it as like 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 where all of our traffic that, you know, that's what all of our traffic traverses. And I think being able to understand that is is really important and that I'm that's not going away and Yeah. That's why we're here. But, yeah, I I I learned a bit from you about, about vendor lock locking in the networking space.

And, yeah, my I've got some homework to do to to, you know, find some stuff to dig in my heels on, I guess.

Yeah. Very good. Oh, I'm glad to hear it. So if, if folks have a question for you. If they wanna reach out, maybe they have a comment for you, how can they do that? How can they find that? 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 at kentic dot com. And I will happily field your questions or chat with you.

Great. And you can still find me on Twitter at network underscore fill. You can my name in LinkedIn as well. My blog network fill dot 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 telemetry now kentic dot com. I'd love to hear from you and chat about that. And until next time, thanks for listening very much. Bye bye.