Built.IO eliminating API Lock-in - CTO034

Machine-generated from the episode audio and not hand-corrected, so names and technical terms may be imperfect. The audio is authoritative.

So, Kirk, can you introduce yourself? My name is Kirk Collins. io. So that's saying a mouthful, because you work for a startup. And titles, I've learned, at startups don't really mean much. They're more like suggestions than they are really. They're guidelines. They're general guidelines. Yeah, they don't really define it. What does that actually mean? io? So on a day-to-day basis, you're actually right. I'm lucky. I think 80% of what I do is actually within the two titles that I mentioned.

But on a day-to-day basis, it's either I'm blogging or writing something surrounding our platform, actually more often than not necessarily directly related to our platform, but surrounding the industry and the space that we're in, thought leadership pieces. But on the flip side of that, I'm also going and doing some product development with partners and clients of ours, helping them do some implementation work. So some sales engineering work is part of my job as well. Basically, anything that has to do with generating leads or generating potential sales leads or making clients happy.

Those two kinds of things are where I sit. So that is a fairly straightforward job, especially in a smaller company. You come in and the sales process when needed. You develop relationship to other organizations from a business development perspective. And then you just talk about Build, which is, I think, one of the main reasons I've been wanting to get you on. I met you a few months ago at John Troyer's event. io. And it's just never happened. So I'm glad that we finally got around to it.

I'm really happy we did, too. It has been, you know, our schedules have been crazy. And part of that is because I've been moving internationally. But things are settling down now. So we finally got a chance to talk. So let's begin with the most basic thing. io's website. And I see things that talk about kind of Cisco Spark, anywhere from existing collaboration tools and this workflow idea. io, and who's it targeted to? io is actually, we call ourselves a startup.

We're actually about a nine-year-old organization at this point in time. We have three different products. One of them is a back-end-as-a-service platform. Another one is a headless content management platform, a headless CMS. And then the third one is the one that you alluded to there. io Flow. And that is, it's an integration platform as a service. So we're an enterprise platform provider. We try to empower enterprise organizations to build mobile applications, and in fact, any applications quickly, to be able to manage the content on those applications easily, and also integrate those applications with anything that has an API.

Those are the things, that's what we do. Build, implement, and manage? Yep. So walk me through a typical workflow where a customer would start to use Build, build one of the three product lines from Build to the end. io Flow. We launched it at Dreamforce in 2015, so last September, basically. That's actually the one that's been getting a significant amount of uptick lately, especially surrounding bots. And I'll get into that later. But there are a lot of, when you think, if you're a developer, period, your job right now is to build an application that's integrated to two, three, five different things.

Let's just talk about mobile developers. Mobile developers alone have to integrate in, on average, I'd say, anywhere between three and five different APIs just to get an application off the ground. And that's things like Facebook Connect, the Twitter API. And then after that, let's say you're building something about restaurants. Well, then you've got to pull in stuff from Yelp and Foursquare, right? So that's just an example of all the, right now, developers are becoming much more integration experts and less building stuff completely from scratch because none of us like to reinvent the wheel anymore.

So, go ahead. Sorry to interrupt because I think I have to draw a parallel to us infrastructure guys and the things that we have to deal with. One of the central concepts that I've been preaching over the past few months has been this concept that cloud is not going to take away our jobs because we're making a larger distributed system. We're, in a sense, making internal IT more complex because we have all these integration points from AWS to Azure to our private cloud to these SaaS services that we're all, you know, Office 365, Google Docs, that we're all trying to integrate and stitch together.

And I'm just starting to hold my head up and see that on the development side of the house, you guys are having those same problems or the customers that you're talking to are having those same problems. Exactly, exactly. And I couldn't agree with you more on the infrastructure side, right? Because now you've got the, this is something you guys have to deal with, the concept of hybrid clouds, right? So, how do you deal with the fact that you have your public cloud and your private cloud?

You have your in-house, you have your in-house server infrastructure and then you have your AWS server infrastructure, right? They're still gonna need, the infrastructure people aren't going anywhere. You guys are not gonna lose your jobs because of cloud. In fact, your jobs are just gonna become more complex. Right, so that complexity from an API perspective, please continue, you were saying how you guys help lighten that load. So one of the things that is oftentimes, and in fact, especially now with the explosion in APIs, I believe Programmable Web has something like 14,000 or 15,000 different APIs listed in their database right now.

