from the Regency Center in San Francisco it's the queue covering serverless con San Francisco 2018 brought to you by silicon ankle media upstream in a minute you're watching the cubes coverage of thanks for joining me yeah thanks all right so you work for a company server lists we're in a conference about server list help us explain a little bit your background your company yeah well I guess I'll start with the capital s service the only way I know to distinguish so service got its start when Austin Collins he was an AWS community hero he decided that he wanted to use this new lambda thing to launch some of his own side projects so he built the service framework he did not expect for it to completely skyrocket I think we have like somewhere close to thirty thousand github stars it's like 25 28 at this point and it really kind of like this whole surrealist movement lowercase s now started to build up around AWS lambda and like all of the major cloud providers started launching their own service solutions right and so I got involved with serverless calm because I guess I had been in the tech industry in San Francisco for a while I think I have a pretty non-traditional background for someone who's at a developer tools company I've kind of done things all over the map and right now what I do primarily at service is write a lot of their content you know think that they tweet out things that are in their newsletter on their blog a lot of tech writing and stuff like that yeah you know some techies you know they it's like oh wait that's like marketing stuff we can't do this you give a lightning talk here maybe give give our audience a little bit of a flavor what you talked about there yeah I mean I think one of the biggest appeals to me about service as a company was how passionate everyone there was about the fact that you didn't need to have an engineering background to be able to develop software and we have people in our company who have like film backgrounds who have fashion backgrounds and they're working at a tech company and so really what my talk was about is I deploy applications and that's because technologies like Surrealists really lower the barrier to entry for people who were trying to get involved in this stuff so I was able to deploy a fully working applications that even having to coat that much and I think that it's something really exciting that not a lot of people are talking about right yeah and you're something I'm a little older than you when I went to school it's like we called it programming and that was like you know you wrote code which meant you know you got some big book you look like you know lines of code and you execute this now it's like you know well coding you take a bunch of stuff you put it together you know it looks you know very different from you know what I learned to program back in the day and therefore you know right you don't need a CS major necessarily to be able to get some doing and several it sounds like you know is lowers that bar even more right yeah I mean like one of the things is I do feel like AWS lambda for instance that already makes it so much easier to be able to you know code something and publicly host it you don't have to worry about setting up your own server isn't all that stuff it also makes it a lot cheaper to get started so if you just have like this side project or a hackathon project you know super easy to kind of just deploy that to anyone a cool thing that I feel like other developer tools like the serverless framework does is make it so that you don't even have to understand AWS so you can leverage the power of not having to administer your own servers and also not have to understand like confirmation you know you can just kind of like few lines of code and get it done tell us a little bit of your journey you know what what have you you build with it with the server with stuff how do you get involved in it what can you do with it yeah I mean uh whenever you say how do you get involved you mean just me or just like any person out there so start with a personal oh yeah what what's your recommendation to others yeah I mean I would say there are so many tutorials available that actually start from the basics and one thing that's already started happening is service is attracting all different kinds of people so I would say just start looking online for tutorials like even I've written some that cover everything from how do you set up an AWS account in the first place - how do you put this on AWS and that sort of thing also I think a thing that's really important whenever you take on any sort of side project like this is why does it matter to you and I think for me that reason is I don't have a lot of time you know life is short and there are lots of things I do it we're just like everyone that are so mundane and so routine and I do them over and over and those are perfect candidates for automation and so anytime you have something in your life like that that you feel like you'll be really motivated to never have to do again I feel like it's a great reason to want to learn all right Andrea one of the other things you're involved with here is there's women who serve a lists event that that is happening you know later today so you know we love supporting at Silicon angle in the cube a lot of these women events you know especially here in the Bay Area but all over the place so gets a little bit of insight as to what's happening at this event yeah so I feel like you know one thing that a lot of women in the tech industry can't help but notice is that it's pretty male-dominated and I think that it makes it really important then to try and create community and try to bring more women into the space make it feel like it's really safe and fun place to be for women so I've been throwing these women who serve us happy hours and we're gonna have one tonight after serverless comp so if you're really excited if anyone wanted to come also like keep on event right because we'll be throwing more of them and I hope to see everyone there who can come alright last thing if people want to find out more about women who serve or less about I believe server luscom is the website for your company that's easy as a matter of fact yeah I think in the early days I grabbed us one of the stickers from your company just because I thought it was about serverless in general so alright you know pretty well fused together from a from a branding standpoint yeah yeah I would say that the server list calm and surrealist movement distinction is sort of a blessing and a curse on the one hand it makes it a little bit hard to talk about one or the other you can kind of get them mixed up on the other hand it's been really nice for us to be able to see like all of the excitement that's kind of come out of service and being able to educate people so all right Andrew really appreciate you joining us shit sharing your story as to have somebody you don't have to be in a hardcore a you know developer to be able to get yeah and if anyone makes an application who thought they couldn't code I would love to hear about it yeah and we also love to hear about it here on our program so of course reach out to us the cube dot that's the website I'm just apps to on Twitter always appreciate the feedback love to hear these stories about people using phenomenal technology I'm Stu Mittleman and thanks so much for watching the Q [Music]

>> From the Regency Center in San Francisco, it's theCUBE covering Serverlessconf San Francisco 2018 brought to you by SiliconANGLE Media. >> I'm Stu Miniman and you're watching theCUBE's coverage of Serverlessconf 2018 here in San Francisco at the Regency ballroom. I'm happy to welcome back to the program Simon Wardley, who's a researcher with the Leading Edge Forum, I spoke with you last year at Serverless in New York City, and thanks for joining me again here in San Francisco. >> Absolute pleasure, nice to be back. >> Alright, so many things have changed, Simon, we talked off camera and we're not going into it, your wardrobe stays consistent >> Always. >> But, you know, technology tends to change pretty fast these days. >> Mhmm. >> You do a lot of predictions and I'm curious starting out when you think about timelines and predictions, how do you deal with the pace of change, and put things out, I have my CTOs, like well, if I put a 10 year forecast down there, I can be off on some of the twists and curves, and kind of hit closer to the mark. Give us some of your thoughts as to how you look out and think about things when we know it's changing really fast. >> Okay, okay, so there are a number of different comments in there, one about how do you do predictions, one about the speed of change, okay? So I'm going to start off with the fact that one of the things I use is maps. And maps are based on a couple of characteristics. Any map needs an anchor, in the case of the maps of business that I do, that's the user, and often the business, and often regulators. You also need movement and position in a map. So position's relative to the anchor, so a geographical map, if you've got a compass then this piece is north, south, east or west of that. In the sort of maps that I do, it's the value chain which gives you position relative to the user or the business at the top. Movement, in a geographical map you have consistency of movement, so if I go, I don't know, north from England I end up in Scotland, so you have the same thing with a business map, but that evolution is described, sorry, that movement is described by evolution. So what you have is the genesis of novel and new activities custom-build examples, products and rental services, commodity and utility services, and that's driven by supply and demand competition. Now, that evolution axis, in order to create it, you have to abolish time. So one of the problems when you look at a map is there is no easy use of time in a map. You can have a general direction and then you have to use weak signals to get an idea of when something is likely to happen. So for example if I take nuts and bolts, they took 2,000 years to go from genesis to commodity, electricity was 1,400 years from genesis to commodity, utility, computing 80 years. So, there are weak signals that you can use to identify roughly when something is going to transition, particularly between stages like product to a commodity. Product-product substitution very unpredictable, genesis of novel acts, you can usually say when stuff might appear, but not what is going to appear because in that space it's actually what we call the uncharted, the unexplored space. So, one of the problems is time is an extremely difficult thing to predict without the use of weak signals. The second thing is the pace of change. Because what happens is components evolve, and when we see them shift from product to more commodity and utility, we often see a big change in the value chains that that impacts. And you can get multiple components evolving, and they overlap, and so we feel that the pace is very very fast, despite the fact that it actually takes about 30 to 50 years to go from genesis to the point of industrialization, becoming a commodity, and then about 10 to 15 years for that to actually happen. So if you look at something like machine learning, we can start with it back in the '70s, 3D printing 1968, the Battelle Institute, all of this stuff, virtual reality back in the 1960s as well. So the problem is, one, time's very difficult. The only way to effectively manage time is to use weak signals, it's probability. The second thing is the pace of change is confusing because what we're seeing is overlapping points of industrialization like for example cloud, and what's going here with Serverless. That doesn't actually imply that things are rapidly changing because you've actually got this overlapping pattern. Does that make sense? >> Yes, it does actually. >> Perfect. >> Because you think, we have in hindsight we always think that things happen a lot faster but-- >> Yeah. >> it's funny, infrastructure space when I talk to some of the people that I came up with, they were like oh yeah, come on, we did this in mainframe decades ago. and now we're trying again, we're trying again. Things like-- >> Containers, for example, you've got LXE before that, and we had Solaris Zones before that, so it's all sort of like, interconnected together. >> Okay, so tie this into Serverless for us. >> Okay. >> You were a rather big proponent of Platform as a Service, is this a continuation of us trying to get that abstraction of the application or is it something else? What is the map we are on, and, you know, help us connect things like PaaS and Serverless and that space. >> So back in 2005, the company I ran, we mapped out our value chain, and we realized that compute was shifting from product to utility. Now that had a number of impacts. A, that shift from product to utility tends to be exponential, people have inertia due to past practice, you see a co-evolution of practice, around the changing characteristic. It's normally to do with something called MTTR, mean time to recovery changes. And so you see rapid efficiency, rapid speed of development, being able to build new sources, new areas of value. So that happened with infrastructure, and we also knew it was going to happen with platform, which is why we built something called Zymkey, which was a code execution environment, totally stateless, event-driven, utility billing, and billing to the function, and that was basically a shift of the code execution platform from a product, lamp.net stack, to a much more utility form. Now we were way too early, way too early, because the educational barriers to get people into this idea of building with functions, functional program, much more declarative environment, was really different, I mean when Amazon launched EC2 in 2006, that was a big enough shock for everybody else, and now of course, now we're in 2014, Lambda represents that shift, and the timing's much much better. Now the impact of the shift is not only efficiency and speed of development of new things, and being able to explore new sources of value, but also a change of practice, and in the past, change of practice created DevOps, this is likely to create a new type of practice. For us, we've also got inertia to change because of pre-existing systems and governance and ways of working, sunk capital, physical capital, social capital. So it's all perfectly normal. So in terms of being able to predict and far-predict these types of future, well for me, actually, Lambda's my past, because that's where we were. It's just the timing was wrong, and so when it came out, it was like for me, it was like, this is really powerful stuff and the timing is much, and we're seeing it here, it's now really starting to grow. >> Alright, you've poked a little bit at some of the container discussions going on in the industry, you know, I look at the ecosystem here, and of course AWS is the big player, but there's lots of other Serverless out there. There's discussion of Multicloud. >> Yeah. >> How does things like Kubernetes, and there was this new term canative, or cane-native project, that was just announced, and we're all, don't expect that you've dug in too deeply, but, if you look at containers and Kubernetes, and Serverless, do these combine, intersect, fight? How do you see this playing out? >> So when I look at the map, you know, you've got the code execution layer, the framework which has now become more of a utility, and that's what we call platform. The problem is, is people will application to containers, and therefore describe their environments as application-container platforms, and the platform term became really messy, basically meant everything, okay. But if we break it down into code execution, this is what we call frameworks, this is becoming utility, this is where things like Lambda is, underneath that, are all these components like operating systems, and containers, and container management, Kubernetes type systems. So if you now look at the value chain, the focus is on building applications, and those applications need functions, and then lower down the stack are all these other components. And that will tend to become less visible over time. It's a bit like your toaster. I mean, your toaster contains nuts and bolts and all sorts of things, do you care? Have you ever noticed? Have you ever broken one open and had a look? >> Only if something's not working right. >> (laughs) Only if something, maybe, a lot of people these days wouldn't even go that far, they'd just go and buy themselves a new toaster. The point is, what happens is, as layers industrialize, the lower-order systems become much less visible. So, containers, I'm a big fan of containers. I know Solomon and the stuff in Docker, and I take the view that they are an important but invisible subsystem, and the same with container management and things like containers. The focus has got to be on the code execution. Now when you talk about canative, I've go to say I was really excited with Google Next last week, with their announcements like functions going GA, I thought that was really good. >> We've been hoping that it would have happened last year. >> Yeah exactly, I wanted this before, but I'm really pleased they've got functions coming out GA. There was some really interesting stuff around SDO, and there was the GRPC stuff which is, sort of, I think a hidden gem. In terms of the canative stuff, really interesting stuff there in terms of demos, not something I've played with, I'm sort of waiting for them to come out with canative as a service, rather than, you know, having to build your own. I think there was a lot of good and interesting stuff. The only criticism I would have was the emphasis wasn't so much on basically, serverless code execution building, it was too much focused on the lower end systems, but the announcements are good. Have I played with canative? No, I've just gone along and seen it. >> So Simon, the last question I have for you is, we spoke a year ago today, what are you excited about that's matured? What are you still looking for in this space, to really make the kind of vision you've been seeing for a while become reality, and allow serverless to dominate? >> So, when you get a shift from, say, product to utility, you get this co-evolution of practice, this practice is always novel and new. It starts to emerge, and gets better over time. The area that I think we're going to see that practice is the combining of finance and development, and so when you're running your application, and your application consists of many different functions, it's being able to look at the capital flow through your application, because that gives you hints on things like what should I refactor? Refactoring's never really had financial value. By exposing the cost per function and looking at capital flow, it's suddenly does. So, what I'm really interested in is the new management practices, the new tooling around observing capital flow, monitoring, managing capital flow, refactoring around that space and building new business models. And so there's a couple of companies here with a couple of interesting tools, it's not quite there yet, but it's emerging. >> Well, Simon Wardley, really appreciate you. >> Oh, it's a delight! >> Mapping out the space a little bit, to understand where things have been going. >> Absolute pleasure! >> And thank you so much, for watching as always, theCUBE. (upbeat music)

