Simon Crosby, SWIM.AI | theCUBE on Cloud 2021
>>from around the globe. It's the Cube presenting Cuban cloud brought to you by silicon angle. Hi. I'm still Minuteman. And welcome back to the Cube on Cloud. Talking about really important topics is toe how developers we're changing how they build their applications where they live. Of course. Long discussion we've had for a number of years, you know? How do things change in hybrid environment? We've been talking for years. Public cloud and Private Cloud and really excited for this session. We're gonna talk about how edge environment and ai impact that. So happy to walk back. One of our cube alumni, Simon Crosby, is currently the chief technology officer with swim. Got plenty of viewpoints on AI the edge and knows the developer world. Well, Simon, welcome back. Thanks so much for joining us. >>Thank you, sir, for having me. >>All right. So let let let's start start for a second. Let's talk about developers, you know, used to be, you know, for for years we talked about, you know, what's the level of abstraction we get? Does it sit? You know, you know, do I put it on bare metal? Do I virtualized it? Do I contain Arise it. Do I make it serve? Ellis? Ah, lot of those things. You know that the app developer doesn't want to even think about. But location matters a whole lot when we're talking about things like a I where do I have all my data? That I could do my training? Where do I actually have to do the processing? And, of course, edge. Just changes by orders of magnitude, Some of the things like Leighton see, and where data lives and everything like that. So with that as a set up would love to get just your framework as to what you're hearing from developers and what will gettinto Some of the solutions that that you and your team are helping them toe do their jobs >>where you're up to lights to the data onslaught is very riel. Companies that I deal with are facing more and more real time data from products from their infrastructure from their partners, whatever it happens to be, and they need to make decisions rapidly. And the problem that they're facing is that traditional ways of processing that data or to so so perhaps the big data approach which by now is a bit old. It's been long in the tooth, Um, where you stored it and then you analyze it later is problematic. First of all, data streams of boundless so you don't really know winter analyze. But second, you can't store all. And so the story and analyze approach has to change and swim is trying to do something about this by adopting a process off. Analyze um, on the fly. So as dead is generate as you receive events, you don't bother Saw them. You you analyze them, and then if you have tow you still the data. But you you need to analyze as you receive data. Andre react immediately to be able to generate reasonable insights or predictions that can drive commerce and decisions in the real world. >>Yeah, absolutely. I remember back, you know, the early days of big data, you know, real time got thrown around a little, but it was usually I need to react fast enough toe. Make sure we don't, you know, lose the customer, we react toe something. But it was we gather all the data and let's move compute to the data. Uh, today is you talk about real time streams are so important. We've been talking about observe ability for last couple of years to just really understand the systems and the outputs More than, uh, looking back historically at where things were waiting for alerts. So could you give us some examples, if you would, Is toe You know that those streams, you know what is so important about being able to interact and leverage that data when you need it? And, boy, it's great if we can if we can use it then and not have to store it and think about it later. Obviously, there's some benefits there because >>every product nowadays has a CPU, right? And so there's more and more data and just let me give you an example. Um, swim processes real time data from more than 100 million mobile devices in real time, Um, in for a mobile operator. And what we're doing there is We're optimizing connection quality between devices and the network. Now that volume of data is more than four petabytes per day. Okay, now there is simply no way you could ever store that and analyze it later. The interesting thing about this is that if you adopt and analyze. And then if you really have to store architecture, you get to take advantage of Muslim. So you're running at CPU memory speeds instead of a disc speed, and so that gives you a million fold speed up. And it also means you don't have the Leighton see problem off reaching out to her boat storage, dead base or whatever. And so that reduces cost so we can do it all about 10% of the infrastructure that they previously had for her do style implementation. >>So maybe would help if we just explain when we say edge, people think of a lot of different things. Is it? You know, on I o. T device sitting out into the edge Are we talking about the telecom edge? We're watching a WS for years, you know, Spider out their services and into various environment. So what when you talk about the type of solutions you're doing and what your customers have is that the Telkom edges that the, you know, actual device edge, you know, where where does processing happen and where do these, you know, services that that work on it live? >>Uh, so I think the right way to think about edges. Where can you reasonably process the data? And it obviously makes sense to process data at the first opportunity you have. But much data is encrypted between the original device. Say Onda. The application and so edge as a place doesn't make as much sense as edge as an opportunity to decrypt and analyze data in the clear. So is computing is not so much a place in my view as the first opportunity you have to process state in the clear and to make sense of it. And then edge makes sense in terms of Leighton, see, by locating compute as close as possible to the sources of data, um, to reduce latency and maximize your ability to get insights. You know, Andre return to uses in, you know, quickly. So edge for me often is the cloud >>excellent. One of the other things I I think about back from, you know, the big data days or even earlier It was that how long it took to get from the raw data to processing that data, to be able to getting some insight and then being able to take action. Uh, it sure sounds like we're trying to collapse That completely. Is that you know, how do we do that? You know, Can we actually, you know, build the system so that we can, you know, in that real time continuous model that you talk about, You know? So what character movements? One >>of the wonderful things about cloud computing is that two major abstractions really served us on. Those are rest which expect this computing and databases and rest means in the old server can do the job for me. And then the database is just a napi I call away. The problem with that is that it's desperately slow. So when I say desperately slow, I mean, it's probably thrown away the last 10 years, Um, was law. Just think about this way. Your CPU runs at gigahertz and the network runs at milliseconds. So by definition, every time you reach out to a data store, you're going a million times slower than your Cebu. That's terrible. It's absolutely tragic. Okay, so a model which is much more effective is to have and in memory, computing architecture er in which you engage in state will computation. So instead of having to reach out to a database every time to update the database and whatever you know, store something and then fetch it again a few moments later when the next event arrives. You keep state in memory and you compute on the fly as data arrives and that way you get a million times speed up. You also end up with this tremendous cost direction because you don't end up with as many instances having to compute by comparison. So let me give you a quick example. If you go to a traffic dots from the AI, you can see, um, the real time state off the traffic infrastructure in Palo Alto. And, um, each one of those, um intersections is predicting its own future. Now, the volume of data from just a few 100 lights in Palo Alto is about four terabyte today. And sure, you can deal with this in AWS Lambda. There are lots and lots of servers up there. But the problem is that the end to end per event leighton see, is about 100 milliseconds. And you know, if I'm dealing with 30,000 events a second, that's just too much so solving that problem with a stateless architectures is extraordinarily expensive. You know, more than $5000 a month. Where is the staple architectural? Which you could think of as an evolution all for, uh, you know, something reactive or the actor model, Um, get you, You know, something like 1/10 of the cost. Okay, so cloud is fabulous for things that need to scale wide, but a state formal is required for dealing with things which update you rapidly or regularly about their changes in state. >>Yeah, absolutely. I You know, I think about if we were talking, I mentioned before AI training models often, if you look at something like autonomous vehicles, the massive amounts of data that it needs to process, you know, has to happen in the public cloud. Um, but then that gets pushed back down to the end device. In this case, it's a car because it needs to be able to react in real time and get fed at a regular update. The new training algorithms that that it has there. Um what are you saying? You know, we >>were reviews on on this training approach and the science in general, and that is that there aren't enough the scientists or no smart people to train these algorithms, deploy them to the edge and so on. And so there is an alternative worldview, which is a much simpler one, and that is that relatively simple algorithms deployed at scale to staple representatives. Their school, you know, digital twins off things, um, can deliver enormous improvements in behavior. Um, as things learn for themselves. So the way I think the at least this edge world gets smaller is that relatively simple models off things will learn for themselves for their own futures based on what they can see and and then react. And so this idea that we have lots and lots of very scientists dealing with vast amounts of information in the cloud, Um, it's suitable for certain algorithms, but it doesn't work for the vast majority of our applications. >>So where are we with the state of what the developers need to think about? You mentioned that there's compute in most devices. That's true, but you know they need some special in video chip set out there. Are there certain programming languages that that you're seeing more prevalent? Yeah, you know, interoperability. Give us a little bit of toe, you know, some tips and tricks for for those developing >>super so number one a staple architectures is fundamental and sure react is well known. Andi, there are, For example, on er lang swim is another. So I'm going to use some language. And I would encourage you to look at Cem O s or G to go from play there. A staple architecture, ER which allows actors small, concurrent objects to Stapley evolve their own state based on updates from the real world is fundamental. But the way in swim, we use data to build these models. So, um, these little agents for things we call them Web agents because the object I'd is a your I, um they staple evolved by processing their own real world data safely representing it. And then they do this wonderful thing, which is build a model on the fly, and they build a model by linking to things that they're related to. So a knit section would link to all of its sensors. But it would also licked all of its neighbors because the neighbors and linking is like a sub in pubs up and it allows that Web agent then to continually analyze, learn and predict on the fly. And so every one of these concurrent objects is doing this job off and analyzing its own raw data and then predicting from that and streaming the results so and swim you get stream board data in. And what streams out is predictions. Predictions about the future state off the infrastructure, and that's a very powerful staple approach, which can run all the memory. No stories required, by the way. It's still persistence. If you lose the no, you can just come back up and carry on. But there's no need to store huge amounts of raw data if you don't need it. And let me just be clear. The volumes of raw data from the real world are staggering, right? So for Porter by today from Palo Alto. But Las Vegas, about 60 terabytes today from the traffic lights, Um, no more than 100 million mobile devices is is tens of petabytes per day, which is just too much the store. >>Well, Simon, you'd mentioned that we we have a shortage when it comes to data scientists and the people that could be involved in those things. How about from the developer side? Do most enterprises that you're talking to? Do they have the skill set? Is the ecosystem mature enough for the company take involved? Or what do we need to do? Looking forward, toa help companies be able to take advantage of this opportunity. >>Yeah, So there is a huge change in terms of, I guess just cloud native skills. Um, and this is exacerbated. The more you get out into, I guess what you could think of as traditional kind of companies, all of whom have tons and tons of data sources. So we need to make it easy and swim tries to do this by effectively using skills of people already have Java or JavaScript and giving them easy ways to develop, deploy and then run applications without thinking about them. So instead of finding developers to notions of place and where databases are and all that sort of stuff, if they can write simple, object oriented programs about things like intersections and push buttons, a pedestrian lights, and in road loops and so on and simply relate basic objects in their world to each other, then we let data build the model by essentially creating these little concurrent objects for each thing, and they will then link to each other and solve the problem. We end up solving a huge problem for developers to which is that they don't need to acquire complicated cloud native skill sets to get to work. >>Well, absolutely. Simon, that's something we've been trying to do for a long time. Is to truly simplify things. I wanna let you have the final word. Uh, if you look out there, uh, the opportunity that challenge in the space, what final takeaways would would you get our audience? >>So very simple. If you adopt a staple competing Achter should like swim, you get to go a million times faster. The applications always have an answer. They analyze, learn and predict on the fly, and they go million times faster. They use 10% less. No. So 10% off the infrastructure of a store than analyze approach. And it's the way of the future. >>Simon Crosby. Thanks so much for sharing. Great having you on the program. >>Thank you too. >>And thank you for joining. I'm stew Minuteman. Thank you. As always for watching the cube. Yeah,
SUMMARY :
cloud brought to you by silicon angle. gettinto Some of the solutions that that you and your team are helping them toe do their jobs It's been long in the tooth, Um, where you stored it and then you Make sure we don't, you know, lose the customer, we react toe something. And then if you really have to store architecture, the Telkom edges that the, you know, actual device edge, you know, where where does processing the first opportunity you have to process state in the clear and you know, build the system so that we can, you know, in that real every time to update the database and whatever you know, store something and the massive amounts of data that it needs to process, you know, has to happen in the public cloud. Their school, you know, digital twins off things, Yeah, you know, interoperability. And I would encourage you to look at Cem O s or G to How about from the developer side? I guess what you could think of as traditional kind of companies, all of whom I wanna let you have the final word. Achter should like swim, you get to go a million times faster. Great having you on the program. And thank you for joining.
SENTIMENT ANALYSIS :
ENTITIES
Entity | Category | Confidence |
---|---|---|
Simon | PERSON | 0.99+ |
Simon Crosby | PERSON | 0.99+ |
Palo Alto | LOCATION | 0.99+ |
10% | QUANTITY | 0.99+ |
Las Vegas | LOCATION | 0.99+ |
Java | TITLE | 0.99+ |
today | DATE | 0.99+ |
JavaScript | TITLE | 0.99+ |
first opportunity | QUANTITY | 0.99+ |
AWS | ORGANIZATION | 0.99+ |
million times | QUANTITY | 0.99+ |
Telkom | ORGANIZATION | 0.99+ |
Ellis | PERSON | 0.99+ |
One | QUANTITY | 0.98+ |
second | QUANTITY | 0.98+ |
about 100 milliseconds | QUANTITY | 0.98+ |
WS | ORGANIZATION | 0.96+ |
about 60 terabytes | QUANTITY | 0.96+ |
more than $5000 a month | QUANTITY | 0.96+ |
each one | QUANTITY | 0.96+ |
Leighton | ORGANIZATION | 0.95+ |
First | QUANTITY | 0.95+ |
30,000 events a second | QUANTITY | 0.94+ |
stew Minuteman | PERSON | 0.93+ |
each thing | QUANTITY | 0.93+ |
two major abstractions | QUANTITY | 0.93+ |
100 lights | QUANTITY | 0.92+ |
about four terabyte | QUANTITY | 0.92+ |
Cuban | OTHER | 0.91+ |
more than 100 million mobile devices | QUANTITY | 0.91+ |
tens of petabytes per day | QUANTITY | 0.9+ |
a million | QUANTITY | 0.89+ |
Cube | ORGANIZATION | 0.89+ |
SWIM.AI | ORGANIZATION | 0.89+ |
no more than 100 million mobile devices | QUANTITY | 0.89+ |
last couple of years | DATE | 0.82+ |
more than four petabytes per day | QUANTITY | 0.82+ |
a second | QUANTITY | 0.82+ |
Muslim | ORGANIZATION | 0.8+ |
edge | ORGANIZATION | 0.79+ |
a million times | QUANTITY | 0.79+ |
years | QUANTITY | 0.77+ |
Cloud 2021 | TITLE | 0.75+ |
Andre | PERSON | 0.75+ |
tons and tons | QUANTITY | 0.74+ |
last 10 years | DATE | 0.74+ |
1/10 | QUANTITY | 0.73+ |
data | QUANTITY | 0.68+ |
Cebu | COMMERCIAL_ITEM | 0.68+ |
few moments later | DATE | 0.67+ |
Lambda | TITLE | 0.63+ |
Porter | PERSON | 0.56+ |
Achter | ORGANIZATION | 0.56+ |
cube | ORGANIZATION | 0.55+ |
Cem O | TITLE | 0.53+ |
Minuteman | ORGANIZATION | 0.53+ |
lots | QUANTITY | 0.45+ |
G | TITLE | 0.45+ |
theCUBE | ORGANIZATION | 0.4+ |