Adam Gross - Cloud Connect, 8 8 2013

Alright, next up we have Adam Gross, cloudconnect.com, and Adam's gonna be demoing his new product that integrates MySQL or Postgres and Salesforce in a bi-directional sync. Do you wanna do this now? We'll do it, we'll do it. Do it at the end, okay. You gotta stick around to the end to get the end. Okay. 14 seconds to make my Mac happy. I would like to mirror these, please. Will that work? Break the monitor? We don't really like that, do we? Okay. Well, thank you everyone for taking some— did I break something? This is my product. It's called the Matrix. Imagine, if you will. What's the line from The Matrix? What does it say? Give me the blue pill. This is more exciting than Matrix. Thank you, everybody, for taking the time to learn about Cloud Connect. Quick kind of room survey. How many people would consider themselves developers? Ooh, you guys are in luck. You came to the right place. How many of you know SQL? How many of you love SQL? OK, that's close. Come on. You don't love SQL? Maybe you'll love Sequel by the end of the presentation. That's me wearing half of a suit and uncharacteristic pose. I'm a former Salesforce guy. I was also at Dropbox. Take those two things together, what do you get? You get Cloud Connect. Because what are we doing? We're doing sync for your Salesforce data. I spent a lot of time in the SaaS space. And I've been delighted to be part, along with many people, in helping organizations and individuals be more productive and successful by virtue of being able to employ SAS. However, there's kind of this one issue, which as you can see from the slide, I like to say working with your data in SAS, it's kind of like putting something for drawing mittens. It's possible, right? But you always get that sense that you're just kind of fumbling around it and like, You don't quite have the right tool and you're kind of spacewalking a little bit, you know, and that can be very frustrating and can ultimately hinder your adoption and deployment of SaaS and all the awesome things that you might otherwise be able to do. And one of the things that's gratifying, I'm very much a developer guy, I'm very much a tools guy. This is an AppDev discussion, my apologies if that's boring. I'll try to make it interesting. One of the things that's kind of going on out there that's exciting exciting is this resurgence of SQL. And there's, right, everyone talks about big data, everyone talks about information, all this stuff is changing the world, right? But for as much new data processing technologies that we have and new ways of interacting and working with data, what's kind of now happening in the second wave is the resurgence of SQL. So if any of you worked on like big data projects with the dupe or things like that, you might be You're familiar with projects like Hive, which put a SQL layer around Hadoop, make it much easier to interact with that data. You know, why do, why are all these people so interested in SQL? Well, we know that databases themselves can scale to, relational databases scale to handle the most, the biggest and most complex problems, right? They basically run the world. SQL itself, I'd argue, is the most commonly known development language. I think probably, right? If anybody, if a developer knows anything, they know SQL. And it's really the cornerstone of the entire kind of app dev and integration ecosystem. Right? There's the world of innovation that exists around SQL or implicitly around databases, whether that's everything from, you know, ASP.NET to Rails to Node to pick your favorite app dev flavor of the week. As new and different as all of that stuff is, at the foundation is SQL and relational databases. It is the lingua franca of data. So we're kind of like Tale of Two Cities here, right? Salesforce is the best platform for building enterprise apps, bar none. It does all this great stuff and of course helps you manage your customer data. On the other side, we have really widely understood technologies that are awesome for doing really high volume, high computational intensity, sophisticated kinds of data operations, and most importantly, great for building customer experiences, right? All of the beautiful customer experiences that we love and use every day, the, you know, Ubers of the world, right? What's happening under the hood? It's all those modern app dev technologies operating at great scale that are powering that, or for that matter, Facebook or Instagram or whatever, right? So we have these kind of two worlds that to date have been separate. So what are we trying to do at Cloud Connect? Well, wouldn't it be great if the way that you worked with your data was kind of like a hybrid car, right? In a hybrid car, you've got your gas engine and you've got your electric motor. When you're driving up the hill, maybe you're using gas. When you're going down, maybe you're using electric, right? These things trade off seamlessly and you can just choose whichever one you're going to use at any given moment. Well, imagine if we could do the same thing with our database technologies. So you've got your SaaS application on one side. You've got your database on the other side. You're interacting with your Salesforce application over here. You're interacting with your database and your database application over here. But they're seamlessly synced and connected to the same analogous drivetrain. Does that work? And so you can interchangeably use them. In your applications, allowing you to take off the mittens and access that entire world of innovation. So we're going to automatically— it's kind of like a hybrid car circa 1970. If you go back, like I'm sure people had the idea for hybrid cars 20 years ago, right? Why didn't we all have them? Because they were really hard to build yourself. So what we're trying to do is not just kind of allow this pattern to exist, but make it really, really, really simple, right? Dropbox-style simplicity where you set it and forget it. It just works. You're not doing microsurgery between your different systems. You're not setting cron jobs and timers to do all this crazy stuff that is the current paradigm, unfortunately, of integration. It should just work because that's our expectation. So by analogy— and I'll get to the demo very soon. Is there a time right now? I wasn't paying attention to the time. By analogy, you know, you could create your own Dropbox. You could set up an FTP server, you could script rsync, you could, you know, set this file to go over here, you could schedule it, schedule it, all this kind of stuff. And this is what the integration vendors are asking you to do today. They're asking you to create your own Dropbox, as opposed to, right, why can't we have these things that just work out of the box? So, If we were to rethink this problem from scratch and we were to say it's 2013, how should this all look? What would it look like? So we're going to go ahead and set up and get up and running in Cloud Connect in— it's 7:37. We'll do this in 4 minutes. So I'm going to go ahead and sign up, and all of you are welcome to do this. As well. And I'm gonna create a password. You can note the CSS transformation we're doing for the Stickit note. You can tell, isn't that cool? Oh, that's already in use. I'll be test5. And I've gotta accept the terms of service. This is by far the most exciting part of the demo. This is the part where I validate my email. You can see our emails get sent quickly. Okay, I validate it, now I can get started. So we're going to create this new database, we're going to bidirectionally sync it, and we're going to have full SQL glory. Well, the first thing I need is database. Now what would you do in the olden days? You go find an IT person, yourself, you go put a database under your desk or whatever the hell would happen. Well, this is the magical new world of the cloud, so I just choose whether I want a Heroku Postgres or an Amazon MySQL database. I Click continue. We go ahead and we're going out now and actually provisioning that database for you. You don't even know you need to know how to use Heroku or Amazon to do all that stuff. And we're literally spinning up. That database is now created. And then the next step is I can link this to either my production or my sandbox account. And I will link it to this developer edition org. You do have to remember your password. Okay, now the OAuth handshake is back, and all I need to do now is tell Cloud Connect which objects I want to map. So for the purpose of the demo, I'll grab account, and it's doing all the fun stuff of grabbing all my account. Obviously I have all my standard and custom fields. I'll just pick the defaults, click OK, and it's off doing its thing. You can see, you can tell it's syncing. And now I'll grab contact and I'll just grab kind of the standard fields there. And literally what's happening under the hood is we're creating those, in this case a Postgres table, just a regular standard SQL table, right, that maps to that schema. We're going ahead and populating those objects. And from here on out, you can see it's actually telling us it's reloading those. From here on out in perpetuity, those objects will be kept in sync. That's it. You're done. You now have a SQL database. So, let me, by default we're read-only for kind of safety reasons, but I'm going to switch us to read-write mode, which means of course that it's now bidirectional. And I will go ahead and email myself the database credentials. It's now 7:40, that was 3 minutes. And we're done. Now we get to actually use this thing. Now I wait for my email credentials to arrive, and while I do that, we take a look and see what's happening with our load. So our load's complete. Not a very big org, right? It was about 200 rows per object, but of course this is a der— this is a standard database, a cloud database. We could stick, you know, a couple hundred million in here without breaking a sweat. That's the That's the beauty of these databases. And we're waiting for that connection to arrive. Let's try that one more time. You guys are getting a good demo of how you request your email credential. Hopefully because I'm using this random address— oh, there you go. Okay. So how many times— In one of these meetups, has somebody used the command line? Am I breaking new ground here? Maybe? No? I don't know. All right. Well, we'll see. You guys are excited to see the command line. I am now logged into a database. Guess what I can do? Oh yes. Whoops. Of course I have to know what I'm doing. I just did SELECT FROM account. How about that? Watch this. UPDATE— I'm doing this by, like, feel here. I'm just doing standard SQL update and of course I probably don't have a fax field. Man, this is an awful demo. I'm gonna show you the better part of this in a second. Nope. What's my schema for this thing? I'm on account, right? Try state. Do do do do do. I think I've done this before. It doesn't like that. I'm about to give up. Don't worry. OK. What I'll show you next— OK, that's great, the command line. End of command line demo. What you guys really want to do is you want to use normal tools. The rest of us. Nobody uses the command line. So here, right, is a standard Postgres Client, and for another thrilling part of the demo, we will now fill in the connection details to prove that there's nothing up my sleeve. And username and password. Oh, I hope you can't read this poorly or not. And database. Yes. Okay. Turn on SSL. Connect. And I now have a database connection, standard Postgres database connection to all of my Salesforce data. This database is ddam. I've just gotta find it. This is a Heroku thing. How many of you guys have used Heroku before? Okay, yeah, you guys are, you're good to go. So this is the really fun part. Oh, you love this. This is great. What's your naming convention? This is a— I'm gonna blame Heroku for their naming convention. It's a weird— this is how I just have to browse through the database list. And— oh, I'm gonna get there soon. It's so gonna be worth it. Okay. So you can see I've got account tables, I've got whatever. Double-click on account, here you go. It's gonna show me all of my accounts. Hey, it's SQL. I can update it, write, it'll go back into Salesforce. That's it. Now the beautiful thing is that you don't have to worry about— as you guys, you've all— many of you work with Salesforce API, you know there are all kinds of different best practices about how you're supposed to work with the API, right? And a lot of the times you might be thinking about, well, how am I conserving my API calls, things like that. So what we've been able to do is really just bake in all the best practices, right? Because we've got this kind of database in the middle. So if you have a ton of data that changes on the Salesforce side, We'll detect the amount of data that's changed and will automatically do a bulk versus a batch query. Right. Well, every time you update something on the database side, we'll actually compare it with the local copy so we're only sending the deltas. So we're only automatically updating the least amount of data every time. We're automatically batching up the updates. So if you do a bunch of changes all in a very short period of time, right, we'll batch them up into the biggest chunks as possible. Again, increasing your performance, decreasing your API count. And of course, for any kind of customer-facing application or any computational application or analytics application, all of your reads against the database are free because obviously they're not using the API. Let me know if that doesn't make sense. And they're super performant because you've got this big funky database that you can optimize the bejesus out of underneath. So this becomes really useful in two contexts. One is just doing straight— it's a new way of doing integration. So instead of thinking about targeting— if you think about API today, I'll use more of a straight developer metaphor since so many of you graciously are developers here. If you think about how you build integrations today, it's a lot like doing assembly language. You do kind of a very specific instruction. Right, bulk, upsert, object, right, these kind of very, very discrete low-level instructions and kind of wire them together very delicately. In this model, you just have a standard SQL endpoint, right, which every single tool and system and developer already knows. You just pump the data in and we take care of whatever optimizations need to be handled on the other side. But where it gets really interesting is you think about creating new customer-facing experiences, right? Both from a technology stack point of view— what do you want to use to build your customer-facing experiences so that they look as great as Pinterest or Uber or as performant as Google or whatever? You're going to use Rails. You're going to use Python. You're going to use PHP. And you want to do that in a way that those tools expect so you can take advantage of those frameworks, which is to say a database. And what you get is a new way of building essentially portals or customer websites. So to make this complicated, one of our customers is Heroku. This is the Heroku partner portal. It's both a partner directory and the portal, right? So I've got all of the service provider partners for port— for Heroku. It's this like beautifully built application and it looks great and it's all very Heroku-ish. And of course, since this is Heroku, this is a Rails app. But what's different about this app, all of those partners are accounts inside of Salesforce. So if I'm a BD guy and I change a Pirio from a silver to a gold partner, that'll show up in this automatic— that's application automatically. If I'm a Pirio, I log in, I do something That propagates back. You say, well, isn't that great? You know, is that possible before? The beautiful thing is that the person who wrote this application didn't even have to know Salesforce was in the mix. Right? Because they're just going in against the database. That's the first beautiful thing. The second beautiful thing is because this is running on standard open cloud goodness like Heroku, we can scale this infinitely, effectively. This website can become as popular as Pinterest All we do, if you guys are familiar with Heroku, is we crank up the dynos, right? That just throws more horsepower in it. I never have to worry about the performance. I don't have to worry about limits, any of that kind of other goodness. Final use case. There's another great use case which I don't— I will just kind of speak to, which is, again, think about this kind of hybrid engine concept. Think about the business logic that you're writing, right? You can— we have a lot of customers who need to do complex operations against their Salesforce data. And because this is an analytics meeting, I'll kind of tie it together that way. It's not uncommon, for example, we have a customer that the way that they manage their opportunities is the lift in revenue over a 6-month period. So they have this whole process by which they put their They create opportunities based on cohorts, based on the first touch of the customer, based on how much revenue lift there's been at the end of that 6-month period. That goes into the opportunity amount that gets closed. That's how the reps get paid. That's like a multi-object complex computation, right? What are your two options of how to build that? Well, one is you can kind of eke it out maybe in Apex, which is great, but you might be pushing it a little bit too far. The other is you just write about 15 lines of SQL, right? And those values and those opportunities get updated in the database, they get automatically updated in Salesforce, everyone's happy. IT's happy because the data warehousing analytics guys are using SQL to build what they want. Sales is happy because now all of this information is being reflected back into Salesforce in line for the sales managers so they don't have to go to some external system in order to see what's going on. It's on the website, it's free, you're welcome to sign up. We charge based on number of rows. First 10,000 rows are free, so if you have a D account, you have a small thing, go at it. Questions? Yeah, this is awesome. Thank you. SQL is terrible, so it's great. SQL's okay, I'm here to praise it. It's a limited gift. Um, uh, but you kind of went over this, uh, quickly, and I just want to recheck. Like, if I write to this database, yes, then it does push it back up to Salesforce. Yep, that's awesome. That's the magic. Yes, yes. There's a lot of analytics folks, and doing kind of the pattern that's been common is unidirectional, right, where I'm just using it for read-only purposes. And of course, that's great for analytics applications What it isn't great for is for app dev, for building new apps. And not surprisingly, partially given my Dropbox experience, right, I learned a lot about sync. And sync is very hard, but if you do it well, it's possible. That's kind of the message. Yeah? How do you handle the classic sync issue when somebody makes two updates to the same data item? Yep. Different updates to the same data item, you just do it both places. That's one of the reasons why, as I mentioned before, we always check to only send the field-level deltas, not the row-level deltas. So the surface area of possible collision is greatly narrowed. What that means is if I've got a customer, I've got a contact, you know, I've got contact Joe over here and the Salesforce contact Joe over here in the database. Let's say I, you know, update both of them. Well, first we're going to be— we're running this process all the time, so it's whoever's Last wins. But if in the database I update phone number and Salesforce I update name, they're not going to conflict because we're only going to send the piece of data that changes. And that's precisely why we do that, because you minimize the possible surface area of conflicts. But in the case that both did try to change the name, last wins. Last wins. Okay. Do you get error message? How do we do error messaging? Um, I'm sorry, do you get any error messages? Do you get error messages? Yes. So if you have a, a row-level— I don't have any since I just created this, this tenant, but let's say that there was a requiredness on contact that I didn't satisfy. That particular row would be in an error state, and you'd see that reflected here. And it would stay in that error state until you reconcile that. You'd see both the detail here as well as you see the error count there. Errors. Would that include conflict errors also if you've done parallel updates? No. Conflicts are last wins. Because we don't know whether that's a conflict or whether that's explicit. You don't know that semantically. You showed the example of setting up a table based on an object. Can you do the reverse, based on a table create a custom object? Technically it's possible. There are a couple reasons why you wouldn't want to do that. For example, in a database you have just the, essentially what in Salesforce terms is the API name, not the label, right? So there's a bunch of additional data that you would need. And also frankly, doing schema changes to Salesforce is a reasonably serious act. So, you know, we're like, you know what, just go through the process and, and do it. Or, you know, maybe at some point we'll write tools to help migrate that, but we don't want to— we're very sensitive to doing things that are too automatic, right, because then it can be a little destructive. Yeah. Just wondering, is it pricing well? I mean, it looks like we— did you already have a Heroku account when you did this demo? No. So it's a batteries-included model, which means that in the price is the data, includes the database. And I can get into the pricing The very short version, all you guys, you know, of course get free accounts because you're here. Well, one thing, let me talk about pricing and I'll talk about something else. The, uh, how it basically works is the amount of data, which is the number of rows, and then the database capacity. So whether you're on a shared database or a dedicated database. There's another dimension here which is kind of interesting, which is we support multiple orgs together in the same database. So you can query across them in SQL. Gee, isn't that handy, right? So that's handy for two use cases. One is if you have multiple orgs and you want to find everybody with this email address across all of these orgs and like actually do operations on that, you can. The other, and this is one of the reasons why we built it, is for our ISV customers. So if you're a company like JobScience, what— and you're doing resumes and full-text search and this kind of stuff, right? You want to do that in Postgres that has this really meaty full-text search engine, and you want to put your application logic out in the app tier like a normal multi-tenant service. So you're not pushing code updates to all of these orgs all the time, every time you want to do something. You just want to manage it as a single app. So we map multiple orgs into a single database And then the application, the Java application essentially just points at a given database based on who's logged in. Much, much simpler, more powerful application model for doing complex things that weren't possible before. Should I show you a Job Science demo? You guys want to see that? You guys want to see that? Sure. One, just real quick follow-up and separate question, but SQL, I mean, you can do anything, right? Yes, you can. Absolutely do anything. And then I'm thinking of You can't do it, of course. And so I'm like, okay, so on-the-fly joins, you know, all these things you can do in SQL, how's that going to translate to SOQL? Is there a subset that you, you know, these are approved SQL things you can do, or just do anything and then you've written the magic layer that figures out how to do it? We're not translating queries into Salesforce terms. Oh, okay. It is the database, and that's part of the value. The full capability of the database, the indexing, the full-text searching, all that, you're talking the database, right? We're moving the changes. We're not just providing a different interface to Salesforce. So there are products out there that will put a SQL personality onto the APIs, but, right, you lose the power of having the database, which is the whole thing. This is an app that was built by customer of ours. And I'll show you, this is searching, I won't give the exact numbers, but let's call it a bucket ton of full-text resumes. And you'll notice, first of all, if you've ever used search, right, this is really, really fast. You'll also notice not only is it searching this, but look at what's happening to the company names as I— up, right, you see how they're getting updated in real time. So think about how computationally expensive that is to issue that query and then, you know, you're doing multiple queries, both full text, you're doing this highly attributed search, you're delivering this kind of next generation experience, right? I can then go ahead and filter and do all this kind of good stuff. It's just super fast. Why is it like that? Because it's built using a standard app dev stack and a database that has a lot of muscle behind it. How big is the database? In that particular case? Millions? Yeah, in the hundreds of thousands of resumes in that particular example. We have customers that have millions of records. So we have another customer and their use case, one of their use cases is they have millions of contacts and they want to automatically parent those contacts based on domain name. So you're traversing the entire, you know, multi-million set of rows on a, you you know, call it an hourly basis and kind of doing all these parenting operations, right, which is again very expensive from a just database point of view, but is— it's expensive in traditional terms, it's comparatively cheap for a database. And then of course, right, as those changes come from the database, they get batched up and sent over to Salesforce. Another example, a little bit to what some of the things we were talking about before, is they're doing a form of custom lead assignment. Well, technically they're using contacts, not leads, so they built their own contact sales assignment just again in, it's like 15 lines of SQL. It does the whole thing. It looks at how many, you know, leads or contacts each rep has. It, you know, can see who's there, can see who's on vacation, right? Just again, classic business logic stuff, but expressed in more straightforward terms. Any really hard questions? Embarrass me by making her ask me SQL questions that I clearly can't answer. Security? Well, the beautiful thing is we're just using— that's one of the reasons why we use Heroku databases, right? It's a standard off-the-shelf Heroku database, so it's as secure as any other Heroku database. Can you create stored procedures or triggers or anything on that side, like a typical database? Constraints, rules, those kind of things. All database goodness. And if you guys haven't, I will put one final plug in. Heroku Postgres is an amazing product. So, it's super, super cool. So one of the things that our customers often do is they'll have a database, a Postgres database set up as kind of the operational store where they're running this logic or these apps. And one of the things that Heroku Postgres will do automatically for you is create a read-only follower. So literally by just clicking one button, it now instantiates another database and you've got a read-only copy. And then they give that to, you know, random business users to query away on knowing that they'll be safe and not break anything. Future of databases. Are you planning to do something similar for other enterprise SaaS platforms like NetSuite or— It's part of the vision. Which would you like us to see do first? NetSuite or Intact, I guess. So voted. Take that into consideration. Any other questions? Thank you for your time, guys. cloudconnect.com. Sign up. Thank you, Adam Gross. Thank you. We had two great demos. Thanks both very much. I guess the vote was all for? No, individual. Oh, individual, okay. For NIMS. Someone want to come up and— Corey, you want to come up and do the honors here? Sorry, I didn't have a fishbowl this time. You think I would. Do you have a crowd center anymore? Hey, I know that paper we passed out had a lot of stuff on it. If you just want to put your email address on there and check a box, that's cool too. I'm not trying to make your homework assignment. All right, pick a card. We have Adam Perkus. Ah, there you go. You said one? All right. Steve Patton. All right. Hey, not too many. Easy, easy. Everybody in the row right here. Easy on the men here. All right. Crank up your frame rate. David Gerster. 3 men, okay. Wow. That's away from you. Last one. All right, last one. You even get to recycle your card. We'll take this one. Matthew Moran. Hey! All right. All right. Oh, jeez. Oh, ow. All right. All right. Take it high now. Thank you all very much for coming. I will do this again I guess not next month, but the month after, first week of, uh, October. October, yeah. Thank you. Thanks for coming.