>> 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)

(Upbeat Music) >> Announcer: Live from Los Angeles, it's theCUBE, covering Open Source Summit, North America, 2017, brought to you by the Linux Foundation and The Red Hat. >> Hey, welcome back everyone, live here in Los Angeles, California for theCUBE's exclusive coverage of Open Source Summit in North America. I'm John Furrrier, with my co-star Stu Miniman, Our next guest is Patrick Chanezan, who is a member of the technical docker, also on the governing board of the Cloud Native Compute Foundation, also known as CNCF, which is the hottest part of the open-source community right now. It's very fast, we're very trendy, a lot of people are on the bandwagon, a lot of contribution going on. Welcome back to theCUBE. Great to see you. >> Hey, thanks, John and Stu, it's very good to be back on theCUBE. >> Docker's been just a great company to follow since the beginning, the birth of Docker to the transformation from Dark Cloud to Docker. It's just a great team. We have a lot of respect for you guys. Congratulations. But the CNCF right now is the hottest thing, there's more platinum sponsors than I think maybe members. It seems to be very hot. Industry loves it, developer is going crazy about it, why is CNCF so hot? What's your perspective on that? >> What we're seeing right now is really the realization of adoption of containers, we talked about it two years ago. It was very early, and people were starting to use Docker and just covering containers. Today they're really putting them into production, and what we see at Docker with our customer base is that they are using it more and more to modernize traditional applications. So we see tremendous use of containers everywhere in enterprises, and the rise of CNCF is tied to that, I think. We're seeing more and more developers joining the bandwagon, more and more systems being built based on containers. And at Docker, we're playing a big role into that. >> Patrick, for a couple years, the chant was Docker, Docker, Docker, and sometimes people say, "Cubernetti's is where the hotness is." Well underneath that, there's containers. And a lot of those containers, Docker's involved there. Maybe you can help us understand the nuance a little bit as the Cubernetti's wave has grown, sure there was the Mezos, Docker Swarm, Cubernetti's war, if you will there, but what does this mean for Docker? What are you seeing from your customers? Give us the update on Docker itself. We'll probably need to get into the Mobi stuff, too, as we get into the interview. >> Sure, definitely. That's a big question, so let's start with the beginning. When enterprises adopt containers, what happens is that usually it starts with the wrappers who are adopting containers with Docker. So they download Docker for their Windows machine, or for their Mac, or on Linux, they start modernizing their applications. What we see is more and more enterprising wrappers, modernizing existing applications by Dockerizing them, and then the next step is that they want to put that into production. For that, you need the whole system. So at Docker, we have two systems. We have Docker C and Docker E, our enterprise version that has role-based controlled sequencing and all that good stuff. There are lots of different components that you need in order to have a production container system, and so Cuberneris, the orchestration engine is one piece of that. At Docker, we have swarm kits. But there are lots of other different components and lots of different layers to that system. So you have the infrastructure layer that you are using to deploy that inside the firewall or in different cloud providers. Many different solutions there. At Docker, we have one that's called infrakit, that we're using in our additions, to deploy it everywhere. Then on top of that, you need some version of Linux. At Docker Con in April, we released a project called Linuxkit, which helps you do that. On top of that, you need a container run-time. Traditionally, it's been Docker. Right now, we re-factored the Docker codebase to extract a core run-time component that's called container G, which we donated to CNCF. Container G is nearing one or better, so it would be one of them pretty soon. Then, on top of that, you need an orchestration engine. Docker E comes with its own orchestration based on swarm, Cuberneris is another orchestration engine that people like. Cuberneris, behind the scenes, is using Docker, and right now we are working very closely with theCUBE rneris community to implement CRI container G. So CRI is the container run-time interface in Cuberneris that lets you plug in different engines to plug container G in the place of Docker in there. >> Stu: There's a lot of pieces in here. We had too many interviews yesterday talking about the Open Container Initiative, or OCI, which really made sure we've got the 1.0 version of that done. What container format, seems like we're in agreement. We're not fighting over that kind of piece anymore. From the Cubernetti's community, I heard loud and clear, they're like, we've got container D. We've kind of got what we want. We're happy it's open-sourced. We're going. We were at Docker Con when you annouced Mobi, which is kind of open-source, and it felt like we were still trying to figure out all those pieces. Give us the update as to Mobi, you're talking at the open source show, you talk a little bit about CE and EE being the productized versions, but part of it is what we used to think of as Docker is now Mobi, and the company Docker versus the project. You kind of teased those apart a little bit, right? >> Yes. Exactly. And actually, that's what I came here at the Open Summit to talk about, to give people an update on the Mobi project. So what we announced back in April was the launch of the Mobi project, which is the end of a two year re-factoring of the Docker codebase into different components. So all these components on the stack that I told you about, we just tease them out from the Docker codebase so that it's a modular set of components that you can assemble together. Mobi is three things. It's an open source project where people can collaborate in container-based systems. It's also a tool that we're using to assemble our components into Mobi Corp, which is the upstream of Docker products. Then it's also a set of lots of components, like container G, Linux, Infrakit, Notary, and all the projects I talked about. One other thing we've started doing since April as well is we started proposing to donate some of these container projects to CNCF. So container G is already part of CNCF now. Recently, this summer, we proposed Infrakit, and they think it's a little bit too early for donation, because they want to see other, different projects in there. Right now we're in the process of donating and proposing Notary, so there's an active discussion in there, and I hope that the vote will happen probably next week or something like that. So Notary is the component that we're using for Docker, and we think that this could be used in lots of different Cloud Native systems, so it really has its place in the CNCF. >> So identity component for the container management, or what specifically is that going to address? >> So Notary is the piece that we're using in Docker Con Contrast to make sure that you can trust the images that you've built. A signed signature should be able to revoke all the signatures, all the kind of features that our customers love in Docker E. >> John: It's kind of like Stu and me on Twitter, he's verified, I'm not. But this is important, because now, this is a stamp of approval, if you will, that the community can look to. >> Yeah, definitely. So it's something that we implement in Docker, and now people building other containment systems who will be able to use it. And so Mobi saw a lot of traction for its different projects, some of them are going to CNCF, some of them are growing by themselves. On the Docker side, we made some progress prioritizing all that with Docker C and Docker E. We had a 1706 launch of Docker E recently, with lots of new role-based axis control, controls for enterprises, who are adopting it essentially to modernize their traditional apps. >> Take us through a kind of personal question. You were just at a board meeting with the CNCF. Did everyone show up or are people calling in? >> I think Alexi Richardson was the only one, maybe two people on the phone. >> John: Was Sam Redjay there? >> Sam was not there either, but Epona was standing for him. So the room was full, and to me it's really an impressive achievement, two years after we helped start the CNCF. The first meetings were 10, 15 people at Google deciding to create this foundation, and today, maybe we're twenty or thirty people around the table. An\d everybody-- >> Even before that Google meeting, we were covering theCUBE Con Cubernettis' movement early on from your event. So I think, out of Docker Con and some of the Linux Foundation events, the early momentum, we were there, Stu. Then it became the CNCF, and they decided, hey, let's get the Cloud Native Foundation. So it's interesting to me, seeing the growth from the beginning. And it's unique to have that opportunity to be in the front lines of an organically developing group. It wasn't really build the table and come, this was a realization. >> It was a realization and also a concerted effort to build something together to show customers where the containment systems were going in terms of architecture-- >> What were the factors beside, I mean Docker was big driver. Notably, you should get the credit for pioneering the space. But what were the drivers for this coalescing, this call to arms, if you will, or this organic formation of CNCF. What were the key drivers in your mind. Obviously, containers is one. What are the other ones? >> Yeah, to me, containers is a big one, because when you are starting to design your system with containers in mind, you need to change lots of things, how you're building them and things like that. And how you are architecting things together. There were lots of questions about how you do the balancing in that kind of system, how do you do monitoring, how do you do tracing. The CNCF was assembled so that all these components have a place where we can show our inter-repairability between them. So Docker is part of that, Mezos is part of that, as well as Cuberneris. There's a big inter-repairability work that's happening in there. We had a report in the board meeting today about the new CI Initiative that tests different CNCF projects together. >> John: What CI? >> Sorry, continuous integration. >> John: Got it, yeah. >> So there's the continuous integration-- >> John: Not conversion infrastructure. >> Oh, you're right, yeah. >> We always get acronym-ed up. But Chris Anazik was talking yesterday about the graduation path, still waiting to see something graduate from the process. What's going to graduate first? Any bets, what's the betting, what betting is going on? Do you guys actually make bets? Is there a fantasy drafting going on? >> I don't think that really matters, what matters is really adoption of the components. >> Okay, so what's happening on the graduation scale? What's coming out of the woodworks? What's next? What's going to graduate first? >> So one thing I'm curious about is whether Container G will graduate, because it's kind of mature now, it's reaching 1-0 with the CRI and soon integration in Docker, it may be a good candidate for graduation. For the others, I don't know which ones would be first into the graduation process. >> Well, we know it's a high bar, for sure. >> Patrick, the stuff that's getting mature. What about some of the roadmap there? From Docker and CNCF, something like serverless containers, first generation, are going to be important. We had too many interviews this week talking about, today, many of the containers we'll see in the future where serverless and open Faz and things like that go. So how does that all fit in? Can you give us a Docker and a CNCF view on that? >> Let's talk about the CNCF view first. CNCF is working on lots of different areas where there needs to be more definition about what Cloud Native means for storage, for example, with the CSI Initiative, container storage interface, CNI, container networking interface, and then there's the working group for CI, which is about integrating all these projects together, but the working group I'm most interested in is the serverless one. So we have a Docker rep at the serverless working group, and there we're trying to define what a portable, serverless stack looks like. And at Docker, we're naturally interested in this -- >> Of course, Serverless is a beautiful thing. >> Most of these projects are running on top of Docker, so open Faz for people-- >> I got to ask you, Patrick, because we love serverless, I have a love/hate relationship with the word serverless because technically it's a beautiful thing, but there's servers involved. I'm an old-school, so I kind of look at it differently. The younger generation, they want infrastructure as code. This is a clear obvious thing. It was once a dream, but now it's become a reality. What's your position on that? Where is it on the progress bar? How close are we to serverless? >> I'd say there's an initial adoption of serverless on one of the few stacks that exist out there today. So you have the hosted services, the Faz services, from Amazon, Microsoft, and Google, where I'm more interested, and I think customers are kind of looking for that, is a portable way of doing that. For example, in studying that on top of Docker platforms, so that's what projects like Open Faz is doing. Right now, I think we're really in the stage of discussions with CNCF of what a portable service layer would look like so that you could focus on your code, but be able to deploy on Prim, on top of Docker, or in different cloud providers. So that portability aspect to me is very important there. And I think it's important for customers as well. To me, also, I'm an old timer as well, I used to pitch a platform as a service at the beginning of it, Google App Engine, many years ago. To me, it's kind of a feeling of deja vu. We're kind of re-inventing that, but with containers and in a much more portable way. >> The beautiful thing about being an old-timer is we get to look back and, not so much to the young kids, get off my lawn, we had to walk to school with bare feet in the snow, build our own libraries. I was just talking to Eilene, she's like, "Oh, my low-level class was C and my high-level class was Python." I'm like, "Our low-level class was machine code "and high-level wasn't even C yet." >> Yesterday, at the party, I was discussing with one of the IBM engineers, who's working on Linux and containers on mainframe, and we were talking about GCL, and that's the type of feeling that we got. Like we're getting higher up in the stack, and I think for modern developers, it really helped them-- >> It's a beautiful thing right now. Just think about the young guns that are coming up. This is a beautiful library of options now. 90% of the code is leverage-able. That's like unbelievable. So it really allows the creativity of the developer to be a lot more about structural engineering code-base rather than just being very creative on the 10-20% of real intellectual property that they can bring to the table. >> I would add something, it's really about creating value, as opposed to building infrastructure. When we're getting up the stack, and serverless is an example of that, it's really about creating value for enterprises, and that's what these wrappers are about. >> When you start dreaming in code, you know you're doing good. Patrick, thanks so much for coming on theCUBE, and congratulations on all the success with CNCF, and certainty Docker. You guys continue to impress and do a great job. I know there's some changes over there we're looking for, some of the cool stuff graduating out of CNCF, more Docker container goodness from you guys. Thanks for coming on theCUBE. We appreciate it. I'm John Furrier, we're live in Los Angeles, California, for the Open Source Summit North America coverage with theCUBE. I'm John Furrier, Stu Miniman back with more after this short break.