If not, it's somewhere around there. And that's a lot of APIs for anybody to deal with. And that's just the stuff they have listed. We don't even know all of the APIs that are out there. So in any given application, you might be integrating a couple of different APIs together in order to do something. Now, as a developer, you can probably do it pretty quickly, but pretty quickly still means a couple of days worth of work without QA. io Flow, what that allows you to do is actually integrate multiple APIs together in a matter of minutes or hours.

So let me give you an example, a direct example, actually. My typical demonstration is integrating Evernote with Dropbox, Gmail, OneDrive, and Twilio. And that's just, and doing the demo, including the explanation, takes me about 10 minutes. And what that, and the demo is, it's simple. It's being able to pull a note from Evernote, email that same note out via Gmail, write that note to a file while it's being emailed, and then upload that file to Dropbox and OneDrive. And when all of those processes are done, send out a confirmation text message using Twilio.

So that's a really great example of a end-to-end workflow and the challenge that developers face from an API perspective. I just got off the phone with a active, not active directory, but identity management vendor, and they were talking about the feature set of their solution is to avoid lock-in. And I said, you know what, what about API lock-in? If I develop a solution where I integrate, you know, ServiceNow, Google Apps, and a bunch of other services, and I leverage your API to do something, then what happens if I wanna move to another service provider I've locked into your API?

You guys help solve some of that problem for, it sounds like you guys are helping solve some of that API lock-in problem by saying, you know what, if your messaging platform is Google Mail Today, and you need that to be Yahoo Mail Tomorrow, or you need to support both, sounds like you guys are giving that flexibility. And so you hit the nail on the head quicker than anybody else I've spoken to about this, actually. I will posit that API lock-in is gonna become a huge problem in the next couple of years.

And the reason why I say that isn't because of what's already out there. It's because APIs are now being utilized to call ride-sharing services from within an application. They're now being utilized to find parking spots for cars in the city. And imagine what happens when Tesla integrates a parking finder directly into their car, utilizing a particular API, and then, you know, they wanna change that a year and a half from now. That's some serious API lock-in. So I think the issue, we may look at API lock-in as a relatively light issue today, but what happens when connected spaces and connected cities all become a serious issue?

APIs are gonna be powering all of that, and to be locked in is a big problem, especially for municipalities and infrastructure providers like that, right? Yeah, you're reminding me. I have a Smart Cities colleague who worked at PWC who's now a director in their Smart Cities program in India. I have to get him on a podcast and talk about some of this because these are really interesting problems. After a city has solved a Smart City problem, what happens when you get connected cities that need to interoperate or services between that integrate between connected cities?

There's no standards today, so it's all API-driven, and having inconsistent APIs is just as bad as having inconsistent standards. So I was in Barcelona actually about a month ago at Mobile World Congress, and I was giving a talk, and a large part of my talk was we need a standard. We need to make sure the connected city is a standards-driven process, right? Because there are no standards now. You're right, it's the Wild West out there. io cares a lot about connected spaces and connected cities.

Our integration platform as a service, a large part of the reason why we built it was to be a part of the connected spaces movement that's happening right now. We're working with a number of cities, a number of municipalities, a number of different vendors. We're working with the Sacramento Kings on their new stadium, actually, and integrating all the different technologies that are gonna be in that stadium, making them talk to each other, and avoiding vendor lock-in. So for instance, a client of ours may end up going out there and doing a deal with an API vendor.

Let's just give you an example. They may do a deal with a CRM provider known as PipeDrive, as an example, right? And that may be the CRM solution they're using. They link up the APIs, they do what they need to do in order to integrate it into all their different systems, and then a year from now, or two years from now, they move off of PipeDrive because they're growing, right? And they need to move to something a little bit more robust.

So they move to Salesforce or Salesforce IQ. Then they have to spend six months, nine months, they have to spend five times the amount just integrating Salesforce into their daily workflow. If you utilize tool sets like ours, that integration process goes from six months down to about six days to six weeks, right? It's a significant difference. As opposed to going in, getting your engineers and telling them to rip out all the code that they wrote two years ago and put in this new code, you just drag and drop some things around and you're done.

