From Library-Based Pipelines to Book Clubs: Live From DevOps World | Jenkins World 2019

Brian Dawson: Hello, this is Brian Dawson, and we're here with you for a special edition of DevOps Radio, live from DevOps World Jenkins World 2019 at Moscone Center in San Francisco. And we have Aravind Kalavagattu, is that correct? Can you correct me, please?

Aravind Kalavagattu: Yeah, Kalavagattu.

Brian: Alright, thank you. Well, I appreciate you joining us today. You're joining us from and on behalf of LendingClub, is that correct?

Aravind: That’s correct.

Brian: Awesome. Can you give your audience and give me a little bit more about your background? What do you do at LendingClub? What was your path there?

Aravind: Awesome. So, yeah, thanks for the opportunity with the conference as well as the DevOps Radio. So, I am currently an engineering manager at LendingClub. So, I manage two teams. So, the names of the teams are Engineering Efficiency, who are more focused around development productivity, the CI/CD tooling, code review process—the whole pipeline.

Brian: Okay.

Aravind: And then the second team I manage is Test Infrastructure and Automation, where the focus is more around how can we efficiently test? What should be the testing strategies, and then what are the tools around, more around testing? By testing, I mean, like, contract testing, end-to-end testing, what’s the most efficient way to test?

Brian: Okay.

Aravind: So, but the philosophy for the teams is the same. Basically, we are a horizontal team across the company.

Brian: Okay.

Aravind: So, we want to build tools that can make all the developers, QAs across the company more productive and save engineering hours, both in terms of the developer hours, the QA hours, and processes wise and shipping things faster. So, that’s why it’s a great venue for me to go through so many tools and stuff.

Brian: Right, right.

Aravind: So, coming to my background before that—so, I started as a software developer and then slowly transformed more into, like, I was working both in backend for a few months and then front end for a few years. So, I know pretty much how it works on the application side as well as platform-driven back end side.

Brian: Okay.

Aravind: When I joined LendingClub, I was more doing like a lead architect, leading software engineer type of role for the same team.

Brian: Okay, right.

Aravind: Then I grew into the management role. So, now I manage a team of great engineers and I have a principal test automation engineer. We work very closely with our InfraOps people as well to stay on top of the cutting edge and stuff. Outside of work, while I am not chasing my two little kids, an interesting fact I would like to mention is, me and three of my friends, we run a podcast in Telugu. So, Telugu is one of the Indian languages, so through India, I think it’s most spoken in terms of numbers.

Brian: Yes, I've heard, yes—yeah.

Aravind: So, and we started this like three years ago more casual, it’s not like a company with assets, more out of interest around talking about tech topics, sports and we did record an episode on CI/CD in the past. So, the name of the podcast is called Telugu Bytes.

Brian: Oh, awesome. Telugu Bytes—alright, B-Y-T-E-S, not B-I-T-E-S, right?

Aravind: Yeah, exactly, the bytes. So, yeah, basically, the idea is sharing bytes of information quickly for people of Telugu origin, talking in Telugu.

Brian: Well, awesome. So, one is, when we're done here, after we're done, since you're a three-year professional, you can give me some tips when you're done and hey, hopefully, maybe one day I can come on Telugu Bytes.

Aravind: Oh, yeah. We would love to.

Brian: And we can talk DevOps, we can talk DevOps Radio. So, that's awesome. Thank you for sharing that. It always helps to kinda understand who you are. And I’d like to ask, or something I caught in your explanation that was really interesting is, you used the word “efficiency” I think, by my count, about five times.

Aravind: Mm-hmm.

Brian: And so, first, I love that as a way to kind of combine and summarize at the end of the day what we're trying to do with really the multiple planes of DevOps, right? From when we talk culture, process, practices and tools—really, at the soul, a lot of what we're trying to do is gain efficiency, right?

Aravind: Right.

Brian: So, part of what I heard as well, though, is—so, you have a principal test automation engineer, you also under a separate group, you have the testing group and you have Engineering Efficiency, right?

Aravind: Right.

Brian: Or Quality Assurance and Engineering Efficiency. Is it by design that they both report into you, and is it because you see engineering efficiency and quality being hand-in-hand, or is there some other reason that you're overseeing both of these groups?

Aravind: Yeah, exactly. I think you captured it well. So, basically, the Engineering Efficiency is more around, say, developers, developer efficiency, the developer tools, whereas the Test Infra is more around testing names. So, we wanted to keep them separate, more in terms of the focus area where I would say—of course, there is a good partnership between the two groups. For example, like, the Jenkins infrastructure is maintained by the Quality Infra group, Test Infra group, because we wanted all the resources together.