>> From the Regency Center in San Francisco, it's theCUBE, covering Serverlessconf, San Francisco, 2018. Brought to you by SiliconANGLE Media. >> Hi, I'm Stu Miniman, and you're watching theCUBE here at Serverlessconf, 2018 in San Francisco. Happy to welcome to the program Michael Garski, who's the director of platform engineering at Fender. Thanks so much for joining me. >> Thanks, Stu. Thanks for having me on. >> All right, so, luckily, I don't need to introduce Fender because I think most of our audience will be familiar with, you know, Fender, guitars, music, all that stuff, but we're going to talk a little bit about the tech side. >> Okay. >> Even though, let me ask, there's a question I usually ask. Most companies, you know, going through the digital transformation, lots of changes there. How does digital impact Fender? >> Digitally, Fender started a digital division in late 2015 and it was a focus on all-new digital products to complement our well-known physical products. Since then we've launched Fender Mod Shop, where a user can order a customized guitar online, have it delivered in a month. We have a single sign-on solution across all of our web and mobile applications, a guitar tuner, we have connected amplifiers, with companion apps to control amplifiers remotely. And our flagship product is Fender Play, which is an instructional app which allows the user to learn to play guitar, ukulele, and coming soon, bass. >> Love it. I'm guessing that has something to do with what you're involved with on the cloud and Serverless side to enable those technologies on the mobile side. >> Exactly. We've fully embraced AWS Lambda to support all of the services for the web and mobile applications. >> Okay, so A Cloud Guru's a training company and we've talked to them extensively as to why Serverless was a good fit for them, and enabled them to do it, but bring us through what led to your adoption of AWS Lambda, give us a little bit about what kind of technologies you were using before, and how you got to this solution. >> Well, we started out building services and go, just standard EC2 based microservices, and then we started tinkering a bit with Lambda. We had to adjust the product catalog from SAP. They could deliver a file, drop it into an S3 bucket, so it was simple enough to create a function that can process that file and ingest it into elastic search. From there, we used custom authorizers with API Gateway mapping templates to save custom tunings for users, and then as we started building for Tone and Play, Tone especially is a very limited audience. It's whoever buys the amplifiers. So we're not talking millions of people, it's going to be hundreds of thousands. So, it was a very good use case to go ahead and do that. Same thing with Play, we're starting a new business that's a great model for us, that we can just pay per usage. >> All right, so, yeah it sounds like you were using cloud and the usage model fit for what Serverless was built for, correct? >> Exactly, yes. >> All right, how much is management aware of, you know, kind of the underlying technology? Is your group, kind of just allowed free reign to kind of deal with this? Or are there anything you need to go to the CFO, and be like, well, you know our billings going to change a little bit compared to what you might have known in the past? >> It's, we pretty much have free reign. And our biggest AWS expense is actually what we pay for, in AWS Glacier for storage for the raw footage, of all the 4K footage from, instructional video shoots, and Lambda on top of that is simply a rounding error. >> Yeah, excellent. And the mobile apps that you've built, are there trials on there? Is everybody up to sign-up to be able to use it? Is it a freemium model or is it a paid model? >> The Tuner is a completely free application. There is an in-app purchase for cord and scale libraries, and some pro features of the tuner. Custom tunings are free. The Play application comes with a 30-day free trial, so user can sign up either on the web, or via the Google or Apple app stores on their mobile device. >> Okay, so, with that kind of model, I would think that Lambda would be nice. There's, you know, you said your expenses aren't that high using this kind of service. >> No, not at all, like I, in the month of June, we spent, I think it was like $132 for 68 million Lambda invocations. And to kind of put that in perspective a bit, it's what we pay for some EC2 services, EC2 instances that support our legacy authentication service, but we're also moving that over to Cognito now so we can get rid of all the EC2 instances. >> Okay, when you started using this technology, how'd you first learn about it? How'd you get up to speed on it? Tell us a little bit about kind of, training adoption. >> It was a lot of experimentation. So, we have it set up where we use one account for our QA and production environments and another account for our development environment. All the engineers on the team have free-reign to do whatever they want to in the development environment. They can spin up whatever they need to. So we just started playing around with things and experimenting. Like, let's hook up Lambda function to API Gateway, oh, this is going to work really well! And just kind of proceeded down that path. >> All right, great, and any learnings, anything that you tried playing with and said, like wow, this just isn't going to be a fit for what I need? Tell us, you know, what worked, what didn't? >> I would say about the only thing we found that really doesn't fit within Lambda and Serverless would be really very low latency applications. You're doing an auto complete for a search system. You want that snappy. It's, humans observe, I think it's about 100 milliseconds things seemed instantaneous, and that's going to be very challenging to get from API Gateway Lambda to get that consistently. >> Okay, great. And you're speaking here at the conference, how'd that end up happening, what are you looking to share with your peers? >> How it happened was I submitted a talk for a conference and then Drew from A Cloud Guru approached me and asked me to submit I had to tell him I already did, so they went ahead and approved it. And, I'm sharing what we've done and built at Fender Digital, and sort of what we found as far as tools for monitoring, performance optimization, as well as some things to really be cautious of when you're dealing with Lambda, especially with regards to concurrency controls. >> 'Kay, great and, how have you found the show so far? You were at the keynote, got about 500 people here. >> Yeah, it's really interesting. I'd really like the focus all on Serverless. You see, go to a lot of conferences, there might be one or two talks that kind of focus on that. It's nice to have something completely focused in that space. >> All right, and, you know, from a maturity standpoint, are there things that you're looking for in the roadmap from Amazon? They've been baking Serverless kind of into all of their services, so do you expect to stay on Lambda, or are there other services that kind of, you know FAZ or Serverless built into it that you might be using? >> We expect to stay on Lambda for the near term. I don't, we don't have any plans or looking at anything else like Azure or Google Cloud functions, our intention is to stay with AWS. They have a lot of other services, their new machine learning services, we use DynamoDB quite extensively, and so we're probably going to stick with them. >> Yeah, but inside Amazon, they've been expanding their Serverless portfolio as it was. >> Oh, yeah. >> And I remember, I was at the show when Lambda was announced, and then, you know it's Aurora with Serverless underneath and all those, so do you expect to adopt some of those other services that have AWS Serverless kind of baked into it as opposed to just using, kind of a Lambda tool. >> Absolutely, especially with, you just mentioned the Aurora Serverless model. That's one that we're taking a look at and evaluating as we've got some data in DynamoDB, but as requirements have shifted in the business over time it's really, it's becoming very difficult to model in DynamoDB, so we're going to kind of take a look at that, and possibly move to Aurora Serverless. >> I'm curious, how does Fender, does Fender think of the data involved? Is that something that, you mentioned AI, some of these, is that something that you'll be able to take the data and leverage that potentially even make new business revenue streams out of that in the future? >> We're doing some of that already by just watching user, analyzing user behavior so we can improve our products internally. And we're looking at adding more features to where we can really understand what people are doing, and then make our products better. >> All right. Michael, want to give you the final word. For your peers out there that might be saying hey, I've heard of Serverless, I'm kind of thinking at it, what advice would you give them? >> Just dive in, get started, don't hesitate. It's, it doesn't cost you anything, really to experiment with it. That model works very, very nice. >> Yeah, and it's one of the things that's great. It used to be you would take a lot of period of time and some big investment to be able to try a technology out or maybe you would get some demo, but Serverless is pretty easy to get started on. >> Exactly. Especially if you're using a framework like say, Serverless framework, or maybe using AWS. Excuse me, AWS's Serverless application model, it really helps as far as setting up all the resources that your function needs as well. >> All right well, Michael really appreciate you riffing with us on your deployments with Serverless and hope your peers will definitely check it out. All right, lots more coverage here from The Serverless Conference here in San Fransisco. I'm Stu Miniman, and thanks for watching theCUBE. (electronic music)

>> Narrator: From Hell's Kitchen in New York City, it's theCUBE, on the ground at Serverlessconf brought to you by SiliconAngle Media >> Hi, I'm Stu Miniman, here with theCUBE at Serverless Conference in New York City, Hell's Kitchen. Happy to have with me, first time guest on the program Sam Kroonenburg, we had your brother on the program at the AWS Summit not far from here, at the Javits Center in New York City, but you're also one of the co-founders its the two brothers for A Cloud Guru. Thanks so much for joining me, and thank you for allowing us to come get some phenomenal content here. >> Yeah, no problem. Thank you for coming for the conference today. >> Alright, so Sam, take me back, you know, we talked to your brother a little bit about, well it was an interesting story, he said actually I got turned down for a job from Amazon and ended up creating a training company. But you built this and you built it on Serverless. >> I did yeah. >> So walk us through a little bit the thought process, the timing, you know, aren't you a little bit ahead of your time on that? >> Yeah, it was mid 2015, it was a strange time. We decided we wanted to build this school, this online learning platform, but the challenge we had was that we didn't have a lot of time, we both had families, kids, you know, mortgages, financial commitments. Basically I had four weeks. I had four weeks of leave owing to me, from my employer at the time. My wife and I had been planning this big family holiday with the kids for years and we were about to take it, and I remember having this phone call with Ryan and we were talking about how there were these people taking these online courses and they were really liking them. And we thought, what if we could build this school to teach people cloud computing. It was such a buzz and we just thought, there's something in this. But the challenge was the timing. I remember my wife turned to me and she said, "Look you've got to do it, we'll cancel the holiday, "take the four weeks and give it a try." So that's what we did, we actually flew down to live with Aaron, my in-laws and help look after the kids and I locked myself in a bedroom for four weeks and tried to build an online school. And that was there was no epiphany to go Serverless there was no grand plan. It was, we had a constraint, which was time. I had no time to build this thing. And so ended up using some of the latest technologies like AWS Lambda, API Gateway, a whole bunch of Serverless technologies because I saw that they would help me build this faster. And I could get something to market in the four weeks that I had. I actually spent the first couple of days trying to skin and configure Moodle, the learning management system and I tore my hair out and yeah, ended up putting this thing together with Serverless technologies. >> Ryan just walked by-- >> Oh, there he is. >> It's a llama unicorn with a cat or something like that. >> I'm going to put in the background. >> In the back of our video. Sam, what's your brother doing here? >> He's always trying to troll me. >> So talk to us, you know one of the things the maturation, kind of the speed of change in the industry for new technologies is just so fast these days. Take us through from those early days to you know Serverless today. What's your experience been? What would you say to people that look at this technology? >> I think it's a lot easier to get into now than it was two years ago. The ecosystem has grown around it, the core technologies are pretty much the same as they were two years ago, function as a service, execute functions in the cloud very similar, but the tooling around it, the ecosystem around it has grown. There's great deployment tools, orchestration systems that have come along. It's a lot easier to just get in now and early on, when we started we had to roll a lot of things ourselves, which took a lot of time, and that's what you're trying to stop, is losing time. Yeah, so there's that and the community has really grown, there's a lot of support in the community now. >> So if you had to do it all over, you could have done it in a weekend, rather than the four weeks. >> Yeah, instead of the four weeks. >> Yeah, I mean what's-- >> That's the interesting thing about what happened to us, we would not exist, our business would not exist if it wasn't for Serverless technologies. I literally couldn't, we could not have, built that school. It's not like it was the most amazing school when we launched it, but it was enough. It was just enough to get people using it, to get to market, to start to build a business around it. >> Alright, talk to me about this event. So, its the 5th Serverlessconf, not unheard of a company that does training to get involved with physical events, 'cause you bring them together, you know, what's the thought process, talk to us a little bit about that journey and this event itself. >> Yeah, I mean, a lot of this is organic for us. We built, it was early last year, you know we're part of the Serverless communities, a lot of pioneering going on here, a lot of people facing the same challenges. And we thought, well there's no event to bring all of these people together. And there's a lot of very fast pace of change here, a lot of rapid ideation and new technologies. Let's bring everyone together and see what we can do. That's what we did with Serverlessconf. We've never run a conference before, we just hired a warehouse in Brooklyn, a bunch of Australians and British guys coming over and we just invited a bunch of people on Twitter and 250 people turned out to the first one. It just got bigger and bigger from there. So this is actually the 5th Serverlessconf now. >> Well, its a hot week again, so we appreciate that the air conditioning works at this one. >> Yes, we have air conditioning at this one. >> 460 people here, you brought in some great speakers, we had a number of them on our program this week, speak to us, I mean you've got sponsors here, you've got good speakers, give us some of the highlights. >> We've got all of the main Cloud vendors are here, Google, IBM, Microsoft, Amazon and it's actually the product teams who build this stuff. That's what I love about this event, it's actually the people who build it. It's vendor neutral, it's really cool. You get great thought leaders from the community, Simon Wardley was a highlight this morning, his talk on Value Chain Mapping and Strategy was really interesting. Randall Hunt from AWS X Space X, talking about the continuous integration process when building rockets. Space X was absolutely fascinating and what bugs in production mean when you're building a rocket. It means the rocket blows up. Really interesting variety of talks from those tooling providers, companies like us who are just building on Serverless and then Serverless tooling companies and vendors. Really fascinating. >> Alright, Sam what should we be looking for in the future from Serverless and from A Cloud Guru? >> We're going to be doing a whole lot more Serverless content. You're going to see a lot of really interesting new content through our site, a lot of teaching on Serverless, we're going to be doing more Serverless Conferences. You'll see a lot from us, not just us, but from the wider community who come to the conference, who we know well, a lot of the experts, we're going to be doing a lot of work with those people. >> Well Sam Kroonenburg, really appreciate you joining us, appreciate the media sponsorship to allow theCube to come get some great content and share it with our communities, hope to see you at many more events in the future. >> Thank you for coming. >> Thank you so much. Sam Kroonenburg, I'm Stu Miniman. Thank you for watching theCUBE. (upbeat music)

