In the cloud-native world, we no longer create applications from scratch. We are taking open source components and assembling them together to create new services and products. This creates a unique challenge for developers. There are so many manual and laborious tasks that can be automated so developers can focus on key aspects of their application. Jonathan Schneider tried to address this problem during his tenure at Netflix and now he has created a company called Moderne to bring his experience to the entire ecosystem. In this episode of Let’s Talk, I sat down with the co-founders of Moderne, Jonathan Schneider and Olga Kundzich, to learn more about the challenges facing modern developers and how Moderne is helping them out.

Guests: Jonathan Schneider, Olga Kundzich

Company: Moderne

Show: Let’s Talk

Here is an edited transcript of our discussion.

Swapnil Bhartiya: Welcome back to Let’s Talk. I’m your host, Swapnil Bhartiya, and we have two guests on our show—Jonathan Schneider, co-founder and CEO of Moderne, and Olga Kundzich, co-founder of Moderne. Jonathan, Olga, it’s great to have you on the show.

Jonathan Schneider: Thank you. Great to be here.

Swapnil Bhartiya: Tell me a bit about the company. What problem or challenge did you see in this space that you wanted to solve and created this company?

Olga Kundzich: We see that cloud-native software has changed a lot in how we developed software in the past decade and right now, instead of building applications from scratch, we kind of assemble it out of third-party dependencies. And a lot of maintenance becomes really hard because developers have to keep re-stitching their applications out of this open source and third party, the inter-dependency that they integrate.

We saw how tedious but also how repeatable this problem was, so we took the technology that Jonathan developed earlier at his time at Netflix, which was used internally to upgrade APIs and we extended its capabilities in the last year significantly. So the whole framework migrations are now possible while CD patching in an automated way.

Swapnil Bhartiya: Jonathan, if you can share your experience from the Netflix days that you brought there, you saw this problem that you wanted to address.

Jonathan Schneider: There at Netflix, we had thousands of repositories, source repositories. It’s really common, especially given the microservices movement that we see a lot of different source code repositories. And when you want it to effect some change across them, it can be very tedious and also difficult to go locate all the particular call sites you need to change and make that change.

It’s much bigger than just a search problem; it’s a problem of how do I actually make the change and affect it. Luckily at Netflix, there was a freedom and responsibility culture which meant there were a lot of different styles of code. So when we built a refactoring solution, we did it in a way where the suggested code changes that we make look idiomatically or stylistically consistent in the context of the project that it’s inserted into.

So it looks like a developer is handwriting the changes for each individual repository, even though they could be very different from one another. Now we go to a design partner and we say, “Look at one of your static analysis tools,” a SonarCube, anything like that and say, “What is it reporting?”

And sometimes the scope of the suggested things to fix can be pretty large, hundreds or thousands of developer days worth of work and we will develop recipes for those sorts of things that will automate the fix across the organization’s code base.

Swapnil Bhartiya: Do you focus on a specific area? Because when I look at developers’ workflow, there are so many things that they have to do.

Jonathan Schneider: I think if you go back 10 or 20 years, there was this concept of technical debt in our code. Technical debt then meant, “I didn’t use the correct pattern” or “I should’ve renamed something this way or that.” Part of this move towards cloud-native software delivery has also involved a change to industrialized software supply chain where, as Olga mentioned, we’re stitching together business applications out of a lot of third-party components.

Jonathan Schneider: What that means is those things evolve independently of our release cycle and now the developer’s on the hook for keeping up with that sort of thing. We’re still calling that technical debt but it’s a different form; it’s not something that the developer imposed upon themselves. It’s being foisted upon them from the outside.

Jonathan Schneider: We estimate 20% to 30% of developer effort is spent addressing this form of technical debt, which is really just software supply chain management activities masquerading as technical debt in the modern development ecosystem.

Olga Kundzich: We just help the developers in their activities, so it’s complimentary to all of the investments that we’ve made already in our DevSecOps pipelines. So to help them speed it up and then leveraging all of those investments to automate promotion of the code into production.

Swapnil Bhartiya: You mentioned technical debt. Technical debt can be seen in so many different ways. You can fork a code and now suddenly you have made it your own version. One more thing that could be closely associated with technical debt is also called tribal knowledge. Within an organization a lot of people solve a particular problem in their own way; there is no externalization, there is nothing automated. Now when those people move, they take their knowledge with them, another team comes and they try to reinvent the wheel. How big is that problem and how do you also address that as well?