Brian: Okay.

Aravind: Whereas some of the tooling—an example is, we developed a pipeline library that powers LendingClub’s CI/CD pipelines build and release processes.

Brian: Right.

Aravind: So, that is primarily owned by the Engineering Efficiency group.

Brian: Right.

Aravind: But then the Test Infra is also actively contributing.

Brian: Okay.

Aravind: So, there is enough—

Brian: Synergy, they support each other—right.

Aravind: Partnership, synergy between the two, but the reason why they're separate is more around the focus. Like, we want the Test Infra to focus more on the testing strategies with our challenges, whereas Engineering Efficiency on tools primarily to help out the developers in their day to day software processes.

Brian: Okay. I love that, and I would say I'm a guy that’s never accused of not having an opinion, and what I do love about that is that they work together but there’s still value in domain expertise. I think sometimes we forget to value depth and domain expertise as we look to share knowledge, right?

Aravind: Exactly. For example, the principal test engineer in our group, he collaborates with, let’s say, engineers from other teams, product teams. They come to us and say, “Hey, we have this new Python app. How do you recommend testing it in the microservices world?” and we are collaborating.

Brian: Right, and he can take that expertise. So, shifting gears a bit, would you consider LendingClub a fintech company?

Aravind: Yes.

Brian: Okay. Can you explain for our listeners before we dig more into the business and how DevOps applies—what is fintech?

Aravind: Yeah, so, in my opinion, fintech is using all the technology and all the innovations like software to innovate traditional finance practices.

Brian: Okay.

Aravind: For example, let’s take an example of LendingClub. So, traditionally, the way you apply for a loan is like, you go to a bank, you submit your application on paper. There are some things online, but you are physically there, you have to go through all these underwriting processes.

Brian: Right.

Aravind: And even considering the banking aspect of it—this is the customer side, right?

Brian: Right.

Aravind: On the banking side, people go through a lot of data, do the underwriting processes and stuff.

Brian: Right, right.

Aravind: So, where we are making a difference is making this process seamless and very easy to do. For example, you can go to our website or mobile app, then fill up your details, submit a loan and you right away know what are your offers.

Brian: Oh, okay.

Aravind: So, for a personal loan, let’s say you are applying for a $20,000.00 loan. You provide your assets and basic background information, we offer you, like, “Hey, these are the types of loans available. Would you be interested in taking them?”

Brian: Okay.

Aravind: Then, once you finish the application process, behind the scenes, it’s like, our software is churning. Like, we are running machine learning models, credit policies to, first of all, give you the loan, the underwriting process, plus there is also the investor side of it. So, we are a marketplace where we help both borrowers and investors.

Brian: Okay.

Aravind: So, our goal is to make the borrower process easier as well as good rates for the borrowers compared to credit cards, debt consolidation and stuff. Whereas the investor side, we want to also maximize the returns, so there is always this what I would say the challenge of what would be the best interest rate and then making sure you are also maximizing the returns for the investors.

Brian: So, over simply put, you guys have taken a fintech approach to modernizing the investor/borrower, lender/borrower relationship.

Aravind: You got it, yes.

Brian: And you use technology. And so, is it fair to say LendingClub is sort of the Tinder for loans?

Aravind: I would say Uber for loans.

Brian: Okay, better.

Aravind: Yeah, basically, yeah, Uber for loans, because we don’t physically own transport cars, we don’t physically own a bank.

Brian: Right, but you make the match.

Aravind: Exactly, yeah.

Brian: So, why is it important that LendingClub stay on the cutting edge of technology in order to provide that service? So, more importantly is, why are modern software development practices, tools and technology important to LendingClub’s business?

Aravind: That’s a great question. So, basically, because we are fundamentally a finance—I mean, a technology company powering the finance, so, it’s all about how innovative and how effective we are with our software. So, that’s what drives our speed, for example. We have to be constantly innovating in our mobile app, the way we process the loan, the way we run the batch servers in the background. Similarly, coming to software development, the faster we move, it helps us. So, we want a quicker feedback loop, because we are one of the very first such companies in the space. So, there is a need to learn how the users are doing. So, we really need faster experimentation, a faster feedback loop, which means a faster way to release the software.

Brian: Okay.