>> Announcer: From Hell's Kitchen in New York City. It's theCUBE, on the ground, at Serverlessconf. Brought to you by SiliconANGLE Media. >> Hi, I'm Stu Miniman, here with theCUBE at Serverlessconf 2017 in New York City, Hell's Kitchen, actually, happy to welcome to the program, hard to believe, someone, as far as I can tell, we've never had on the program-- >> Yeah, I don't think so. >> But I've known for a long time, actually been drinking with him in Hell's Kitchen before, so Aneel Lakhani, thanks so much for letting me interview you. Your current position is vice president of marketing at Honeycomb.io >> Correct. >> Do you just call it Honeycomb or-- >> We just call it Honeycomb. >> Alright. So, Aneel, how are you doing? Tell us a little bit about your background, but keep it short and what gets you involved in the whole serverless ecosystem? >> Yeah, sure. So, about me, I've been in tech for a little over 20 years now, started out as an engineer, moved through a bunch of systems roles, architecture roles, and product roles, and now I run marketing at start-ups, which is what I've been doing for the last half decade or so. >> I think back to when Amazon announced Lambda, everybody's like, "Ooh, it's cool, what is it? "How do I use it?" Things like that. One of the things I've heard out of this event, this week, is tooling, monitoring, understanding, digging into it, which really falls into Honeycomb space. >> Yeah, I mean, it sort of does. I mean, at Honeycomb we do what we call observability, which is something a bit larger than just monitoring, right. It's really getting to the point where you can develop an understanding of what your services and what your code do in real life under real load with real users. >> Speaking of John Willis, about what is the role of operations when I don't own the infrastructure, I have to trust someone else to do it. So, bring us in there a little bit, what are some of the challenges people are having, how do they help when they're leveraging? >> Yeah, so something that's very clear about serverless approaches to building things, and especially if you're using something like Lambda, is that, as a software engineer, who writes a function, you are 100% responsible for all of your operations at that point, because the ops people for your stack are behind an API. You are on the other side of that API, and what they do is effectively a black box, which means you have to not only understand what your thing does, you have to understand what they do and how they do it, and it's some means of accessing both those bits of data. So you get what Amazon tells you for Lambda, or what any of the other providers tell you for their functions, but you also have to then understand how your code performs on that specific provider, which means you have to do things like wrap your functions in timers and emit events which go into Kinesis, or wherever else, so that you can track what's going on. >> Yeah, one of the problems, of course, any time you have any layer of abstraction is, if things go wrong, how do you get the expertise to know, how do you get in there, is this even worse in serverless? >> Yes and no, I mean, it depends on how much faith you have in your provider, right? So, one of the companies here put up a chart that shows you the performance, on average, of the call response time for the functions for all of the providers that provide serverless infrastructure. And they're not even remotely consistent. They're not consistent within even a few percentiles. In other words, if you care about performance, and you care about predictability for your function, it's basically impossible to get that from any given provider. >> Alright, so, talk to us, what are you hearing from users these days, what's exciting you in this space? >> Yeah, so what we hear from our users, anyway, at Honeycomb, who are using Lambda, and using serverless functions, is that the ability for them to get visibility into how a function performs is basically the highest priority outside of writing a function itself. Because they don't know what's happening below them, they don't know all the resource allocations at any given point in time by the provider, so the thing they have to go on, for the rest of the black box, is how their own function performs, which means they need the ability to take any given function and either decompose it into parts, which have their own events or metrics or telemetry that they emit, or they need to do that to the entire function from end-to-end. So basically have a concept of, this is an old concept for us, which is an end-to-end check, right? I want to know what happens when a point that I touch with a sim until my entire set of functions are complete at the end. >> Yeah, we're going back to like an IP ping, right? >> That's right, yeah, effectively. >> Today, Honeycomb, do you only support Lambda, do you support some of the other serverless frameworks that are out there? >> So, we are agnostic. So, basically, the way Honeycomb works is that our users instrument their code, and we're not service-only, it could be any code running anywhere, and they emit data, and that data is in the form of structured events, those structured events are consumed by Honeycomb, and then Honeycomb turns around and lets you do fast analysis against it. >> Yeah, you've got a lot of background of, "How do we leverage the knowledge of the crowd?" >> Yeah. >> So many times it's what are people finding when they're really getting involved here, you're tooling and others, what mistakes are they making, how can they get better, faster at what they're doing? >> Yeah, a common mistake that people make is not thinking about what is and is not blocking within their functions, and not understanding the threading model of the underlying stack, and when they should spin up additional functions and split up work, versus when they shouldn't, and the only way to understand that is, one, to read all the damn docs, and two to experiment. >> Yeah. What about the maturity of serverless? There've been a lot of discussions here. I had Mark from Trendade on, we talked about security, and the like, but what do you see, kind of in the maturation cycle, of serverless, anything you've heard, or still things that are looking to get fixed even more? >> Maturity isn't the word that I want to use here, I think it's more interesting to think of it in terms of breadth of capabilities, right? So, all of the serverless offerings for all of the vendors have limitations on either the programming languages you can use or the nature of the functions that can be run or the research allocation you can have. I think there's not a lot of maturity that we're going to see from the vendors other than more consistent performance, what we are going to see maturity in is, from the users' standpoint, of how they construct things. >> Yeah. Any data you can share is just how prevalent serverless is out there in the wild, you know, what's the typical use taste, typical customer kind of order of magnitude, how many people are doing it, and therefore driving discussions? >> Yeah, I have no idea. >> You have no idea about this. >> What I do know is, in our user base, we have some significant users of Honeycomb who are 100% run on Amazon Lambda, but that's my tiny, little sample size. >> Okay, want to give you the final word, serverless conference and serverless in general, what's your take today, what should people be looking at in the next six or 12 months? >> Yeah, so I more-or-less agree with Simon Wardley about this, which is, effectively this is a way for Amazon to eat most of the tech ecosystem, assuming people become dependent on it. >> Alright, well, I always say with theCUBE we like to take those hallway conversations, someone that I've had many hallway conversations with, and over the Twitters, and other ways, it's great to catch up with you, Aneel Lakhani, thanks so much for joining us >> Thank you so much. >> I'm Stu Miniman and thanks for watching theCUBE.

>> Narrator: From Hell's Kitchen in New York City, it's The Cube on the ground at Serverlessconf. Brought to you by SilliconANGLE Media. >> Hi, I'm Stu Miniman with The Cube, and we're here are Serverlessconf in Hell's Kitchen New York City, really happy to welcome to the program, another one of the keynote speakers. Ben Kehoe, who's the Cloud Robotics research scientist at iRobot. >> Yeah. >> Ben, great to see you. >> Great to see you too. >> All right, so tell us a little bit about how you got involved with Serverless. >> Yeah, I mean it all started, I was a grad student in robotics, and I started thinking about, you know, we have all these robotics algorithms. And as the cloud can enable robots to do more and better things, how do we help turn those robotics algorithms into web services. And I didn't get very far in that, right towards the end of my PHD, and then that was 2014, LAMBDA was released, and it was like hey, that looks like it does the kind of thing that I was thinking about that we needed. So then I joined iRobot, and we were developing a cloud solution, a cloud application for our connected robots and apps, and to help us scale that to stay lean. Serverless was the right choice, and we've been doing that since 2015. >> Yeah, so Ben, what is it about Serverless that made it a fit for this? You know, I think about, doesn't their responsiveness, performance, latency if I have to go >> Yeah. >> up to the cloud and back like that way. I think some of this needs to kind of live locally. And some that goes there, maybe you can just briefly tease through some of those dynamics for us. >> Yeah, when you're talking about robots, you definitely have to keep things local. You want a robot to be responsive to its environment. You want, that even if its cloud connection disappears, that it can still accomplish all of its tasks. So it's always a mix of keeping it as a timeless robot that is enabled to do better things through the cloud, in terms of additional computational power, or accessing libraries of information to help it understand its world better. And of course, when one robot learns something, all robots can benefit from that experience. >> Excellent, so this is the first step for Skynet is what you're saying, right? >> Could be. >> All right, bring us in a little bit. Your keynote, what were you looking to share? You know, some of the key points. >> Yeah, I think in the talks that I've given at Serverlessconf, they tend to be as much as I am enthusiastic about Serverless, fully bodying, I try and pull us back a little bit to say, "What are we still missing? "What's not here yet? "Where do we need to go?" And so I had some frowny face emoji in my talk about event driven programming, event driven Serverless, and Serverless without event driven programming. Now we're still, you know, we have areas to improve in each one of those. And then that transitioned really into, "How do we start bringing in people who "are just starting into Serverless?" Larger organizations, more traditional architectures, and people who are experienced with that, and understand traditional architectures well. How do we get them on board with Serverless? And so that starts with just the gateway drug, which is infrastructure automation at the edges of their application, taking scripts that they run from developer machines with Cron jobs, and moving those into a function that's triggered by some cloud event. And then from there, starting to bring them over in terms of you can reduce your costs by eliminating idle resources. You can start to simplify and strengthen by refactoring some of that. And then once you really get them thinking about, "Oh, this is really working for the things "that we're doing." New features will start to be developed. Serverless native or event driven native. And then sort of at the end of the talk, the key is that because Serverless architectures look different from traditional architectures, there's something called Conway's law that says, "The design of your application will follow "the communication patterns in your organization." >> Stu: Right. >> And so you have to sort of flip that around to say, "Well if our design is changing, then we have "to make our organization change as well." >> Right, does that mean we're going to have, micro-employees you know? Instead of micro services we have, you know, employees that we hire them, and then we fire them pretty quick when we don't need them, or? >> I hope not. >> Yeah. >> I hope not. >> (crosstalk) that that's the part time, the uber's >> Yes. >> nation of the workforce. >> Yes. That would be, I think an inefficient way of going about it. >> Yeah. >> But I think we do need to reset expectations around what we have control over, and what we don't, because when you're on a traditional architecture with servers, you can reach in and fix problems that you have. And recognizing that when you're running on functions as a service platform, and using managed services, that when the provider has some sort of incident, you're out of control of that. It's a very uncomfortable place to be of not being in control of your own destiny, even though when you look at the big picture, that's going to happen less often, then if you were doing it yourself. >> Stu: Yeah. >> And so that's making sure that the mindset inside the organization, and the way that people communicate, is appropriately tuned to that sort of new paradigm. >> Okay, yeah. Ben, some of those frowny faces, what are things that the community is working on that you're hopeful for? What are some of the areas that we need for the maturation of this space? >> Yeah, I think something that I talked about previously that's coming around, is monitoring. So there's much more tools out there to monitor the infrastructure to know what's going on inside these functions and these managed services. And there's now some security analysis tools that are coming out, that some of these people are present here. And that was a big aspect that I've harped on for a long time of... We have a lot of mature traditional tools, that will do network analysis of your servers. Well it's like, "I don't have any servers." And those vendors then say, "Well, we can't help you." And there's static code analysis vendors who say we look at your whole application, and the flows inside it. And we say, well most of my application exists outside of code that I've written. I just write little bits, that glue it together in the way that my business works. And they say, "Oh, well we can't help you." >> Yeah. It reminds me, I think you know for so many years, people were really excited about how they could build their infrastructure. >> Yeah. >> And now they look to environments, well I can get out of that. So it caught my eye. You know, you put out on twitter, said "Maybe we need to have, you know, my next talk will be, "Work dumber not harder." Maybe explain that a little bit. >> Yeah, so I think, >> Yeah. >> I've been thinking about, you know, with some of the talks here about how it's not building it yourself. That in some ways, there's not invented here syndrome. And we kind of want to go a little bit down the road of invented here syndrome, of if you're building something that is not business logic, you're probably ideally thinking, "Maybe I shouldn't be doing this." So turning it into, I don't want to have to be clever in setting up my architecture, because being clever and like writing, it's always interesting to do, right? When you're developing, you're solving a computer science problem. But often that mean you're not delivering business value. And so, in Paul Johnson's talk, he was talking about the kind of people he looks like. What the kind of people he looks for, look like. >> Yeah. >> And he was saying, you know, "It's people "who want to get stuff out the door. "And who think about good enough." And I think that's really the thing of, how do we, when the people you hire are people who just want to ship features, they're going to say, "I can pull together services to do that "without having to actually solve any hard problems." And that means that you're delivering value, and you're operating more in your business space then in a technology space." >> All right, Ben I want to give you the final word. >> Thank you. >> You know, only 460 people here, which is good growth for the show, but a lot of people out there that are still learning about Serverless, what tips do you give them? You know, first steps to get involved, get involved with the community, (mumbles) some early wins they can have? >> I think there's a couple of things. There is training out there, there's blogs. There's twitter. Ask questions. You know, ping me on twitter if you wonder about something. And there's a Serverless slack that's very active, and if you ask basically anybody, the link is floating around. >> All right, well Ben Kehoe, thanks so much. Great to meet you, and thanks for sharing in this community. >> Yeah, thanks for having me. >> And our community, I'm Stu Miniman and thanks for watching The Cube. (upbeat, exciting music bumper)

>> Announcer: From Hell's Kitchen in New York City, it's theCUBE, on the ground at Serverlessconf. Brought to you by Silicon Angle Media. >> Hi, I'm Stu Miniman with theCUBE, here at Serverless Conference in Hell's Kitchen in New York City. Happy to welcome back to the program. keynote speaker at the event, and a guest that we've had on a couple times before, John Willis, who's the vice president of DevOps and digital practices at Eastray Technologies. John. >> In Hell's Kitchen. >> Stu: In Hell's Kitchen, and go Yankees. >> Yeah, man. I was at the game last night, the other night. Yeah. You'll see tonight. Yeah. Thank you. Glad to be here. >> Great to see you. So look, you've been talking to audiences about DevOps for as long as I can remember, as long as I've known you, definitely. Tell us, what's so important about serverless and how that fits into the world of the developer these days. >> Yeah, I mean, my interest, you know, I was invited to do a keynote, and my interest is to break down the tribal nature of new things. And I sound like a hypocrite because I'm the DevOps tribe, but I prefer to stop calling it DevOps, because there are super patterns that exist, and as I watch serverless, I spend a lot of time having these conversations around that yeah, we don't need that DevOps anymore, because we got serverless. It was the same reason like we didn't need any of the infrastructure stuff because we got cloud. And like, we keep throwing the baby out with the bathwater, and my presentation this morning was like, it's not about the technology, stupid. Like the principles of business value, how you understand value stream, how you inject the governance, the policy, the security, the values and the outcomes that you want. I know those sound like platitudes, like I get a sense that we're making the same mistake over again, and hey, sorry folks, Serverless is just another form of compute. Sorry to get you all wound up and then let you down. It's just compute, folks. And so all the core principles that we've really learned about high-performance organizations apply, they apply differently. Monitoring is differently. How do we deliver? But the principles stay the same. And that was my core message today. >> Yeah, no, very passionate, definitely came through in the keynote. I just have to ask you just on the tech for a second, I mean you were heavily involved in containers, you were part of a company that got acquired by Docker, you were a big proponent of unikernels, now it's serverless, how do you kind of paint that picture >> I think it's amazing tech, and more these days. So I left Docker and I'm going back to something I did 10 years ago, which is kind of consulting but transformation type consulting. It sounds platitudish, but like, I'm back in the mode of looking at things at bigger scale. How do you change an organization to think differently about things? So I've kind of taken a little bit of my tech hat off. I mean, I love containers and minimal delivery, right, I've been yacking about that for like the last two or three years, right? About how minimal delivery models work. And serverless is like, amazing too, like unikernels was an interesting model of function as a service. I think serverless will eat up a good portion, you know I've said this, and I don't know, I may have to modify it. You know, I would say four years ago, three years ago, and you guys been a big part of this discussion. The world went to most companies would say we're a cloud-first organization. I've been saying for the last couple of years, I think most organizations should now thinking that they're a container-first organization. So that doesn't say everything, it just means, and I think the world now should be kind of still container first, and I know that might sound horrible to serverless people, but then look at serverless functions as a place where it fits in the architecture, repeatability, and containers. And there's actually kind of a.. >> Is that just from a maturity standpoint, you know, containers a little bit more mature than serverless? >> I don't know that it's, I think there are like, there are models of architecture, right, and I don't know that, I mean I know there's a lot of successful startups in certain value streams and enterprises that are all serverless. I know a couple of friends that have built complete infrastructure on Amazon Lambda. It works. I just don't know that all value stream delivery of services will go complete serverless. I'm pretty certain that today, almost all applications can run on containers. So I'm not creating a division of war. I'm just saying that I think, and I could be dead wrong on this, but I think in this future like placeholder where we're container first, it's going to be, give me an exception of why it can't be containers left, like it has to be cloud, or it has to be bare metal, or it has to be (mumbles) and the right side is about mapping reusable functionality in functions. So I think you have like a container-first world assumes that smart architecture mandates repeatable functions in a function-like world. Does that make sense? >> Yeah, it does. So I think back on my career, there's so many times we said like, oh, we've got this new way to really simplify the environment and get rid of things you don't need to worry about. You know, I lived through the whole virtualization, oh wait, networking storage took us a decade to fix that. >> Yeah, yeah, yeah, yeah. >> Containers, oh we're going to just focus on the application. Oh wait, networking really important, you worked on a whole company focused specifically on that. >> DevOps for networking, yeah. >> Serverless, the question is, what's the rule of operations when it comes to serverless? >> Again, that's my thoughts on serverless and if it ain't right that's secondary to my real passion right now, which is when I hear the word NoOps for serverless, I cringe. Like this idea that you don't... I mean it's different. Do you need observability and telemetry in a serverless world? I ask you. Of course you do. Do you need to have repeatable patterns of delivery to make sure you don't have vulnerabilities in your code? Of course you do. That's Ops folks. And it's about supply chain and building repeatable, structured delivery with all the gates and the checks and the units, and none of that I believe goes away with serverless. Just like it didn't go away with cloud, just the way it didn't go with virtualization, right? So I think you know, we make a big mistake to think serverless means we don't need operations now. Does it mean that our providers, we have a different relationship with our providers? We don't own the server anymore. So we can't run detrace or those kind of things in that environment. But we still own the service. So who's the site reliability engineer for the service that's running on Lambda? Or functions of serverless, right? If it ain't, I mean if you don't got one, like you're going to have a bad service. >> Yeah, what are you hearing organizationally, what's happening in companies that you're talking to? You know, I was a at a show recently, I think it was Kelsey Hightower I think, it was like DevOps is a given at this point. So do you see that, you know, where's the line from what you've seen? >> Well the curse and the blessing of DevOps, the curse is we've never had a clear definition of it. I say we, you know, everybody, but. And the blessing is we've never had a clear definition. Like it's always emerged. And the problem is, I will tell you what my definition of DevOps is, it has really very little to do with technology. It has to do with human capital and how you create high-performing organizations and the principles and practices that lead to that. The DevOps handbook, if you will, is a lot about, that I co-authored with Gene and Patrick and Jez. Those things, that's my definition of DevOps, but the problem is, when you hear people have discussion about DevOps in lieu of a good definition, you can't really get upset when somebody thinks DevOps is like Jenkins and Sheffer Puppet and Ansable, and like oh no, you're wrong, right, like that's their view. So the problem that you run into then is, if your definition is that it's pure technology and it's tied to kind of cloud, and it's something like infrastructure is code, then in your world and your definition, serverless is going to make all that obsolete, or a good portion obsolete. But if your definition is more about how you create patterns and practices around humans who deliver services a certain way, then nothing about serverless makes any of that obsolete. >> All right, Jon, want to give you final word. What do you think people, that you know, just hearing about serverless first time, where do they start, what kind of things should they look at, or you know, if there's other things you think they should probably look at first? >> You know, I think you're asking the wrong guy for that really. I think there's far better people that you've interviewed take care of that. I mean I would go with Peters Brook, the founder of this conference. That was a book I read, he gave me a copy, it made sense to me, I was able to do some labs and then you know, as they say, the rest, Bob's your uncle, you know, there's a ton of stuff out there to figure out how to navigate. >> Anything, any commentary you'd make on the community for here, a couple of people just you know, it's new but very vibrant, reminds me a lot of the emerging tech where, you know, a lot of help from the community, it's pretty easy to get started. >> So yeah, so in the technology, yes. A lot of vendors, a lot of good stuff, great conversations, and I was actually pleasantly surprised there was less discussion about NoOps or you don't need operations, and I got kind of a little bit of a cheer when I mentioned that this morning. So it seems like there are some good lessons learned that I think the message loud and clear is that operations still exist, it just has to be thought about. The keynote yesterday, the gentleman in the keynote yesterday said, day one, closing keynote, said serverless things are different, in some case easier, but harder in other things, and that was through a cloud. Cloud was much easier from getting infrastructure but we ran into a whole lot of operational issues around how to match this cloud to scale. So serverless is easy to create a function, get it set up, cost-effective, but we're starting to learn all of the complex operational issues of MTTR, how do you restore stuff, what does SRE look like, I mean this is why we get paid the big bucks, dammit man. >> All right, John Willis, always a pleasure to catch up with you. I'm Stu Miniman, thank you so much for watching theCUBE.