Jonathan Schneider: This is such a great question. We talked to principal engineers and our lead architects and a million developers all the time and one thing we hear a lot, especially of the more senior folks is they say, “I feel like I’m going around telling everyone to pick up their socks all the time. I’ve identified something I don’t want to see again.”

Jonathan Schneider: So now what we provide is the ability to develop a recipe that encapsulates that knowledge. So it’s interesting. You start a change campaign with that encapsulated knowledge to eliminate all the occurrences of some pattern you don’t want to see anymore and maybe you get that to zero. But then you can run that recipe in perpetuity to prevent that pattern from reemerging in the organization, as the developer goes out and copies and pastes something off a stack overflow or they see something else somewhere in another example.

Jonathan Schneider: And so what you get is the more recipes you add, the more knowledge you encapsulate this way, the more you raise the bar of software quality inside your organization.

Swapnil Bhartiya: If you just look at the company, we talked about the problem and how you are addressing it. If you can talk about the solutions that you’re offering, either their products or services or SAAS/IAAS. Talk about that as well.

Olga Kundzich: I think that the refactoring technology is in open source, specifically to build a community around contributors and people using recipes. And especially, we feel like we have aligned interests with framework authors and security researchers for them to publish and distribute recipes that migrate their consumers and large CDs.

Olga Kundzich: And part of our solution is a SaaS offering that allows organizations to distribute these recipes across the large code bases that they have with collaboration features and change campaign management, etc. Many organizations have accumulated vast amounts of code and coordinating the distribution and code improvements is already very difficult.

Jonathan Schneider: So it’s fantastic to be able to test a recipe on one repository and see a change. So I think one of our design partners was trying to move from JUnit 4 to JUnit 5. They have been working on it for 18 months and have migrated 20% of their unit tests from JUnit 4 to JUnit 5. On that one repository, they apply the migration recipe we had written and they’re done. So five minutes later, the remaining 80% of the code base was migrated. That was an incredibly tedious amount of work done.

Jonathan Schneider: So then once they see that on one repo, they think, “How could I do this across my other 1,000 10,000 repositories?” And that’s where the SaaS offering comes in and helps distribute that change across the organization.

Jonathan Schneider: What I love about this company, and it’s the way the company is structured, is that all these recipes, we will always put in Apache license repositories. Like Olga said, we want that aligned incentive with framework authors to write recipes. What we’re here to help with is to distribute that change across the organization and make sure patterns don’t reemerge.

Swapnil Bhartiya: Your solutions are also based on OpenRewrite and Open Source components there. Can you talk about what open source components you’re using and why did you pick OpenWrite there? What libraries are used? What frameworks are you using? And not only how you’re using these things, but also how you’re giving back because that is critical to any open source project.

Jonathan Schneider: Absolutely. So OpenRewrite is the main organization on GitHub where the core refactoring engine and all of our recipes live. So it’s OpenRewrite, Rewrite is the main repository. One of the ways we give back is byactually running a public forum of the SaaS and we’ve ingested to this point about 50 million lines of code of open source repositories from Spring, Microsoft, Apache Projects, et cetera, and we apply our recipes regularly to those open source repositories and issue PRs to help them improve the quality of their code and move forward on versions as well.

Jonathan Schneider: So that’s something we’re going to continue to do is be a big source of fixes and PRs going into other open source repositories.

Swapnil Bhartiya: If you look at last year,a lot of companies did rush to Cloud because of the pandemic in order to accelerate their transformation journey. Two things happened. Yes, a lot of companies rushed but they also rushed kind of blindfolded. They did not know because it was not very strategically planned. Now that hangover period is kind of over, they are hitting reality. So what do you see from the area that you are specifically working on, as you mentioned? What are the challenges that they’re facing and how are you helping them to overcome those?

Olga Kundzich: Things have accelerated but this is not just in the past year, it’s been happening in the past 10 years. Like again, we mentioned that software development becomes industrialized and not handcrafted but assembled and gradually more and more changes are coming and developers have to keep including these changes. So I think this is a trend and last year accelerated it, but it’s been around for a while.

