(upbeat music) >> From the Silicon Angle Media office in Boston, Massachusetts, it's theCube. Now, here's your host, Stu Miniman. >> Hi, I'm Stu Miniman, and welcome to the first interview of theCube in our Boston area studio for 2020. And to help me kick it off, Jeremy Daly who is the host of Serverless Chats as well as runs the Serverless Day Boston. Jeremy, saw you at reInvent, way back in 2019, and we'd actually had some of the people in the community that were like hey, "I think you guys like actually live and work right near each other." >> Right. >> And you're only about 20 minutes away from our office here, so thanks so much for making the long journey here, and not having to get on a plane to join us here. >> Well, thank you for having me. >> All right, so as Calvin from Calvin and Hobbes says, "It's a new decade, but we don't have any base on the moon, "we don't have flying cars that general people can use, "but we do have serverless." >> And our robot vacuum cleaners. >> We do have robot vacuum cleaners. >> Which are run by serverless, as a matter of fact. >> A CUBE alum on the program would be happy that we do get to mention there. So yeah, you know serverless there are things like the iRobot, as well as Alexa, or some of the things that people, you know usually when I'm explaining to people what this is, and they don't understand it, it's like, Oh, you've used Alexa, well those are the functions underneath, and you think about how these things turn on, and off, a little bit like that. But maybe, we don't need to get into the long ontological discussion or everything, but you know you're a serverless hero, so you know give us a little bit, what your hearing from people, what are some of the exciting use cases out there, and you know where serverless is being used in that maturity today. >> Yeah, I mean well, so the funny thing about serverless and the term serverless itself, and I do not want to get into a long discussion about this, obviously. I actually wrote a post last year that was called stop calling everything serverless, because basically people are calling everything serverless. So it really, what it, what I look at it as, is something where, it just makes it really easy for developers to abstract away that back end infrastructure, and not having to worry about setting up Kubernetes, or going through the process of setting up virtual machines and installing software is just, a lot of that stuff is kind of handled for you. And I think that is enabled, a lot of companies, especially start-ups is a huge market for serverless, but also enterprises. Enabled them to give more power to their developers, and be able to look at new products that they want to build, new services they want to tackle or even old services that they need to, you know that may have some stability issues or things like long running ETL tasks, and other things like that, that they found a way to sort of find the preferal edges of these monolithic applications or these mainframes that they are using and find ways to run very small jobs, you know using functions as a server, something like that. And so, I see a lot of that, I think that is a big use case. You see a lot of large companies doing. Obviously, people are building full fledged applications. So, yes, the web facing user application, certainly a thing. People are building API's, you got API Gateway, they just released the new HEDP API which makes it even faster. To run those sort of things, this idea of cold starts, you know in AWS trying to get rid of all that stuff, with the new VPC networking, and some of the things they are doing there. So you have a lot of those type of applications that people are building as well. But it really runs the gambit, there are things all across the board that you can do, and pretty much anything you can do with the traditional computing environment, you can do with a serverless computing environment. And obviously that's focusing quite a bit on the functions as a service side of things, which is a very tiny part of serverless, if you want to look at it, you know sort of the broader picture, this service full or managed services, type approach. And so, that's another thing that you see, where you used to have companies setting up you know, mySQL databases and clusters trying to run these things, or even worse, Cassandra rings, right. Trying to do these things and manage this massive amount of infrastructure, just so that they could write a few records to a database and read them back for their application. And that would take months sometimes, for them to get it setup and even more time to try to keep running them. So this sort of revolution of managed services and all these things we get now, whether that the things like managed elastic search or elastic search cloud doing that stuff for you, or Big Table and Dynamo DB, and Manage Cassandra, whatever those things are. I'm just thinking a lot easier for developers to just say hey, I need a database, and okay, here it is, and I don't have to worry about the infrastructure at all. So, I think you see a lot of people, and a lot of companies that are utilizing all of these different services now, and essentially are no longer trying to re-invent the wheel. >> So, a couple of years ago, I was talking to Andy Jassy, at an interview with theCube, and he said, "If I was to build AWS today, "I would've built it on serverless." And from what I've seen over the last two or three years or so, Amazon is rebuilding a lot of there servers underneath. It's very interesting to watch that platform changing. I think it's had some ripple effect dynamics inside the company 'cause Amazon is very well known for their two pizza teams and for all of their products are there, but I think it was actually in a conversation with you, we're talking about in some ways this new way of building things is, you know a connecting fabric between the various groups inside of Amazon. So, I love your view point that we shouldn't just call everything serverless, but in many ways, this is a revolution and a new way of thinking about building things and therefore, you know there are some organizational and dynamical changes that happen, for an Amazon, but for other people that start using it. >> Yeah, well I mean I actually was having a conversation with a Jay Anear, whose one of the product owners for Lambda, and he was saying to me, well how do we sell serverless. How do we tell people you know this is what the next way to do things. I said, just, it's the way, right. And Amazon is realized this, and part of the great thing about dog fooding your own product is that you say, okay I don't like the taste of this bit, so we're going to change it to make it work. And that's what Amazon has continued to do, so they run into limitations with serverless, just like us early adopters, run into limitations, and they say, we'll how do we make it better, how do we fix it. And they have always been really great to listening to customers. I complain all the time, there's other people that complain all the time, that say, "Hey, I can't do this." And they say, "Well what if we did it this way, and out of that you get things like Lambda Destinations and all different types of ways, you get Event Bridge, you get different ways that you can solve those problems and that comes out of them using their own services. So I think that's a huge piece of it, but that helps enable other teams to get past those barriers as well. >> Jeremy, I'm going to be really disappointed if in 2020, I don't see a T-shirt from one of the Serverless Days, with the Mandalorian on it, saying, "Serverless, this is the way." Great, great, great marketing opportunity, and I do love that, because some of the other spaces, you know we're not talking about a point product, or a simple thing we do, it is more the way of doing things, it's just like I think about Cybersecurity. Yes, there are lots of products involved here but, you know this is more of you know it's a methodology, it needs to be fully thought of across the board. You know, as to how you do things, so, let's dig in a little bit. At reInvent, there was, when I went to the serverless gathering, it was serverless for everyone. >> Serverless for everyone, yes. >> And there was you know, hey, serverless isn't getting talked, you know serverless isn't as front and center as some people might think. They're some people on the outside look at this and they say, "Oh, serverless, you know those people "they have a religion, and they go so deep on this." But I thought Tim Wagner had a really good blog post, that came out right after reInvent, and what we saw is not only Amazon changing underneath the way things are done, but it feel that there's a bridging between what's happening in Kubernetes, you see where Fargate is, Firecracker, and serverless and you know. Help us squint through that, and understand a little bit, what your seeing, what your take was at reInvent, what you like, what you were hoping to see and how does that whole containerization, and Kubernetes wave intersect with what we're doing with serverless? >> Yeah, well I mean for some reason people like Kubernetes. And I honestly, I don't think there is anything wrong with it, I think it's a great container orchestration system, I think containers are still a very important part of the workloads that we are putting into a cloud, I don't know if I would call them cloud native, exactly, but I think what we're seeing or at least what I'm seeing that I think Amazon is seeing, is they're saying people are embracing Kubernetes, and they are embracing containers. And whether or not containers are ephemeral or long running, which I read a statistic at some point, that was 63% of containers, so even running on Kubernetes, or whatever, run for less than 10 minutes. So basically, most computing that's happening now, is fairly ephemeral. And as you go up, I think it's 15 minutes or something like that, I think it's 70% or 90% or whatever that number is, I totally got that wrong. But I think what Amazon is doing is they're trying to basically say, look we were trying to sell serverless to everyone. We're trying to sell this idea of look managed services, managed compute, the idea that we can run even containers as close to the metal as possible with something like Fargate which is what Firecracker is all about, being able to run virtual machines basically, almost you know right on the metal, right. I mean it's so close that there's no level of abstraction that get in the way and slow things down, and even though we're talking about milliseconds or microseconds, it's still something and there's efficiencies there. But I think what they looked at is, they said look at we are not Apple, we can't kill Flash, just because we say we're not going to support it anymore, and I think you mention this to me in the past where the majority of Kubernetes clusters that were running in the Public Cloud, we're running in Amazon anyways. And so, you had using virtual machines, which are great technology, but are 15 years old at this point. Even containerization, there's more problems to solve there, getting to the point where we say, look you want to take this container, this little bit of code, or this small service and you want to just run this somewhere. Why are we spinning up virtual containers. Why are we using 15 or 10 year old technology to do that. And Amazon is just getting smarter about it. So Amazon says hay, if we can run a Lambda function on Firecracker, and we can run a Fargate container on Firecracker, why can't we run, you know can we create some pods and run some pods for Kubernetes on it. They can do that. And so, I think for me, I was disappointed in the keynotes, because I don't think there was enough serverless talk. But I think what they're trying to do, is there trying to and this is if I put my analyst hat on for a minute. I think they're trying to say, the world is at Kubernetes right now. And we need to embrace that in a way, that says we can run your Kubernetes for you, a lot more efficiently and without you having to worry about it than if you use Google or if you use some other cloud provider, or if you run on-prem. Which I think is the biggest competitor to Amazon is still on-prem, especially in the enterprise world. So I see them as saying, look we're going to focus on Kubernetes, but as a way that we can run it our way. And I think that's why, Fargate and Kubernetes, or the Kubernetes for Fargate, or whatever that new product is. Too many product names at AWS. But I think that's what they are trying to do and I think that was the point of this, is to say, "Listen you can run your Kubernetes." And Claire Legore who showed that piece at the keynote, Vernor's keynote that was you know basically how quickly Fargate can scale up Kubernetes, you know individual containers, Kubernetes, as opposed to you know launching new VM's or EC2 instances. So I thought that was really interesting. But that was my overall take is just that they're embracing that, because they think that's where the market is right now, and they just haven't yet been able to sell this idea of serverless even though you are probably using it with a bunch of things anyways, at least what they would consider serverless. >> Yeah, to part a little bit from the serverless for a second. Talk about multi-cloud, it was one of the biggest discussions, we had in 2019. When I talk to customers that are using Kubernetes, one of the reasons that they tell me they're doing it, "Well, I love Amazon, I really like what I'm doing, "but if I needed to move something, it makes it easier." Yes, there are some underlying services I would have to re-write, and I'm looking at all those. I've talked to customers that started with Kubernetes, somewhere other than Amazon, and moved it to Amazon, and they said it did make my life easier to be able to do that fundamental, you know the container piece was easy move that piece of it, but you know the discussion of multi-cloud gets very convoluted, very easily. Most customers run it when I talk to them, it's I have an application that I run, in a cloud, sometimes, there's certain, you know large financials will choose two of everything, because that's the way they've always done things for regulation. And therefore they might be running the same application, mirrored in two different clouds. But it is not follow the sun, it is not I wake up and I look at the price of things, and deploy it to that. And that environment it is a little bit tougher, there's data gravity, there's all these other concerns. But multi-cloud is just lots of pieces today, more than a comprehensive strategy. The vision that I saw, is if multi-cloud is to be a successful strategy, it should be more valuable than the sum of its pieces. And I don't see many examples of that yet. What do you see when it comes to multi-cloud and how does that serverless discussion fit in there? >> I think your point about data gravity is the most important thing. I mean honestly compute is commoditized, so whether your running it in a container, and that container runs in Fargate or orchestrated by Kubernetes, or runs on its own somewhere, or something's happening there, or it's a fast product and it's running on top of K-native or it's running in a Lambda function or in an Azure function or something like that. Compute itself is fairly commoditized, and yes there's wiring that's required for each individual cloud, but even if you were going to move your Kubernetes cluster, like you said, there's re-writes, you have to change the way you do things underneath. So I look at multi-cloud and I think for a large enterprise that has a massive amount of compliance, regulations and things like that they have to deal with, yeah maybe that's a strategy they have to embrace, and hopefully they have the money and tech staff to do that. I think the vast majority of companies are going to find that multi-cloud is going to be a completely wasteful and useless exercise that is essentially going to waste time and money. It's so hard right now, keeping up with everything new that comes out of one cloud right, try keeping up with everything that comes out of three clouds, or more. And I think that's something that doesn't make a lot of sense, and I don't think you're going to see this price gauging like we would see with something. Probably the wrong term to use, but something that we would see, sort of lock-in that you would see with Oracle or with Microsoft SQL, some of those things where the licensing became an issue. I don't think you're going to see that with cloud. And so, what I'm interested in though in terms of the term multi-cloud, is the fact that for me, multi-cloud really where it would be beneficial, or is beneficial is we're talking about SaaS vendors. And I look at it and I say, look it you know Oracle has it's own cloud, and Google has it's own cloud, and all these other companies have their own cloud, but so does Salesforce, when you think about it. So does Twilio, even though Twilio runs inside AWS, really its I'm using that service and the AWS piece of it is abstracted, that to me is a third party service. Stripe is a third-party service. These are multi-cloud structure or SaaS products that I'm using, and I'm going to be integrating with all those different things via API's like we've done for quite some time now. So, to me, this idea of multi-cloud is simply going to be, you know it's about interacting with other products, using the right service for the right job. And if your duplicating your compute or you're trying to write database services or something like that that you can somehow share with multiple clouds, again, I don't see there being a huge value, except for a very specific group of customers. >> Yeah, you mentioned the term cloud-native earlier, and you need to understand are you truly being cloud-native or are you kind of cloud adjacent, are you leveraging a couple of things, but you're really, you haven't taken advantage of the services and the promise of what these cloud options can offer. All right, Jeremy, 2020 we've turned the calendar. What are you looking at, you know you're planning, you got serverless conference, Serverless Days-- >> Serverless Days Boston. >> Boston, coming up-- >> April 6th in Cambridge. >> So give us a little views to kind of your view point for the year, the event itself, you got your podcast, you got a lot going on. >> Yeah, so my podcast, Serverless Chats. You know I talk to people that are in the space, and we usually get really really technical. So if you're a serverless geek or you like that kind of stuff definitely listen to that. But yeah, but 2020 for me though, this is where I see what is happened to serverless, and this goes back to my "Stop calling everything serverless" post, was this idea that we keep making serverless harder. And so, as a someone whose a serverless purist, I think at this point. I recognize and it frustrates me that it is so difficult now to even though we're abstracting away running that infrastructure, we still have to be very aware of what pieces of the infrastructure we are using. Still have setup the SQS Queue, still have to setup Event Bridge. We still have to setup the Lambda function and API gateways and there's services that make it easier for us, right like we can use a serverless framework, or the SAM framework, or ARCH code or architect framework. There's a bunch of these different ones that we can use. But the problem is that it's still very very tough, to understand how to stitch all this stuff together. So for me, what I think we're going to see in 2020, and I know there is hints for this serverless framework just launched their components. There's other companies that are doing similar things in the space, and that's basically creating, I guess what I would call an abstraction as a service, where essentially it's another layer of abstraction, on top of the DSL's like Terraform or Cloud Formation, and essentially what it's doing is it's saying, "I want to launch an API that does X-Y-Z." And that's the outcome that I want. Understanding all the best practices, am I supposed to use Lambda Destinations, do I use DLQ's, what should I throttle it at? All these different settings and configurations and knobs, even though they say that there's not a lot of knobs, there's a lot of knobs that you can turn. Encapsulating that and being able to share that so that other people can use it. That in and of itself would be very powerful, but where it becomes even more important and I think definitely from an enterprise standpoint, is to say, listen we have a team that is working on these serverless components or abstractions or whatever they are, and I want Team X to be able to use, I want them to be able to launch an API. Well you've got security concerns, you've got all kinds of things around compliance, you have what are the vetting process for third-party libraries, all that kind of stuff. If you could say to Team X, hey listen we've got this component, or this piece of, this abstracted piece of code for you, that you can take and now you can just launch an API, serverless API, and you don't have to worry about any of the regulations, you don't have to go to the attorneys, you don't have to do any of that stuff. That is going to be an extremely powerful vehicle for companies to adopt things quickly. So, I think that you have teams now that are experimenting with all of these little knobs. That gets very confusing, it gets very frustrating, I read articles all the time, that come out and I read through it, and this is all out of date, because things have changed so quickly and so if you have a way that your teams, you know and somebody who stays on top of the learning this can keep these things up to date, follow the most, you know leading practices or the best practices, whatever you want to call them. I think that's going to be hugely important step from making it to the teams that can adopt serverless more quickly. And I don't think the major cloud vendors are doing anything in this space. And I think SAM is a good idea, but basically SAM is just a re-write of the serverless framework. Whereas, I think that there's a couple of companies who are looking at it now, how do we take this, you know whatever, this 1500 line Cloud Formation template, how do we boil that down into two or three lines of configuration, and then a little bit of business logic. Because that's where we really want to get to. It's just we're writing business logic, we're no where near there right now. There's still a lot of stuff that has to be done, around configuration and so even though it's nice to say, hey we can just write some business logic and all the infrastructure is handled for us. The infrastructure is handled for us, if we configure it correctly. >> Yeah, really remind me some of the general thread we've been talking about, Cloud for a number of years is, remember back in the early days, is cloud is supposed to be inexpensive and easy to use, and of course in today's world, it isn't either of those things. So serverless needs to follow those threads, you know love some of those view points Jeremy. I want to give you the final word, you've got your Serverless Day Boston, you got your podcast, best way to get in touch with you, and keep up with all you're doing in 2020. >> Yeah, so @Jeremy_daly on Twitter. I'm pretty active on Twitter, and I put all my stuff out there. Serverless Chats podcast, you can just find, serverlesschats.com or any of the Pod catchers that you use. I also publish a newsletter that basically talks about what I'm talking about now, every week called Off by None, which is, collects a bunch of serverless links and gives them some IoPine on some of them, so you can go to offbynone.io and find that. My website is jeremydaly.com and I blog and keep up to date on all the kind of stuff that I do with serverless there. >> Jeremy, great content, thanks so much for joining us on theCube. Really glad and always love to shine a spotlight here in the Boston area too. >> Appreciate it. >> I'm Stu Miniman. You can find me on the Twitter's, I'm just @Stu thecube.net is of course where all our videos will be, we'll be at some of the events for 2020. Look for me, look for our co-hosts, reach out to us if there's an event that we should be at, and as always, thank you for watching theCube. (upbeat music)