>> Narrator: From Hell's Kitchen in New York City, it's theCUBE. On the ground at Serverlessconf. Brought to you by SiliconANGLE Media. >> Hi I'm Stu Miniman, here with theCUBE at Serverlessconf in New York City, really excited to have on the program one of the keynote speakers and a first time guest on theCUBE, it's someone I've know through the interwebs and have read his stuff for many years, Simon Wardley who's a researcher with a leading edge firm, Simon, great to see you. Thanks so much for joining us. >> Thank you ever so much for inviting me. It's a delight to be here. >> Alright, so my understanding is thanks to this event, you've reached a lifelong career goal. You're now a Sith Lord? (laughing) >> Well, somebody basically took a quote of mine and put it on a Star Wars poster with The Empire at the bottom, so yes, it is absolutely there you are, I am a Sith Lord, so delightful. >> The quote was that Serverless will just fundamentally change the architecture of how we build things. Something along those lines, I believe. >> Absolutely, yes. >> Alright, so let's start there. There are so many, come on, we all got really excited when containers came out. We're going to talk to John Willis >> You did. (laughing) >> We're going to talk about unikernels. The industry as a whole, there's frothiness and buzz >> Okay. >> So Serverless, you know, how's it different? How's it the same? Why's it so important from your standpoint? >> So, really good questions. So, to explain that question, we have to start off with a subject that is dear to my heart which is mapping. So when we look at the value chain of any organization, the components in that value chain are evolving and they evolve from the genesis, the novel and new to custom built examples and eventually products and rental services and then commodity and utility services. And that process is driven by supply and demand competition. It happens not only to activities, but to practice and data, but we give them different terms. They have all of the same characteristics as when they evolve. Now, when you look at that evolving environment, what you discover is there are two basic forms of disruption. There is the highly unpredictable form, which either occurs due to the appearance of something novel and new, which we don't know what it's going to impact or to product substitution. So that's the Nokia versus Apple, sort of battle, you don't know which way it's going to go until after the battle. And there is a second form of disruption, which is much more anticipatable or predictable and that is the product to utility change. So we know that when things evolve from product to utility we're going to see a rapid period of change and then there's a punctuated equilibrium. Explotion of higher order systems. We're going to see co-evolution of practice, disruption of past companies stuck behind inertia barriers. Yes it's going to be a bad efficiency, no we're not going to save any money 'cause we're just going to do more stuff with it and we're going to have all these new things as well. And we can anticipate that in advance. So when you start looking at value chains of organization, it's always the shift from product to commodity and utility which makes the big transformation in industry. And so one of them was compute. Shifting from products, as in servers, to utility as in cloud. Unfortunately dreadful term, cloud, an awful word, you know it's not a wispy thing up in the sky, it is something very specific, the shift from compute to utility. >> Would you put virtualization along that continuum? >> Okay, so virtualization was one of the underlying components, which actually helped with that happen. >> Yes. >> And so you've also got the explosion of practices around that co-evolution of practice, things like DevOps. Well, the same transition is now happening in the platform space. So, we're moving away from a product stack, things like, LAMP and .NET, to much more utility-based code execution environments. And that's what we're getting with Lambda. And we're going to see an explosion of new things built on top, inertia barriers, companies stuck behind, they'll die off, It'll be a rapid change punctuated equilibrium. You'll get all sorts of new things built. So we're going through that big transformation. Now, these transformations have been going on for about 300 years, some of them impact micro scale economics, some macro, the biggest we call ages. And that all depends upon how widespread that component is in other value chains, so when we're talking about software, we're talking about a component which is in almost all other value chains, it's shifting from product to utility, massive change, highly predictable. This is what Serverless is about. So, will it change everything? Absolutely it will. >> Alright, so Simon, I'm wondering, if you've mapped out for Serverless, where's the land of economic expection, the land of happiness and the land of despair? (laughing) >> Well, okay, happiness, despair and expectation? >> Yes. >> Okay interesting one. So the land of despair will be getting stuck behind the inertia barriers, dismissing it, saying it's not going to impact, it's not going to impact, no, no, because there's a punctuated equilibrium, it'll surprise you because it's an exponential growth, so you'll think you've got loads and loads of time and 10 years from now, you're like, be panicking, oh my gosh, it's impacting, I can't get the skills for people to help me do the transformation. My entire industry and business model is starting to disappear, so that is the land of despair that's coming to people, that's easy to defend against because most people can't see the environment. They're going to just walk straight into that one. The land of happiness. Well, obviously other than being the utility providers who'll be extremely happy about the growth of their industry, another area of happiness will be some of the novel and new things built on top. So, we're bound to see the, sort, of, one person, two person company who builds a fuction which is sold through something like the marketplace and everybody uses and they sell it for a billion. So, we'll get the two person billion dollar company and I'm sure that will make them delightfully happy. So, that's despair, happiness, also inflated expectations. So one of the big lies will be, Serverless is going to save me money in terms of reducing my IT budget. I'm afraid not. This is Jevons Paradox, this is being going on since 1865. All that's going to happen is yes, it becomes more efficient but we'll do more stuff because we're in competition so we'll spend exactly the same as we've always done, but just doing vastly more. But none the less, loads of consultants will write reports about how it will save you money and lots of people will be disappointed. >> I want to poke at that for a second. (laughing) I don't disagree with Javons Paradox when it comes to power, but example, say you know, our host for this event, A Cloud Guru. >> Yeah. >> They're priced to deliver per user is way lower than if they'd have done this the traditional way and I've heard many examples here at the show already where they've said, oh if I had built it this way, you know, it's now an order of magnitude less dollars, so. >> Let's forget order of mag, let's go many orders of magnitude. So from now to say the 1980s, for a thousand dollars, I can get a million times more compute resource than I could back then. Has my IT budget reduced a million fold during that time? And the answer is >> Yeah. >> What, my IT budget has reduced a million fold? >> No, no, no my IT budget has not reduced a million fold. >> Not at all, because we've just ended up doing vastly more stuff. >> Yeah, yeah. >> So the point is, yes. >> Budgets are always flat, yes. >> So the point is yes, we will be able to do the same things but more efficiently, but your IT budget doesn't reduce because we end up doing more things. So we're in competition, say, you and me and say you evolve, you use these environments you don't reduce your IT spending, you do more things, I'm now having to spend more and more just to try and keep up with you. So eventually I'm forced to adopt to that new world. So what happens is the individual acts become more efficient, but because we do more, we don't save anything. >> You know, want to look at kind of, maps versus strategy. >> Okay. >> I guess one of the things, if I'm talking to the typical Enterprise CIO or Board and they say, oh, well, a year ago I heard about Serverless, or today I heard about Serverless, you know, the strategy is going to change greatly because this is changing so rapidly, how do you help companies understand when things are changing so fast, how do I set a strategy for today? How long do I keep it? How often do I revisit it? >> So, if you map an environment, like all maps, they're dynamic, so you're constantly adapting and changing them as the environment is changing. So, when you look at, you have the purpose of your company, you have the landscape you're operating in, there are a number of climatic patents, about 30 of them, which impact that environment, will change it, so you need to understand those. Then there's sort of university useful patents known as doctrine, then there's game play. Now, for most organizations, because they cannot see the environment, they cannot distinguish, or may just be completely oblivious to any of this, so when they were talking about change, if I look at how things evolve from genesis, custom built product commodity, most organizations will go genesis, that's an innovation, every custom built feature differentiation of a product's an innovation, every shift in product to utility is an innovation, so all they see is innovation, innovation, innovation. And therefore, it's very easy to get sucked in to one size fits all methods work. One size innovation programs, where in fact, the genesis you would be using something like a lightweight XP, the product development, much more lean enterprise, so SCRUM and MVP and the utility is much more outsourcing or Six Sigma. So you should be using multiple techniques and multiple methods and most organizations aren't in that position. And if they're not in that position, of being able to see the environment, it's difficult to see where to attack, it's difficult to understand why here over there, it's difficult to manipulate the market. So, what happens is most organizations work on gut feel, whatever's popular in HPR and just act. And you can call that strategy if you wish. >> Alright, so I wish we could talk for another couple of hours, but want to give you the final take away >> Yes. >> Serverless today, how should people be thinking about it and what should they be looking for over the next six to 12 months in this space? >> So, the key thing about Serverless is we're seeing a shift from platform from product to utility, so you should be developing skills in that space. And we're seeing co-evolution of practice. By that, we mean there is a new set of practices combining finance and development together. What those practices are, we don't know yet. You have to experiment and explore. That's why attending events and being involved in building stuff will help you discover those practices. So today if your company, well it depends on your position, so if you're a company which is behind the game, you, say, haven't gone into infractructure as a service, you're not doing DevOps, you're own people are resistant to this change cause the other vendors say you're going to lose their jobs and blah, then rather then embarking on a five to seven year program, 'cause that's how long it will take to do that, you should move up the stack and start with Serverless and learning those practices. 'Cause no one knows them well, so you can take your people who've got inertia and re-train them in that space overcoming that inertia and give yourself a path forward. So, depends on your position, but I think most companies should be experimenting in this space. >> Alright, well Simon Wardley, it's a pleasure to catch up with you today. >> Delight. >> Hope to have you back on theCUBE at another event soon. Thank you so much for watching theCUBE.

