 on the ground. Presented by theCUBE, here's your host, John Furrier. Hello everyone, welcome to the CUBE's on the ground segment here. I'm John Furrier, the host of theCUBE. We are at the IBM Open Computing Architecture Summit. I'm here with Dr. Sarah Cooper, the machine to machine intelligent course. Welcome to on the ground. Good to see you. Good to see you too. So a lot of rage on big data for the years, but now more than ever AI machine learning, it's the front lines of all the conversations, certainly hyped up beyond all recognition, but it's relevant. And so IOT right around the corner, all these unknown processes are coming that need to be automated, but yet no one knows how to automate them because all this unknown stuff happening. How are you guys seeing this big trend? Because this is some people scratching their heads on right now. There are a lot of folks scratching heads. There's a lot of, you got it right, with the unknown unknowns. You've got a ton of data coming in. Most of it is very low value. Healthy, I'm still healthy. I'm still healthy is irrelevant for most of the conversation. So there's an incredible amount of intelligence that goes into filtering and determining what is actually valuable data and getting that up into the decision and interpretation tools like the big data, the machine learning, Spark, some of the streaming analytics as well, and figuring out what questions you wanna ask today versus what questions you wanna ask next week or in five years is dramatically complex in the internet of things. That data goes from being really fresh as it's coming off the devices and valuable for making automation and closed loop decisions, but then as at ages, you're looking more at historical and predictive training models for some of that machine learning. What's interesting is that, we were talking about on our Cube segment a couple of weeks ago that the old days, client server days, you had known processes and unknown technologies. You put together to automate those known processes, HR, accounting, CRM, et cetera, et cetera. There it is. Now you have all these unknown processes and known technology. So the question I always get is, what do I do I'm an architect? I got to figure out an architecture that's going to enable me to take advantage of what might be around the corner, but yet I don't want to foreclose myself into it because the answer in the old sensor world was, I'm going to just have a vertically integrated stack. I'm going to maybe connect to IT, but I don't want to because those guys are different than I am. So you have the collision. We have collision between these two cultures of ops, edge, sensor, meets data. How does someone in IT build an architecture? I mean, what are you seeing as a step forward best practice? It's a big challenge. One of the reasons is that device vendors and manufacturers have shipped devices with an existing architecture, which is built around a device where the margins have been pushed down. So of course they want to sell you the analytics package. If you're a farmer and you've got one nitrogen sensor out in the field giving you an analytics package, that's not useful. You need an analytics package that's pulling in all of the sensors in that field and potentially publicly available data about weather, about historical tomato respiration. All of that information coming into one place is a very different architecture from the one device to one app. So that democratization of data layer is something, there are a lot of platforms out there. They're starting to move into that. You see a lot of vendors who have had strong data platforms trying to figure out how to pull in all of that machine data. And I think an architect needs to turn around and say, what are the key components? What are the key connectivity components, the security components, the ways I'm going to parse this information? And then how can I build them loosely coupled? So that way as maybe the next version of Spark is better than today, you can switch them out and you're kind of future-proofing your architectural and containers are a great way. So decouple and highly cohesive functional components, basically? Yeah, functional is the right word. The sort of functional equivalence of saying, hey, I need to filter. You can do that at a firewall, you can do it at the data layer, you can do it on a server, you can do it on a router. That filter function is what you need to write to, not the specifics of an architecture. So one of the things we were saying, we were just at HP Enterprise Discover and they had some IoT stuff. And one of the things I was saying was, oh, the iPhone was a great invention because it was a computer that had software that makes phone calls. Not a phone that has software to do text messages and do email, which was the old phones and iPhone is history. Now the premise is a data center that happens to have software that runs an edge device. So the form factors of data center power is getting smaller and smaller. So how is that going to change in your view? Because now machines are very powerful. Now you can have policy, you can have some software, but ultimately you don't want to rewrite software at the edge if the form factor is not built. So do you see a trend where new devices are coming out that are being deployed at the edge, almost like a data center? Absolutely. There's a company out there called Resin.io that's putting containers on embedded Linux so that you can do hot swap of applications on your endpoint. And that type of functionality pushes the DevOps model that we're all been talking about in the data center down towards the edge. And now you've got all of your IT guys who can move into IoT without the huge learning curve. And the more tools that kind of extend out, frankly, the better we all are in such a complex environment. We need that cohesiveness across not just day one deployment, but the entire operation scale. And that actually eliminates a lot of the running around that ops has to do. So that's- The big philosophical question is, do I move data around or do I put the compute to the data? Your thoughts? You have to move some data around. A single device only has perspective of its information. It doesn't know what its neighbors are doing and so its ability to interpret data is limited. You can ship a certain amount of context between devices, but that's very expensive, frankly. So there needs to be some centralization. It doesn't need to all get sucked into a cloud somewhere you can make intermediate decisions about the value of information and be able to dynamically determine, do I have a discrete set to make a decision here, or do I need to move up into the network or into the cloud? So that's really a function of the beauties in the eye, to behold, or it depends on the situation. So if you're an oil rig, maybe you might have a lot of gear out there or if you're a little device on the edge, you know, trickle data back. So it's a mix. It is absolutely a mix. And oil and gas is an excellent example. You've got, you know, drill heads that need 20 microsecond turnaround times for automation. That has to be done at the drill. That can't be done. We don't have the latency characteristics to do that back there. Final question, what do you think about IBM's open cloud architecture summit here? What's this all about? Helps the industry, what's your thoughts on how the openness changes the game? Obviously, security is a concern, more surface area? More surface area, I think with, again, the complexities and the heterogeneity and IoT opens the only way to go. It's the only way to pull all those pieces together and to leverage the workforce that is the open source community, particularly when you start combining things like hybrid and IoT, which we're talking about today. That's not something that anybody wants to go rebuild the proprietary solution around. So I think it's, you know. Sarah, thanks for sharing your insights here on the ground. I'm John Furrier. We're here on the ground at the IBM Open Compute Summit here, getting all the data, sharing that with you. Thanks for watching.