 Live from Las Vegas, Nevada, it's theCUBE. Covering AWS re-invent 2016. Brought to you by AWS and it's ecosystem partners. Now here's your host, John Furrier. Welcome back everyone, we are here live in Las Vegas for Amazon re-invent 2016. This is SiliconANGLE, it's theCUBE, our flagship program where we go out to the events that expect the signal from the noise. I'm John Furrier, the founder of SiliconANGLE. Our next guest is a partnership between SnapLogic and Snowflake Computing. We have Ravi Darnacota, who's the head of Enterprise Architecture with SnapLogic. Welcome to theCUBE and Matt Glickman, Vice President of Product at Snowflake Computing. Guys, welcome to theCUBE. Thank you. Appreciate you coming on. Thank you. So talk about the partnership, take a minute to describe what you guys are doing together and the focus here at AWS re-invent. Then I want to get into the conversation of that everyone's trying to figure out right now. I got to start thinking of a holistic architecture to move to the cloud in a way that's not going to foreclose the benefits I want to get downstream. So let's talk about the partnership you guys are doing and then we'll dive in. Sure, I think the Snowflake and SnapLogic stories are so aligned from being cloud native, from bringing the cell service to data integration and getting to quick insights. That's why we have this great partnership now where we've aligned the products and SnapLogic has just announced a native connector to Snap to Snowflake, where you can do bulk uploads and do crowd operations in Snowflake. We help ingesting the data within Snowflake and of course deliver it to any of the BI tools. And the key thing that makes the partnership great is being built for the cloud natively and architectures that are built that way just can perform better than architectures that were ported from on-prem and moved into the cloud. Snowflake in particular, we basically took a completely different approach, separating compute, storage and metadata that allows you to basically only use the compute you need and be able to put all your users at the same data and then bring all the data with partners like SnapLogic into one place and then do analysis on it. So your premise then, Matt, is not to move the data around. Too much data in motion causes problems. It's the thing that everyone underestimates, just the complexity of doing it and the achieving consistency and making decisions on consistent data is the thing that at some point people gave up on because they didn't think it was possible to get the scalability and the concurrence you needed. At Snowflake, we basically, and this is one thing I saw when I maybe joined the company was that it was just fundamentally different. It allowed you to get all of your users on all of your data and maintain that consistency on those answers. So this weekend before I reinvent started, I asked a question to my Facebook friends. I said, well, I'm looking for some of my smart friends. They're like, yeah, you had two camps. Obviously the pro-Amazon camp, everything's great. Then you had the other camp. Well, no, they're going to screw you here. It's where it's going to be locked in. They're going to spend more money. It's not always that cheap. And so the debate will always rage on. My premise is that Amazon has a great architecture. So I'm very pro-Amazon or pro-Cloud in general. I love the building blocks approach. I think services and having things available through APIs and whatnot, winning formula, no doubt. But I think people don't pay attention is when they get in trouble. So the question, Matt, for you is, folks going to the cloud, where and specifically Amazon or others, what's the tripwires? Where's the hotspots? Where are the landmines? That they should look out for? It's a great question, John. And I think it really comes down to this notion of concurrency. People think about the cloud enabling all this compute that you can have and all these problems you can solve. But they underestimate what has to happen and be able to handle that concurrency. And the cloud allows you to scale up and scale down. But if you have to scale up to a very big architecture to handle the load you need, it could actually be expensive. If you actually can architect using what the cloud can offer and separate to only, you can dial up and dial down more importantly, then you get the concurrency and you actually get in a very cost-effective way. And that's the thing that a lot of questions- So that's the preferred outlook? Yes. So what's the architecture for that? What does that look like? And the key part of that architecture is being able to separate compute from storage, from metadata about that storage so that allows you to, when you dial up, you can basically dial up and be hot. You don't have to keep something big running all the time. I think that separation of the... People talk about the dial up, it's the dial down. We have lots of customers who literally dial down the system and literally only pay for storage when they're not using it. And storage is, as I know, that's three. It continues to drive down the price. And Snowflake is actually, we pegged our storage pricing to S3 pricing. So we have no spread on storage. It's all about compute. You passed that straight through. Passed that straight through. I mean, it's like a helicopter versus an airplane taking off. You want to go up and down fast, but you don't want to crash on takeoff or landing. And that's really kind of what you're getting at. Exactly, but you need an architecture that you need architectures that were built for the cloud to do this. Like, you know, I mean, maybe talk a little bit. And sure, yeah, I'd like to comment on the architecture for integration and how to bring that data into Snowflake, for example. So the way we're architected is by separating the design and the execution plane. So you're designing the cloud through a multi-tenant application that's hosted on Amazon's web services. But the execution is a lazy, late-time execution where you can either decide to execute this in the cloud, in the public cloud, or in your private cloud. And this actually helps you integrate on-prem data as well as the cloud data, bring it together, and then push it into Snowflake. The complexity around the different data formats, the different velocities that they're flowing, all handled by one platform, which is easy to use. Okay, so guys, take a minute to explain to the folks watching the relationship of the partnership, what you guys do, and what Snowflake does, and then a use case of a customer example so people can kind of visualize and understand when they might want to call you guys up or get involved. We'll start with SnapLogic. What do you guys do in the relationship? Who does what, and a use case? Sure, yeah, we can bring up the use case of the craft group. They're a media entertainment and event management company who run the Gillette Stadium and own the... Patriots, Patriots. Patriots, Patriots, Patriots. I'll need some tickets, too, by the way. This too, at least, is a season ticket holder, so. So yeah, so they bring in data from different data sources, like Tetheredata, MySQL, Salesforce, et cetera, and then use SnapLogic to bring all of that data in and push it into Snowflake through our native integration into Snowflake. So you do all the data analysis, data wrangling. The wrangling, the wrangling is the... Data ingestion, the wrangling, the transformations. Got ETL, that you're on the ETL side. But more ELT, so I think the difference is is that the data gets loaded and then you have this massive compute that you can spin up to do the transforms that get orchestrated by SnapLogic. But it's interesting, so there's use cases like that, the BI kind of use cases that just now scale. What we're finding is our customers want to basically now that they've aggregated this data in one place, they want to run their actual business on that same data. And that's the unique, that allows the data to actually be valid because you're actually using it every day as well as doing BI on it. And we have customers like Localytics, also out of Boston, who have massive trillion-row tables that they can actually do live queries on while they're actually doing data science other things on that same data set and allowing that to really scale. I mean the scale on the data is ridiculous. You heard the guy on stage today, trillions of rows, all this is going to happen. The question that you're bringing up really goes down to what Peter Burris has been talking about at Wikibon is putting data to work. That putting that data to work is about the value creation once you get it all organized. So what you're saying, Matt, is you got to kind of get it all kind of, I don't want to say data leaks, that implies it's just not doing anything, set up an addressable, and then putting it to work in the applications. And that's exactly what they were trying to do was within their stadiums, they were trying to extract data from their fans and optimize their experience within that stadium and how to interact with them, give them promotions and so on and so forth. So extracting data from their CRM systems from live interactions that are happening around the kiosks in the stadium and then do some analytics and behavioral decisions. An analytics is like three things. What happened in the past, what's happening now, what's going to happen in the future. So here's my question for both of you guys. Given this great conversation, by the way, I love it. Now let's take it to the next level. IoT and real-time are really hot. So if you go down what Matt was saying about, you decouple everything, they're optimized, then you can manage what you do with compute, you can manage what you do with the data. So some are saying is David Floyd, Wikibon, it's a big proponent of, you move compute to where the data is. A lot of people think that's the way to go, so I don't. So real-time's another one. How do you get stuff in memory? That's the combination of metadata. Thoughts on this is because this is a real area because people want to know what's happening now. If you're at Chilette Stadium, I want to change the prices of braiders. He's just won his 200th game. John, the funny thing about integration is that when you go in an enterprise, you have one of everything and so you have to retrofit that into whatever is already existing. So we provide the flexibility to do either a batch type, look back and then do analytics on that, or real-time by connecting to some of the real-time streaming engines or do predictive analysis. But we're the plumbers. So we bring in data in any one of those types of data that you want to move data in. And the interesting thing then on top of that is when you get those real-time streams in the machine-generated data, it's typically semi-structured data. In Snowflake, we can ingest that semi-structured data without transforming it and query it because we literally transform it behind the scenes into columnar form, so you don't have to transform that IoT data. You just stream it in. You're doing that on the fly. We're doing it on the fly. While it's streaming. So no separate process. And less copies of the data, again. But that is the key. Consistency, concurrency, and minimizing data movement. So what's on the product roadmap is Snowflake because a lot of customers kind of want to see that trajectory of kind of anticipating the headroom of what's next, it's like a car. They start with wheels and a motor, then you get windshield wipers, then you get power windows, air conditioning. We're in the early days still. Where are we now on that? You touched on one of them. I mean, streaming is making streams be something that can be, today you have to be thinking about having a compute cluster to receive that stream. Tomorrow you won't, right? We'll just hook up to the Kinesis Kafka Streams. Data comes in and we'll figure out the right interval to pull that data in and allow you to transform on the way in with orchestration on what you want to do with that data. Just have it come in in massive streams. So what you're saying basically if I read you correctly is in the future the scarce resource will not be compute. I'm sorry, in the future compute will be so small and addressable, small in terms of form factor, but everywhere it's going to be the data that's the problem. It has to be. Because data is going to be the constrained area that you've got to be optimized for. That's right, for all the different data formats, the different ways it comes through and integrate that with whatever is existing that becomes a challenge. And all right, so where does this partnership go next? What's next? Go get customers and you guys going to market together? Yeah, I mean, getting more customers, more data sources, having data move less. You know, one of the things that's also on our roadmap is minimizing data movement between organizations. Like one of the things that still is a pain point is that if you provide data to your partners, you have to export it and reload it, right? That's one thing that the cloud enables where you literally you can basically say this data set, you know, and a snap logic could know by this data set and basically provide it as a virtual copy. Again, minimizing movement as data grows, you want to find ways to minimize data movement. And Ravi, quick, final comment, snap logic, any guiding principles or advice you'd want to share with folks, big picture, what they should be thinking about? Yeah, one of my colleagues here just gave a great analogy. When people are thinking about modernizing, they're not just picking out the small pieces and changing that. They usually think about it from a larger standpoint. You cannot just change your applications and not think about the plumbing that goes along with it. And that's what snap logic provides in a flexible, easy to use interface. So when you're thinking about going to the cloud and putting on all these different cloud applications, you got to think about the plumbing that supports that as well. Great, great for coming on theCUBE. Guys, great conversation. Again, I think it's very early on, but I think architecturally, this is one of those big decisions people got to make is how do you look holistically at your resources, minimize the complexity, decouple things, make them highly cohesive? Sounds like a good plan to me. And get to the insights quickly. Congratulations. Yes, thank you. Snap logic, snowflake computing here inside theCUBE. I'm John Furrier, back with more live coverage after this short break, day two of Amazon web services. Three days of coverage. I'm John Furrier.