Aravind: Additionally, because we are also in the finance space, we are bound to meeting the complaints, audit requirements, which means we have to be very thorough with our software practices.

Brian: Okay.

Aravind: At the same time, because we are competing against traditional finance services, we want to make sure these processes are not slowing us down. So, we have to be creative in balancing both. Like, while we are doing the complaints, we are having the right checks and balances. At the same time, how we are speeding up the software development, testing and release.

Brian: Okay, and at the core of that, it also sounds like the core of your innovation in the market, automation in software intelligence is key. Is that fair to say?

Aravind: Exactly, exactly. Yes, the more we do that, the faster we can move, the faster we can experiment with new products. So, we have always been growing our product line. Like, we started with personal loans, but today, we have auto loans, we have purchase finance loans, and if you followed our recent earnings last week, we are releasing new products as well.

Brian: Oh, wow.

Aravind: So, it really helps us innovate.

Brian: Yeah, what I’d like to do is, since we're in this special edition, I can’t dig down as deep as I’d like to into the release of these new products, but maybe in the future, we can dig in a little more. To start to sort of look at the output and outcomes, I’d like to ask, what’s the biggest success or surprise success that you've encountered in your journey to implement CI/CD and DevOps?

Aravind: I would say the pace of adoption is a successful surprise is what we're calling it. So, an example is, we had the traditional model of many teams having their own Jenkins jobs, pipelines with the various microservices.

Brian: Yeah.

Aravind: But when we set out to automate the process with central library-based pipelines, pipeline library tools to make life easy, both standardized as well as help people set it up easily.

Brian: Right.

Aravind: Example is, if there is a new service, we want to onboard the bill process for it in, like, 15 minutes.

Brian: Okay, wow. Okay.

Aravind: So, such kinds of things, the success, the surprises—of course, the very first couple of services we do with this approach took a lot of time than expected, because we are trying to bring a change, convince people how this is more effective.

Brian: Right.

Aravind: So, the team was a little bit, like, “Oh, it’s going at a slow pace.” But once we could prove for the initial set of developers, it’s amazing, like, within the next two, three months, all jobs are using our approach, plus the code review practices, what we developed with our tools for command line. Now, it’s so embedded into our DNA that people don’t even realize it’s like a special tool.

Brian: Okay, and they just sort of take it for granted that it’s part of the process.

Aravind: Yeah, exactly.

Brian: Let me ask, in terms of that adoption—because it is rare. Usually, when people say they're surprised at the rate of adoption, they're surprised that it’s taking longer than they expected. So, it’s really interesting and encouraging for you to say that your surprise is adoption has picked up, and it sounds like it got faster and faster, right?

Aravind: Exactly. So, let’s say, from concept to beta, it’s slower, but from beta to full rollout, it’s like, super-fast.

Brian: Awesome.

Aravind: Like, first three services, from then 3 to 300, 200 services, faster adoption for anything we bring, because people see the value and they all add up.

Brian: And they're now, for greenfield now is net, new things come on, like you say, it’s 15 minutes at least to have their pipeline and infrastructure in place, right?

Aravind: Exactly.

Brian: Awesome, awesome. Now, looking at the flip side of that, we often like to ask about lessons learned, failures. We call them DevOoops, so D-E-V--O-O-P-S. Not DevOps but DevOoops—do you have any moments that you can think of to share where you guys stubbed your toe, you messed up and you took an important lesson away from it?

Aravind: I would say maybe, like, the DevOoops moment really helped us in the sense, for example—oh, in my memory, what I feel is, the DevOoops moments are places where there were a lack of good DevOps practices.

Brian: Got ya. Right, right, right.

Aravind: And then people found the need—oh, yeah, I should have listened to you guys.

Brian: Right, right, right.

Aravind: And then put a job for this. Let’s say, like, a common mistake people do is something very simple. People think, “Oh, we don’t need an overhead of setting up the automation job for this.” People understand—

Brian: For a given step.

Aravind: Right, exactly. So, those are the kinds of examples.

Brian: Okay, so I'm sure you have a lot of them, but it’s usually, sometimes your customers who you service within your organization have to feel the pain and have their DevOoops moment.

Aravind: Right.

Brian: And that adds value to the solution since you guys can bring it.

Aravind: Right, yeah.

Brian: Awesome. Now, another question I’d like to ask is, what are you reading? What reading of any type, technical or otherwise, do you suggest our readers listen to that will help them on this journey in modern software development, CI/CD, and DevOps?

