>> Hi, I'm Peter Burris and welcome to another Cube Conversation. We're broadcasting from our beautiful Palo Alto studios and this time we've got a couple of great guests from SWIM. And one of them is Chris Sachs, who's the founder and lead architect. And the other one is Simon Crosby, who's the CTO. Welcome to the Cube, guys. >> Great to be here. >> Thank you. >> So let's start. Tell us a little bit about yourselves. Well, Chris, let's start with you. >> So my name's Chris Sachs. I'm a co-founder of SWIM, and my background is embedded in distributed systems and bringing those two worlds together. And I've spent the last three years building software from first principles for its computing. >> But embedded, very importantly, that's small devices, highly distributed with a high degree of autonomy-- >> Chris: Yes. >> And how they will interact with each other. >> Right. You need both the small footprint and you need to scale down and out, is one thing that we say. People get scaling out in the cloud and scaling up and out. For the edge, you need to scale down and out. There's similarities to how clouds scale and some very different principles. >> We're going to get into that. So Simon, CTO. >> Sure, my name is Simon Crosby. I came this way courtesy of being an academic, a long time ago, and then doing startups. This is startup number five for me. I was CTO and founder at XenSource. We built the Xen hypervisor. Also at Bromium, where we did micro-virtualization, and I'm privileged to be along for the ride with Chris. >> Excellent. So guys, the SWIM promise is edge AI. I like that, down and out. Tell us a little bit about it, Chris. >> So one of the key observations that we've made over the past half decade is there's a whole lot of compute cycles being showered on planet Earth. ARM is shipping five billion chips a quarter. And there's a tremendous amount of computing, generating a tremendous about of data and it's trapped in the edge. There are physics problems, economic problems with back on it all to the cloud, but there's tremendous, you're capturing the functionality of the world on these chips. >> We like to say that if software's going to eat the world, it's going to eat it at the edge. Is that kind of what you mean? >> Yes. >> That's right. >> And you start running into, when you decide you want to eat the edge, you run into problems very quickly with a traditional way of doing things. So one example is where does your database live if you live on the edge? Which telephone pole are you going to put at your database node in? >> Simon: How big does this need to be? >> There are a number of decisions that are very difficult to make. So SWIM's promises, now, you have some advantages as well in that billions of clock cycles go by on these chips in between that work packets. And if you can figure out how to squeeze your software into these slop cycles between network packets, you can actually do, you actually have a super computer, a global super computer on which you can do machine learning. You can try and predict the future of how physical systems are going to play out-- >> Hence, your background in distributive systems because the goal is to try to ensure that the network packets are as productive as possible. >> Chris: Exactly. >> Here's another way of looking at the problem. If you count top down, it's reasonable to think of things in the future, all sorts of things, which have got computer and maybe some networking in them, presenting to you a digital twin of themselves. Where's the thing come from? >> Now, describe digital twin. We've done a lot of research on this, but it's still is relatively novel concept. GE talked about it. IVM talks about it. When we say digital twin, we're talking about the simulacrum, the digital representation of an actual thing, right? >> Of an actual thing. There are a couple of ways you can get there. One way is if you give me the detailed design of a thing and exactly how it works, I can give you all of that detail and maybe (mumbles) can help use that to find a problem. The other way is to try and construct it automatically. And that's exactly what SWIM does. >> So it takes the thing and builds models around it that are-- >> Well, so what do things do? Things give us data. So the problem, then, becomes how can I build a digital twin just given the data? Just given the observations of what this thing is seeing, what its sensors are bleating about, what things near it are saying. How can I build a digital twin, which will analyze itself, tell you what its current state is and predict the future, just from the data? >> All right, so the bottom line is that you've got, you're providing a facility to help model real world things that tend to operate in an analog way and turning them into digital representations that then can be a full member, in fact, perhaps even a superior member in a highly distributed system of how things work together. >> Yes. >> Got that right. >> A few key points is digital twins are in the loop with the real world. And they are in the loop with their neighbors, and you start with digital twins that reflect the physical world, but they don't end there. You can have physical twins. You can have digital twins of concepts as well and other higher order notions. And from the masses of data that you get from physical devices, you can actually infer the existence of twins where you don't even have a sensor. >> It's making it real. So you could have a digital. If you happen to be tracking all of the buses in downtown San Francisco, you can infer PM10 pollution as a virtual sensor on a bus. And then you can pretty quickly work out something which is a value to somebody who's trying to sell insurance, for example. And that's not a real sensor on every bus, but you can then compose these things, given that you have these other digital twins which are manifesting themselves. >> So folks talk about the butterfly effect and things like chaos theory, which is a butterfly affecting the weather in China. But what we're talking about is locality really matters. It matters in real systems. And it matters in computers. And if you have something that's generating data, more than likely, that thing is going to want its own data because of locality. But also, the things near it are also going to want to be able to infer or understand the behavior of that thing, because it's going to have a consequential impact on them. >> Correct, so I'll give you two examples of that. We've been using aircraft manufacturing facility. The virtual twin here is some widget which has an RFID tag in it. We don't know what that is. We just know there's a tag and we can place it in three ways because it gets seen by multiple sensors we triangulate. And then, as these tags come together makes an aircraft sub-assembly. That meaning of an aircraft sub-assembly is kind of another thing but the nearness, it's the locality that gets you there. So I can say all these tags came together. Let's track that as a superior object. There's a containment notion there. And suddenly, we're tracking will assemblies instead of widgets. >> And this is where the AI comes in, because now, the AI is the basis for recognizing the patterns of these tags and being able to infer from the characteristics of these patterns that it's a sub-assembly. Have I got that right? >> Right. There's a unique opportunity that is opened up in AI when you're watching things unfold live in that you have this great unifying force to learn off of, which is causality. It's the what does everything have in common? It's that data that you've lost through time. And what do you do when you have billions of clock cycles to spare between network packets? Well, you can make a guess about what your particular digital twin might see next. So you can take a guess based on what you're state is, what the sensors around you are saying, and just make a guess. Then you can see what actually happens. You see what actually happens. You measure the error between what you predicted would happen and what actually happened. And you can correct for that. And you could do that just add in an item. Just trillions of times over the course of a year, you make small corrections for how you think. Your particular system will evolve, whether it's a street of traffic light trying to predict when it's going to change, when cars are going to show up, when pedestrians are going to push buttons, or it's a machine, a conveyor belt or a motor in a factory, trying to predict when it might break down, you can learn from these precise systems that very specific models of how they're going to evolve and you can play reality forward. You learn a simulation. And you can play your own, predict your own future. >> And there's a very cool thing that shows up from that. So instead of say, let's take a city and all of its lights. Instead of trying to gather all that data from the city and go then solve a big model, which is the cloud approach to doing this, big data in cloud approach, essentially each one of these digital twins is solving its own problem of how do I predict my own future? So instead of solving one big model, you'll have 200 different insections all predicting their own future, which is totally cool, because it distributes well in this fabric of space CPU cycles and can be very efficient to computers. >> And a consequence of that is, again, you can get these very rich patterns that then these things can learn more from and each acting autonomously in individual as groups. >> Even more than that. There's an even cooler thing. Imagine I set you down by an insection and I said, "Write me a program for how this thing is going to behave." First of all, you wouldn't know how to do it. Second, there aren't enough humans on planet Earth to do this. What we're saying is that we can construct this program from the data, from this thing as it evolves through time. We'll construct the program, and it will be merely a learned model. And then you could ask it how it's going to behave in the future. You could say, "Well, what if I do this? "What if a pedestrian pushes this button? "What will the response be?" So effectively, you're learning a program. You're learning the digital twin just from the data. >> All right, so how does SWIM do this? So we know now we know what it is. And we know that it's using, it's stealing cycles from CPUs that are mainly set up to gather, to sense things, and package data up and send it off somewhere else, but how does it actually work? What does the designer, the developer, the operator do with SWIM that they couldn't do before? >> So SWIM is a tiny, vertically integrated software stack that does all, has all the capabilities you'd find in an open source cloud platform. You have persistence. You have message dispatch. You have peer-to-peer routing. You have analytics and a number of other capabilities. But SWIM hides that and it takes care of it, abstracts over what you need to do to, rather than thinking about where do you place compute, it's when you think "What is my model? "What is my digital twin? "And what am I related to?" And SWIM dynamically maps these logical models to physical hardware at run time and dynamically moves these encapsulated agents around as needed based on the loads and the demand in the network. And in the same way that-- >> In the events? >> Yes, in the events. And in the same way that you, if you're using Microsoft Word, you don't really what CPU core is that running on? Who knows and who cares? It's a solved problem. We look from the ground up and the edge is just one big massively, multi-core computer. And there's similar principles to apply in terms of how you maintain consistency, how you efficiently route data that you can abstract over and eliminate as a problem that you have to be concerned about as a developer or a user who just wants to ingest some data and get insights on how-- >> So I'm going to make sure I got that. So if I look at the edge, which might have 200, might have 10 thousand sensors associated with it, we can imagine, for example, level of complexity like what happens on a drilling platform on an oil field. Probably is 10 thousand sensors on that thing, all of these different things. Each of those sensors are doing something. And they're sending, dispatching information. But what you're doing is you're basically saying we can now look at those sensors that can do their own thing, but we can also look at them as a cluster of processing capability. We'll put a little bit of software on there that will provide a degree of coordinated control so that models can-- >> So two things. >> Build up out of that? >> So first off, SWIM itself builds a distributed fabric on whatever computer's available. And you can smear SWIM between an embedded environment and a VM in the cloud. We just don't care. >> But the point is anything you pointed at becomes part of this cluster. >> Yes, but the second level of this is when you start to discover the entities in the real world. And you begin to discover the entities from that data. So I'll get all this gray stuff. I don't really know what it means, but I'm going to find these entities and what they're related to and then, for each entity, instantiate when these digital twins as an active, essentially the things that microservice. It's a stateful microservice, which is then just going to consume its own real world data and do its thing and then present what it knows by an API or graphical UI components. >> So I'm an operator. I install. What do I do to install? >> You start a process on whatever devices you have available. So SWIM is completely self-contained and has no external dependencies. So we can run as the (mumbles) analytics box or even without an operating system. >> So I basically target swim at the device and it installs? >> Chris: Correct. >> Once it's installed, how am I then acquiring it through software development? >> Ultimately, in this edge world, there is, you've asked the key question, which is how the hell do I get ahold of this stuff and how does it run? And I don't think the world knows the answer to all these questions. So, for example, in the traffic views case, the answer is this. We've published an API. It happens to be an (mumbles), but who cares? Where people like Uber and Lyft or UPS can show up and say what's this traffic light can do in the future. And they just hit that. What they're doing is going for the insides of digital twins in real time as a service. That's kind of an interesting thing to do, right? But you might find this embedded in a widget, because it's small enough to be able to do that. You might find that a customer installs them in a couple of boxes and it just runs. We don't really care. It will be there, and it's trivial to run. >> So you're going to be moving it into people who are building these embedded fixtures? >> Sure. >> Yes. >> Sure, but the key point here is that I know you, particularly in the Cube, you're hearing all these wonderful stories about DevOps and (mumbles) and all this guff up in the cloud, fine. That's where you want those people to be. >> Don't call it guff (laughs). >> But at the edge, no (mumbles). There aren't enough humans to run this stuff so it's got to be completely automatic. It's got to just wake up, run, find all the compute, run ceaselessly, distribute load, be resilient, be secure, all these things that just got to happen. >> So SWIM becomes a service that is shipped with an embedded system. >> Possibly, or there is a potential outcome where it's delivered as software which runs on a box close to some widget. >> Or willed out as a software update with some existing manufacturers. >> In this particular case of traffic, we should be on 60 thousand insections by the end of this year. The traffic infrastructure vendor, the vendor that delivers the traffic management system, just rolls up an upgrade and suddenly, a whole bunch of new insections appear in a cloud API. And an UBER or a Lyft or whatever, it's just hitting that thing and finding out what they are. >> Great, and so but as developers, am I going into a SWIM environment and doing anything? This is just the way that the data's being captured. >> Simon: So we take data. >> That the pattern's being identified. >> Take data, turn into digital twins with intelligent things to say and expose that as APIs or as UI components. >> So that now the developers can go off and use whatever tools they want and just invoke the service through the API. >> Bingo, so that's right. So developers, if they're doing something, just hit digital twins. >> All right, so we've talked a couple. We've talked a little bit about the traffic example and mentioned being in an oil field. What are some of the other big impacts? As this thing gets rolling, what is it going to, what kind of problems is this going to allow us to solve? Not just one, but there's definitely going to be a network effect here, right? >> Sure, so the interesting thing about the edge world is that it's massively diverse. So even one cookie factory's different from another cookie factory in that they might have the same equipment, but they're in different places on planet Earth, may have different operators in everything else. So the data will be different in everything else. So the challenge in general with the edge environment has been that we've been very professional services centric people bring in (mumbles) people and try and solve a local problem and it's very expensive. SWIM has this opportunity to basically just show up, consume this gray data, and tell you real stuff without enormous amounts of semantic knowledge a priority. So we hae this ability to conquer this diversity problem, which is characteristic of the edge, and also come up with highly realistic and highly accurate models for this particular thing. I want to be very clear. The widget in chocolate factory A is exactly the same as the widget in chocolate factory B, but the models will be 100% different and totally (mumbles) at either place, because if the pipes go bang at 6 a.m. here, it's in the model. >> And SWIM has the opportunity to reach the 99.9% of data that currently is generated and immediately forgotten, because it's too expensive to store. It's too expensive to transport. And it's too expensive to build applications to use. >> We should talk about cost, because that's a great one. So if you wanted to solve the problem of predicting what the lights in Palo Alto are going to do for the next five minutes, that's heading towards 10 thousand dollars a month in AWS. SWIM will solve that problem for a tiny fraction, like less than a 100th of that, just on stranded CPU cycles lying around at the edge. And you have say, bandwidth and a whole bunch of things. >> Yeah, and that's a very important point, because the edge is, it's been around for a while. Operational technology. People have been doing this for a while, but not in a way that's naturally, easily programmable. You're bringing the technology that makes it easy to self-discover simply by utilizing whatever cycles and whatever data's there and putting a persistence, making it really simple for that to be accessed through an API, and ultimately, it creates a lot of options on what you can do with your devices in the future. Makes existing assets more valuable, because you have options in what you can do with it. >> If you look at the traffic example, it's the AWS scenario is $50 per month per insection. No one's going to do that. But if it's like a buck, I'm in. And you can do things, 'cause then it's worthwhile for UBER to hit that API. >> All right, so we got to wrap this up. So one way of thinking about it is, I'm thinking. And there's so many metaphors that one could invoke, but this is kind of like the teeth that are going to eat the real world. The software teeth that's going to eat the real world at the edge. >> So if I can leave with one thought, which is SWIM loosely stems from software and motion. And the idea is that teeth edge. You need to move the software to where the data is. You can't move the data to where the software is. The data is huge. It's immobile. And the quantities of data are staggering. You essentially have a world of spam bots out there. It's intractable. But if you move the software to where the data is, then the world's yours. >> One thing to note is that software's still data. It just happens to be extremely well organized data. So the choice is do you move all the not-particularly-well-organized data somewhere where it can operate or would you move the really well organized and compact? And information theory says move the most structured thing you possibly can and that's the application of the software itself. All right. Chris Sachs, founder and lead architect of SWIM. Simon Crosby, CTO of SWIM. Thank you very much for being on the Cube. Great conversation. >> Thanks for having us. >> Good luck. >> Enjoy. >> And once again, I'm Peter Burris. And thank you for participating in another Cube conversation with SWIM. Talk to you again soon.