And how does that, so do you guys take away the burden by understanding the APIs and then doing that visual translation itself so you guys do the hard work of doing the API translation to your tool? Yeah, and I think the, honestly, we're a standards-driven organization in a lot of ways. So we're using standard practices, right? We're using RAML and Swagger for our API structure. But then at the same time, most of the APIs we have inside of our tool return information via JSON, right?

And they also take JSON as input. So if I'm in that example that I gave you, I can actually pull the information from Evernote using JSON and then push it to Gmail also using JSON, right? And that allows, because that's a standard now, which is why I want connected cities to become standardized, but because that's a standard now, a standard way to exchange information, it makes everything easier. So we've talked about the API and workflow side of the house, which is extremely enlightening conversation.

What about the other two areas you guys help in? Yeah, so when it comes to backend as a service and content management as a service, so our backend product is called Backend. We try to make it simple. And what backend, it's a backend as a service as you can think of it, similar to Parse and some of the others that are out there. There are a couple of things that we try to do differently and we package. We work with enterprise organizations as our primary client base, right?

For all of our products, enterprise organizations are our primary client base. And as part of that, they have certain needs. So enterprise organizations, now you alluded to infrastructure lock-in before. Well, we are a part of that in the sense that as a backend as a service, you don't wanna be locked in if you're an enterprise organization. You don't wanna be locked into using us necessarily, but you especially don't wanna be locked into hosting your data on our infrastructure. So what we allow you to do is actually take our stuff and install it in your own private cloud.

If you wanna put it on Azure, if you wanna put it on AWS, if you wanna put it anywhere that you guys need to, go ahead, right? And so that's part of what we try to do from a vendor perspective, as far as allowing you guys to do what you need to with your own infrastructure. So that's one thing. We have real-time communication. So Google's Firebase actually kind of pioneered it, pioneered to be the wrong word, but they really made it blow up, which we think is an important part of the Connected City and the Connected Spaces infrastructure, being able to have different technologies communicate in real time.

That is so important to the Connected Spaces infrastructure. So we put that into our backend. There are lots of other little things like that that we do that a lot of our competitors don't do or they do in pieces. On the content management side of things, we have a headless CMS, which is now becoming a big thing. But honestly, we've had a headless CMS now for three and a half years, even though everybody's starting to talk about it now and WordPress is starting to move in that direction.

So they have their own headless CMS version. And what headless CMS is, is the separation of the marketing side of the house from the IT side of the house, essentially, coming from an enterprise perspective. You don't want to, if you're a marketing person, you need to update your content. Do you really need to know HTML in order to do that? That feels a little weird. And sometimes you may need to ask developers to do things and so on and so forth, and it takes you a long time.

Well, our CMS kind of separates the two sides of the house. All the marketing people need to do is write. That's all they need to do. They don't need to know HTML, they don't need to know JavaScript. They don't need to have to copy and paste shortcodes into X, Y, and Z. None of that stuff. They just need to write. The developers, they create their templates and they make sure they enforce policies on the marketing people. So if a title field is only supposed to be 80 characters long, because that's exactly what the HTML can deal with, then that will be enforced automatically.

So this is taking the, to borrow term DevOps and continuous integration, this is taking this concept and putting it into real practice, going all the way into the marketing group itself. So beyond developers and operations, but going into the end user and making internal applications as self-service as possible. Exactly. That's exactly what it is. And also being very, very, as techies, we have been, we're getting better at it, but we've been pretty bad about identifying our target market. For most products, we've been pretty bad at it.

We think we're good, but we're not. We dance around our target market until we finally hit something that we think sticks. And if you look at most organizations that have sprung up, they've all kind of done that, right? The good ones have known their target market from the beginning. Facebook knew their target market from the beginning. They hit the college students. In fact, they hit the Ivy leagues first, and then they expanded into other colleges, and then they expanded more and more and more until it's now all over the world.

But they understood their market very, very well. I would posit that most tech companies don't really nail that, right? And so what we're trying to do is make sure that our products are targeted very specifically towards the people who are gonna be using them. Marketing people use content management systems, and developers use content management systems, but they use them for different things. So why not separate the functions instead of blending them together? That would be a logical thing to look at in hindsight.