Aravind: So, I would strongly suggest reading this book called The DevOps Handbook. So, what we did—one thing that the book helped with our DevOps transformation ease. We have a book club-slash-lending club where we help people from, let’s say there are a couple of junior engineers, a couple of architects, there is a Dev manager, there are people from QA, from Infra all meeting every week, setting aside a certain time and then going through one chapter a week. 

Brian: Ah.

Aravind: Somebody takes ownership, moderates the discussion and this DevOps Handbook was very interesting in that it brought in several perspectives. Like, initially, it starts off with, “Hey, what are the common pain points in traditional software development? How does CI/CD help? What are feature flags?” And then once you do a deployment, what is blue print deployment? Several concepts.

Brian: Right.

Aravind: Plus, also, the culture change. I think the biggest help it brought in is the culture change, because people are, as a team, thinking together, reading the same book. And the book itself has several stories from other companies, so that really helped.

Brian: Oh, okay.

Aravind: So, I would strongly suggest, the book’s name is The DevOps Handbook.

Brian: Okay, and you also recommend this idea of—The DevOps Handbook, do you know who the author is, by the way?

Aravind: I think Jez Humble, if I'm correct. I think the same people who wrote—

Brian: Okay, he’s a contributor, yeah, to—

Aravind: - The Phoenix Project, it’s from those guys.

Brian: Yeah, okay, so DevOps Handbook for our listeners. And it sounds like you also are a big proponent of a book club for sharing knowledge and encouraging collaboration. Would you say this is something that you recommend other people look into?

Aravind: Yes, definitely. Like, from my experience at LendingClub, the major transformations I can think of—so, for example, the first transformation was moving from a monolithic architecture to microservices.

Brian: Yes.

Aravind: At that point, we were all reading this microservices book. Then, now this one, and now there is a good focus on AWS. So, some of us are reading some of the certification courses on solutions architect, developer architect. So, people are forming study groups. That’s really driving the base.

Brian: I love it, I love it. Alright, so another question I’d like to ask as we get ready to wrap up is, who is your DevOps superhero, either in the industry, personally, at work—who do you consider your DevOps superhero, and why?

Aravind: So, I would consider a developer who is conscious about the overall operational knowledge as the DevOps superhero.

Brian: Yeah. Okay.

Aravind: The reason I mention is, such developers are very valuable because they inherently feel that they are not like, “Okay, this is, I'm only doing development, and then I am doing a handoff.” They don’t have that mindset.

Brian: Oh, right. They have an ownership.

Aravind: They are consciously thinking, like, as an—because, from the grassroots levels, they can bring the change. So, as they are designing their architecture, they think about, “Oh, if I architect this way, can I allow feature flags in future?”

Brian: Okay, right.

Aravind: Yes or no. So, because of that, it helps operationally managing better, so the analogy I would give is—because you brought in the superhero type analogy, I would say, so, I feel like Batman. More specifically, The Dark Knight.

Brian: Okay. Ah.

Aravind: He’s a very good superhero for DevOps, because, during the day, he’s a businessperson running the business. At night, he’s going and saving the city.

Brian: Ah.

Aravind: And the way Dark Knight ends, the cops are chasing Batman and he’s running away, and then the cop, he says it, I like saying, “This is the hero our city deserves, but not the one we need right now.” And then he ends it saying, like, he’s a watchful protector and a silent guardian, and hence, he is The Dark Knight. So, I feel DevOps practice or mindset or the CI/CD pipeline is nothing but a silent guardian or watchful protector.

Brian: I love it, that was great. And I wanna add my piece—and it’s also a normal person that wants to do good equipped with the right tools to get the job done and save the city.

Aravind: Awesome.

Brian: No, that is awesome. Well, thank you for joining us for this episode. Thank you for coming out to DevOps World Jenkins World. I hope you enjoy the rest of the show. Real quick, before I let you go—what are you planning on going and doing next at the show?

Aravind: Yeah, so, I wanted to check out sessions around Jenkins X and then also, there are interesting sessions on innovations with test automation. So, there is a talk on AI-driven dynamic locators to do test automation easier.

Brian: Awesome.

Aravind: So, those are the top offers.

Brian: Always thinking efficiency and quality. Well, alright. Thank you for your time. Hopefully, we'll get to talk again later and I'll look forward to being invited to your podcast sometime, soon.

Aravind: Yeah, thanks. Thanks for the opportunity. Great talking to you.

Brian: Right on. Thank you.