 Live from Barcelona, Spain, it's theCUBE, covering KubeCon CloudNativeCon Europe 2019. brought to you by Red Hat, the CloudNative Computing Foundation and Ecosystem Partners. Hi and welcome back, I'm Stu Miniman, my co-host Corey Quinn, and you're watching theCUBE, the worldwide leader in live tech coverage of KubeCon CloudNativeCon 2019. Happy to welcome to the program a first time guest, Jeff Ferrer, who's the Vice President and Chief Architect of Small Business and Self-Employed Group at Intuit, going to talk about your cloud journey. Jeff, thanks so much for joining us. You're welcome, glad to be here. All right, so Jeff, the easy part of this is, I think most of our audience has probably heard of Intuit, but maybe give us that first setting of the, part of the group you're in and your role and then we want to get into that journey. Yeah, yeah, no, that's great. So yeah, first of all, thanks for having me here and I'm what's called the Chief Architect of the Small Business and Self-Employed Group. Intuit is about powering prosperity around the world. That's our fairly new mission and helping both taxpayers with TurboTax and QuickBooks is our other big project. So think of me as the Chief Architect for the QuickBooks Group. And so mostly for small businesses, helping small businesses survive through their first year, survive and prosper continuing on. Okay, and your charter there is that the infrastructure on there? You're not trying to help the world rid those malicious attacks of like, oh no, I got the new TurboTax and it didn't work well because disclaimer, I'm not paid, I've used it for many years and it's super easy for me. Yeah, so as a Chief Architect, I set the technical direction of the overall QuickBooks franchise, both the desktop version, which is our older version that has been around for 25 years and our QuickBooks online version, which is only about 15 years old and is our SaaS offering. And so I do things like choose technologies that we adopt. I do things like set what are the most important technology priorities, whether it's breaking things up into microservices, our cloud strategy, Kubernetes, going to cloud native, all that kind of stuff. Okay, so you are a member of the Technical Oversight Committee but we're actually going to bring you back a little bit later to talk about that so we'll get a pin in that. But give us a little bit as to kind of what led to this journey towards cloud and all of those pieces that you were just talking about. Yeah, so like many other companies with lots of legacy and lots of code that we've developed over about 35 years of existence, we actually started out in the early 2000s with building our own data centers, right? And it's very expensive, very ambitious, but at the time there really wasn't a public cloud. And so, but we realized that putting servers under our desks and stuff like that, we really needed to grow to a more robust data center. And as we progressed in that journey, we figured out we're not the experts at maintaining and developing all the complicated networking you have to do, reliability, resiliency. We had some outages, this is 10 years ago or so, where a truck drove into a light post outside of one of our data centers and took us down for a day. And that's just not acceptable for our customers. And so the public cloud was just starting out, AWS was a big partner with there and our CIO and CEO met with the AWS executives and really decided that we needed a great partner in public cloud that really was their technical expertise. And so we began this journey, mostly I would describe it as lift and shift of technologies and services that we already had. We had to rewrite a few of them to make them actually work with the cloud. But by and large most of our code is written in Java and that ports pretty well. So we started on that journey and really right now we are mostly running in the public cloud. We have a few legacy systems that are still running in our private data centers but we're planning on decommissioning those. And with the public cloud a journey we really have seen quite a improvement in our reliability. Our downtime we can fail over between availability zones. It's just been fantastic from our overall availability, recoverability standpoint. But what we realized during that journey was that the AWS native experience for our developers, while AWS is just an amazing, amazing partner, it wasn't quite the developer experience we wanted. And so we worked with them on that. And that's why we started looking at cloud native technologies. Things are developed by the community. AWS is part of the community as well. And so they were extremely supportive in our journey to want to, from the developer experience standpoint, really start to press on these cloud native technologies. Wonderful. As you went down that entire path, whenever a company goes public and they put in their S1 that they're doing some committed level of a giant deal with AWS, people immediately chime in with, oh, they could save so much money by building and running their own data centers. How do you stand on that particular perspective? So what's really interesting about our public cloud journey is it's not necessarily about saving a lot of money, right? And we realized that, and to it as a mature company, we're not a startup looking to shave every little penny off of every little server. What we really want is liability for our customers. We want awesome operations. And so the public cloud journey actually hasn't been a huge, huge cost savings, but it has been a huge improvement in all these other levers. So it does amazing things for our customers. And we're looking to cloud native as just another bump up in that overall thing where we get immediate mean time to recovery where things go down, things go wrong, and we get those pods and those services right back up and running. Yeah, can I elaborate a little bit about the application that you're talking about? Like when I first heard you say, we just lifted and shifted there? Yes, yes. Ooh, wait, a lot of times, that is when we kind of claw things back because it costs more than I thought or it didn't run as well as I thought. It turns out the main frame's hard to move because they didn't build an AWS 400 yet. It was something that didn't happen. So the challenge is there, and then connect the dots with that to what you're calling the cloud native piece of this as to what your application development looks like. So I'll use QuickBooks Online as an example. Massive property, over 4 million customers running on that. And it started out as our kind of our first really big foray into SaaS, right? And luckily at the time we wrote it, and mostly in Java, but it was written as this huge monolithic piece of code, right? And so millions of lines of code, you can imagine large memory footprints, all that kind of stuff. And so during our first, for public cloud, we just looked at like, well, we're not going to rewrite these millions and millions of lines of code, but we want to get into the public cloud. Lucky for us, EC2 instances, things like that can run those large memory footprints. But once there, we really started examining like, okay, what does this look like as microservices? Because when you have over 400 engineers working on a single code base, imagine what doing a release, a release is a ceremony, right? It's like this huge thing you have. It takes a many page calendar. Exactly, exactly. And so what we really wanted to do is press into the microservices journey and say like, okay, what if instead of having this huge oil tanker, sailing down the ocean, what if we could be a bunch of speedboats, right? And use that analogy. And that's where Cloud Native comes in because that's really what it's meant to do, right? Is a bunch of independent teams doing DevOps, you build it, you run it, right? You write the code, you run the code. And so it just plays right into this ability to be very agile, give each team, you can imagine at a scale of 4,000 engineers, you want every little pizza team to be independent and do their own releases and not have to coordinate all with each other. So Jeff, which of the CNCF pieces are you using it into it? And I would like you to go in a little bit, like Kubernetes, a lot of people, it's like, oh, well, I want portability and it sounds like you're all in primarily on one public cloud. So that's probably not the first thing on your list. So help us understand the landscape from your eyes. So really it's about developer productivity. And that's, so yes, we do have this a very good, strong partnership with AWS and that is our public cloud provider. And so the cloud native technology using obviously Kubernetes, obviously, we're running Docker in the background for running the containers and all that infrastructure. We have our own open source called Argo, which we're using for deployments in the community. So we're contributing a little bit back to community as well. We're using Istio, an envoy as a service match to really secure the inner service communications and support all the routing and whatnot. And we're also leaning very heavily now into serverless technologies. So we rewrite our app QBO or QuickBooks Online as a stateful application, but we're realizing the power of having these really stateless small functions. And so we want to do that as well. And the way we look at it as Lambda is a fantastic technology for something like that. But the developer experience, we want the same developer experience for our containers that we do from our functions, right? And if you really think about it, it's just about deploying. It's how you deploy. Do I deploy into containers and in a pod structure like in Kubernetes? Or do I deploy to a functions as a service? It should run on the same infrastructure. And so, but from a developer standpoint, from the end developer that's actually developing the applications and services that our customers are using, we want the declarative infrastructure of Kubernetes. We want the ease of deployment and of operations. I mean, you can just imagine a development team not having to learn the huge depth that's behind that Kubernetes, that developer experience is just unbelievable and second to none. And you can imagine these teams sitting around, at lunchtime doing their release, something goes wrong, they're on the call. They're solving the problems for their customers, in fact, doing another release if there's any problems. And so that's where we really, really lean in heavily to these cloud technologies, so the cloud native technologies so we can get even faster at the developers. Do you find that making it more accessible and having a consistent developer experience has, I guess, broadened the ability of your developers to iterate more rapidly? Or is it more about ensuring consistency across the board? In other words, is it a speed value for you? Or is it more about just consistency so you can wind up deploying to multiple architectures? It's really about both. We see, you know, agility is often confused with speed and velocity, but we see that enabling a developer to release code to production in just a few minutes is extremely, extremely powerful to the overall velocity because what they're more likely to do is they're more likely to experiment, be bold, try new things, see if the, and then get immediate feedback for the customer. There's this experiment, experimentation loop that you want it to move as fast as possible. And so, not only that, but to your second part about the consistency, it's for a company like Intuit with 4,000 developers, you want mobility in your organizations and so you want someone to feel very natural going from one small piece of team to another and have the same tools, the same deployment architecture and the same thing, right? So you're not retraining them on a ton of different technologies. So, Jeff, you know, what could the ecosystem, you know, the partners you're working with, the various ecosystems, what could they do to make your life easier? I mean, the one that comes to mind for me is, you know, today, serverless, you know, Lambda specifically and Kubernetes. There are some ways to get them, you know, working a little bit, but, you know, is that top of your mind or are there other things? That is actually really top of my mind. We have a lot of teams experimenting with Lambda. We're running huge workloads in Lambda, but we're very much worried about this. If there's teams working on that and it's very fragmented, some teams are deploying Lambdas off their laptops, other teams are, you know, using CI CD processes. And so we want that experience to be consistent, secure and everything. And so as it moves to more production workloads, right? We would really like the Kubernetes and the CNCF or the CNCF Foundation to really have a story about serverless itself. I think it's probably more aptly called functions as a service or running functions. And I think a lot of the thing happens is that it's treated out of the versus. It's like, oh, I'm going to skip over that container to Kubernetes thing and go to serverless because it's versus, right? It's not versus. It's a choice for the developer. They're aligned. About do I want to deploy in functions, in short running functions, or do I want to deploy in containers? Everything else up to that point is the same. And so I'd really like to see, and as my role on the technical oversight committee, that's something I'm really focused on for the end users because I see that a lot in the end user communities. They're dealing with the same thing that we are on that functions as a service. All right, so Jeff, before I let you go, into it's an award winner. So congratulations on that. I want final word from you. Talk a little bit about the award and talk to your peers that might be, they've heard about Kubernetes, but we're into the, we've crossed the chasm in the majority, but that still means there's a lot of people that are still relatively early. What do you recommend to them? What tips would you give them? And start with the award though. Yeah, so we are extremely honored to be the CNCF end user award winner. We are, our cloud journey has been a really interesting one that came really out of a, also out of an acquisition that we did of some fantastic Kubernetes experts, about 14 of them, a little company called Aplatics that had this Argo project. And their mission was to make Kubernetes accessible to the overall community. And by aquarium, we left their mission the same, but they're really helping into it. And we're not selling, they're helping the community for free when they were charging before as enterprise customers. And that's something I'd overall recommend for the peers and the companies thinking about going on a cloud native journey is, it's about those people that you can find here at the conference, right? About those experts that you can hire, just a few of them, have them come into your company, explain these things, and it turns the entire company around. We now have hundreds and hundreds of teams going through and onboarding, we call it modern SaaS internally, onboarding onto this technology because they started out with that nugget or that kernel. Well, Jeff, modern SaaS, love the story. Thank you so much. And thanks for joining us. And we will see you later to talk about the TOC. Glad to be here. Thank you very much. Thank you very much. For Corey Quinn, I'm Stu Miniman, and that was Jeff Brewer from Intuit. We'll be back with lots more coverage and thank you for watching theCUBE.