>> Announcer: From Hell's Kitchen in New York City, it's the Cube on the ground at Serverlessconf Brought to you by SiliconAngle Media. >> Hi, I'm Stu Miniman with the Cube, here at Serverlessconf in Hell's Kitchen, New York City. Our first time doing the Cube here. Happy to welcome back to the program, a multi-time guest, Mark Nunnikhoven who is the Vice President of Cloud Research at Trend Micro. Mark, great to see you. >> Thanks for having me. Great to see you Stu. >> Alright, so Mark repeat after me. >> Stu and Mark: Security is everybody's responsibility. >> Yeah. >> So you did a keynote talking about security, and I love, unfortunately I didn't get to see it in person, but I feel like I was there 'cause we had the Twitter's and the commentary. >> Yeah. >> And stuff like that. So security, it's a non-issue right? Serverless it's all set, containers and everything before it, everything's secure right? >> Yeah. As you know from looking at the headlines, we do security really well in the IT community. So you can sleep well at night. We don't have to worry about anything. No, unfortunately it continues to be a challenge, and the point of the keynote yesterday was, sort of, give the state of the nation, how we're doing in the Serverless environment. And the good news is we're doing well in security for Serverless designs, but the bad news is not through any individual or purpose action. Simply by just building in these methods, we get a huge amount of security advantages. >> Yeah. >> But we can do better. >> Alright so Mark, what can we learn? It's funny, we see these repetitive things go on in the industry. It's like "Oh well, I'm just going to use Sass." "I don't need to worry about security, right?" "Oh, I'm going to go public Cloud, they'll take care of it for me." >> Yeah. >> Now containers, Serverless it feels like we have the same trope over, and over, and over again, right? >> We do, very very much so. And one of the things I called out yesterday was actually highlighting how the OWASP Top 10, which is the 10 most common vulnerabilities in web applications, have not really changed since 2010. Yet we didn't have even the concept of Serverless in 2010, but we're still making the same mistakes. SQL injection, still the top mistake that we've been making for the last decade. >> Alright, so we're talking about security. Let's step back for a second. So I believe a lot of the people watching these interviews are going to be like "Serverless, I don't get it." I love the, the Cloud Guru folks have the t-shirt, the update of the Cloud one. There is no Cloud, it's just somebody else owns the computer now. I forget the full thing. >> Somebody else's informal execution environment that last's for milliseconds, something along that. >> So what from your standpoint, you've been talking to a lot of customers >> Yeah. >> that you're speaking at this conference. You know, the what and the why of Serverless? >> Yeah, so Serverless is really that sort of, I won't say conclusion, but the logical next step of Cloud where you start to realize, when you move out of your own data center where you were doing everything, and you move into the Cloud and go, well half of the responsibility is on Amazon, or Google, or Microsoft, or whoever. And then you go, well hold on a second, why am I even managing Windows or Linux? What advantage is that to me? I make widgets, or I sell shirts or whatever. And so you move up into something like containers, and you ask the same question. Go, well why am I even running those? Serverless is that last step on the current line of going, I don't have to run any of this stuff. I can just write code that's directly tied to my business. >> Yeah, and I like how you said it's the next step. I think back to science, and it was like when we found the atom. Everybody was super excited, and then oh, there were protons and neutrons, and they were like oh my gosh, and electrons and everything. And then they're like "Oh and then there's the quark." >> Yeah. >> Everything like that. So the digger, the further down we deep, but what is the value of that? So we went from the server, to virtualized environments, to microservices, to containers. Why is that important? What's the business outcome that people are getting when they get excited and start playing with Serverless? >> For sure, so there's really two main points for me. One is that you have a direct tie between IT and the business, both from performance as well as cost. So now you can actually say that application had cost me $1.10 per transaction, and I normally make $9 on each transaction. So this is good, let's continue to invest there. So there's finally a breakdown between the separation, and you get that unity with the business and IT. And the second is accessibility. Because there's far less infrastructure and plumbing to worry about, you have people who aren't traditionally viewed as developers, more of the business analysts, starting to actually write solutions that are far more directly in line with what you want to do as a business. >> Alright, one of the things I liked seeing in the keynotes was can we do today and what can't we do today? So web applications, great, IOT, things like the Amazon Button, or the Amazon Alexa. >> Yeah. >> All leverage that. What are some of the cool applications that you've seen leveraging Serverless today? >> Yeah, so a lot of cool robots. A friend of mine, Ben Kehoe from iRobot gave a great talk on it. A lot of their stuff leverages that, and I'm a nerd, I love robots. >> Who doesn't like robots? >> Exactly, right? >> We welcome our robot overlords here at the Cube. >> Absolutely. And if they're listening, when they process this, thank you for your service. But yeah, there's a lot of great things where we're crossing out of the digital world into the real world. Because we can connect these things up with the advantage of Serverless. We don't have to build out a huge infrastructure. If you need smart lighting, if you need smart appliances, all of the IOT world, it's all Serverless. >> Yeah. So I'm going to bring up this word >> Yeah. >> That has some weight to it enterprise. >> Uh oh, let me brace. Yeah. >> So companies, we're talking, the Cloud is being used for whole businesses and everything like that. Is Serverless for, it's web, and robots, and cool toys, and everything like this. What are you seeing? What are the limitations, and does this become a predominant operating model in the future? >> Yeah, there's a lot of hesitancy in the enterprise because they're not familiar with it. >> Yeah. >> But realistically, any enterprise today should have a very simple, sort of, fall down model. When they're building something new, start at Serverless. If that doesn't meet your needs, put it in a container. If that doesn't meet your needs, build a server. Again, you want to do less work. The challenge, again, is comfort level. Serverless breaks a lot of our tooling. >> Yeah. >> So you need to learn a lot of stuff, but it's definitely where enterprises should be looking today if they want to get ahead. >> Okay, and Mark what advice do you give to companies today as they think about security across some of these various environments? >> Well you led the cheer at the start. Security is everybody's responsibility. From a security practitioners side, point of view, we've done ourselves a disservice in isolating ourselves in teams and not talking to people. We need to be educators within our organizations to help people understand what they can do. It goes all the way back to the Mythical Man-Month. It's easier to squash a bug before you ever write it, rather than when it's deployed to millions of people. Same thing for security, the earlier you're on it, the more people are looking at it, the better off you're going to be. >> Alright Mark, I want to give you the final word. Take aways, the event isn't done, but for people that aren't familiar where do they get started? Where should they dig in for Serverless? >> Yeah, there's a ton of great content here. So this is the fifth Serverless event. A lot of the old talks are up on YouTube, and Cloud Guru's done a fantastic job on pulling this community together. Check out all that stuff. The major providers, all of them are here. All of them have excellent entry level projects to help you get rolling and really that's the best way to start. Fire up the console, start building something. Why not? >> Alright Mark, really appreciate you joining. Thank for sharing with the community here, our community. Look forward to seeing you at many more events, and thank you so much for watching the Cube. (upbeat music)

>> Announcer: From Hell's Kitchen in New York City, it's theCUBE on the ground at Serverlessconf brought to you by SiliconANGLE Media. >> Hi, I'm Stu Miniman here with theCUBE and we're at Serverlessconf in New York City in Hell's Kitchen. Happy to have on the program a first time guest, Linda Nichols, who is does Cloud Enablement Reader at Cloudreach. Linda, thanks so much for joining me. >> Thanks. >> Alright, so, it's the fifth one of these events, the first time we've been doing some interviews. I know I'm excited to be here. Tell our audience a little bit about yourself, Cloudreach and what brings you to the event. >> Sure, well, I'm at this event because I love this community. I'm really passionate about Serverless. I was at the event in Austin, I loved it, I had a great time. I submitted talks this time and they accepted mine. And I was so excited. Honestly, I would have come anyway, even if they hadn't invited me. So I work at Cloudreach, it's a company originally based in London, we have an office here in New York and we're a Cloud adoption company. So we're helping companies go from on-premises servers into the Cloud and then once they're in the Cloud, that's sort of where my team comes into play. Where we work with app-modernization, taking the software apps that are now in the cloud, and helping to break apart monoliths and modernize the apps using Serverless. >> Yeah, Linda, tell me a little bit about the community. Because you talked Cloud adoption, most companies I talk to, they're figuring out their Cloud strategy. Some of them are getting on board with containerization, coo-ver-net-tees is the latest hotness, so Serverless is still new, so tell us a little bit about that community, how long you've been a part of it and what is it that excites you so much about it? >> It's been about a year and I think as soon as I started kind of getting into it and creating apps on my own and kind of doing some things for clients, immediately the community was there. I was on Twitter, I was on Gitter, I was talking to Serverless framework people, asking questions and immediately people came back with answers. Yeah, they've really embraced me and everyone else really quickly. And I think that when new people come on the scene and they say, what is this? People in the community are like, we don't really know either, it changes every day. Every time I see a talk from someone, their definition of Serverless is different. And mine is changing, too, with every talk. >> I know we've had that discussion, kind of what is it, but what are the outcomes? What are you excited about? What's helping your users? Any proof points or roll outs or things that have- what has that game changer been? >> I think it's cheap and it's fast. Those are the two really important things, especially with a startup community. They don't have the money, they don't have the funding to really be having an entire development team. And now they can bring in one or two people and they can get something written and deployed really quickly. It's good for prototyping, non-profits, and now, for enterprises too. 'Cause now we're saying it's not just for non-profits, you can save money too. We've brought you into the cloud, you're more secure, you're saving money and now, we're going to save you more money and we're going to make your developers happy too. 'Cause they're having a great time. >> Yeah, I've been looking in the events, so far, and it seems like there's big focus on tooling, helping to understand really digging into it. Because, yes, fast, easy, let me get up, I can save some money, but, there's always the wait, but. Okay, we know we need to work on security. I need to make sure I have visibility. What have you been seeing? What are you impressed that you've seen so far? And what are some of the open things that you think the community still needs to work on? >> Well, one thing that's really interesting is you have the four Cloud platforms and they have similar products which are competing, but they still really are working together. IBM and Google are hanging out behind us, no pressure there really and they're all like, oh great, you have a new tool. That seems cool, it's like what we have. Maybe we can work on ours, make it better. So, they're kind of working together. I think the thing that, maybe, we have to work on is maybe a little bit of standardization, which I think is kind of starting to happen. Because people want to be able to use a hybrid system, or maybe they use multiple Cloud platforms and so standardizing some of the events and the services I think is going to kind of help that. >> Okay, Linda, I want to give you the last takeaway. For people that don't know about Serverless, haven't attended, and any tools or place of view, how do they get started, how do they get into the community that you love so much? >> I think, I would say, start with AWS Lambda, maybe. There's some tutorials on the site. A Cloud Guru has some great tutorials, I have to go give them a plug. And, just start building something. And once you start building, if you have a problem, reach out to the community, they'll help you. They'll answer your questions. >> Absolutely, A Cloud Guru, of course, puts on this event. Really, not only are they, they use the Serverless to be able to build their company, but dramatically, those price points, though. Less time and less money to get involved. Linda, thanks so much for joining us, really appreciate, great, great talking with you. >> Yeah, thanks for having me. >> Thank you so much for watching theCUBE. (electric bubbly music)

