 Live from New York, it's the queue. Covering AWS Global Summit 2019. Brought to you by Amazon Web Services. Welcome back to New York City. This is AWS Summit and I'm Stu Miniman. My co-host is Corey Quinn. We've talked to Amazon executives. We've talked to some customers. We've also talked to some of the partners and part of the partner ecosystem is of course these startups. AWS, very robust ecosystem that they've been building out and one of the pieces we're really excited to dig into in the serverless space. Happy to bring the program for the first time. Ken Robbins is the CEO and founder of GoTo Software who's the maker of Cloud Pegboard. Thanks so much for joining us. I'm happy to be here, it's really exciting. All right, so Cloud Pegboard, you had us hooked when we talked about serverless, the information overload that we all feel in the AWS world. Corey's got a full-time job helping with that and other things related to it. So it brings us a little bit about Cloud Pegboard and your background. Yeah, I want to help you out. So my background is I ran a major cloud transformation to Amazon on my past job, which I left in January and really saw this problem, this information overload was slowing people down. People making suboptimal choices. They're spending a lot of time trying to keep up. Sometimes we have to refactor because it didn't have the right information at the right time. And I realized we need to solve this and it wasn't just in our organization. Every Amazon practitioner across the planet really needs help to keep up. When I talk with people at these conferences, it's like the main comment, like I can't consume it all, how do I keep up? Ken, it is staggering. I actually, I stopped asking about two years ago how you keep up because I talked to some amazingly smart, well-connected people and they're like, no, no, it's impossible. But I want you to comment on something. So it used to be when you talked about I need to start this. I should have started a year ago, but I didn't, so I should start now. And now it feels like, well, if I could, I actually should wait a couple of months or six months or even a year, but I absolutely need to get started. So I guess I might as well start now because things change at such a pace. I mean, that, you know, oh wait, if I could just wait a little bit longer, it's going to be more and better and cheaper and faster. So, you know, what's your take in kind of the pace of change in the industry? Well, you know, one thing is to think, you guys just have to keep agile and buy into the fact that you're going to have to throw away things. Like, don't get so married, build with what you can do today as best you can, but be ready to refactor and get rid of it. Oh, oh my God. The IT organization under the whole are hoarders. Everything in IT is additive. Nothing ever dies, but I do agree with you. We've been, you know, for more than a decade, you know, our annual esteem of talking, you have to get rid of stuff and that needs to be able to do that. That, you know, sunk costs is something if you're familiar with economics is, you know, I need to understand that, that even I've been doing it for a while, we need to be able to cut that. But we have these attachments to the things we've been doing and how we've been doing it. No, change isn't necessarily easy. Right, well, there's a reason for some of the attachments because there's a lot of investment to build up in the first place. And when you put so much sweat into it, then I don't want to undo it. When it gets easier to build, it's easier to throw away. So I was just giving this talk earlier and saying religiously stick with infrastructure as code. Because if you do that, it's just so easy to make incremental changes. And again, serverless makes everything so much easier. You really don't get so married to something if it's changing like one limb to function. You know, it's just not a bunch of a big deal. So if you invest a little bit less, and it's easier by making use, especially at the high level managed services, then it's easier to pivot from one thing to the another when you need to. Yeah, and something I've found as I play with this stuff myself in a very similar space with less comprehensiveness and far more sarcasm, I suspect, than your service does, is that when you're building everything out of composited Lambda functions tied together in a microservices style, refactoring one of those microservices usually doesn't take more than a day or two, as opposed to, oh, just rebuild the entire monolith from scratch, which it feels like everyone tries to do at some point. It almost enforces good behavior and makes it easier to evolve. Has that been your experience, or do you see it differently? Absolutely, so there's two things. It helps, it's easier to refactor and throw things out because it's small, and that's, again, you're not married to it as much, but it's also easy to incrementally add on. So I have this whole tier of these microservices that I capture, all this data that we're pulling in from multiple sources, whether it's Amazon's website or Terraform or GitHub, any source I can find that has data that I want to organize to help with my users. So we're continually finding new data sources. Well, each new data source is essentially a new Lambda function. It's independent, and if I change it, we actually had one recently, I found a better data source, I just threw out the old one and plugged in the new one, and it's really less than a day to write the new function and deploy it into production. So, yeah. So, Ken, one of the answers I've had for a long time is I need to rely on my consultants and my suppliers because you don't even understand some of these architectural things that are going on and things are changing so fast. So, how much could software solve this for us and the tools itself? I have to imagine there's still a lot of people involved. Yeah, there's always going to be a lot of people involved. And there is no free lunch that every architect or developer of Amazon, you still need to get yourself trained, get the certifications, read the white papers, keep up to date with all the changes, and we really do, when we're running inside, again, back to my past life as an enterprise, you really want to build internal excellence. Certainly, we can use outside help when you need it, especially for augmentation, and there's lots of smart people everywhere, but you definitely want to have some internal expertise and people that are committed to growing and continuing, going to New York Summit, going to re-invent, talking to people and always constantly learning. Because it's going to take human effort to help filter down and find out where's the trend that I really need to start thinking about. Now, hopefully cloud paper, what is a tool, helps people be much more efficient and focus in much easier, but nothing will replace engineers, which is a good thing, yeah. Right, and for those who are outside of the, I guess, very small fraternity, we've apparently built, now there are two of us who track this stuff for a living, it is far more complex than most people would accept. Oh, why don't you just sign up for the RSS feed? Well, for starters, there's over a dozen official AWS RSS feeds, and they're not all inclusive. You have to look at pull requests getting merged in. There are API updates, you see it in cloud formation and terraform from time to time, and I am certainly not comprehensive. In fact, when I built my newsletter originally, my thought was that someone was going to point out something like cloud pegboard and say, well, idiot, use this instead, and then I shut it down and admit defeat, and that was the plan. Instead, a bunch of people signed up, and now I want people to read it for the jokes, not because it's the only half-sensible way to figure out what happened last week. So I'm a huge fan of the problem you're solving and the way you've gone about doing it. That said, when we talk about serverless architectures, you mentioned spinning up Lambda functions and tying it back into other things, but as they mentioned in the keynote today, serverless goes beyond just functions as a service, there's a lot more to it than that. What else does your architecture include? Everything serverless and exclusively so. So they're Pokemon, so you're collecting every serverless thing they offer and then some just to get the style points. There we go. Exactly. Well, so, you know, one of those, we have several strategic principles, and one of them is to rely solely on serverless because I just can't afford as a small startup to be building out non-functional requirements that aren't building the business, so S3 hosting, DynamoDB, CloudFront API gateway, and we use a lot of these features. Not only do I use all serverless, but we're also using it for disaster recovery design so that we're using some additional features within these so it's easier to fail over. So CloudFront, for example, has ARGEN failover, it's a relatively new feature, and it's really amazing, right? I can go to my S3 and I have all the benefits of S3 serverless hosting, but now in a failure, CloudFront will route to my alternate region and continue operating. Same thing with DynamoDB, using global table replication. Finally, we got- And continuous backup, which they released, I'm not kidding, three days after I really needed it. It's, that seems like that's always the case where they have these features and they come in right after you needed it, right after you built a crappy version of it, and it's one of those, and what I love about things that are relatively small scale like this is the economics are ridiculous. Well, watch out for continuous backups, that could be expensive, and I wound up checking it and it wound up being something like two cents a month. Yeah, I'll work real hard to bring enough in to cover the backup, please. I had someone come up to me after one of the talks and asking like, he's not in Amazon, he's thinking of moving there, it's like how much, I have something that's a little bit similar to what you're doing and how much will it cost and how much should I budget, and I'd say, to be honest, I've got some credits that I've been hoarding, but I can't spend them. I want to accelerate by spending money, I can't do it, especially with DynamoDB, used to be that you would provision something with a lot of IOPS, and that would rack up fairly fast. Now I'm using the on-demand, and it's just not costing anything. So that's what, again, this Vernon was talking about not paying for idle time. Yeah, and some of the monitoring tools in the serverless space are still approaching it from an economic first perspective, which for anything that isn't already scaled out is ludicrous. It has like warnings going, arrows going up or down on my spend on my lambdas every month, and it's 22 cents. I appreciate where you're going with this, but maybe that's not the driving concern right now. So I had a funny experience where I turned on Macy so we could get some good inspection on all my buckets, and on the first of the month, I got a notice saying, hey, you exceeded the free tier, and I was in a bit of a panic because there's been more than once, I'm sad to say that where I've let things run longer than they should and paid the price, and I said, oh, something has run amuck. Well, it turns out just because of the metadata scans, it does kind of use a lot of accesses, but then still was under a buck for the whole month by the time I was done, because it came in at the beginning of the month in a bunch of scanning. Yeah, I'm just a big fan of serverless. You know, I did this thing, so go ahead. Yeah, Ken, speaking of serverless, Amazon EventBridge was announced this morning, really building that event ecosystem around Lambda. Curious, what impact that'll have on you? Will Cloud Pegboard be able to go outside of AWS to kind of understand some of these SaaS applications? I have to learn more about it. I was not in on a preview or anything, so I don't know exactly yet, but yes, we're partnering with other providers anywhere there's an information source that can help developers hone in better and kind of get everything in the right place at the right time. And so, yes, things like that will help, especially if it can work through, I don't want to be opening up SQSQs and worry about the IAM, the cross-account, that can be complicated, so I'll be interested to learn and I don't know yet if that will help in those sorts of integrations, especially on the authentication and authorization aspects of it. Yeah, there's a lot of promise in the idea of being able to give the minimum, viable, required API call for something third-party. It seems like they'll integrate into something like that and well, here's how IAM works and then we have to worry about access controls and oh, yeah, there's no direct IP address to whitelist and on and on and on. It's challenging to, I guess, forcibly upgrade third parties unless you're effectively a giant, world-spanning company who can demand that they do it. So this, it really feels like we're meeting third parties in some ways where they are. Yeah, I think so and I think this is, I'm looking forward to that because I want to both consume APIs but also all my data is available via API so today it's a bit of a traditional key and rest sort of interface but if I could export that in other ways, that would be very interesting as well. I think it's too easy to get stuck in the economic story at times. I know it's weird as a cloud economist to be saying that but when it comes to serverless, the value is less about cost control and saving money and it is, you don't have to worry about entire subsets of problems. Capacity planning, effectively when it comes to things like Lambda, DynamoDB and the rest, the constraint on scaling is going to be your budget, I promise, no matter who these budgets are, go for them. This is what they run Amazon.com on. I don't think I'm going to do more business than that unless I really misconfigure something. Challenge accepted. Yeah, yeah. So I totally agree that scaling is the value but there's more, right? The scaling is absolutely one and then in addition to agility because serverless means serverless but now the term is getting confused, right? It means so many things. So I would say serverless managed services to help say, oh, I'm talking about more than compute. What it also means is I'm getting a very high level function. So I'm getting, so for example, we're using Comprehend. That's an awful lot of stuff going on under there that I don't have to worry about. I mean, I literally have an intern in a couple of days completed a task to do some entity extraction of essentially Amazon service names out of some unstructured data. She was able to do it. She's just finished her freshman year, right? She was able to do this with minimal training because it's serverless. She didn't worry about the scalability. What she needed to know is that, oh, I can use this function, I can read an API documentation and I can just use it. And then for me, another big function, being high on the stack but also the no maintenance, low, maybe more of an accurate term, but essentially it's no maintenance, especially for a small startup. I used to have businesses way back when pre-internet, I ran an aviation weather service and my life was this bane of my existence because it had to be up 24 seven. I had big satellite dishes that would get snowed on. I was an idiot and did this in New England and they have to shovel them off at four in the morning. I don't like waking up in the middle of the night to serve my computers. They should serve me. And the serverless, the fact that there's no maintenance, stuff just runs. Think about the times, how many times have you had a server in the past where you just thought you should reboot it every week because maybe there's tradition and maybe there's a leak somewhere. A lambda function reboots every invocation. It just never happens that I have a, and it run out of resources or something like that. I'm just, yeah, I love affair. All right, so Ken, it's obvious how you feel about serverless, but as a startup, just give us final thoughts on what it's like to be a startup that is on with and using AWS. Well, for me, it's fantastic. It allows me to focus on the problem to solve immediately and by using high in the stack, like I was saying, serverless capabilities, I'm not worried about the infrastructure. I write a little bit of confirmation, I deploy it, and I'm always working on business logic and functionality and I'm not worrying about will it scale? Do I have to maintain it? I can really focus on the problems to solve and that's really been very helpful to me. So now we have something where I can scale. I'm hoping I'm not there yet, but every Amazon practitioner should want to use Cloud Pegboard, I think. It helps with a general problem. So I need to be able to scale to millions, bursty, I don't know what the adoption rate's going to be, but I have confidence because I'm using all these serverless capabilities. S3 will do it. Amazon Gateway and Lambda will do it, so I don't have to worry about it. So for a startup to not have to worry about that is really pretty powerful. And by the time you wind up in a cost-prohibitive situation where, okay, running some baseline level load that's on something that isn't serverless begins to make significant economic sense, at that point your traffic volumes definitionally are so high that by that point there's a team of people who will be able to focus on that. You don't need to bring those people in to get off the ground in the same way. Right, it's that fast start and we got to learn. There's so much to learn here with any startup, but in mine as well, to really get some of that user experience, get the feedback. We have a lot of good ideas and I think what we have now is helpful. I have a long-term roadmap with a lot of great ideas, but it's going to take a lot of user feedback to say, is this work? And the serverless lets you try things quickly. I can get in front of people, get that learning cycle going and iterate as fast as possible. And so that'll be really important. Well, Ken Robbins, really help you, appreciate you educating our audience about Cloud Tag Board. Wish you best of luck with the solution. Yeah, I appreciate being here. All right, for Corey Quinn, I'm Stu Miniman. We'll be back with more coverage here from AWS Summit in New York City. Thanks as always for watching theCUBE.