New Technology Adoption & the Price of Doing Nothing: Ron Nevo, cPacket
Lee Razo speaks with Ron Nevo, Chief Technology Officer at cPacket, about the opportunity costs of doing nothing when faced with new technologies, and the potential consequences not only for security but also in other areas.
Welcome, Ron Nevo, from cPacket, CTO of cPacket. It's great to get a chance to talk to you.
I've become more and more familiar with what cPacket's doing. So, this is a great chance for me to, you know, grill you a little bit, find out more, and just talk about the tech industry in general. That's always an interesting topic. So, thanks very much.
Sure. I appreciate you having me then. So, it's great to have opportunity to talk.
Yeah. Your work in cPacket works in a really considerably interesting area because, you know, I've been working in the IT business for, I don't know, a hundred years or so. And my background is in storage, but I've worked some things in compute.
But when you start bringing the topic of networking, people get nervous, you know. They say, 'I can do anything, but I don't do networking.' In the last like...especially the last 10 or 20 years, both compute and storage have really transformed in many ways.
And networking still looks a lot like it used to look. Do I...am I missing something? Has it changed? And how is it going to change in the next few years? What's new with networking?
I don't know if it changed. I mean, so I've been in networking for pretty much the hundred years. And I remember when I started in Qualcomm, they were saying, you know, everything...and that's, you know, probably the middle of '90s.
They said, 'Well, you know, everything that used to go on cable now is in the air. And everything that was in the air is now going on cable, right?' So, TV was going to cable TV. And, you know, communication was going on mobile phones. I think now 20 years beyond that, everything is everywhere, right? So, you kind of...it's all there.
I think there was a time probably when Wi-Fi was introduced where people were getting to the point, 'Well, if it computes, it connects, right?' There was also this kind of transition. Today, you know, with the internet and things, they just assume that everything is connected, right? Nobody thinks that things are not connected. Connected means that it's networked, right? And it can be like 100 gig if you're inside a data centre. It can be wireless if you're somewhere.
But people just think about it today as...I think if one thing changed is that people receive networking as a utility, right? They think it's just obvious that it's there, and don't really appreciate the complexities of actually making it work.
Yeah. It's kind of like infrastructure, you know like....
Yeah, you know, it took me a while...it took me actually spending time in Africa before I realised that roads actually had to be paved, you know? (Laughter)
Right, yes. Exactly.
Once it's not like that, you realise, 'Oh wow, this is a lot of work.' I think, you know, IT infrastructure is the same.
It's easy to take for granted.
Now, I think (overlapping conversation).
Yeah, but you remember in the beginning of the 2000, if you wanted to connect, you had to buy a PCMCIA card for Wi-Fi and plug it in and look for a hotspot, right? People don't do that today, right? They just...their laptop, they open it, and it's connected then, right?
Even worse, I'd show up in a hotel room, and there would be a telephone that had [inaudible 00:03:21] with a timer, and it was with [inaudible 00:03:22] be on the modem for too long, right? So, yeah.
Right. And listening to the beats there, right?
Yeah. And I think networking was originally designed or at least the sort of TCP/IP networking was designed, you know, with servers and clients in mind.
And now, it's becoming devices and it's becoming things, you know, internet of things.
It's becoming...so now, it's like either you abstracted into many devices or you find a way to attach a networking endpoint to a person, you know, it's kind of a tricky thing. So, it also I guess changes security as well, you know, the balance between access and, you know, having security.
How do you see that change in the last years?
Yeah, I think the point is that...well, there is not a thing, right? It used to be, okay, you have a server and you connect it to server and you download and....
Today in application, it's something that consists of many, many applications.
So, you know, if customers [inaudible 00:04:21] you know, we serve a lot with the big [inaudible 00:04:24] and their portal is actually 2700 applications.
They talk to each other.
And the security now becomes, you know, you and all these other applications that talk to each other.
This continuous authentication is one of the things that they have to pay attention to both from a security as well as from performance because you might go back and forth to a security server, you know, not just once to authenticate you, but every single application.
And that generates not only security concerns of course, but also performance issues and user experience issues.
And of course, security has never finished, you know.
It's never a topic that you solve.
It's a continuous process.
So, you know, your company now, cPacket, is...basically, it's not just security.
It's also performance and looking through all these sorts of things.
But, you know, tell me a little bit about how the approach is to security and, you know, performance as well.
You know, we can start with one of those topics.
Yeah. In general, what we do is we, I would say, enable security. We're not a...cPacket itself is not a security company.
But what we find is that in order to have a high quality security tool, you really have to have high-quality data.
So, one thing that we are doing is the ability to provide very high quality meaning we are not losing packets.
We're able to prepare the packets whether we are working in the data centre at 100 Gb/s or in the cloud through the different utilities that Azure provides or AWS or GCP.
And you need the same security tools the whole kind of built-on ability to receive packets. We receive the packets they need, the time they need, and process them.
So, it's kind of one thing that is not trivial to achieve essentially...especially when you talk about hybrid environments where the services might fire at 100 Gb/s in the data centre, but they might have some other services that they run in the cloud or even third-party services.
So, that's one thing that has to happen.
So, it's kind of a foundational capability to have any security solution.
The second part is really forensics.
So, once a tool identifies an anomaly and says, 'Okay, there is something weird here,' that you have to, you know, investigate further.
You basically escalate to level three or however they refer to it.
And that again, it's about going back to the packets and looking at what exactly happened.
And the ability to store the packets, again, [inaudible 00:07:16] including them and providing them back to the investigator is another critical part that we provide to them.
So, I would say we have a lot of partners with the security companies.
We're not necessarily a security company itself, but we'd certainly partnered with them to provide a complete solution as they go off to other customers.
And how is that, like what is the challenge in that? Like, for instance, you know, you had a blog post of that, that was really interesting, where you distinguished between events flows and packets, right?
The advantages and disadvantages or risks of each kind.
And I like the way you framed it, like tracking events is basically tracking known unknowns, you know?
Things you already know you should be looking for, and you put something in advance.
But it seems like actually being able to capture and analyse all of the packets is ideal, right? Then you have all the information in there, you know, the source of truth.
Why isn't that an approach that people do by default, you know? Why hasn't that been the case up till now?
Sure. The complexity is orders of magnitude more.
When you do flows, it's really about counting packets in a given time slot.
Time slots can be very short or can be very long.
And what you need to do is you can just run counters and you can implement it in a router or a switch, relatively cheaply.
Still, you know, it still takes some time, and people will revert to sampling and whatnot.
But at the end of the day, you need to keep two numbers.
In order to look at the packets, you need to do a lot more.
You have to actually analyse the packet for a longer time.
You have to keep things like the last acknowledgement that you're able to measure things like round-trip time.
You have to measure things like with transmissions.
That requires a lot more memory, a lot more resources, and a little more innovation in how you do things.
So, yeah, so I would say this is the main reason that people kind of reverted to lowest common denominator to reach our flows instead of investing in actually packet analysis.
So, you would see packet analysis for security tools. Security tools couldn't really...they didn't have an option.
They have to look at the packets.
But collecting packets in order to understand why a user calls and complains that something is slow or that he cannot connect or that the quality is poor was not there before or it's very little that they have that.
I guess that's the...we were kind of talking about with infrastructure that people don't notice it until it's not doing the thing they expect.
Yeah, the person who makes the trains run on time, you don't know he exists until the trains aren't running on time.
Yeah. And I'm amazed how if somebody does call, then the way that many, you know, very big and sophisticated companies do that, they have essentially like one guy in the company that they call him in for [inaudible 00:10:27] one.
And then he, you know, collects packets, here, there, and another.
And, you know, some black magic.
And after three weeks, he said, 'Okay, that's the solution.'
There is no, you know, many cases, I come in, there are no tools. There's no methodology.
It's very amazing how things work.
Yeah. No, I completely agree with that.
And I guess when in, you know, anytime you're, you know, selling or providing a new technology or solving a new problem, my experience at least has been the biggest competition is doing nothing (overlapping conversation).
Right, (overlapping conversation).
I love this thing.
This is great.
And then nothing, you know.
Do you see that...what is the mindset behind that and what is the consequence of that sort of approach when it comes to security and performance in this case?
Well, so, security, it's obvious.
We've just seen the big incident this...the last few weeks, right? That's....
So (overlapping conversation).
That's priceless, right? I mean, the damage that a security incident can do for you is priceless, right? Even in the current case, you know, nobody knows if they haven't left other bots there that will wake up in two years.
And then they will cause the damage, right? So, you basically really don't know what you don't know.
I think from what we are seeing more from the, you know, performance or user experience side is it manifests itself in many places.
So, for example, if you're trying to be an agile business and you're trying to introduce new services and more services, what you'll see from the organisation is a lot of friction because the people kind of make sure that what they know today stays the same.
So, they will say, 'Oh, I don't know if I can introduce it because I think our firewalls are too loaded.
So, I don't want you to introduce this new service until I run whatever.' Every time you're trying to be agile and introduce business faster or...new services faster, you get pushback from the operations because they don't know.
So, that's one thing that if you don't have feasibility, you just are very cautious and you slow down everything.
On the other hand, you know, you lose productivity, right? So, if you have a big hospital and you have doctors that wait for an x-ray and just, you know, give up and go to the next...either they stay there and lose time or they go to the next one because they're frustrated.
Or, you know, actually, the nicest thing I see that is very easy for us that we work a lot, again, with the financial trading companies and the old fellow latency, they know exactly because they can count at the end of the day how many trades failed because they failed to receive packets on time.
So there, it's measurable. And even there, it's interesting because we work with the service providers there and they need to increase the capacity of the [inaudible 00:13:21].
And so, they have their sales guy saying, 'Oh, I want more and more.' And the operations guy said, 'No, it's too expensive.' And, you know, they just stand there and like, 'Okay, I don't know.
Do I need to buy another one or don't need? Should I wait for the failures, you know?' And again, without data, you're just getting to these ever-going, you know, discussions without being able to move forward.
So, I would say it's both the loss of productivity if something does happen as well as just agility of the business as you plan and move forward.
Yeah. And as well as in the finance sector, you can often put a direct price tag on these things.
It makes it a little bit easier to talk about. But there's so many ways in which everybody suffers those [inaudible 00:14:00].
It's just that it's...
...harder to put a number on it, you know.
Yeah. I mean, at the end of the day, every business has something that you can think about it as transaction, right? If you're a hospital, that it's, you know, doctor's hours.
If it's a website, it's how many...how much time it takes you to, you know, go through the page and move to the next one.
So, most businesses at the end, well, they can think about a transaction.
And this loss of productivity if transaction takes too much, too much time or more time, and the frustration associated with that, is essentially what they benefit by actually investing in tools to give that feasibility.
Another side is churn.
I mean, and again, with financial services, it's very easy to see because their customers are also sophisticated. They can measure.
But we say it with service providers too, you know? People kind of get frustrated and, you know, things don't work.
So, they just jump to the next service provider because, you know, it's very easy.
And they hope that the next one would give them something less frustrating.
Yeah. I guess more and more services are being spread everywhere, right? That, you know, you....
They're literally called micro services even so they're, you know, on premise in different clouds.
How are you seeing companies dealing with that complexity that's basically emerging and growing now?
That's a good question.
So, I mean, I would say that for the most part, I see people taking advan-...I don't think they see this complexity.
I think it's a big advantage for them.
It's their ability to...for every little thing, they are able to choose from a multitude of offerings whether it's their own services or third-party services.
So, for the most part, it's an advantage.
Again, I think the big issue, it's the end where you bring it all together and somebody complains. And now, you have such a complex infrastructure and offerings that it's hard to pinpoint where the problem is.
But just from the pure advantage of today being able to get things from the cloud or service is a great opportunity for businesses.
That's something that in all aspects has been a challenge, you know, from managing data from, you know, like I said, networking is a challenge for many IT professionals.
Yeah. I started my tech career way back in the '90s in the middle of the dot-com bubble, you know.
I was very young and impressionable and didn't know what was going on, but coincidentally landed in the middle of like what was probably one of the most amazing periods of time, you know.
I'm thinking around that time, you were working at Qualcomm which I happened to go to university right next to where they were being founded.
Also very familiar.
But what I find interesting is how you basically see the same things repeating themselves, you know, even today.
Back then, it was, you know, networks, you know, TCP/IP networking and IP address.
And people would argue about token rings and all kinds of things we [inaudible 00:17:13] talk about it, and we were still using VHS tapes as well.
And then pretty soon, you know, the Mosaic browser came out, and it just...today, it's just not even talked about. It's online.
We don't even say (overlapping conversation) anymore. How do you see these cycles repeating themselves? Do you see some of the same things back then happening now, and in particular, in the areas where you're working in networking and securing the performance?
Yeah. I think it's...yeah, I mean, we're still dealing with the same problems.
It's just faster.
You know, last, you know, when I started having a few hundred kilobits per second modem, wireless modem was amazing, right? Now, we're talking 100 gig.
And as soon as we get to the 100 gig, people are asking us, 'Is there 400 gig?' So, yeah.
But I think, yes, we fundamentally try to solve the same problems which is the user experience at the end of the day.
Either it's too slow and they want it faster or, you know, the quality is not there and you get, you know, broken video or broken audio or [inaudible 00:18:25] are missing or it can't connect.
'Okay, I can't connect.' And, you know, that was true in 2000.
It's true today, right? It's like, oh, going to this website, it doesn't connect, and then....
So, I think that's the same, just faster.
And you have to build.
I would say the security is somewhat different.
I mean, I think, you know, when we started in 2000 or the late '90s, people realise all of a sudden that nobody in the...when they designed TCP/IP and the internet, they thought about security. And, you know, things started.
Today, the security attacks and the security protection is a lot more sophisticated than then.
But I would say from the fundamental of how you connect are the same problems, just faster.
I mean, and in a way, I think what I've learnt from that ever since then is that the technology is actually the easy part, you know.
Inventing the tech is, yeah, that's done in one year or something.
It's the...I think like what really is a challenge with adoption is trust, you know, just that people trust it.
Like, you know, back in the '90s, nobody could imagine paying a credit card using a credit card to pay for something online from a person you never met. And now, people do that.
They even, you know, their phone...they don't even know they're paying anymore.
It just happens automatically.
And then the other of course with the established people, the established powers that are threatened by the new technology, you know, the...I think the telephone companies were one at one time, you know.
In the music industry, you have record publishers, and then Spotify has kind of taken that over.
So, I think we'll see that with blockchain.
I mean, for instance, that the technology is actually kind of simple, you know, blockchain.
It sort of works.
There's a lot of trust has to happen.
And, you know, obviously, certainly there's some applications and things like that.
But it reminds me a lot of TCP/IP 25 years ago or something like that.
Are you seeing companies adopting or experimenting with these sorts of like new technologies that they're not quite sure what to do.
Have you seen this in practice?
Yeah, we certainly see...yes, absolutely, we see that.
I think it's trust. But also, the other thing is convenience.
I think once people enjoy the convenience, they will actually sacrifice a lot of the security, right? Nobody cares about privacy when they can post whatever on Facebook, right? So, to me, the technology is there.
It's really about making it simple to use and convenient.
So, that's a certain, you know, it's...again, if you're going to the simple PCMCIA card over the Wi-Fi, right, you had to be a geek to understand that part.
But now that you're open and Starbucks just connects you, everybody does that, right? So, I think that's where we're seeing today coming in.
If we go back to the no consumption kind of the other side is for the companies that introduce that, I think, you know, there is the technology to make things work.
There is the technology to debug things when they don't work and deploy tools that give you the visibility if things don't work.
And to me, the one exciting thing that is happening today is really of the AI machine learning that should take the tools not only help you figure out what's not working but also gives you the answer or at least an approximate answer of what went wrong.
Which will kind of take the tools to the next level, right? It's the tools should be easy for you to use, but you still...if you debug issues, you still have to be a pretty sophisticated user.
Being able to just tell, okay, here's what we think is wrong, and you just need to validate it is the next level.
And that's the next challenge from deploying technology to solve technology problems, right? Which is where cPacket is.
And actually, you mentioned big data.
That's a great one because that's also probably an enabler and an accelerator of this scale, you know.
The amounts of data that we're talking about are absurd, you know, they're unheard of before.
They always say that you'd see this sort of Gardner-type stats and say the last two years, more data has been generated than in all of history before it. And then the next year, you hear the very same thing again.
So, either by doubling in that time or, you know, it's [inaudible 00:23:07] and the technologies that come with it, you know.
Yeah. I mean, when we talk about 100 Gb/s networks, it's not only the speed.
It's also the amount of data that you have to sift through, right? One second generates 100 Gb, you know, that gigabyte of data.
That's one second.
And you're talking now a session that can take a day or [inaudible 00:23:30].
Many, many terabytes of data to sift through and find what the relevant data is.
Yeah, which is of course the business Nvidia is in now, you know. They launched a company like Nvidia, it's absolute (overlapping conversation).
And what's interesting too is that, you know, I know it's true too for me, but I'm a bit of a geek, but I think an individual person probably has as much or more data as an entire corporation did 15 years ago, you know.
So, some of these problems are becoming very personal, you know.
I'm still trying to...I'm trying to figure out why I have a hundred copies of the same file in my hard drive or my DropBox even.
I just have iCloud complaining that I'm exhausting my storage there and wants me to upgrade, yeah.
Yeah. And when you go in there, you're going to find, you know, oh, I actually made a backup copy of this directory four different times, you know.
Right. Actually, one of my early managers, I think maybe [inaudible 00:24:25] my first manager told me, 'Hey, you know, when my hard drive gets full, I know that it's time to upgrade.'
I never delete any e-mail.
It's like, yeah, that's probably time to upgrade your computer.
And I pretty much follow that.
I never delete e-mails because....
Oh yeah, it's....
Probably should just upgrade.
I mean, now, everything is in the cloud, so it's not even an issue, but....
Yeah. It's absolutely an archive now.
And it's true.
I'm kind of the same.
I don't delete anything, I don't even upgrade.
It just seems like Gmail seems to upgrade itself at the right moment, yeah.
Yeah, that's one of the things that change, right? You don't really keep your e-mail locally anymore.
You trust Google that it will be there when you need it and (overlapping conversation).
It's a matter of time I think before the technologies that we're working on become B to C, you know, become consumer technologies because, you know, it's just that they are doing [inaudible 00:25:19] digital lately.
Yeah. It's kind of, you know, you say, well, if it's the same.
Yeah, I think it is the same, but you also look on, you know, I obviously remember getting on an airplane and you had to have the paper ticket with you.
And if you lost, it was a big deal, right? Now, it's....
Yeah. I had that once.
Your phone and...yeah.
I actually packed my ticket into my suitcase by accident and checked it in, and then I couldn't get on the flight, you know.p>
That was [inaudible 00:25:46].
It was, what, less than 20 years ago, right?
For us, it looks like a short time.
I guess for our kids like, yeah, it's like what are you guys talking about? But I remember that.
Yeah. We had an interesting career path as well.
You started...you're from Israel, but you've now...you've been living and working in the US in Oregon in Portland for the last 20 years or so.
What's that been like? What's the difference working in Israel and the tech business and working in California...sorry, in Oregon? I'm California, biased myself [inaudible 00:26:19].
You know, what's the differences like? What has that been like for you?
Yeah. Actually, you know, I think people here start career at 18. After...at 18, I also had, you know, four years in the army, not touching computers at all, and another year hiking in South America. So, I also took the time to kind of get out of my system all of the other things you can do before you actually go and become an engineer.
Yeah. And then as I worked...actually, in Qualcomm, I was still in Israel.
And then I moved for Mobilian, which was a start-up in Portland and grew up here.
I think the difference is, actually, I see it even if I go from Portland, Oregon to California.
The intensity goes up.
I think people here in Portland have a much better work-life balance perspective of the world, you know, cycling, and people are much more laid back.
Every time, you know, I spend a lot of time, mostly sleeping, in Silicon Valley.
And I can feel the intensity goes up as I go there.
People are just....
And if I go back to Israel, when I go back to Israel, the intensity goes up even higher.
It's always funny to me when I fly to Israel.
It's kind of like so you fly east, you know, you stop in New York.
So, you know, if you go in Portland when you use to go to a restaurant and you ask for something, you know, there is a whole small talk before they ask you what you want.
You go to New York, they ask you what you want, right? And in Israel it's like why didn't you tell them already what you want, you know? It's like you feel the intensity, and it's everywhere.
So, it's, you know, when you buy something in the store and also when you, you know, kind of the speed of people going through and working and talking.
I find...well, in [inaudible 00:28:11] you know, basically grew up and worked in California.
Now, I'm in the Netherlands in Europe and I work a lot with Israeli companies as well.
And I can see that there is a difference like the West Coast US indirectness, you know.
Everything's great, everything's great, everything's great.
And then suddenly, something's not good, you know.
With Israel, everything's terrible, everything's terrible, everything's terrible.
Actually, everything's fine, you know? (Laughter)
I remember it's like, 'Oh, this desk is a mess.
You really need to move this mouse to here, you know.' And now, it's okay.
What if an Israeli colleague or customer or client says to me, 'It's not the worst,' I'd take that as a high compliment, you know.p>
(Laughter) 'I did it.' Yeah.
I've nothing to complain.
It's the highest...that's the highest you're going to get.
Yeah. And the other...I mean, may not be so much in Oregon as it is in California, but I find also that in the Silicon Valley, you're very much on the supply side of things, like the focus is on the technology and the technology-building.
And when you leave there, it's really on the customer and how the customer...what their needs actually are, you know.
So, have you seen that difference? Like if you get out of the centre of innovation, how does your...how do your interactions change with people?
I think even in Silicon Valley, I think people understand today that the user...it's going back to what we said before, which is the...is a few. So, even I think today in Silicon Valley, there's huge amount of investment in hiring design engineer and user experience engineers. And people I understand for the most part that if people cannot use your technology, they will not use it.
So, actually, I think in the last, whatever, five or maybe 10 years, the investment in user experience went pretty high.
And people do talk about it.
Successful or not, you know, you can argue, but they certainly try and put a lot of effort.
I think Apple basically exposed. They tried or educated everyone.
Because if you think about the iPhone, you know, I remember, you know, phones that you could touch years before the iPhone, right? It was the ability that you can actually use it that made the difference between the technology of a screen you could touch, right?
So, I think certainly I would say Apple showed people that it's...I don't know if it's all about user experience, but it's very important.
It's more than the technology.
And of course, when you are on the demand side of things, that's one thing I learnt.
When I moved to Europe, everybody was a customer, is that you have to sort out what the actual...you have to understand the actual problem they're trying to solve, and then figure out what technology comes in.
Whereas when I would go back to headquarters and spend a week, you know, you go out to a bar, and even in the bar, the conversation is about Linux or, you know, networking or something like that.
So, that's a very different approach, that.
Personally, I love being on the customer side of things and demand side.
Yeah. One big topic, and it's like a regular question that I ask everybody, because obviously, it's in our interest.
We're very much focused in this area that's called cloud native.
But I find that if I ask five people what cloud native means, I'll get 10 answers, yeah.
No one's really sure what it means.
It means, you know, I think it started out meaning exactly how it sounded, you know, everything's born in the cloud.
And then, you know, we became a specific thing around micro services.
And then, you know, as we go on, I think even that changes again, you know, what that means.
What does that term mean for you when you hear cloud native? What do you think of? And what should it mean?
Yeah. No, I can probably talk about that for a long time.
So, I think there are multiple ways to...so, most of our customers I would say, our big customers, are Fortune 500 companies that own their data centres, understand networking, invest a lot of both networks and servers in the data centre, and going through this transition to the cloud, right? So, a lot of that is probably painted from my experience working with our customers.
So, I think there is the time of the very technical level that says, 'Okay, I want you to take the applications that used to run and managing the data centre, and I want to take advantage of the cloud.' And then what does it mean? So, does that mean that you're going to just, you know, spin out a VM in the cloud and do the exact same? Or are you going to rewrite the applications to take advantage of something that is in the cloud? Or are you going to redesign your application to really rethink the application and start from, you know, the scale of the cloud and take advantage from there? So, even there, I see at least three grades.
And of course, there is a lot of radiance between the two, just thinking about the applications.
And then as you move things over to the cloud, you know, we're calling it Cloud Smart or I guess the technology.
It's like can I move everything? And if I can't move everything because regulatory or security or performance considerations or, you know, any set of reasons, what do I do with the things that stayed in the data centre, and how are they going to play?
That would be the second kind of thought process and technology challenge that they're going through.
And the third one is really this multi-service, multi-vendor environment, and what does that mean to my business and security and user experience and how all of that comes together? So, I'd say cloud native in the application space is really about are you just taking some advantage of not storing packets locally, but you're storing them on a [inaudible 00:34:31] or redesigning your application such that, you know, they take advantage from the ground up from the capability of the cloud.
But then, how these cloud native applications play in my overall user experience and what is it that I'm trying to do as a business is another aspect of thinking about what's going to the cloud, what doesn't go, how to think about the cloud, and how to work with that.
So, it's kind of one direction.
Another one specifically for us is really the networking.
So, a lot of companies that grew up on the cloud, I think they are used to run their business with [inaudible 00:35:08] and built...and they design their business such that they don't really know about the network.
And they let the network or the cloud provider own the network, and they kind of designed around it. What we see, again, for our customers is that that doesn't work for them.
Again, maybe they haven't designed the application correctly or maybe there is other good reasons.
And then when it got to the friction between the cloud provider and their application, it becomes tricky.
So, what is the information? What is the native information? What native information they provide back to AWS to solve their problem or GCP? And I've seen that we're seeing a lot of friction today where the cloud provider says, 'Well, it is what it is.' And then the customer is trying to get capture and provide them proof that it's not what they say it is.
And so, that's certainly a lot of friction that we received today just around the connectivity in the cloud and getting their services throughout in the cloud.
So, that's I would say the third thing that comes in mind in cloud native when you say cloud native.
Yeah, there's (overlapping conversation).
There is indeed a lot of complexities.
Every cloud provider has a different set of networking protocols or networking, you know, details.
And on [inaudible 00:36:22] of course, this is...really, if you're not in networking, you can easily underestimate how complex it can be.
Right. And that itself is exciting.
I mean, if your data centre is in Denver and you're in, you know, AWS on the West Coast, that's 20 millisecond that's just there.
And if you do it too many times, just because the way you design your application, all of a sudden, users are going to feel the latency.
Yeah. And of course....
So, it's beyond, you know, issues.
It's just sometimes really geography that you can do nothing about it if you haven't, again, designed your application to be cloud native or take into consideration both the nativeness and geography, right?
Yeah. And of course, even one action, the one thing that you do on the internet has like hundreds of processes underneath it that if each one of those is 20 milliseconds too slow, that adds up very quickly.
Yeah. Great. So, what are cPacket's plans going forward? So, are you guys very well-positioned? You have a, you know, basically a platform that enables anybody to kind of, you know, capture and know everything they need to know about their network? Looks like you're keeping up with the scale and the way thing are changing. Does cPacket have some interesting plans going forward in the coming year?
Yeah. No, I think it's kind of those back...so, we are always in the business of providing technology to solve technology problems.
So, a lot of the investment was around in the last three years was really to...and I think going back to the beginning of the discussion, you mentioned that a lot of the challenges we usually have is that people don't even know that they can use technology to solve technology problems, right?
So, it was about building tools that are easy to use, right? A huge amount of the...high-quality data was always there, but being able to show them a very simple dashboard or a workflow that can help them really quickly solve a problem was a lot of investment.
Going forward, it's really about taking all these amounts of data that we collect primarily from packet bays, complementing it for more with data from events or, you know, server.
Server KPIs is one thing.
But events from Syslab and others events and others correlate everything and provide them with I would say phase one, relevant alerts, phase two with the solution.
When we, you know, one of the things that people like us or, you know, tools similar to us say, oh, we can...they tell the customers, 'We can provide you alert.' And the first reaction we get is, 'I don't need more alerts.
I have 100,000 of these.
Don't provide me alerts.
It's not what I need.' But relevant alerts is very important.
And relevant alerts is pretty tricky because you can come in today to a network connected to them all.
You know, you have 100,000 transmissions on your network.
It's like, 'Well, nobody called me, so it's not a problem.
So, don't tell me about that.
If it's go to a level that somebody's going to call me, then I want you to tell me before it calls me.
But otherwise, I don't want to hear.' So, a lot of the investment we're doing today, and that's probably what was going to take a lot of our attention next year, is applying AI machine learning algorithms to understand what's relevant, right? What is the level by which is normal, and I can move on maybe, you know, in some maintenance cycle that will go back and fix it or maybe they not? But if I see everyday around noon that somebody's, you know, for whatever reason, the outlook server is being loaded, I can tell him, you know, in a week or in three weeks or in a month, somebody's going to call you around noon because something is going on there.
So, being able to understand what's going on, understand how it connects to actual humans and when he's going to get the call and alert ahead of time, that's the effort that we're putting in, right? So, it's not just giving them the right tools to be able to do the work on their own, but really guiding them through the problem and the solution before they even, you know, got the call, right? They basically don't want to get the call from someone.
Yeah. I like that approach, the...one of my favourite sayings is if everything's a priority, nothing's a priority.
(Laughter) So, you know.
Yeah. Using the...and of course, it's such an opportunity, right, the machine learning? I don't know if you have machine learning in mind and things like this.
But, you know, anything that's repetitive I think is also becoming a growing industry.
Yeah. No, absolutely. Machine learning, I mean, there are different ways you can go.
But certainly, machine learning and the scale.
So, a lot of what we're doing is moving some of the analytics engine we have today to the cloud such that we can scale it to that level, and really being able to absorb the huge amounts of data that we get today.
So, today, we deploy, you know, tens and hundreds of sensors in a network that can be on cloud or can be in the data centres, you know, riding at very high speeds, getting all this data. Sift through that to identify the one relevant alert a day is a very tough technical problem.
And making it simple, that's the hard thing.
Yeah. Well, that's great. I really appreciate the time because it is a topic we could probably go on for ages.
And I'm sure if in three months we can talk again, then there'll be new things even.
So, (overlapping conversation).
This is super interesting. I think it'll be interesting also for our viewers.
Obviously, we are focused on the users, you know, the...CloudNativeX is really about connecting also non-technical people to these topics because there's plenty of resources for developers out there.
But I think this context is something that's really important.
So, look forward to seeing much more from cPacket, and hopefully speaking with you again soon for an update.
Sure, thank you. It was great. It was a pleasure.
We should exchange more experiences from the '90s and early noughts. So, that's always fun to remember how technology worked then.
Yeah, a couple of old guys talking war stories. That's fun, man. (Laughter) Great. All right. Well, thanks very much, Ron. Take care.
Oh, thank you so much.
Yeah, and speak soon.