(lively music) >> Hello, and welcome to this special CUBE conversation. I'm John Furrier, founder of SiliconANGLE Media, co-host of theCUBE. We are here in our Palo Alto Studio to have a conversation around cloud computing, multi-cloud, hybrid cloud, the changes going on in the IT industry and for businesses across the globe as impacted by cloud computing, data, AI. All that's coming together, and a lot of people are trying to figure out how to architect their solution to scale globally but also take care of their businesses, not just cutting costs for information technologies, but delivering services that scale and benefit the businesses and ultimately their customers, the end users. I'm here with a very special guest, Donnie Berkholz, who's the VP of IT services delivery at CWT, Carlson Wagonlit Travel. Also the program chair of the Open Source summit, part of the Linux Foundation, formerly an analyst, a great friend of theCUBE. Donnie, great to see you. Thanks for joining us today. >> Well, thanks for having me on the show. I really appreciate it. >> So we've been having a lot of conversations around, obviously, cloud. We've been there, watching it, from day one. I know you have been covering it as an analyst. Part of that cloud ought to go back to 2007, '08 time frame roughly speaking, you know, even before that with Amazon. Just the massive growth certainly got everyone's attention. IBM once called Amazon irrelevant. Now going full cloud with buying Red Hat for billions and billions of dollars at a 63% premium. Open Source has grown significantly, and now cloud absolutely is the architectural linchpin for companies trying to change how they do business, gather more efficiencies, all built on the ethos of DevOps. That is now kind of going mainstream. So I want to get your thoughts and talk about this across a variety of touchpoints. One is what people are doing in your delivering services, IT services for CWT, and also trying to get positioned for the future. And then Open Source. You're on the Open Source program chair. Open Source driving all these benefits, now with IBM buying Red Hat, you've seen the commercialization of Open Source at a whole nother level which is causing a lot of conversation. So tell us what you're doing and what CWT is about and your role at the company. >> Absolutely, thank you. So CWT, we're in the middle of this journey we call CWT 3.0, which is really one about how do we take the old school green screens that you've seen when you've got travel agents or airline agents booking travel and bring people into the picture and blend together people with technology. So I joined about a year and a half ago to really help push things forward from the perspective of DevOps, because what we came to realize here was we can't deliver quickly and iterate quickly without the underlying platforms that give us the kind of agility that we need without the connections across a lot of our different product groups that led us, again, to iterate on the right things from the perspective of our customers. So I joined a year and a half ago. We've made a lot of strides since then in modernizing many of our technology platforms. The way I think about it here, it's a large enterprise. We've got hundreds of different applications. We've got many, many different product teams, and everything is on a spectrum. We've got some teams that are on the bleeding edge. Not even the leading edge, but I'd say the bleeding edge, trying out the very latest things that come out, experimenting with brand new Open Source tools, with brand new cloud offerings to see, can we incorporate that as quickly as possible so we can innovate faster than our competitors? Whether those are the traditional competitors or some of the new software companies coming into things from that angle. And then on the other end of the spectrum, we've got teams who are taking a much more conservative approach, and saying, "Let's wait and see what sticks "before we pick it up." And the fortunate thing, I think, about a company at the scale we are, is that we can have some of those groups really innovating and pushing the needle, and then other groups who can wait and see which parts stick before we start adopting those at scale. >> And so you've got to manage the production kind of stability versus kind of kicking the tires for the new functionality. So I've got to ask you first. Set up the architecture there. Are you guys on premise with cloud hybrid? Are you in the cloud-native? Do you have multiple clouds? Could you just give a sense of how you're deploying specifically with cloud? >> Yeah, absolutely. I think just like anything else, it's a spectrum of all we see here. There's a lot of different products. Some of them have been built cloud-native. They're using those serverless functions as service technologies from scratch. Brought in some leaders from Amazon to lead some of that drive here. They brought in a lot of good thinking, a lot of good culture, a lot of new perspective to the technologies we're adopting as a company that's not traditionally been a software company. But that is more and more so every day. So we've got some of that going on as completely cloud-native. We've got some going on that's more, I would say, hybrid cloud, where we're spanning between a public cloud environment back to our data centers, and then we've got some that are different applications across multiple different public clouds, because we're not in any one place right now. We're putting things in the best place to do the job. So that's very much the approach that we take, and it's one that, you know, back when I was in my analyst's world, as one of my colleagues called it, the best execution venue. What's the best place? What's the right place to do the right kind of task? We incorporate what are the best technologies we can adopt to help us differentiate more quickly, and where does the data live? What's the data gravity look like? Because we can't be shipping data back and forth. We can't have tons of transactions going back and forth all the time between different public clouds or between a public cloud and one of our data centers. So how do we best account for that when we're architecting what our applications should look like, whether they're brand new ones or whether they're ones we're in the middle of modernizing. >> Great, thanks for sharing, that's great, so yeah, I totally see that same thing. People put, you know, where the best cloud for the app, and if you're Microsoft Shop, you use Azure. If you want to kick the tires on Amazon, there's good roles for that, so we're seeing a lot of those multiple clouds. But while I've got you on the line here, I know you've been an analyst. I want you to just help me define something real quick because there's always kind of confusion between hybrid cloud and multi-cloud. Certainly the multi-cloud, we're getting a lot of hype on that. We're seeing with Kubernetes, with stateful applications versus stateless. You're seeing some conversations there. Certainly on Open Source, that's top of the agenda. Donnie, explain for folks watching the difference between hybrid cloud and multi-cloud, because there's some nuances there, and some people have different definitions. How do you guys look at that? Cause you have multiple clouds, but some aren't necessarily running a workload across clouds yet because of latency issues, so define what hybrid means to you guys and what multi-cloud means to you. >> All right, yeah, I think for us, hybrid cloud would be something where it's about integrating an on-prem workload off a more traditional workload with something in a public cloud environment. It's really, hybrid cloud to me is not two different public clouds working together or even the same application in two different public clouds. That's something a little bit different, and that's where you start to get, I think, into a lot of the questions of what is multi-cloud? We've seen that go through a lot of different transitions over the past decade or so. We've seen a lot of different, you know, vendors, going out there thinking they could sell multi-cloud management that, you know, panned out at different levels of success. I think for at least a decade, we've been talking about ideas like can we do cloud bursting? Has that ever really worked in practice? And I think it's almost as rare as a unicorn. You know, on-prem for the cost efficiencies and then we burst the cloud for the workload. Well, you know, to this day, I've never seen anything that gives you 100% functionality and 100% performance comparability between an on-prem workload and public cloud workload. There always seems to be some kind of difference, and this is a conversation that, I think, Randy Bias has actually been a great proponent of it's not just about the API compatibility. It's not just, you know, can I run Azure in their data centers or in mine? It's about what is the performance difference look like? What does the availability difference look like? Can I support that software in my data center as well as the engineers at Microsoft or at Amazon or at Google or wherever else they're supporting it today? Can I keep it up and running as well? Can I keep it performing as well? Can I find problems as quickly? And that's where it comes to the question of how do we focus on our differentiators and let the experts focus on theirs. >> That's a great point about Randy Bias. Love that great API debate. I was looking at some of that footage we had years ago. But this brings up a good point that I want to get your reaction to, because, you know, a lot of vendors going out there, saying, "Oh, our cloud's this. "We've got all this stuff going on," and there's a lot of hype and a lot of posturing and positioning. The great thing about cloud is that you really can't fake it until you make it. It's got to be working, right? So when you get into the kind of buying into the cloud. You say, "Okay, great, we're going to do some cloud," and maybe you get some cloud architects together. They say, "Okay, here's what it means to us. "In each environment, we'll have to, you know, "understand what that means and then go do it." The reality kind of kicks in, and this is what I'd like to get your reaction to. What is the realities when you say, "Okay, "I want to go to cloud," either for pushing the envelope and/or moving solid workloads that are in production into the cloud. What is the impact on the network, network security, and application performance? Because at the end of the day, those are going to be impacted. Those three areas come up a lot in conversations when all of the glam and all the bloom is off the rose, those are the things that are impacted. What's your thoughts on how practitioners should prepare for those three areas? The network impact, network security impact, and application performance? >> Yeah, I think preparation is exactly the right word there of how do we get the people we have up to speed? And how do we get more and more out of that kind of project mindset and into much more of the product mindset and whether that product is customer-facing or whether that product is some kind of infrastructure or platform product? That's the kind of thinking we're trying to have going into it of how do we get our people, who, you know, may run a Ci Cd pipeline, may run an on-prem container platform, may even be responsible for virtualization, may be responsible for on-prem networks or firewalls or security. How do we get them up to speed and turn them into real software engineers? That's a multi-year journey. That's not something that happens overnight. You can't bring in a team of consultants to fix that problem for you and say, "Oh, well, we came in and implemented it, "and now it's yours, and we walk out the door." It's no longer that, you know, build and operate mindset that you could take a little bit more with on-prem. Because everything is defined as code. And if you don't know how to deal with code, you're going to be in a real rough spot the next time you have to make a change to that stuff that that team of consultants came in and implemented for you. So I think it's turned into a much more long-term approach, which is very, very healthy for technology and for technology companies as a whole of how do we think about this long-term and in a sustainable way, think about scaling up our people. What do those training paths look like? What do those career paths look like? So we can decide, you know, how many people do we want certified? What kind of certifications should they have or equivalent skill sets? I remember hearing not too long ago that I think it was Capital One had over 10,000 people who were AWS certified, which is an enormously large number to think about, but that's the kind of transitions that we've been making as we become more and more cloud-native and cloud by default, is getting the right people. The people we have today trained up in these new kinds of skill sets instead of assuming that's something we can have some team fly in from magic land and implement and then fly away again afterwards. >> That's great, Don, thanks for sharing that insight. I also want to get your thoughts on the Open Source summit, but before we get there, I've got to ask you a question around some of the trends we've been seeing. Early on at DevOps we saw this together of the folks doing the hard work in the early pioneering days, where you saw the developers really getting closer to the front lines. They were becoming part of the business conversation. In the old world of IT, "Okay, here's our strategy. "Consolidate this, load some virtual machines," you know, "Get all this stuff up and running." The business decisions would then trickle down to the tech folks, then with the DevOps revolution, that's now cloud computing and all things, you know, IoT and everything else happening where the developers and the engineering side of it and the applications are on the front lines. They're in more of the business conversations, so I have to ask you. When you're at CWT, what are some of the business drivers and conversations that you guys are having with executive management around choices? Are they business drivers? Do you see an order of preference around agility? The transformation value for either customers or employees, compliance and security, are the top ones that people talk about generally. Of those business drivers, which ones do you guys see the most that are part of iterating through the architecture and ultimately the environment that you deploy? >> Yeah, I think as part of what I mentioned earlier, that we're on this journey we call CWT 3.0, and what's really new about that is bringing in speed and agility into the conversation of if we have something that we imagine as a five year transformation, how do we get to market quickly with new products so that we can start really executing and seeing the outcomes of it? So we've always had the expectations around availability, around security, around all these other factors. Those aren't going away. Instead, we're adding a new one, so we've got new conversations and a new balance to reach at an executive level of we now need a degree of speed that was not the expectation, let's say, a decade ago. It may not even have been the expectation in our industry five years ago, but is today. And so we're now incorporating speed into that balance of maybe we'll decide to very intentionally say, "We're not going to go over quite as many nine's today "so that we can be iterating more quickly on our software." Or, "We're going to invest more "in better release management approaches and tools," right? Like Canary releases, like, you know, Green-Blue releases, all these sorts of new techniques, feature flags, that sort of thing so that we can better deal with speed and better account for the risk and spread it to the smallest surface area possible. >> And you were probably doing those things also to understand the impact and look at kind of what's that's coming in that you're instrumenting in infrastructure because you don't want to have to put it out there and pray and hope that it works. Right, I mean? The old way. >> The product teams that are building it are really great and really quick at understanding about what the user experience looks like. And whether that's their Real User monitoring tools or through, you know, other tools and tricks that we may incorporate to understand what our users are doing on our tools in real time, that's the important part of this, is to shorten the iteration cycle and to understand what things look like in production. You've got to expose that back to the software engineers, to the business analysts, to the product managers who are building it or deciding what should be built in the first place. >> All right, so now that you're on the buyer's side, you've actually got people knocking on your door. "Hey, Donnie, buy my cloud. "Do this, you know, I've got all these solutions. "I've got all these tools. "I've got a toolshed full of," you know, the fool with the tool, as they say. You don't want to be that person, right? So ultimately you've got to pick an environment that's going to scale. When you look at the cloud, how do you evaluate the different clouds? You mentioned gravity or data gravity earlier. All kinds of new criteria is up there now in terms of cloud selection. You mentioned best cloud for the job. I get that. Is there certain things that you look for? Is there a list? Is there criteria on cloud selection that goes through your desk? >> Yeah, I think something that's been really healthy for me coming into the enterprise side from the analyst perspective is you get a couple of new criteria that start to rise up real quickly. You start thinking about things like what's that vendor relationship going to look like? How is the sales force? Are they willing to work with you? Are they willing to adapt to your needs? And then you can adapt back with them so you can build a really strong, healthy relationship with some of your strategic vendors, and to me, a public cloud vendor is absolutely a strategic vendor. That's one where you have to really care a lot and invest in that relationship and make sure things go well when you're sailing together, going in the same direction. And so to me, that's a little bit of a newer factor because it was easy to sit back and come in as the strategic advisor role and say, "Oh, you should go with this cloud. "You should go with that cloud "because of reasons X, Y, or Z," but that doesn't really account for a lot of things that happen behind the scenes, right? What's your sourcing and human department doing? How do they like to work with around contract, right? Will you negotiate a good MSA? All these sorts of things where you don't think about that when you're only thinking about technology and business value. You also have to think about the other, just the day to day, what does it look like? What's the blocking and tackling working with some of those strategic vendors? So you've got that to incorporate in addition to the other criteria around do they have great managed services? You know, self-service managed services that will work for your needs? For example, what do they have around data bases? What do they have around stream processing? What do they have around serverless platforms, right? Whatever it might be that suits the kinds of needs you have. Like for example, you might think about what does our business look like, and it's a graph, right? It's travelers, it's airports, it's planes, it's hotels. It's a bunch of different graphs all intersecting, and so we might imagine looking for a cloud provider that's really well-suited to processing those sorts of workloads. >> In the old days, the networking guys used to run the keys to the kingdom. Hey, you know, I'm going to rack and stack servers. I'm going to do all this stuff, but I've got to go talk to the networking guys, make sure all the routes are provisional and all that's locked down, mainly because that was a perimeter environment then. With cloud now, what's the impact of the networking? What's the role of the network? As we see DevOps notion of infrastructure as code, you've got to compute networking stores as three main pillars of all environments. Compute, check. Stores getting better. Networking, can you imagine Randy Bias? This was a big pet peeve for him. What's the role that cloud does? What's the role of the network with your cloud strategy? >> Yeah, I think something that I've seen following DevOps for the past decade or so has been that, you know, it really started as the ops doing development moved more into the developers and the ops working together and in many cases sharing roles in different ways, then incorporated, you know, QA, and incorporated product, to some extent. Most recently it's really been focused on security and how do we have that whole DevSecOps, SecDevOps thing going on. Something that's been trailing behind a little bit was network, absolutely. I had some very close friends about 10 years ago, maybe, who were getting into that, and they were the only people they knew and they only people they'd ever even heard of thinking beyond the level of using some kind of an expect script to automate your network interaction. But now I think networking as code is really starting to pick up. I mean, you look at what people are doing in public cloud environments. You look at what Open Source projects like Ansible are doing or on the new focus on network functionality. They're not alone in that. Many others are investing in that same kind of area. It's finally really starting to get up. Like for example, we have an internal DevOps Day that we run twice a year, and at the most recent one, guess who one of our speakers was? It was a network engineer talking about the kinds of automation they'd been starting to build against our network environments, not just in public cloud, but also on-premise. And so we're really investing in bringing them into our broader DevOps community, even though Net may not be in the name today. I don't think the name can ever extend to include all possible roles. But it is absolutely a big transition that more and more companies, I think, are going to see rolling along, and one that we've seen happening in public cloud externally for many, many years now. It's been inevitable that the network's going to get engaged in that automation piece. And the network teams are going to be more and more thinking about how do we focus our time in automation and on defining policy, and how do we enable the product teams to work in a self-service way, right? We set up the governance, but governance now means they can move at speed. It doesn't mean wait seven to 30 days for us to verify all of the port openings, match our requirements, and so on and so forth. That's defined up front. >> Yeah, and that's awesome, and I think that's the last leg of the stool in my opinion, and I think you nailed it. Making it operationally automation enabled, and then actually automating it. So, okay, before we get to the Open Source, one final question for you. You know, as you look at plan for the technologies around containers and microservices, what sounds a lot like networking constructs, provisioning, services. The role of stateless applications become a big part of that. As you look at those technologies, what are some of the things you're looking for and evaluating containers and microservices? And what role will that play in your environment and your job? >> I think something that we spend a lot of time focusing on is what is the day two experience going to look like? What is it going to be like? Not just to roll it out initially, but to, you know, operate on an ongoing basis, to make upgrades, to monitor it, to understand what's happening when things are going wrong, to understand, you know, the security stance we're at, right? How well are we locked down? Is everything up-to-date? How do we know that and verify it on a continuous basis instead of the, you know, older school approach of hey, we kind of do a ECI survey or an audit, you know, once a year, and that's the day we're in compliance, and then after that, we're not. Which I was just reading some stories the other day about companies saying, "Hey, there's a large percentage "of the time that you're out of compliance, "but you make sure to fix it just in time "for your quarterly surveys or scans or what have you." And so that's what we spend a lot of our time focusing on is not just the ease of installation, but the ease of ongoing operability and getting really good visibility into the security, into the health, of the underlying platforms that we're running. And in some cases, that may push us to, let's say, a cloud managed service. In some cases, we may say, "Well, that doesn't quite suit our needs." We might have some unique requirements, although I spend a lot of my time personally saying, "In most cases, we are not a snowflake, right?" We should be a snowflake where we differentiate as a company. We should not be a snowflake at the level of our monitoring tools. There's nothing unique we should really be doing in that area. So how can we make sure that we use, whether it's trusted vendors, trusted cloud providers, or trusted Open Source projects with a large and healthy community behind them to run that stuff instead of build it ourselves, 'cause that's not our forte. >> I love that. That's a great conversation I'd love to have with you another time around competitive advantage around IT which is coming back in vogue again. It hasn't been that way in awhile because of all the consolidation and outsourcing. You're seeing people really, really ramp up and say, "Wait a minute, we outsourced our core competency and IT," and now with cloud, there's a competitive advantage, so how do you balance the intellectual property that you need to build for the business and then also use the scale and agility with Open Source? So I want to move to that Open Source conversation. I think this is a good transition. Developers at the end of the day still have to build the apps and services they're going to run on these environments to add value. So Open Source has become, I won't say a professional circuit for developers. It really is become the place for developers because that's where now corporations and projects have been successful, and it's going to a whole nother level. Talk about how Open Source is changing, and specifically around it becoming a common vehicle for one, employees of companies to participate in as part of their job, and two, how it's going to a whole nother level with all this code that's flying around. You can't, you know, go dig without finding out that, you know, new TensorFlow library's been donated for Google, big code bases are being rolled in there, and still the same old success formula for Open Source is continuing to work. You're on the program chair for Open Source summit, which is part of the Linux foundation, which has been very, very successful in this modern era. How has that changed? What's going on in Open Source? And how does that help people who are trying to stand up architecture and build businesses? >> I think Open Source has gone through a lot of transitions over the past decade or so. All right, so it started, and in many ways it was driven by the end users. And now it's come back full circle so that it's again driven more and more by the end users in a way that there was a middle term there where Open Source was really heavily dominated by vendors, and it's started to come back around, and you see a lot of the web companies in particular, right? You're sort of Googles and Amazons and LinkedIns and Facebooks and Twitters, they're open sourcing tools on an almost daily basis, it feels like. I just saw another announcement yesterday, maybe the day before, about a whole set of kernel tools that I think it was Facebook had open sourced. And so you're seeing that pace just going so quickly, and you think back to the days of, for example, the Apache web server, right? Where did that come about from? It didn't come from a software vendor. It came from a coalition of end users all working together to develop the software that they needed because they felt like there's a big gap there and there's an opportunity to cooperate. So it's been really pleasing for me to see that kind of come back around full circle of now, you can hardly turn around and see a company that doesn't have some sort of Open Source program office or something along those lines where they start to develop a much more healthy approach to it. All right, the early 2000's, it was really heavy on that fear and uncertainty and doubt around Open Source. In particular by some vendors, but also a lot of uncertainty because it wasn't that common, or maybe it wasn't that visible inside of these Fortune 500 global 2000 companies. It may have been common, right? What we used to say back when I worked at RedMonk was you turned around, and you asked the database admins, you know, "Are you running MySQL? "Or are you running Postgres?" You asked the infrastructure engineers, "Are you running Linux here?" and you'll get a yes, nine times out of ten, but the CIO was the last to know. Well now, it's started to flip back around because the CIO's are seeing the business value and adopting Open Source and having a really healthy approach to it, and they're trying to kind of normalize the approach to it as a consequence to that, saying, "Look, it's awesome "that we're adopting Open Source. "We have to use this "so that we can get a competitive advantage "because every thousand lines of code we can adopt "is a thousand lines of code we don't have to write, "and we can focus on our own products instead." And then starting to balance that new model of it used to be, you know, is it buy versus built? And then Sass came around, and it's buy versus build versus rent. And now there's Open Source, and it's buy versus build versus rent versus adopt. So every one of these just shifts conversation a little bit of how do you make the right choice at the right time at the right level of the stack? >> Yeah, that's a great observation, and it's awesome insight. It feels like dumping a little bit, a lot of dumping going on in Open Source, and you worry that the flood of vendor-contributed code is the new tactic, but if you look at all the major inflection points from the web, you know, through bitcoin, which is now 10 years old this year, it all started out as organic community projects or conversations on a message board. So there's still a revolution, and I think you're right. Their script is flipping around. I love that comment about the CIO's were last to know about Open Source. I think now that might be flipping around to the CIO's will be last to know about some proprietary advantage that might come out. So it's interesting to see the trend where you're starting to see smart people look at using Open Source but really identifying how they can use their engineering and their intellectual capital to build something proprietary within Open Source for IT advantage. Are you seeing that same trend? Is that on the radar at all? Is that just more of a fantasy on my part? >> I think it's always on the radar, and I think especially with Open Source projects that might be just a little bit below the surface of where a company's line of business is, that's where it will happen the most often. And so, you know, if you were building an analytics product, and you decided to build it on top of, you know, maybe there's the ELK Stack or the Elastic Stack, or maybe there's Graylog. There's a bunch of tools in that space, right? Maybe, you know, Solar, that sort of thing. And you're building an analytics tool or some kind of graph tool or whatever it might be, yeah, you might be inclined to say, "Well, the functionality's not quite there. "Maybe we need to build a new plugin. "Maybe we need to enhance a little bit." And I think this is the same conversation that a lot of the Linux kernel embedded group went through some number of years ago, which is, it's long term a higher burden to maintain a lot of those forks in-house and keep updating them forever than it is to bring some of that functionality back upstream. That's a good, healthy dialogue that hopefully will be happening more and more inside a lot of these companies that are taking Open Source and enhancing it for their own purposes, is taking the right level of those enhancements, deciding what that right level is, and contributing those back upstream and building a really healthy upstream participation regardless of whether you're a software vendor or an adopter of that software that uses it as a really critical part of their product stack. >> Awesome, Donnie, thanks for spending the time chatting with me today. Great to see you, great to connect over our remote here in our studio in Palo Alto. A final question for you. Are you having fun, these days? And what are you most excited about because, again, you've seen. You've been on multiple sides of the table. You've seen what the vendors have. You actually had the realities of doing your job to build value for Carlson Wagonlit Travel, CWT. What are you excited about right now? What's hot for you? What's jazzing you these days? >> Yeah, I think what's hot for me is, you know, to me there's nothing or very little that's revolutionary in technology. A lot of it is evolutionary, right? So you can't say nothing's new. There's always something a little bit different. And so the serverless is another example of something that it's a little bit different. It's a little bit new. It's similar to some previous takes, but you got new angles, specifically around the financials and around, you know, how do you pay? How is it priced? How do you get really almost closer to the metal, right? Get the things you need to happen closer to the way you're paying for them or the way they're running. That's remains a really exciting area for me. I've been going to Serverlessconf for probably since the first or second one now. I haven't been to the most recent one, but you know, there's so much value left in there to be tapped that I'm not yet really on to say, "What's next? What's next?" I've helped myself move out of that analyst world of getting excited about what's next, and for me it's now, "What's ready now?" Where can I leverage some value today or tomorrow or next week? And not think about what's coming down the pipe. So for me, that's, "Well, what went GA?" Right? What can I pick up? What can I scale inside our company so that we can drive the kinds of change we're looking for? So, you know, you asked me what am I the most excited about right now, and it's being here a year and a half and seeing the culture change that I've been driving since day one start to come back. Seeing teams that have never built automation in their lives independently go and learn it and build some automation and save themselves 80 hours a month. That's one example that just came out of our group a couple months back. That's what's valuable for me. That's what I love to see happen. >> Automation's addicting. It's almost an addictive flywheel. We automate something. Oh, that's awesome. I can move on to something else, something better. That was grunt work. Why do I want to do that again? Donnie, thanks so much, and again, thanks for the insight. I appreciate you taking the time and sharing with theCUBE here in our studio. Donnie Berkholz is the VP of IT source of CWT, a great guest. I'm John Furrier here inside theCUBE studio in Palo Alto. Thanks for watching. (lively music)

