Bummer! This is just a preview. You need to be signed in with a Pro account to view the entire video.
The Rise of Pareto-as-a-Service34:57 with Adam Duvander
Building web and mobile applications is easier now than ever before. Adopt the architecture of building on APIs and cloud services and 80% of your project will be completed before you start. This talk tracks the history of APIs through mashup mayhem, an openness backlash and to a future where regular people will ask for APIs. Immersed in APIs since 2009, Adam DuVander will share stories of API success and failure. As he looks to the future, Adam will share how the hundred year-old principles of an Italian economist are about to make the lives of today’s creative technologists really interesting.
We're gonna chat about Pareto-as-a-service. 0:02 Who's, who's sick of the, of having to install your own Pareto to? 0:04 >> [LAUGH]. 0:09 >> No. 0:11 Pareto-as-a-service, an ide, an idea that can can save you 0:12 time, have you focus on, what it is that you do. 0:17 Better than anyone else. 0:21 So, put yourself in a position where I'm sure as, we have developers here? 0:24 Okay. 0:31 [LAUGH] There was a, of course raised hands. 0:33 Yeah. 0:34 So you've been in this business and you're coding furiously. 0:35 And all the while, things are falling apart. 0:38 Maybe your server is crashing, your your 0:41 forgot password emails aren't showing up in inboxes. 0:45 You keep having to restart, your MySQL daemon, something like that. 0:50 Has anyone, at some point in your career, had any of those things happen? 0:53 They're. 0:58 Again, of course. 0:59 This is the interactive portion. 1:00 so, but probably who's, who's redact a server recently? 1:04 Last couple years, any, anyone on there? 1:09 Yeah, so, [SOUND] that gives you a little taste of Pareto-as-a-service. 1:12 So, when I'm kinda in this cloud. 1:16 [SOUND] furiously coding and problems are cropping up, and it 1:20 just doesn't feel, central to what I'm actually trying to solve. 1:24 I actually have, an Italian economist, up here in my brain. 1:28 And, he says to me. 1:36 Have I got a principle for you! 1:41 That's, that's the way that the, Italian economists, in my brain, talks. 1:42 You can add the accents if that helps for the Italian economists, that 1:46 I hope, to incept into, your brains at the end of this talk. 1:50 So, have I got a principle for you and that is. 1:55 The Pareto Principle. 1:58 Vilfredo Pareto, an Italian economist, and he he noted 1:59 that 80% of effects, come from 20% of the causes. 2:05 And so, the talk today, Pareto-as-a-service, is about, 2:08 learning from those principles, and being able to. 2:15 Notice that, architecture and how you architect your applications has changed, 2:19 and that, because of that it helps you focus on your core strengths. 2:25 And then, as a as a benefit of those, 2:29 two we're gonna talk about how to evaluate APIs, which. 2:33 Being the API tract are the things that, 2:39 enable you to focus on what makes you special. 2:42 So those are the three areas, we're gonna go down. 2:44 I wanted to, to first, since I'm calling it Pareto-as-a-service, talk 2:47 a little bit about, what, what he noticed, because, you notice by. 2:51 He, he died in 1923. 2:57 So probably he was not talking about APIs himself. 2:59 He noted the income distribution in Italy was that 80% of the wealth was with 20% 3:02 of the people, and that was, sort of 3:09 noted in, many different areas, up until recently. 3:12 to, to sort of maintain that. 3:16 But others have taken, what he noticed 3:19 about economics and applied it to other areas. 3:22 For example, 80% of support tickets come from 20% of the customers. 3:24 Does that resonate with anyone here? 3:30 I'm seeing some smiles, so, so perhaps. 3:32 Or maybe. 3:35 On the upside 80% of revenue comes from 20% of the customers. 3:36 If those 20% [LAUGH] overlap enough, then you might have a good business, right? 3:39 And then, 80% of the bugs coming from, 20% of the code. 3:47 And people have noted this sort of 80/20 rule. 3:51 The Pareto Principle and a lot of different areas. 3:54 In fact as I was preparing slides for this talk, 3:57 I realized that Vilfredo Pareto born in 1848 died in 1923, 4:01 but he was a civil engineer before he was a an 4:06 economist and in fact, his, his his principle he didn't even. 4:10 Notice until 1906. 4:16 So actually, 80% of Pareto's life work, was done in the last 20% of his life. 4:18 So, he really stuck, stuck to his principles. 4:25 [SOUND] So, this idea that architecture has changed. 4:36 Probably not a complete surprise to those who are 4:40 attending a conference like this, but here's your typical developer. 4:42 I think we can, probably agree, perhaps a junior developer. 4:47 But, your typical developer is, interacting with a lot of different APIs. 4:50 Hopefully using, using Orchestrate as a backend 4:56 definitely hosting the infrastructure in the cloud. 4:59 There were no hands that went up when I asked about, racking servers, right? 5:03 And then maybe Facebook and Twitter for social login, a bunch of other things. 5:07 In fact, based on, this sort of 5:11 architecture, you end up building your own services. 5:14 Your own internal APIs because you're used to 5:18 interacting, and creating your software in that way. 5:20 So, I wanna go back a bit to, a site 5:26 that I built in 2004 in Portlands to find public Wi-Fi. 5:31 These are coffee shops that, had Wi-Fi available. 5:36 There were. 5:39 In 2004 there were 54 of them that I had found. 5:40 And so I thought it would be really good to be able to type 5:45 in your address, and you could see the nearest ones to, to that point. 5:47 Well, it took a lot of effort in 2004, to do that. 5:52 And, I was even helped by a library 5:57 that Skylar Earl wrote during Google Summer of Code. 6:00 It was a, a Pearl Module that could take, 6:04 census data, you had to kind of, take this weird 6:09 format and compile it into a Brooklyn DB, but 6:11 once you'd done that, you could just make a call. 6:14 And, and see the coordinates of, that address that was able to parse it. 6:18 And so I made something to where you could do that in Portland. 6:23 You can put in your address, and then it would show you a 6:26 list, of the closest places, like, seems like a perfect application for a map. 6:29 But maps were hard then. 6:35 So here's the, two thousand and twelvish version of it and a, 6:38 that minus the spam that's been added in the last two years. 6:43 But, clearly and in between there I did when the Google Maps API maps came 6:46 out, I added a map because it, it was a perfect use case for it. 6:52 But prior to that, even the, the Geocoder was 6:57 that hard, which is now a single API call. 6:59 Well, maps were even harder. 7:03 And I'd tried to, implement them in another, in 7:04 a, in a client project, and, building maps very difficult. 7:07 But then of course. 7:11 The Google Maps API came out. 7:15 Does anyone recognize either of these two? 7:17 There's Housing Maps there that uses, Craigslist real estate 7:20 and rental listings and applies it to a map. 7:26 And Chicago Crime which would scrape crime data from 7:29 the Chicago Police Department and put that onto Google Map. 7:33 And, the reason I use those two as examples is 7:37 because they actually came out before the Google Maps API 7:40 came out so they had to reverse engineer, Google Maps 7:43 proper to get it to be able to plot points. 7:46 And, that sort of, usage led, I think, to the 7:49 Google Maps API and of course after that we all remember. 7:54 Mashup Mayhem, of everything goes on a map. 7:57 Right, even if it has no, no point to, to be on a map, we'll put it on map. 8:00 Everything, everything is a maps mashup. 8:05 But that also led to, that growth in APIs. 8:09 And to this, change in architecture that we've all experienced. 8:14 Now, I wanna be careful not to, call Google 8:20 Maps like the beginning of APIs because there were 8:23 APIs and even, there were web APIs before that 8:26 and these are three really early ones, early 2000s. 8:30 EBay to be able to add auction, 8:34 add auctions to, to those site. 8:37 Amazon to be able to search though all of their products. 8:40 And then salesforce to be able 8:44 to automate, adding leads and, generating reports. 8:45 All the their API, but the difference here is that those APIs extended products. 8:49 So I'm from Portland and we like our beer. 8:55 So. 8:57 I like to give it as a beer example. 8:58 So, for many APIs, including those three I showed, the 9:00 APIs the table, the foundation upon which you set your beer. 9:05 But for Pareto-as-a-service, many of those APIs, are the products themselves. 9:11 The API is the beer. 9:16 Here. 9:17 And so, that's the, the type of API that we're gonna talk about. 9:19 And it comes with many, in many different areas. 9:26 This one probably the, the most the obvious 9:28 example, right, of cloud infrastructure, with storage and computing. 9:33 But, certainly, communications, SendGrid with email, I worked there for a while, 9:39 Twilio the classic, open API example with SMS and voice, Urban Airship with Push. 9:45 All these is little, modular pieces that you can use in your applications. 9:53 [SOUND] Intelligent calculations are some of the 10:00 ones that I, get excited the most about. 10:02 Has anyone, used FullContact before? 10:04 A hand in the front row. 10:08 Yeah, so you send FullContact an email address, in an API call and then it 10:09 responds with as much information as it 10:15 has about the person behind that email address. 10:17 So maybe their name, gender, links to their social networks. 10:19 Whatever, it can find on that email address. 10:24 So performing these intelligent calculations behind the 10:29 scenes, and providing it via a simple API. 10:32 AlchemyAPI, also give it a bunch of text. 10:36 And it, does some natural language processing. 10:40 Comes back, this example is, is keywords, so it comes 10:43 back with keywords based on a block of text, and then, 10:47 some of the most interesting things that Siri does are really 10:52 does API calls to WolframAlpha like, how old is Mark Zuckerberg. 10:55 Those sorts of those sorts of questions that you can ask 10:59 Siri are actually just API calls, intelligent calculations behind the scene. 11:04 [SOUND] Certainly Data, Hoovers, and Xignite both 11:11 have great businesses based on providing financial data. 11:14 Factual has a database of millions of. 11:17 Business listings. 11:20 And, yeah, perhaps databases which is where Orchestrate comes in. 11:24 Not a database as a service, like running a database. 11:31 But instead an API to be able to access different database features. 11:33 So. 11:39 Clearly not here, to picture Orchestrate, but to explain, 11:40 that this is part of a much greater movement. 11:44 So, when I was a programmable web look through the, the directory of thousands of 11:48 APIs and tried to, pick up the pieces to determine, which of those thousands. 11:54 Were these kind of API Products. 12:00 And, then looked at that based on, on the year, and 12:03 this only goes to 2012 which was the last data I had. 12:06 But this is the number, that were added to the directory, by year. 12:09 So, by 2012, there were nearly 350 that were added just in that year. 12:14 And so there, this, I mean it attracts the 12:21 growth of APIs, but but also shows that there, 12:24 there's just a lot more of these modular pieces 12:28 that we're able to use to build our applications. 12:31 And even Google Maps, which, started as wide open and free. 12:35 Even Google Maps kind of fits this more, there is a, there 12:40 is a main Google Maps product as well, but the maps API itself 12:44 is a full pledged product and there you know, and charging for 12:49 it that makes it clear that Google sees it that way as well. 12:53 So [SOUND] Pareto-as-a-Service is a collection of all 12:58 these many different modular pieces, that you have before 13:04 you even started building whatever you're gonna build. 13:09 80% of it it's already done for you. 13:14 If you choose to use the services that, are available. 13:18 And that just leaves the, 20% at the top. 13:22 The, what makes your app special. 13:26 What makes you special. 13:28 What are your core strengths. 13:30 And so, to be able to take advantage of Pareto-as-a-service you have to focus on. 13:33 Those course strengths. 13:39 So I want to tell you a story, [SOUND] 13:42 about two guys, who did focus on there course strengths. 13:45 Guarav Oberoi and Chuck Groom, built a company called Precision Polling. 13:51 And their core strength, was a massive voice over IP network. 13:59 So they built a worldwide network that then allowed them 14:03 to do, phone polling, [SOUND] on top of that network. 14:07 And then, they built a simple front-end to that 14:12 so that someone who wanted to create a phone poll. 14:15 Could simply fi, fill out a form. 14:18 Create their poll add their, their numbers to it, 14:21 and initiate their poll, all on top of that. 14:25 On top of that network that they built. 14:28 And, they were acquired by Survey Monkey, 14:32 which is the largest survey application online. 14:34 So. 14:39 Who believes all that story? 14:42 Anyone? 14:45 I, I see a, I see a head shake there. 14:46 I did, I did lie a little bit. 14:49 I'll tell the story one more time. 14:50 This time I'll promise a 100% truth in, in this story. 14:53 Guarav Oberoi. 14:57 And Chuck Groom, built a company called Precision 14:59 Polling, and they did focus on their core strength. 15:02 And part of that was building on top of Twilio, 15:05 to be able to make voice calls, easily through an API. 15:09 And then they built, a simple front-end on top of that. 15:14 So, someone who is creating a poll could fill out a form. 15:17 Put in the numbers they wanted to call, and they did 15:20 get acquired by Survey Monkey, the largest survey application on the web. 15:23 So, clearly they focused on their core strength, which 15:29 was not building, the massive voice over IP network. 15:33 Someone else had done that for them. 15:37 [SOUND] So when I, when I tell stories, I mean, I think 15:42 clearly we all no one wants to build, a voice network, right? 15:46 But, when I talk to developers about, building on top 15:49 of APIs, I, I do sometimes get some push back. 15:54 I think that a lot of us have. 15:58 Have maybe had, some bad experiences with, frameworks and libraries that attempt to 15:59 do, too much at at that, same position where I attempted 16:04 to implement maps, I also, converted a site to asp.net, which I think probably. 16:11 Saying that is the equivalent of sort of the 16:18 beginning of the Alcoholics Anonymous meeting in this room. 16:20 But I didn't, but I came from the web world. 16:24 And I tried to, jam the way I thought 16:29 the web was supposed to work, into that framework. 16:32 And, fought against it and and so I understand resistance to that. 16:37 [SOUND] And, maybe there, there's some of that with APIs and a little later I'll 16:43 talk about kind of how to evaluate those and try to make the right, decisions. 16:48 And I, I want as you think about that, to think about. 16:52 Technical debt. 16:56 Now, technically debt gets a, a bad name a lot of times but, if you think 16:57 of it just like, normal debt, money debt, there's good debt and there's bad debt. 17:03 So, who thinks it's a good idea for me to, take a few hundred 17:08 dollars out on a credit card and go Play the slots somewhere in here. 17:13 Anyone? 17:18 I've got, I've got a, one. 17:19 >> [LAUGH]. 17:21 >> One guy. 17:21 We'll, we'll go hang out later. 17:22 right? 17:25 Clearly bad debt. 17:25 But maybe to take, loans out to complete your 17:27 education so that you can, be smarter and earn more. 17:30 I think, should we? 17:34 Let's continue the audience interaction. 17:37 Who thinks that would be, good debt, or at least better debt? 17:38 There are a few hands. 17:42 There we go. 17:42 I, I guilted you into it. 17:43 >> [LAUGH]. 17:45 Yeah, so, technical debt should be seen the same way. 17:46 That there's good, good technical debt, and there's bad technical debt. 17:49 And I think as you think about, focusing on your core strengths. 17:55 Some of that, means taking on good technical debt. 17:59 Because, your core strengths at one moment, might 18:02 be different then your core strengths down the line. 18:05 And, too often I think developers first mind set and. 18:09 And, I don't think it's a bad trait that we wanna solve problems. 18:14 Can you build it? 18:18 Yes, you can. 18:19 and, I think that too often though that's the, the 18:22 one, we, we jump at trying to build it, ourselves. 18:26 And you can't build everything. 18:33 So, a friend of mine, had just started a company a couple of years ago. 18:34 And, we were having drinks, kinda talking about, the, 18:39 the first couple of months and what it was like. 18:42 And he, very proudly said that he got 18:44 into the LaunchRock beta, which allowed him to have. 18:47 A page like this that says hey, we're gonna launch soon. 18:51 Put in your email address here, and we'll tell 18:54 you when we'll launch, and I, said you know, why? 18:56 Like that's a form, right? 19:02 Like why, why aren't you building that? 19:03 And he said well, you know, we. 19:06 Are only a couple of people we can only, build so much, right? 19:09 And, and it, it resonated with me and he has 19:13 since been the company did launch and, and did well and 19:17 was acquired by Yahoo and I'm, I'm thinking probably not 19:22 acquired for, their landing page, their pre launch landing page, right? 19:26 Probably not a core strength. 19:31 One other story and this comes from Orchestrate, so. 19:35 Before, my time at Orchestrate [SOUND] they implemented Persona as a login. 19:38 Mozilla Persona, is anyone familiar with it's kinda a, single sign in 19:44 Tool to be able to, to use someone else for that kind of authentication piece. 19:50 And, and so, they built that. 19:56 And that was the way to sign in. 19:59 To Orchestrate. 20:01 And, then sometime a couple of months 20:02 ago, Mozilla said, we're gonna stop supporting, Persona. 20:05 And so couple weeks ago, 20:10 we launched a, a middle ground, you could log in with Persona, and our own login. 20:16 And, I was just starting at the time and sort of observing. 20:22 And, and you might say, like wow, that, that was a. 20:26 That was a waste of time in, building, or to Persona 20:30 at all if you just have to go away from it. 20:34 And I started listening to the way people were talking about it and 20:37 it seemed like no, no one, no one looked at it that way. 20:40 They looked at it as, good technical debt to 20:43 take on, in an early time before there's any product. 20:46 And you just need to get people signed in, and then, you can spend 20:50 that time focusing on the product, and then later, we've added a few engineers. 20:55 It's it's, a much better time to be able to pay 21:00 down that technical debt than having to pay it, right upfront. 21:05 And so, when I think about, core strengths I think 21:10 you need to go beyond just the, what you can do. 21:15 Because you know, can we build it? 21:19 Yes, developers often will, they want it, they want that challenge. 21:22 We want that challenge. 21:25 But it's not just what you can do, it's what, users want. 21:27 What they specifically want from you. 21:30 Yes, they wanna able to log in. 21:32 Do they need to be able to log in, the way you would build the login? 21:34 Maybe not. 21:38 So finding that spot, in between. 21:40 That's the core strength. 21:43 It's not just. 21:44 No just your core strength but it's the core 21:46 strength you have, that users specifically want from you. 21:48 So, with those two, gone we'll talk about, six 21:54 ways to evaluate APIs as your thinking about sort of. 21:59 You know, there's a lot, I understand the resistance to, wanting to, 22:04 to build any, large piece of 22:09 what your building, on another company's, infrastructure. 22:11 And so six ways to, to be able to, kind of evaluate those. 22:15 This is, from my time of seeing, thousands of APIs go past it programmable web. 22:19 [SOUND] So, you wanna think about company viability, and 22:24 certainly, a start-up, would be a risk. 22:31 A start-up with little funding is, also. 22:37 Neither was the case with SimpleGeo, which has a great. 22:40 Great application. 22:43 But did, it was, one of the acquired and, and disappeared as an API. 22:45 And it allowed you to be able to store GeoData and query it and it was really 22:50 cool and, I hope Orchestrate can bring back a geo query of some sort, like that. 22:56 IQ Engines was a really fun one. 23:04 You could, you could send an, an image and it would, look 23:06 at that and tell you, you can't see on this screen, but that says, cowboy boot. 23:12 And it has a, a certain level of. 23:18 Of it being sure. 23:23 I think it's 0.99 sure that that's a cowboy 23:23 boot and it would send you back that along with 23:27 a list of other things like, you know, it 23:29 might be this other thing but we're not so sure. 23:32 It was a fun one also, acquired, so you have to, and went away. 23:34 So, it's, it's not an easy, an easy thing to try and 23:41 source out, but there are some other, bits you can look at. 23:46 I wanna share just one more, of my 23:49 favorites that got, that got acquired and went away. 23:51 It was called face.com and this was every hackathon that I would attend. 23:54 There would be people using face.com even if face.com wasn't sponsoring. 24:01 If it was face detection and, this is mood detection. 24:05 And so someone build a, a thing that actually rated you 24:08 with points on how good you did at a particular mood. 24:12 And so this was my attempt to get to 99 on surprised. 24:15 But Facebook acquired them before I could get there. 24:19 And shut down the API. 24:23 But one, one fun bit of trivia. 24:26 When Facebook buys Barnes & Noble, which, you know, is gonna happen, right? 24:29 They'll own both face.com and book.com. 24:33 So, wait for, wait for that. 24:37 They're halfway there. 24:38 With face.com. 24:39 [SOUND] So with with company viability it used to be very easy. 24:43 It's, I mean, it's certainly from the, from the three examples I gave, 24:47 you say okay, go with a, go with a big name company, right? 24:51 And so it used to be yeah, if you've got 24:55 something from, is it, if it's from Google or Yahoo. 24:57 You know, that's a, that's a good choice cuz that'll be 25:00 around, well, the companies are around, but not necessarily the APIs. 25:03 So this is I have this one up here cuz I'm just really 25:11 happy with my headline that the Google translate API to go, kaputt in December. 25:14 So Google announces back in 2011 that, it was going away. 25:20 Right? 25:25 This is an API that, a lot of people counted on, but 25:26 they weren't paying anything for it, we were getting it completely free. 25:30 But we thought oh, Google's going to be around. 25:33 They're gonna, they're gonna do that. 25:34 It turns out people were, actually using 25:35 it against Google to be able to, translate. 25:38 Text from one page to another and then use that, for SEO purposes. 25:42 so, but everyone, everyone got upset. 25:47 Cuz there were people who were using it for, for good as well. 25:50 And so, just a couple of days later, Google 25:54 said, okay, we'll offer a paid version of this API. 25:57 And so that really, leads to I think the biggest 26:03 thing that you should for when you're looking at APIs. 26:06 It's hard to figure company viability, even harder to look into, large company 26:09 like Google and say, what's the viability of this product within this company. 26:14 But it gets easier, when there's some way to pay. 26:19 And so, these are the main ways that these API products are charging. 26:24 There's pay as you go that's kind of the, Twilio model of, you you make this number 26:29 of phone calls or SMS and you pay a, penny each. 26:34 Tiered which is more kind of traditional SAS model where. 26:39 Where you have certain features that you maybe get 26:43 in a, in an upper tier or a certain volume 26:45 that you pay for, and then there's the tiered with 26:48 the trial, and that of course is the most popular. 26:50 And, and I put that, in, in a number of, 26:55 of of talks, and I have yet to get a laugh. 26:59 With my most popular batch, and that's okay. 27:03 Oh no, no, no, now, now you just, if you laugh now, I'll just feel worse. 27:06 >> [LAUGH]. 27:12 >> [LAUGH] so, but looking for a way, 27:13 that you can actually pay for what they're providing. 27:17 It makes sense if you're, if you're, Trading in, hours that you'd be spending. 27:21 It's, for, for what you pay for some of these services 27:28 it's, downright cheap to be able to, to pay for it. 27:31 So look for a way to pay. 27:34 Because that's most likely the, be, in a company that's going to stay around. 27:36 And then you wanna look for some 27:44 transparency around uptime and latency cuz that's 27:45 certainly, like that's, the biggest risk is 27:48 you integrate with something, that is always down. 27:50 Right. 27:53 So, see some way, a, a status page. 27:54 This is from a blog post on the Orchestrate blog. 27:57 We certainly think about that if your using 28:01 a database, you wanna make sure that, that 28:02 you can actually make the calls to it and not have it slow down your application. 28:06 but, I think if you're looking for a best practice, I mean, 28:12 GitHub, is all about working with 28:15 developers and helping developers work flow. 28:17 Right, and so they've got a great status page. 28:20 That's really transparent about, their up time and and their response time. 28:23 And so, look for, you know, use that as the, as the high bar and look 28:29 for something gets, gets near that, And it, 28:33 and a company that's willing to talk about it. 28:37 Then, of course, the ease of self-service. 28:42 Okay, hand up time. 28:45 Who has, has seen a page like this to request a demo 28:47 of an API and closed the window and not filled out the form? 28:50 Yeah, raise them high! 28:54 Yeah, me too. 28:56 And there's still a lot of that what 29:00 you're looking for is more something like this. 29:02 Oh, I can see how it works, I can sign up for free. 29:05 That's Twilio again. 29:08 So look for that ability to self-serve because, waiting for someone else. 29:11 Is just going to delay your development time. 29:18 So you wanna be able to, to work on it on your own. 29:21 But you also want, that full service if its available, so who, has 29:26 gone to a contact page and only seen, a form like that, right? 29:30 So you fill out the form and you have no idea where it's going into the ether. 29:37 Much better would be okay, you can submit a ticket, 29:44 or hey, there's, people in a public chat right now. 29:47 And, I admit that both of these are from Orchestrate. 29:53 And I think we need to fix the, the first one, there's, there's some of 29:57 a different contact for before your customer 30:00 and after your customer, even a free, account. 30:02 You certainly need to change that, because what 30:05 you wanna look for, before you've committed to, 30:07 to someone, is that when you have a 30:10 problem, you'll be able to have that answer. 30:12 So these were the, the six things to look for. 30:18 Company viability, the product viability, some way to 30:21 pay, transparency about uptime and latency, and then 30:24 you want it to be easy to self serve, but also easy to get, full service support. 30:28 From the API that you are considering to 30:35 have the, the base of of the Pareto-as-a-service pyramid. 30:38 So that's how to evaluate APIs, and you are evaluating them because you 30:44 wanna focus on your core strengths, and you are able to do that. 30:50 Because of the way architecture has changed, just in the last few years. 30:54 And so, you want to really, get the full, ability of Pareto-as-a-service. 31:01 When you're able to put 80%, of your effort into that 31:07 top 20%, and, leave the rest to those APIs and Cloud Services. 31:10 So, the next time you're all furiously developing, I hope the 31:17 headaches aren't coming up, you don't have problems with the server. 31:24 Emails going to spam, databases that you have to restart. 31:28 I hope instead you have, an Italian economist from 100 years ago. 31:32 Inside your head, just like I do. 31:37 So, thank you. 31:39 [APPLAUSE]. 31:43 Any questions? 31:47 All crystal. 31:53 Everyone knows how to evaluate APIs now. 31:53 You are gonna go, you aren't gonna build anything. 31:55 Look at that. 31:59 There is one right here. 31:59 >> So is there a certain amount of vulnerability whenever [SOUND] you 32:01 rely on somebody else's service so what are some strategies can you, 32:06 use to evaluate that risk and, mitigate it to reduce feature loss? 32:12 >> Are you sure you don't wanna have the guy next to you ask that question? 32:17 >> Sorry. 32:20 >> [LAUGH]. 32:20 >> He was, he was testing, so, [LAUGH]. 32:21 >> So, you should definitely, go to John Sheehan's talk this 32:26 afternoon at 2 o'clock, where he'll talk about Runscope, which is, a 32:30 service for being able to monitor those, APIs and Get errors 32:34 for, as they come through, there we go, did I do good? 32:41 >> Yeah, [LAUGH]. 32:44 >> And, but of course, but of course you wanna go to, Christians talk at 11, right? 32:45 Where if your designing one of those APIs especially 32:52 wanting to, To, to help people take advantage of Pareto-as-a-service. 32:55 You can find out how to, create irresistible APIs. 33:01 Any questions from non-speakers? 33:06 >> [LAUGH]. 33:08 >> Yes. 33:09 Right back there. 33:10 >> I worked at an enterprise. 33:10 And something like the Persona. 33:12 We, we're gonna test that and it, it got shut down. 33:15 We [INAUDIBLE] just a horrible thing to do. 33:18 [INAUDIBLE] You know, is there a easy way to convince 33:21 leaders that that's, you know, that's a good thing to do. 33:27 >> So, so the issue, the issue was that you. 33:33 You work in an enterprise and you did invest in, Persona. 33:37 >> [INAUDIBLE]. 33:40 >> If you, if you did. 33:42 Right, and that was a huge call not to, not to do it. 33:44 Yeah, I mean, I think, there are a lot of risks in, in development. 33:48 Someone who, if you built a login system yourself. 33:54 And you left. 33:58 That's a risk for the company, right? 33:59 so, I mean, I think you, in looking at 34:02 what's core, I would argue that, some, some kind 34:05 of login system is not core to many companies 34:10 but, it depends on the level of risk that. 34:14 That you're comfortable with in you organization. 34:18 So, it all, it's, the trouble with this talk is 34:19 it's hard to, it's hard to completely, tell people this 34:22 is exactly what you should and shouldn't, you know, it's 34:26 very, it's gonna be very custom to, to your organization, yeah. 34:29 [BLANK_AUDIO] 34:33 Other questions? 34:37 Okay, well bashful people, I'll stay up here, or 34:41 there's a a meet the speakers this afternoon as well, so, thanks again. 34:46 Hm. 34:54 [APPLAUSE] 34:54
You need to sign up for Treehouse in order to download course files.Sign up