Jonathan Schneider: I think one thing that may be surprising as you look at… you hear automated migration, and you think the largest applicability of this would be to legacy applications that were running on-prem, maybe not in a Cloud environment. Lifting them up from struts to spring boot, or lifting them up from a very old version of something else.

Jonathan Schneider: And while there is applicability to that, there’s actually a stronger case to be made that a modern cloud-native application requires automation at the source code level, because it’s more likely to involve more open source components and third-party APIs that evolve at their own pace.

Jonathan Schneider: So in a recent internal meetup, we asked an interesting survey question to inter-developers. If you could no longer touch the code in your application, how long would it continue to function? 81% said bust in six months. That was really surprising to me. If you’d asked me that question 20 years ago, I wouldn’t have really understood the question. Of course, it doesn’t accrue features automatically, but it keeps running as long as it’s deployed somewhere.

Jonathan Schneider: And that’s not true anymore of a modern cloud-native app. So that cost is going to be incurred one way or another. We build apps faster but we also have to maintain them on a more regular basis. And so I think what we’ll see is a good application of this to the more modern applications.

Swapnil Bhartiya: I think when it comes to Cloud, it’s not just about cloud-native computing. A lot of it is that automation is kind of becoming key, you cannot do without that. But if I ask you then, how further are we in the path of automating most of the things? Have we achieved most of it and we are in the early phase or we are like, “Hey, that’s done. Almost everything is fully automated. That problem is solved.” Or are you like, “Hey, no, we are just getting started.”

Jonathan Schneider: I feel like we’re just getting started. We really view this in language verticals. We’re going to do Java really well. We’re going to doTerraform really well. We do YAML really well? We do XML really well. And then you start layering things on top of that. I could autoremediate GitHub action files. I can autoremediate CircleCI files. We’re adding a JavaScript TypeScript language, binding a Python language, a .NET binding, a COBOL binding. We’re not opinionated about this sort of thing. I think to do these kinds of things well, especially around auto remediation, you have to take a really deep white glove treatment of each language because each language has different idioms, different experiences that developers in that ecosystem demand to have automation be something that’s accepted. So I feel like we’re just getting started.

Olga Kundzich: I think if you look at the refactoring technology that’s in open source, I think in the last year, we really did build a lot of high-level building blocks. The recipes that composable we validated them on pretty significant migrations. Like you mentioned, JUnit 4 to JUnit 5 was a good one to two. Java eight to 11.

Olga Kundzich: So I think there’s a lot of promise and we know that this is 100% correct and style preserving. And from this point on, we just need to build more and more of these recipes.

Swapnil Bhartiya: Can you also talk about what are the use cases where your company is playing a role there?

Olga Kundzich: Well, it’s very interesting because we see that this is applicable to so many organizations from very large enterprises to medium-sized technology organizations to small startups, even us, as a young startup, we leverage quite extensively to refactor our own code.

Olga Kundzich: Because again, we’re going back that everyone is re-stitching some sort of a business application from the same subset of open source that third-party vendor dependencies that need to be upgraded and tended to.

Swapnil Bhartiya: What kind of roadmap do you have for at least this year? Because we cannot even talk about five years in this, a very, very volatile time. But if I ask you, “Hey, what is going to be the focus for you?” What would that be?

Olga Kundzich: I think we will continue to build refactoring recipes and extend them into different languages. We are working on TypeScript right now as well as with our design partners early, for whom we would like to bring the SaaS offering internally to their internal code basis.

Jonathan Schneider: When we work with a new design partner, what we want to see is just a list of problems they have; their top five or 10 things in code that they wish they could do away with. That they could improve, that they could move faster on. And what we want to do is tackle those five or 10 things right away, be done with it this year.

Jonathan Schneider: And then there’s a larger story of how I run this and how do I keep this going in perpetuity? How do I expand the set of changes that I want to be able to make on an ongoing basis? But we love solving concrete problems for the design partners that we work with.

Swapnil Bhartiya: Olga, Jonathan, thank you so much for taking time out today to talk about not only the company but also one of the pressing problems that we are all facing and how the company is helping effect a lot of things, moving developers into an automated pipeline. There are a lot of things that I want to talk about, so I would love to have you folks back on the show and continue this discussion, but thanks for your time today.

Olga Kundzich: Thank you.

Jonathan Schneider: Thank you. It was a pleasure joining you.