(uplifting music) >> Hi, I'm Stu Miniman and welcome to a CUBE Conversation. Really excited to have a start up in the serverless space here in our studios in Palo Alto. Welcome to the program, first-time guest, we have Nate Taggart, who's the CEO, and Farrah Campbell, who's the Ecosystem Manager, both with Stackery. Thank you so much for joining us. >> Stu, thanks for having us. >> Thank you. >> Farrah, I know you're just in from Vegas and from the DevOps Enterprise Summit. Why don't we start there a little bit? DevOps, this big wave, a lot of changes, what's the energy you're hearing, what are people talking about what's exciting them these days? >> A lot of things are exciting them. I think that the whole ecosystem is changing. There's so much happening it's almost like the 80s and 90s, you know what I mean, where there's like the dot-commer I guess. There's so much new technology that's out there and it's available. I think that people are really trying to understand where they should go. Maybe I've already started with containers, now people are talking about serverless. What do I do? >> It's a great point. These waves of technology come so fast. When people write their strategy, you might now even want to write it in ink. (Nate and Farrah laughs) They may be drawing because Clay Christensen always says it's something you should revisit. You should go at least once a quarter. It's directionally where I need to go, but things change. All right, Nate, Stackery. Bring us back. First, give us a little bit about the team's background, yourself and what led to the formation of the company. >> Yeah, thanks, Stu. My founding team actually comes out in New Relic. We were early employees there, stayed 'til the IPO. We've worked building, DevTooling for a long time, hand-managing at scale infrastructure. One of the things that we found was, I mean, New Relic was a high-velocity engineering team and the bottleneck, in many cases, was infrastructure. After New Relic, I worked with the data science group at GitHub, again, building massive data infrastructure and the bottleneck was not figuring out what to do. It wasn't the work in front of us. It was the underlying, un-differentiate heavy-lifting of infrastructure. Chase Douglas, my co-founder, and I, when we saw AWS Lambda come out us, it's the first example of a wave of serverless services, we got really excited and realized this took away a lot of the barriers and a lot of the burden of building new applications, started playing with it. This was three years ago. Over the next few years, we've been working with all the serverless pioneers figuring out what are the changes that they're experiencing from their operations cycle from managing the life cycle of an application, how are their teams in the dynamics changing the workflow. We took those best practices and built it into Stackery, which is now a software product to accelerate serverless operations. >> We've been watching this for a while. Give us a little bit of a perspective first. There's some things different about this serverless wave or functions as a service. I'm an infrastructure guy by background and we've always wanted to not have the boat anchors of network and storage slow us down, but I lived through the virtualization wave. (Nate laughs) I've got the scars of over a decade. >> Sure. >> Working in the ecosystem of trying to fix that. Everybody got super excited when containers in a Docker helped bring that to the mainstream, but it was tools helping us move up the stack a little. Serverless, to me, when I look at it, it really starts from the application level down and there's still lots of infrastructure stuff. It's not like it disappears. I've got the great T-shirt from the cloud guru people. (Nate laughs) It's like there is no cloud of someone else's computer, they have the longer version of that for serverless. I love your viewpoint 'cause, New Relic, they'd seen, they track, they monitor that, you had a great way to look at it, GitHub of course, but what's the same, what's different about what's so important about serverless and what it does for companies? >> Fundamentally, we're looking at just two different patterns and neither one of them is right or wrong, but they have different use cases, different applications, areas where they excel. New Relic was a big champion in early pioneer of Docker. We used a lot of containers, a lot of orchestration technology, so I'm still a big proponent of that. I think when I look at the serverless marker today, it's tempting to look at it as an abstraction layer, disfunction as a service, there's maybe micro-container type view. It's not really the pattern we're seeing in industry. What we're actually seeing is people are saying it's a manage service and it's not just Lambda, it's not just compute as a manage service. It's me stringing together the manage components I need to develop quickly and deliver business value to focus on business logic instead of the plumbing. I think API Gateway is manage service, I think there's manage databases in their manage service, there's event streams. You pull all the pieces together and Lambda may be a component of that. In that way, it actually fits in and compliments a container program. >> Absolutely. What I was trying to say is containers kill VMs and serverless kills this. It's kind of like cloud is more of an operation model. >> Sure. >> Serverless is more of how I build my applications and services that I can use, not the unit of how I build something. Farrah, when I look at it, the conversations I've had with users, it's not the okay, let me take the person that did some silo and teach them to code or put that together. I've talked to marketing people that are like, "I got involved and I can do this." What are you seeing from the personnel and who's using it, how is it very different from what we've seen in the past? >> I think it opens up a lot of doors. I think it makes the unattainable attainable. You see people that go from front end to full stack. It takes you to the tip of technology. I'm mentoring a woman that is using serverless as a way to get app out. She doesn't understand infrastructure, she doesn't understand all the ops and how to set all those things up and it would take a long time to figure all those things out. Those are harder doors to open. Everything's been done the same for a very long time. There's like this free knowledge is shared here. Serverless has an ecosystem. It's kind of like a community where everybody is working together, sharing knowledge and trying to actually build something bigger and better, something that feels good to be a part of. We have a lady that's working at our office coming out of code school and she is a killer engineer. You can talk more about what Anna's doing for us at Stackery, but she's coming out of a code school and is operating as if she's a full-stack engineer >> I think that's really the compelling story behind serverless, is focus on business value. >> Yeah. >> And that's the mission of every software engineer. It's the reason most of us got into software engineering was 'cause we wanted to solve puzzles, we wanted to work with logic and idea, we wanted to build. We didn't want to sit and configure infrastructure as code templates in order to stand up some basic EC2 server, so that we can run our application, right? >> Nate, maybe you troned a little bit for us. What does Stackery do in this ecosystem? What are you helping customers? If you've got any customer examples, we'd love to hear that. >> Absolutely. First off, the development model is changing. If you want to do serverless, serverless, again, is a manage service. I can't replicate all of AWS on my laptop. In order to work with these manage services, in the development cycle, I'm shipping code to the cloud. I'm provisioning resources in the cloud. Maybe in my own account or a developer account, but I have to know how to provision those resources and then configure those resources. If I'm doing this in a professional environment, then it means I need to do this in a way that's automated, scalable, I can hand off to someone else, they can replicate and this is the workflow to tooling, the guardrails that Stackery brings to your serverless program. We make it so that a developer can take a branch out of version control and deploy their own instance of it in their sand-boxed environment within their AWS account. This was kind of automation workflows, handling of configuration templating, being able to pull a resource off the shelf, I need to put my database in a VPC (Nate snaps fingers) and boom, it's pre-configured and ready for you to go. >> Okay. >> Stackery also enables you to work on your core problems. I'm not busy trying to research how the 1400 services are going to interact with each other. I don't have time to do that. I'm trying to focus on one of my projects. I'm focused on a deadline. I'm trying to get a specific task done. I don't have time to research for a week to try to get that, to figure that out. Not only that, it's not a language, so focusing time and trying to figure out and formulate cloud formation, it seems like a waste of time. >> The flip side of this is that that is some of the most important mission critical work that teams are doing. You can't provision into your production AWS account if you have misconfigured IM roles. You don't want to open access to that account to every single person in the organization. You don't want misconfigured resources. This new model, this new development change, where the application is at the heart of the life cycle, if we're not helping people to quickly stand up correctly configured resources then we're putting more load on the ITT, more load on the operational team and actually slowing down development. >> Bring us inside. When do you usually get engaged, who's driving those engagements, when you talk about write, what were they doing before and what does this enable them to do once they're engaged? >> Even though serverless feels like an infrastructure solution, it's actually the application development side of the house that tends to be the leading adopter. A lot of cases, they're trying to un-bottleneck their operations team or not send them low-criticality work loads. A typical entry point might be something like a cron job. We have this little function that just needs to run once a day. Do I really need to have a capacity-planning meeting with the ops team to get this out in production? They go, "Okay, we'll write the code, we'll ship it as a serverless function and we'll get it out the door." That works really well when you're a single-principle engineer with maybe elevated privileges in your cloud accounts. It doesn't work so well as a replicable process that you can then scale across the org. I don't think ops leaders want just like let's open the gates to our kingdom. Instead, what we see is that four companies to go through a maturing curve of embracing this technology where they go from background tasks, data pipelines, cron jobs, low-visibility work to maybe more core services that can extend their product or deliver more customer-facing value. They have to answer a lot of questions in terms of how do we change our process and our culture in order to embrace the velocity of serverless without losing the control that our ops team's been providing for us. >> Also, setting your team up for success. Anybody knows that if I'm working on a specific task or we get a project I'm working on, if I don't understand it and can't figure it out, I'm going to get frustrated, I'm not liking my job anymore, I hate this problem that we're working on, this initiative is dumb, I don't want to be a part of this, but Stackery allows somebody, it made me feel good about it, all the things that you can accomplish. We have a customer that's using this right now that they are moving faster than they ever thought that was possible and it's been so much fun to see their excitement and more things that they learn about that they're using it like, "Look what we just did!" They were going to pull out the whiteboard. He was like, "Let's not pull out the whiteboard, Let's just pull out Stackery." That's awesome. >> It's really fun. We opened Slack channels for some of our customers and it's so exciting to watch them get so fired up about being able to self-serve, being able to actually deliver value and hit their milestones very quickly and successfully. You were talking about what segments are driving this. One of the interesting patterns that we've seen is that it's not like the cutting-edge infrastructure team. In a lot of cases, it might be the under-served software teams in an organization. One of our first customers was an enterprise company doing retail and it was their marketing enablement team, a business enablement team that says, "Hey, our work is important. It drives revenue," is critical to our business, but it feels like a busy workload to the ops team and it's hard to get priority on this. For them to be able to self-serve to relieve some of that back pressure, but then deliver the business value, it was like an immediate measurable win for 'em. >> We often talk about the future of jobs so often, it's like oh, well. Really, you need to be a data scientist. You could go get all this training, you need to get there. It sounds like the bar is kind of low to be able to jump in here and don't necessarily need to go through certifications to start getting real results. >> I think maybe instead of saying, "The bar is low," we're opening the doors wider. We're saying that you can be successful by being able to write software and deliver business value and that you don't need to learn, also, how to configure cloud resources or write infrastructure as code templates or manage an operations lifecycle, personally, to be able to ramp up and add value to your organization. >> All right. Nate, how many people in the company, tell us what you can about funding and which expect to see from you and the team throughout the next six to 12 months. >> Absolutely. Officially, our company is now two years old, we're a team of 15 and we've raised seven and a half million dollars led by Voyager Capital and Hummer Winblad. >> Okay. >> I want to add that I had been involved in a number of startups. This team is different. We have five women on our team. >> Yeah. >> When I joined 10, there was four. We have one in ops and three women engineers >> We're up to six now. >> I know, but that's what I'm saying. I'm talking 'about when I started and that is like you don't see that. >> I wonder. There's certain shows I go to when I go to the Cloud Foundry show, when I go to Kubernetes show, when I go to, more of, the developer-centered shows, I do tend to find a higher percentage women. Are we seeing it or is that really? >> Oh, for sure. My first conference, when I started Stackery, was Serverlessconf. It was awesome. I walked into this hackathon actually scared to death because I've been to them before and was basically laughed out of there like, "What are you doing here?" I asked to be a part of a team that had to build a product and we to demo it and I went up to 'em and told 'em that I knew nothing about. I'm not an engineer, I can't write code at all, but I did understand business problems and I was trying to understand where serverless could be useful or what service would be useful. They were like, "Let's find you a team," and they had me working on the business plan while they were doing all the coding and I was like, "Let's do check-ins every single hour." Just that feeling like a welcome. You felt welcomed there and, as a women working in tech, I haven't felt welcomed at a number of conferences or a lot of hackathons, but I definitely felt welcomed there. >> It's great to hear. I saw on Twitter the other day and it was like, "Could you just imagine if for the last thousand years, we'd actually use the brainpower of the entire human race, (Nate laughs) not having kept 50% of the population from contributing." Nate, want to give you the final word. Serverless, it's growing fast, there's a lot of excitement, but what do you see as the biggest challenges. What does the industry need to work on? What's exciting you that, when we come and sit down in 2019, you're hoping we've moved the ball more? >> I think that one take-away that I want to make sure your audience has is that if you're sitting here saying, "We're not doing serverless," you're wrong. Someone in your organization is doing it. If you have this self-served model where pockets of the organization, this is the old shadow IT, where they are self-serving their configuring resources, their provisioning and it's outside of your peri-view, you're going to want to start putting practice steps in place to make sure that they're able to be successful with that mission. If they're not successful with that mission, they increase risk on your cloud strategy as a whole. They put more workload back on the operations team if that team ends up being a bottleneck for these needs. I hear a lot of IT leaders going, "I don't know if we're doing serverless today." It's like, "No, you are. I've talked to two of your engineers. I know you are." (Nate chuckles) >> Absolutely, right there. When I interviewed Andy Jassy, we had him on theCUBE last year, it was serverless becomes the underlying foundation for everything that AWS is doing. It is going to leave the audience with it is not a single product, or unnecessarily a single tool, but this is what all the cloud is doing and it's moving there pretty fast. It's something that the users can get involved with even more. All right. >> Absolutely. >> Nate and Farrah, thank you so much for joining us. Look forward to watching Stackery and seeing the updates. Make sure to check out thecube.net for all of our coverage. We'll have a big coverage of course from AWS re:Invent in Las Vegas. Lots of other shows. I'm personally always excited about what's having in the serverless and emerging trends. Thanks so much for watching theCUBE. >> Thanks.