So yes, I tend to agree with you. io, you guys are gaining a lot of traction with the API piece. I think that's actually a pretty brilliant problem that you're solving, and I agree. I don't think the industry at large is giving it enough attention. APIs are becoming the new kind of standards. When you talk to someone and they say they have a REST API, that's usually not enough anymore. Well, what does it mean to have a REST API?

Can you have a compatible API when it comes to a specific given services? I think the next battleground. io over the next few months, few years? What's the big problems you guys are looking to solve and help outside of the immediate product landscape? So honestly, the big thing that we care about is connected spaces, from your connected car on up to connected municipalities, cities, eventually countries, right? How do we get them to talk and communicate? You marry that with the concept that now is blowing up all over the place with bots.

Marry connected spaces with bots, and that's where things get super fascinating. Right now, we think of bots as these things we chat with inside of Slack or Cisco Spark or HipChat or whatever it is. That's what we think of bots as. But in reality, chatbots have been around for a long time. I used to code chatbots in the early 90s on multi-user dungeons. They've been around for longer. I used to code chatbots on IRC in the late 80s. Right.

They've been around forever. So the concept of bots isn't new, but where things get interesting with them, where I think things are gonna get interesting, is what happens when you marry a bot that can take in context and understand true context. Right now, chatbots, for the most part, don't understand context. They can understand context, and it interacts directly with the world around us. So my car needs to know where a parking spot is gonna be, not where an available parking spot is, not where it is, but where it's going to be by the time I get there.

e. if you're going to a sporting event, and sure, there's plenty of parking spaces before the start of the event, but what happens if I get to the event 15 minutes late? Exactly. Exactly. Context, right? How do we synthesize all the information that's coming in and provide the right context to these automated workflows, which is where our flow product kind of comes in? How do we synthesize all that information and actually utilize it in a way that helps improve our lives?

Yeah, you know, I have a beef to pick with when it comes to this, when it comes to Waze. You know, when I leave out at seven o'clock in the morning to go to work, Waze always says it's gonna take an hour and 15 minutes to get to work. However, at that particular moment, and there's like a hundred times as much traffic, when I actually hit the road at seven o'clock, and that travel time inches up every time, you would think with deep learning that it would know that, hey, you know what?

Yeah, right now with the current flow, but the true predicted time is X. Yeah. And we need to get there. It's not, especially in the case of Waze, it's not an easy problem to solve. I mean, that's why companies like Facebook and Google and Autodesk are dumping billions of dollars into their artificial intelligence systems. Yeah, and then getting to another topic that we won't get into, but when you think about it, when someone like Facebook's, when Facebook, who already knows all of your habits and habits across billions of billion people can take that aggregate data, mine it and say that, combine it with the Waze example and say that, you know what?

We know for a fact that these Waze users or these users all hit this particular traffic pattern every day or route every day. We can predict, and you tie in your smart cities example, we can predict traffic loads based on that. I'm starting to see this bot, why Facebook bots make sense. io is concerned, we wanna be there. We wanna be at the point where we can work with cities, stadiums, villages, even whatever. We can work with any one of these real world installations and help them automate and synthesize information into workflows and patterns that bots can utilize in the long run to make your life a little bit easier.

Well, Kurt, it was really great finally being able to connect. I think the wait was worth it. The conversation was amazing. You guys are doing some really cool stuff. Where can people find you online and are you going to any conferences or meetups that you wanna? io, B-U-I-L-T dot I-O. We are, I'd like to say that we're Skynet and we're everywhere, but in point of fact, you can find us at most enterprise related conferences. We were just at Jive World 2016 in Vegas less than a month ago.

We're gonna be at Twilio's conference, Twilio Signal coming up in May. We're gonna be at Cisco's conference in June or July. So pretty much wherever the enterprise is, that's where we will be. All right, and where can people find you on Twitter? Oh, I'm easy to find on Twitter. TimeSync, T-I-M-E-S-Y-N-C. All right, so I really appreciate the time. That's it for this episode of the CTO Advisor. com. Obviously you can find the podcast in iTunes. Please comment, like, tell us what you like, tell us what you don't like, recommend us to a friend.

You can also find us in your favorite podcast, catchers such as Stitcher. Talk to you guys next episode.