 From San Mateo, California, it's theCUBE, covering SnapLogic Innovation Day 2018. Brought to you by SnapLogic. Hey, welcome back, everybody. Jeff Frick here with theCUBE. We're at the Crossroads. It's 101 and 92 in San Mateo, California. A lot of popular software companies actually started here. I can always think of the Siebel sign going up. And we used to talk about kind of the movement of Silicon Valley from the chips down in the South Bay in Sunnyvale and Intel really to a lot of software here in the middle of the peninsula. And we're excited to be here at SnapLogic's headquarters for Innovation Day. And our next guest is Craig Stewart. He's the VP of Product Management. Craig, great to see you. Thank you very much. Absolutely. So we're talking about APIs and we go to a lot of tech shows and the API economy is something that's talked about all the time. But really that has evolved for a couple of reasons. One is the proliferation of cloud services and the proliferation of applications in the cloud services. As we all know, if you go to Google Cloud Next, or Amazon Re-Event, the logo slide of apps and services available for these things is tremendous. So give us kind of an update. Have you been involved in this space for a long time? How it's evolving, what you guys are working on here at SnapLogic. Yeah, so what we've seen change of late is that not only is there a requirement for our customers to build APIs, but also to then allow those APIs to be consumed by their partners and networks out there. And as a part of that, they may need to have more management of those APIs than we provide. We're very good at creating APIs with inbound and outbound payload parameters, all of those things. So we can create those data services via our APIs, but customers then need to have a requirement now to add some functionality around, okay, what about when I have a thousand users of these and I need to be able to throttle them and those kind of things. And so what we've seen happening is there's been this space of the full lifecycle of API management technologies, which have been available for some time. And amongst those, we've had Google Apogee kind of being the benchmark of those with the Apogee Edge platform. And in fact, what we've done in this latest release is we've provided engineered integration into that Apogee Edge platform so that the APIs that we create, we can push those directly into the Apogee Edge platform for them to do the advanced authentication, the monetization, the developer platform around it, the developer portal, all of those kind of things. In addition to that, we've also added the functionality to generate the open API specification, Swagger as it's known, and to be able to take that Swagger definition, having generated it, we can then actually drop it into the API gateways provided by all of the different cloud vendors. So whether it's Amazon with their API gateway or at the Azure gateway, all you need to do is then take that generated Swagger definition, and this literally is a right mouse button, open API, and it generates the file for you. From there, just drop that into those platforms, and now they can be actually managed in those services directly. So I want to unpack kind of API lifecycle management because just for kind of a 101 for people that aren't familiar, we think of APIs and we know applications are making calls and it's, I'm sending data from this app to that app and this is pulling information from that app to this app. That's all pretty straightforward. But what are some of the nuances in lifecycle management of APIs that kind of your typical person really hasn't fought through that are super important and only increasing in relevance as more and more of these systems are all tied together? So the use of those APIs, some of the things around them that those platforms provide is some advanced authentication. So they may be wanting to use OAuth, two-factor authentication, those kind of things. They may want to do some protocol translation. So many customers may know how to consume a SOAP service, generally legacy these days. It's not funny that SOAP is no legacy, it just tracks me up. I'm like the hottest thing since I was born. Oh yeah, oh yeah. I still have the Microsoft Internet Explorer 4 T-shirt. Windows 95 box two, I'm sure. That's another conversation for another day. Yeah. But the management of those APIs adding that functionality to do advanced authentication to do throttling, if you have an API you don't want all of your backend systems to suddenly be overwhelmed. And one of the things that those full lifecycle platforms can do is throttle so that you can say, okay, this user may have only 10 requests a minute or something like that. So that stops the backend system being overwhelmed in the event of a spike in usage. That helps with denial of service attacks and those kinds of things where you're protecting the core systems. Other things that they can do is the monetization. If you want to actually expose an API for partners to consume, but you wanna charge them on that basis, you want to have a way of actually tracking those things to then be able to monetize that and to provide the analytics and the billing on top of it. So there's a number of those different aspects that the full lifecycle provides on top of what we provide which is the core API that we're actually creating. Right. And is it even feasible to plug an API into a cloud-based service if your service isn't also cloud-based? Cause as you're speaking and talking about spikes, clearly that's one of the huge benefits of cloud is that you have the ability to spike whether it's planned or unplanned to massive scale depending on what you're trying to do and to turn that back down. I would imagine if your API is going through that platform and you're connecting to another application and it's Pepsi running a promotion on Super Bowl Sunday, hopefully your application is running in a very similar type of infrastructure. Absolutely, so you do have to plan for that elastic scalability. That's one of the things with the SnapLogic platform is it has been built to be able to scale in that way. Right, now there's a lot of conversation to around iPass and integration platforms as a service. How do you see that kind of mapping back to more of a straightforward API integration? So what we're talking about in terms of API integration here and the things that we've just recently added, this is the consumption of our APIs. The iPass platform that we actually provide consumes APIs, all sorts of different APIs, whether they're SOAP or REST and different native APIs of different applications. And that we do out of the box, that is what we are doing is API integration. Right. The new functionality that we've introduced is this added capability to then manage those APIs from external systems. And that's particularly where those external systems go beyond the boundaries of a company's own domain. It's when they need to expose those APIs to their partners to other third parties that are going to want to consume those APIs. And that's where you need those additional layers of protection. Most customers actually use those APIs internally within their organization and they don't need that extra level of management. Right, right. But I would imagine it's increasingly important and increasingly common and increasingly prolific that the API integration and the API leverage is less and less inside the building and much, much more outside the building. It is certainly going a lot more outside the building and because customers are recognizing that data is an asset. Right, right. And then having it be a cloud broker, if you will, just adds a nice integration point that's standardized, has scale, has reliability, versus having all these point-to-point solutions. Yeah, absolutely. So as you look forward, I can't believe we're like May 16th of 2018 already. Here's halfway over. Well, what are you looking forward to next? What's kind of on the roadmap as this kind of API economy continues to evolve, which is then going to increase the demands on those APIs, the integration of those APIs, the management, as you said, the life cycle of the way all this stuff works together. What's kind of on the roadmap? If we talk a year from now, what are we going to be talking about? There's a lot of settling down of what we've delivered that's going to take place. And on top of that, then the capabilities that we can add to add some additional capabilities that the customers want to use even internally, because even internally, where they're not using a cloud service, they have requirements to identify who in an organization is utilizing those things. So additional capabilities without having to go beyond the boundaries of the customer's own domain. And so that's going to be some things like authentication. It's going to be some additional metrics on what's actually being used in those APIs, the metrics on the APIs themselves in terms of how are they performing? How frequently are they being called? And in addition to that, what's the response time on those things? So there's additional intelligence that we're going to be providing over and above the creation of the APIs that we're looking to do for those customers, particularly inside the organization. And it's very similar requirements, but just different, right? Because organizations take a company like Boeing or something, it's actually not just one company. There's many, many organizations. You have all kind of now with GDPR coming out to kind of data privacy and management restrictions. So even if it's inside your four walls, all those measures, all those controls are still very, very relevant. Very much so. So providing those, some additional capabilities around that is pretty important. All right. Well, Craig, you're sitting right on top of the API economy. So I think you'll keep busy for a little while. That's for sure. All right. Well, thanks for taking a few minutes to stop by. Thank you. All right. He's Craig Stewart. I'm Jeff Frick. You're watching theCUBE from SnapLogic in San Mateo, California. Thanks for watching.