>> Announcer: Live from Austin, Texas. It's theCUBE. Covering DockerCon 2017. Brought to you by Docker, and support from its ecosystem partners. (bright electronic music) >> Welcome to SiliconANGLE Media's coverage of DockerCon 2017. This is theCUBE. I'm Stu Miniman. My cohost for the next two days is Jim Kobielus, and happy to have as our first guest on the program, is Brian Gracely. A year ago, actually, Brian had a beard, and he was one of the hosts on theCUBE. He's now with Red Hat. Brian, welcome back to the program. >> Stu, great to be on this side of the table again. Good to see you guys. >> And Brian, you were at the first CUBE event back in 2010. We've had you on at least once or twice every year. You did a few more when you were on our team, but happy to have you back as a guest. Why don't you bring our audience up to speed? What brought you to Red Hat and what's your role there, and what brings you to DockerCon? >> Yeah, so, been at Red Hat about a year, a little less than a year now, worked on the OpenShift team, so focused on Kubernetes containers, integrated Linux. It was a great opportunity to be in open source, which I've been working on for a year. It was at home, it was in Raleigh, and it's a great team. It's a team that's growing. The Kubernetes space is growing, so, the vendor side of the world drew me back into Red Hat, so it's been good. >> Yeah, open source, big component about what we're talking here at this show. I heard open source mentioned a ton. It was developers, it was contributors. What's your take, did you get a chance to see some of the keynote? Solomon got out there, thanked the 3300-plus contributor. When he put up the name of the companies, I think it was 41% of the contributors for all of this are independent, but then, Red Hat's in the top six companies there. What's your take on that and the ecosystem in general? >> Yeah, I thought it was, I thought the keynote was good. Obviously, the show's doing well, so it's great to see the container space doing really well. We've been part of the Docker ecosystem since sort of day one. We like to say that we're probably the biggest distributor of what used to be Docker is now Moby, within Rail. But yeah, I think we see that, we obviously believe in the open source movement. We're seeing more and more customers, our customers who want to contribute, who want to make it the de facto buying decision as to what they use, so, yeah, it's great to see not only huge open source support, but then seeing it become, to blossom into very viable, commercial offerings around the market. >> Yeah, so, Brian, your team actually wrote a blog leading up to the show that says, "Containers or Linux." After listening to the keynote, with LinuxKit announced, it felt like, oh well, Linux is containers. It seems like, reminds me back, Sun is, the network is the computer, the computer is the network. It's all kind of looking at it. What's your take as to kind of the relationship of containers with Linux, of course Windows fits in the mix, too, but the operating system and the containers. >> Well, I think, the reason we really put that out was if you go back a little bit historically, not to bore people, containers aren't a Docker thing. Containers are a Linux thing. They were created by Google, Red Hat made a huge contribution sort of secondarily around namespaces, Google did cgroups, IBM did LXC, so it's been a core Linux feature for over a decade now. Docker did a great job of making it easier to use, but at the end of the day, even if you look at, like, what LinuxKit and some of these other things are, they're not about sort of Linux versus Windows, it's, they are all Linux, and it's how do I represent Linux in ways of doing that? So we really kind of want to just reinforce this idea that there are things that you expect out of your operating system, containers being one of them, but if you look at every other project that's being built around this space, whether it's Kubernetes, whether it's management tools that are be, they're all being built on Linux. That's the foundation of this, and it's kind of just a reinforcement to people that, remember where your tools come from, what that thing is that drives security for you, things in that space. >> Brian, you wrote a lot about kind of cloud-native and that journey kind of, rewriting applications, containers, for the fits into that a lot. What have you seen changing kind of last 12 to 18 months? Couple of shows I've been to lately, it feels like we're talking about lift-and-shift more than we are about building new applications. What's the application space look like, and I know Jim's going to want to jump in here. He covers the cloud-native stuff. >> So I think there's a couple of big things that, and I wrote about it for a while, and it's, how much has changed in the last two years have been really interesting. So, I think originally, when you went and looked at platforms, whether it was OpenShift or Cloud Foundry or Heroku or whatever, lots of sort of what we used to call opinionated systems. You dictated what developers did, right? And then, we had-- >> Jim: Opinionated systems? >> Very opinionated platforms, right? The opinion of us, the creators, was going to get forced on you, the developer, right? >> Stu: It made a lot of the decisions for you, so. (Jim laughs) >> And again, the idea was make it easier for you. You don't have to think about those things, but you're going to get them in the way that we want them, and what ended up happening was Docker would kind of became a standard way, a standard container format. We ended up having these open source schedulers like Mesos and Kubernetes and other things, and that allowed the platforms to be a little more, what I was calling composable, so, because developers may not want to use the languages that you force on them, they may not want to use them in those ways. So I think what we've seen is this sort of blurring between what used to be heavily opinionated to becoming more composable, modular, and there's always this trade-off between how much do developers want to care, how much do they not? So that's one big trend that we've seen, is this start of back and forth of what that is. The other one we saw was-- >> In terms of compatibility, (mumbles) quickly, do you see any trend in this space, containers, toward visual composition of applications? What I'm seeing in today, and I've seen generally in this space, is mostly coding, command line interfaces, any visual composition tools you guys provide or any partners of yours for-- >> Brian: Yeah, there's-- >> For building containerized applications? >> And so I think there's sort of two pieces there. It's a great question because ultimately, if the coding piece is hard, you only reach a small segment of those developers, right? You want to, it's like when websites came out, they were all hand-coded in HTML and stuff, and then you had things like Dreamweaver and these other visual tools, and then it exploded. We've seen that. To be successful in this, you've got to have tools in the desktop that make it easier for the developers. Red Hat does something that we call the Container Developer Kit, which is really, write your application, a lot of the stuff in the background gets hidden. Docker has Docker for Mac and Docker for Windows. We see some other tools. So that piece is important. The other piece that, to come back to your question about it, is it lift-and-shift? We probably see 75, 80% of the customers we work with who say, "Look, I know I've got to do cloud-native. "I've got digital transformation "and all these sort of things, "but I've got a lot of portfolio "that I'd like to modernize. "Can I do that with containers?" And I think what we've seen is, for the early days, it was containers are only for new. They only work for microservices, they're only for new, and what we're seeing, and this again goes back to the sort of, containers are Linux, is customers say, "I have an application that ran perfectly fine in Linux. "Why wouldn't it run really well in there?" And we've got customers nowadays, and this sort of blows people's minds, like, we've got customers who will pick up things like WebSphere, put them into a container, run them, modernize them somewhat, but, because the platform will give them automation, it gives them high availability, it gives them scalability, and they go, it works, and they get cost-effectiveness. So we're seeing a lot of that because you can address a lot of your portfolio. >> Oh, Brian, it's the typical maturation that we've seen. The use cases that put on stage, keep planes in the air, power the largest infrastructure, monitor fire alarms, websites, it's like, oh, this is same thing we saw in virtualization in every kind of way that's like, oh, containers run applications. (chuckles) >> Right. >> Right? >> Jim: Have you seen a big push by your customers or in the ecosystem to containerize more of the deep learning and artificial intelligence toolkits, like TensorFlow or Theano? Is that, with your customers, is that a big priority rate now or going forward? >> Yeah, so, I think the big data space was always an area that was kind of on the fence if it made sense to, in container, do you need an abstraction layer, do you want to be closer to it? We're starting to see more and more, so for example, Google with TensorFlow. Google, huge proponent of containers and Kubernetes. They're doing a lot of work to make that happen. We've been doing a lot of work with the Spark community to make Spark work really well in containers, and it becomes an issue of can you manage the resources? The container schedulers do that great, and then, can you manage getting access to the data, and we're seeing more and more storage become container-native and people understanding how that works, so yeah, the breadth of what you can do around containers has gotten very, very large. >> Yeah, any difference in how your customers look at it, whether they're doing on-premises or public cloud, or do things like Docker and Kubernetes make that not matter as much? >> I think what they, so, I joke all the time, none of our customers have a container problem. None of them have a, none of them wake up in the morning and say, "That's my problem," right? What they're saying more and more is, "I know I want to, I'd like to start getting away "from maybe owning data centers, "or by destiny, being data centers. "I need to leverage public clouds, multiple, plural," and they're sort of saying, "Look, I get the benefit of what they do, "but there's still operational differences, "what Azure does, what AWS does. "I would like some level of consistency," and so that's where the OpenShift conversation really comes into play. The operational model I can build with OpenShift as a platform is the same thing I can run on top of Azure, on top of AWS, on top of Google, and we're seeing more and more of our deals, our customers who say, "That's what it's going to look like. "Help us make that work," and today, they do it on a basic level. Somebody like Volvo, for example, some in their data center, some in AWS, and then, more and more, they go, "Go contribute upstream in Kubernetes, "and federate this stuff." Make it look more consistent, make it look more operationally consistent, and that's coming in the next version of Kubernetes, and so forth, so, that shift is happening, but what they want is sort of this consistency. The Kubernetes part, the Docker part, they're sort of details under the covers, but it does provide them a level of portability that's really important. >> All right, Brian, want to give you the final word. Red Hat has got Red Hat Summit coming up, OpenStack and Jim Whitehurst is going to be given, I think, the day one keynote there. Talk a little bit of Red Hat's presence here at the show, what we can expect to see in this space from Red Hat throughout the year. >> Yeah, so I think, from us here, and what you'll see at Red Hat Summit, like, containers are front and center. Obviously, it's an extension of Linux, but it's, we're becoming a company that's more about how to do applications faster, how to modernize applications, how to do them across multiple clouds, and it's this whole idea that those things that used to be really hard, you do them in software now, and the community is helping to fix those, so big presence here. Again, we've got a ton of customers who use Docker as a packaging format, run their containers, open, at Red Hat Summit, we're going to have 25-plus production OpenShift customers that you want to talk about running governments, running airplanes, running, like, they're going to talk about that stuff, so that part, we're really excited about. It's fun, it's fun at this point. They don't, our customers don't want to talk about containers. They want to talk about this digital transformation stuff, and that is making the technology industry fun again. >> All right, so that was my last question for Brian Gracely with Red Hat. My last question for Brian Gracely of the Cloudcast is, I haven't heard Serverless mentioned yet this week. What's wrong? >> I know, that's a good, it's a good question. The Serverless stuff's taking off two weeks from now, probably, at the same, no, down the street. Serverlessconf is happening. >> Stu: Is that part of OSCON then, or? >> No, it's its own event now. >> It's own event. >> Serverless complement to their own event. They'll probably get five, 600 people. We're seeing it as another way of looking at applications. It's functions, containerize them, write your own code, and you'll see us, you'll see what we're doing around OpenShift begin to incorporate that, sort of functions as a server, Serverless stuff, very, very soon, and around Boston timeframe. >> All right, well, Brian, always great to talk to you, and glad I can bring it to the audience, so Brian Gracely with Red Hat. We'll be back with lots more coverage here, DockerCon 2017. You're watching theCUBE. (bright electronic music)