Developer Platforms and Productivity, with Serdar Badem

Episode 279 · Tue, 23 Jan 2024 12:46:21 +0100 · 50:30 · SRT · archive.org · all Tanzu Talk

So welcome everybody to the first 2024 episode of Coté and me doing interviews on Tanzu Talk. And I'm really excited today. We have Serdar Badem, who is a director of product management at Tanzu by Broadcom. So one of our very own colleagues. And I'm really excited because I had the opportunity to meet Serdar last week and he made a comment, just sort of a casual comment about all of how excited he was. We'll learn more about him from him directly, but I'll just tell you who was at VMware before and then he left and he spent some time at Uber and then he came back to VMware just in time for us to be incorporated into Broadcom. But he came back and he made a comment that he was very excited and had a lot of ideas to bring into the Tanzu division now at Broadcom. And that just sort of sparked my interest and I wanted to learn more. So I figured why not deep dive into that comment with all of you here today. So just to get us started, I guess, Serdar, would you tell us a little bit more about what you're doing currently at Broadcom? A little bit more about yourself. Awesome. Thank you, Cora and Coté. I am excited to be a part of this podcast. So I'm leading product management for spring and content and developer solutions here at Tanzu division by Broadcom. And really excited to be back at VMware and we have ambitious goals. And our focus is as much as it's ever been around making developers more productive and providing the tools and services to remove friction from their daily lives. Amazing. So do you feel like that's been a thread throughout your career, sort of that focus on

developer productivity? Yeah, pretty much. I mean, it's always, well, originally I started as a developer myself at Hill Packard, the open view of division. Some of us may still remember. And I started, you know, we were building tools for the enterprises, especially IT, to manage their infrastructure at that time, and then slowly evolved from IT into more around tools for developers to remove the tedious work and eliminate friction in their daily workflows. Yeah, we've come a long, a long way. So you've seen everything. You've seen the operation side, you're deep in the operation side and the development side. Yeah, I mean, I think most more recently at Uber, I was the product management lead for their developer platform. Uber has a large platform engineering team and making all the developers, Uber is a technology company at the end of the day, and keeping those thousands of developers more productive and providing them with all the tools and frameworks to make them more efficient was our primary goal. And that may be a more recent context in that. So how do you think about that challenge or measure that goal of developer productivity? What does that mean to you? Yeah, I know. It's a, it's a complicated subject, isn't it? Like, you know, how do we, how would you create an environment where developers feel happy and, you know, they want to just show up and do the best work of their career? So that's, that was the, that was our goal, basically.

And of course, we want to measure, measure it. It's not necessarily for, from performance of individual engineers perspective. But, you know, if you know, if you think about having a team of hundreds of engineers building tools and frameworks that these developers use, you want to understand what are all the pain points, what are the frictions and how, and you can argue that the, if we can provide the best tools, then that would turn into productivity gains for the entire organization. For all the developers and create that atmosphere. It expresses a faith in humanity that if people are happy, they're going to do their best work. So it's not, you know, like, you know, you could have said, well, you know, make developers happiest because that way they'll be most productive and then they'll yield more to the business, you know, which is like the more, the financial sort of drive for a business, I guess. But I think it's really beautiful that you're like this, there's this real sincere, you know, faith in humanity that, that happy people will, will do more and do better because that, that happiness will drive them. And so the idea is to make people happy. I think, I think it's really a beautiful principle to live by. Getting to increasing the beauty in the world, as it were, like, like, I was, you know, given, given what, you know, you, you product manage now at a vendor, if you will. And then having worked at, let's just say, a customer, a user, right? Like a company who's, who's a business other than selling software or cloud services or whatever. And then product managing before that, like, what, so, so you've talked with people at all sorts of organizations and worked in some like Uber, right? And I've been trying to figure out, like, let, let me, let me, let me paint a scenario I think is on the other end of the spectrum of developer productivity, not in a bad way, but like, you know, I was thinking the, like, whatever app I use to refill my prescription, like, it doesn't really get updated that much.

And like, it's fine, right? Like, and, and in fact, it's, I kind of don't want it to be up to, or I don't know, that's, I shouldn't say it that way, but like, versus, in contrast, I would imagine, I mean, you, you would know better than I do, but like, and maybe this answers my question about the pharmacy thing. But even if people using Uber don't see it in, in the UI, there are probably a lot of software changes going on all the time, right? And so I wonder, like, I'm, I'm always trying to calibrate on like, so a company like Uber really cares about developer productivity, because they, in the same way that I assume Mercedes doesn't want their factories to rust. It's just like, they don't even question why you would care about it, right? Absolutely. Versus like other companies, like, how do they figure out, like, how productive do we need to be? Like, and, and how do we figure that out? So that when people like us come in and we're like, ooh, developer productivity, you should be deploying 50 times a day, if not thousands, like booking.com or whatever. Like, I feel like maybe the, the pharmacy people are kind of like, eh, or, or like, not that they're not convinced, but there's like a different discussion going on around that kind of stuff. At a company like Uber, imagine there are thousands of microservices, over 5,000 microservices, and these are running in, and there's a lot of dependencies between them. And small teams own and, or they're responsible for running these microservices. They, they create them and they also run it. They're on call to support if, if, if an incident happens. And, you know, since these platforms are running at a huge scale, there are major implications of having something down or not working the way you expect it.

There are big implications for the business, both financial and reputation wise. So, you know, and, and that's why having a platform to be able to run everything efficiently and in a productive way and producing quality software is, is important. And remember the message is, every, every company is actually becoming a software company these days, uh, when you see the technology, uh, everywhere. So even in cars or, or, or whatever. Uh, so, uh, and then there was no doubt about, uh, why developer productivity was a top of mind for, for the executives, uh, at, at, at any, uh, any, any company. And for sure. The way I, how I see it, there were some key metrics that we would track and, uh, report up to, uh, up to the CEO every month, uh, around this. Yeah. And like, I, I think, you know, you know, you're, you're, you're, you're kind of, as, as you say, driving towards, uh, like a, like kind of an interesting conclusion that in the conclusion, like next sort of juncture in, in the road. We're going to really get trapped in this metaphor, uh, which is like, if you are relying on software to run your business, chances are you care about developer productivity versus like, you know, to be an absurd about it. Right. Like no one's really concerned about like, uh, pencil productivity, just like the, the potential of pencils has peaked like after the mechanical pencil, we don't need to have like someone like yourself working on the pencil platforms inside of a company. It's all settled. Whereas like the, the nature of using software as a tool to, to, to run a business is far from pencilized, uh, as it were. So like, you're still constantly trying to figure out how to do it better.

Um, and I think, and I, and you, you know, the, the, the other thing that. Like you were kind of alluding to as far as like availability and things like that is, and I was kind of joking about is like, maybe even though the way that I, you know, renew a prescription doesn't really seem to change ever. There's probably a lot of stuff that I don't see that's changing that needs developers and developer minded people to worry about it all the time. Like I often think like example, in the pharmacy business, there's always some new regulation that you have to comply with. And, and the government hasn't read that whole thing about like developers are bad at estimating deadlines. They're like, they don't care. You've got to hit this date. Anyhow. Um, so, so maybe as you're saying, that is kind of like a motivation for everyone caring a lot about developer productivity, which, which I think makes sense. I was going to, I know as Coté, as you were talking, like, I mean, this differentiation between like some organizations may care more than others. And I, I can see like in the human experience, like there's certainly like some products that we come across where we can tell that that product is not important to a company. Like the user experience for a certain product is not important to a company. And now that software has gotten so good, the end user experience with software has gotten so good, you know, in the same way that we say like companies care about developer productivity and they care about developer happiness. Companies also care about user happiness, right. For, for good, solid business reasons. And there is, and there are some software products that are produced by companies where like, it's not that important if a user is happy or not, because like when you fill your prescription, like who cares? Like you got your health insurance from your company. It's not a choice that you're making and you're not likely to jump away from that prescription provider to another one. Right. So that is not an area where there's a lot of competition or they feel a lot of threat of losing a customer, but so I feel like maybe that's, maybe it's a prioritization in terms of like sort of business value, but that doesn't mean that those same companies in the software that they're producing, that is more relevant, more germane or more vital and core to their business, those same companies still have this challenge.

Right. Well, I want to actually, I want to maybe disagree. So think about it this way, even every business is, this is always evolving and there's always disruption. There are newcomers coming in, eating, eating away. So there's always new ways and more efficient ways, better ways to serve your customers. And this could be prescription as well. So you see, there's a lot of competition, even in the pharmacies. How do you keep the drug prices? But at the same time, deliver at the delivery, there's a lot of innovation there. With how you connect with customers and help customers manage their prescriptions. And, you know, I think this is, this is a hot area. So if you think about those companies, maybe established players, providing, seeing the pressure to provide new ways to interact with their customers, they need to build those new applications and have all the software to be able to, you know, personalize medicine. So there's a lot of innovation that's needed there. And so it actually forces these businesses, established players to also even brick and mortar players to be, become a software business. And so then they also feel, they should feel the same pressure as, as, as, as, as a, you know, ride share company providing an experience. You know, if you look at the business itself, it's been there for a long time, but the way you provide the service and improving the customer experiences, that's where the pressure is. And now to be able to do that to, so now you're a software business business really, and, and then you really have the same pressures to, to, to run your business more efficiently, productive and have the high availability. So, so productivity, developer productivity, that has to be top of mind for, for any company and really, you know, the way we think about the productivity, or if you think about, you know, teams, platform engineering teams and developer platform teams, there is a, there are some best practices, uh, on how, how they can think about, uh, running, uh, those platforms, uh, efficiently and, and productive.

So the same, the same focus that we used to have for customer happiness has really shifted internally. And that developer is as important as our external customer was. I think, I think it's true, right? That's pretty universally, uh, understood today. I'm not, I'm not actually quite sure when that shift happened. If I think back in history, it was a little bit gradual. There was that book, the new Kingmakers that came out. I think it might've been like 2005 ish or something like that quite a while ago. So, um, maybe that sort of time period is when this kind of thinking kicked off. Right. And the, and the internal developer became as important as the, as the customer, but I guess I wanted to ask you, uh, what are, what are some examples of things that you did at Uber when that developer productivity became your main priority? Yeah. You know, um, so maybe if I, uh, take a step back and think about, think about it, what does the, what does the, what does an internal developer, uh, form team does? You know, one thing is, you know, there, there are, there are three factors really. One is we want to accelerate and that's really, uh, provide, having the right velocity, go fast. Time to market is important. Second, uh, aspect is quality. Um, you know, we want to make sure you have provide the safety nets for your developers. So they can, you're, you can be more confident when you release software and move fast. And the third one is efficiency. So it always boils down to these three factors, quality, and efficiency and efficiency is really about, um, when you run a platform at scale, if you standardize, then you can, uh, lower the cost, you can run things more, uh, in a more efficient way. And that was, that was, uh, uh, this, that's probably a good strategy for, uh, a lot of internal developer, uh, platform teams.

And you really also, you want to be able to measure what matters. You, you want to be able to have the right metrics in front of you. So you can, uh, prioritize, uh, effectively. So now, you know, maybe, uh, a lot of, a lot of the tools that we, uh, we built was in, in these buckets. So when you think about velocity, those are all the tools that you provide to developers, the powerful frameworks. So that takes away all the busy work from developers, uh, lives. So that's why a framework like a spring framework, uh, for Java developers, uh, become really important. It takes, it handles all that boilerplate code that you would write. So you already, you want to make sure, make it easy for developers to get started with a new project and, uh, and make sure that it has all the logs metrics. It's all connected to whatever the platform offers, uh, and new developers can start easily. So the, the framework and, uh, and then, uh, how we organize the repositories, the dependencies was, was an important part of, uh, what we did there. So, um, on the quality side, there were a whole bunch of test automation, uh, tooling, uh, around there. Um, and, uh, to be able to standardize things, uh, at Uber, we used maybe a contradictory subject, but we use mono repos, uh, on, as when we think about standardizing and having a centralized platform team doing all of these, uh, for the thousands of developers that you have. And, uh, and I can be more specific about some of the exciting, uh, some, uh, projects that, that we've, we've done there. And mentioning the spring framework and, and boilerplate and, and then also like, well, standardizing things.

Like, I'm, I'm curious to hear, like, I feel like way back when I actually, uh, worked at BMC software. So I know open view, but, uh, a long time ago when I was actually a developer, like if someone other than if basically anyone said they were going to standardize the way I was doing my work, that made me feel very uncomfortable. Cause then someone else was going to be in control of what I was doing. And so I'm always trying to filter in my head. Like if you're the, you know, a platform group, a tools group, how do you, how do you find the level of standardization that works? And, and I mean, works in the broadest thing that like the developers actually follow it and it gains the benefits that you want by, by standardizing. Yeah, I think maybe, maybe hard that when somebody says you have to use these tools or, um, you know, kind of constraining the things that you, the, the, the tool set or, uh, things that you could do. But if you could make it work, it becomes a magical thing. Um, and, and also you should understand that it's not like forcing everyone to use, uh, use, uh, the tools that, that you provide, uh, you know, these internal teams responsible and they're accountable for the, the, the tools and systems that they provide. And they also have SLAs that they need to provide. And the fact that I, uh, a person, a product manager even exists for that internal, uh, platform team kind of suggests that, you know, you really take it seriously, understanding the pain points of your customers, your internal customers. If you're an internal product team, a platform team is, uh, those developers. So, you know, uh, there are many ways that we get their feedback, uh, like the NPS surveys that you would run every six months or quarterly.

Uh, in addition to other microfeedback loops that, that you have, uh, and all the metrics that you get in, you know, how much time it takes for you to run a git status command on your laptop or how much, uh, the local build takes. You measure these different levels like P-75, P-95, and you try to improve the processes and, and the tooling and the speed every time. And that's, that's the way that, uh, that, that we, we approached. And, uh, but also another point is, you know, having standardization really helps. Otherwise, you know, the governance becomes an issue. You know, we, there's a good reason why we had a monorepo up those dependencies when you have a complex world with 5,000 microservices and thousands of tens of thousands of repositories, uh, with multiple projects. You know, that, you know, that, at that scale, to be able to run, uh, efficiently, uh, and still keep your business running smoothly, that there wasn't much, many options the way, that's the way we saw it. So we had to have a monorepo, uh, in that case, or we had to, uh, provide central team automatically upgrading the dependencies all the time. Or, uh, you know, also it's important that one developer, let's say, uh, who works on some area can easily move to another code and still, uh, help out there if you have that, that, that, that standardization. So all of these are, are the benefits of having, uh, having a platform and having, having a standardization. And I think once you start working in that environment, you know, there wasn't much of a question that, of course, there were sometimes, uh, when, when there's a new project, you know, there are questions.

Okay, is this, uh, you know, should I use these tools that are provided to me or should I go pick something else? That, that's a valid question. Uh, but, you know, we, we really didn't, uh, once the, uh, once you get to a level that everything runs smoothly, there wasn't much question about the, the tools that, that were provided. Yeah, I think, you know, what, well, you, you would know better than I with, with all your roles, but it's, it's sort of like, I think the difference is you product manage the tools and part of product managing is like your customer should be happy, right? Like, like if they don't actually like the product, then you haven't really done that great of a job doing it. Whereas, you know, there is, there is another way of, uh, especially back in, in, uh, in, in probably your open view and my BMC days, there was a way of providing AT, IT services and capabilities. There was a lot more about the delivery of that thing met some sort of like budgetary and performance needs, regardless of the happiness of people using it. And so like, if you, if you add in this, as you were saying, whether it's NPS or, or actually making sure that the day-to-day use of the users, like it's productive for them, then you're more motivated to obviously standardize stuff for the, um, the benefits that the organization, the corporation gets right for cost controls and being able to scale. But then you also have to make sure that standardize what you're giving, the tools you're giving developers, they like, like that's, that's part of what you're supposed to be delivering, which I think is, I don't know. I, I still feel like that, that role is a little novel sometimes when it comes to like really, really big organizations and, and thinking about me, of course, everyone has good intentions, but thinking about how you do that and how you introduce like that into, into the process is, is always the trick of making sure you pay attention to it.

Yeah, thanks Coté, I mean, I think, uh, once you focus on the pain points, uh, of developers and, uh, you have, you're completely, you're obsessed about providing them and making sure they're, um, you fix all the broken windows and, uh, take every feedback and act on them. And, uh, of course you need to prioritize. It's not like these teams have tons of things that they, they do, uh, but, uh, you know, thing on the top developer pain points, uh, once you do that and you use that as a guidance, as you come up with your plans for the, for the team, um, and it, it becomes a magical. And we had data to prove that as well. So year over year, you're, if you're measuring, uh, in a consistent way, the developer productivity with the NPS score, which is that the main question there is how would you recommend this developer platform to, uh, your fellow, uh, engineers or your, uh, friends. And that, that, that question, you get that answer, uh, and, and you can see the, the improvements that you make in, in developers, uh, lives. Uh, and then also the, you can also see a correlation between that and the overall productivity metrics that, that, that you measure and as well. So it's not just, okay, warm and fuzzy feelings. It's, uh, also, uh, very much data driven. One of the things that you said earlier, um, when you talked about, um, I mean, first, first of all, I just want to say like that, the classification of an internal developer platform in these four categories, performance, quality, efficiency, metrics. I think that's, uh, it's, it's, it's so clear and it's so clean.

I think that's a really good framework. Um, and then you mentioned in the, uh, amongst the examples that you mentioned of things that you did at Uber, you talked about sort of standardizing on, on spring. Um, and I guess, so then, you know, sort of like looking at your career transition from Uber over to now, Tanzu specifically has a, a very, very big focus on, on spring. And, and, and, and, uh, it has had this intention for a while and a continued intention to make Tanzu, you know, sort of the best platform to run spring on. Right. Um, so I guess, yeah. So what, I guess, was that part of your interest in, in coming over to Broadcom and how do you see that, um, I guess, how do you see making it, making that impact here? Yeah. Um, I mean, thanks, uh, thanks for bringing this up. So I, um, uh, so what we did, uh, uh, at Uber and, you know, running, learnings from, uh, running the product management for developer platform, um, it's very much applicable to all our customers, uh, because the, the challenges that, uh, uh, any large scale software business is facing. So, um, they're all, they're all same challenges. How do I keep my, uh, builds fast? How do I, uh, manage my dependencies? How do I make sure that, uh, I don't create new incidents as I, uh, try to move fast and deploy more frequently? Um, how do I run my platform in a more efficient way? These are all, uh, challenges that are applicable to any, any business and assuming that every business is a software business. Um, so, you know, I think, uh, we are, you know, with, with, with Spring, uh, our goal is to, uh, help out. Now, now we are in a, in a, in a, in a position to, uh, apply some of these, uh, best practices, help our customers, uh, run their, uh, platform engineering teams, uh, in a more efficient way.

And, and, and, and what we do with, uh, the Spring, we are really excited about the capabilities that, uh, we would like to bring for the Spring developers. So there, uh, you know, uh, you know, majority of the enterprise Java apps, uh, are, are Spring apps. And now, uh, we, we, we, we also have a lot of data about what, what are the biggest pain points of, of, of, of these, uh, uh, these, these developers. And one of the areas that I would like to highlight is, you know, upgrades and, uh, you know, the, uh, older versions of, uh, Spring libraries and the dependencies still existing in the code base and the security, potential security vulnerabilities that they might have. So, uh, uh, even though we are doing a great job, uh, upgrading, providing new updates with, with Spring, you know, we, but we are hearing from our customers are, they're, they're still running the older version, versions of these, these libraries. And one of the areas that we are excited about is to help them, uh, keep their applications, uh, up to date so that they can gain the performance benefits and they can run their applications more securely. in a compliant way. So, uh, you know, what, what makes me excited is, you know, we are, uh, working on some, uh, cool features to help our customers maintain their code base, basically keep them continuously upgrade, help them continuously upgrade their, their applications. And that's, that's an area that, uh, I think we hinted at, uh, uh, before that, that we are actively working on. And I'm really excited about, uh, uh, solving this, uh, this, this dependency upgrade challenge for, for our customers. Of course, this is just one of many, you know, performance is, is, is another area improving the performance of running, uh, uh, stateless services with Java Spring.

Um, and, uh, there, there, there are, there are several, several others that we can, we can chat more about in the, in the upcoming talks. Yeah. I mean, I'd love to hear, cause I, I was looking, um, at a slide deck that you presented at a conference, um, I don't know exactly how long ago it was, but I know you've also done work on generative AI in the software, uh, supply chain. So I guess does that, does that fit into your vision at VMware as well, at, uh, Broadcom as well? Yeah, absolutely. I mean, generative AI, because of the, uh, uh, the capabilities of large language models work really well for natural languages as well as programming languages. And, uh, you know, originally we all, we, we were all, uh, trying to understand what are the risks of, you know, using generative AI in, in, in our business. And then, you know, developer productivity, since it's internal, it's not really, uh, impacting, uh, customer facing, uh, functions. So it's a great area where, uh, you can apply generative AI because, uh, again, you know, you can still experiment and see the, uh, see the impact. And, uh, and, and, and there's a consensus in the industry that by, uh, start by, by leveraging the generative AI technologies, like whether it's co-pilot, like in, during your inner loop, uh, writing code, editing code, uh, or automatically generating test cases or doing large scale code refactorings. Like in, uh, in our example, this is one, one thing that we want to, we want to be able to do. We want to help our customers, uh, keep their spring applications up to date and generative AI becomes a critical, uh, tool to do that in a more efficient way, in a more productive way.

Uh, and it becomes the next step after these rule-based approaches, uh, uh, updating, updating, updating all that code and refactoring them. Amazing. So I'm really, very much excited, but I mean, I mean, we can talk a lot more about how, where, where else you can apply a generative AI in your software development lifecycle. That's, that's, that's a, that's a topic on in itself. Um, yeah, I saw, yeah, the, I, I mean, I guess I'm, I'm most interested in the ones that maybe you think that as Broadcom, we actually have a possibility of bringing to our customers. So, I mean, I hear you talking about dependency upgrades. I mean, the dependency upgrades definitely for our customers. You've mentioned using Gen AI, of course, encoding and generating test cases and refactoring. I don't know. Uh, maybe the dependency upgrades is the, is the one that we, that most fits in with our tool suite. But yeah, like, I, I guess that would be my cure. My biggest curiosity would be like, where, where can we as a company use this to help our own customers? Absolutely. Yeah. So Tanzu spring runtime is, uh, is our commercial product, uh, for our enterprise, uh, customers. And it gives you a, uh, long-term, uh, support for your spring, uh, uh, spring applications. So you can, you have a little bit, you have more time to upgrade. And it also has a lot of commercial differentiated features, uh, with, uh, spring data flow and, uh, spring cloud gateway, um, as well as it includes, uh, JDK and, and support for things like Tomcat. So the, uh, uh, uh, uh, uh, but our vision is, uh, uh, to add more capabilities into, uh, uh, Tanzu spring, uh, runtime to help our customers keep their, uh, spring applications updated.

All the time. All the time. And, you know, our first, uh, uh, uh, initial approach is to, uh, uh, it was, uh, a rule-based approach to help them upgrade. But then eventually generative AI, uh, would, uh, would be, uh, the way to compliment and even, uh, take it to the next level. Uh, if you, if you think about that. So that's exciting. Um, I mean, I'm really excited to hear this, uh, that Tanzu spring runtime has, uh, has a bright future with these really exciting, uh, features. And I know there was one other, I know that we, uh, that was just released this week that we've been trying to, uh, to, uh, highlight, which is the spring health assessment, uh, tool that produces a health assessment report for your application. So, and I know that's been under your purview as well. So I guess what's, uh, are you, how excited are you about that? How's that going for you? What do you see there? What should customers know? Thanks for bringing this up. We're really excited about, uh, uh, spring health assessment. This is a free service that we offer to our customers. Uh, I think you should all go try, uh, search for, uh, Tanzu spring health assessment. It really takes, uh, uh, less than a minute to, to run it. Basically what it does is, uh, you, uh, you run your Maven, uh, dependencies, you generate the dependency tree. And we are only interested in those spring libraries and, uh, you, uh, file with that, you upload that file. And you, uh, end up with a report that shows you your current support status with all your spring libraries. And also it highlights the security vulnerabilities in them. So kind of gives you a guide guidance, uh, on, uh, uh, on your next steps, basically help you bring awareness around the support status, the, uh, security vulnerabilities and, uh, my upgrade effort, uh, involved with, uh, to keep your, uh, application updated.

How do you, uh, upgrade effort when you, I've seen the reports coming out of, uh, spring cloud health assessment. And as you say, they mentioned support vulnerabilities and, and very interestingly, yeah, like they measure the effort it's going to take for you to improve the security posture, I guess, and the supportability of your app. How do you measure that? It's really, uh, uh, uh, at this point, it's really, uh, like a t-shirt size, uh, approach, low, medium, high, you know, we, uh, measuring it, uh, in a more accurate way. Uh, maybe misleading or, uh, could, uh, result in inaccuracies. Uh, our high level approach is to look at the difference from between where you are today and, uh, and, uh, what, what the latest version is. And of course, uh, major versions and how many, uh, uh, releases in between. So that's, that's a, that's really a high level estimate at this point. And if I sort of put together a few of the things that you've said, uh, it's, I, I would make the assumption and you can tell me if it's a good assumption or not, but that from a commercial point of view with Tanzu spring runtime, something like the output of this, uh, health assessment would be used with Gen AI to then help automate, uh, the incorporation of these, of what you find into your code, uh, in a more automated way. Gen AI. So our vision, uh, our vision for Tanzu spring runtime is to do this at scale, uh, for multiple projects. So for all, all your spring applications, you want to be able to, you want to be able to show you bring real time visibility into, uh, your support status and, uh, and security vulnerabilities associated in those apps. And then also take, take, take, take, take it to the next step and automatically upgrade those applications in an ongoing basis. Um, you know, that, that upgrade approach, uh, uh, our initial approach will be a rule-based approach, but that's where we are, uh, looking at leveraging, uh, large language models to help, uh, making those refactor, refactorings, uh, uh, more, more efficient and, uh, automatic.

Amazing. Amazing. Amazing. Okay. So, so spring health assessment report for a free tool that can help you understand the support status and the vulnerabilities in your application. And for larger organizations that want to do this at scale, uh, with support and, and kind of stay up to date and have access to additional features that, that Broadcom would be developing with large language models and things like that. Then definitely, uh, so spring runtime would be more appropriate for that. It's a summary, I guess. And, and, and just, I mean, just one last question. Uh, like, um, do you, in, in your experience, does like upgrading things fit into what the platform tools group is responsible for? Like, where does that like fall? Cause I don't know. It's, it's not immediately clear to me at least. Absolutely. Um, you know, I think, uh, within our developer, uh, in the developer platform team for each language, there would be a separate monorepo and framework team. Um, those teams maintain, uh, the, the, the monorepos and is, and I'm just talking about not everybody uses monorepo. I, I do understand that, uh, when you don't have a monorepo, the, the handling dependencies and all the, all those upgrades become even much, much harder. Uh, but even, uh, when you have an efficient structure like that, everywhere, everything is standardized. Uh, I would, I would suggest that, you know, it would take a team of two, three engineers, uh, a couple of months to upgrade from one version to another. And you think about all those, all the, you know, places where you, where you need to make your code change. I would say that it's one of the things that I think that I get the most when, uh, if I'm ever showing our Tanzu application product, uh, Tanzu application platform to people.

And they see the supply chain that takes your code, you know, builds it, tests it, scans it, whatever. Uh, one of the, one of the most common questions is like, if the scan produces vulnerabilities, obviously the supply chain will stop. But then like, then what, you know, like who, who takes action and how, and you know, all I can say is, well, if it's, if it, if it's because if the vulnerability comes from the OS or the runtime, then the platform team who's supplying those components would take care of it. And if it's coming from your palm file or a gradle file or, or whatever your NPA, what your, you know, your application dependencies. And that has to go back to the developer because they're the one who has to update the dependencies. But this is really taking that and saying like the platform itself can simply, uh, automate that and just make, you know, maybe make a pull request and that gets tested and confirmed. And it's completely just a seamless part of the, in the same way we do that actually with, um, with container builds, right? Like if, if, um, the OS is upgraded, then the container is regenerated by the platform. And so we're basically saying we can take that to the code level, um, and automate that whole process. Yeah. I mean, that's our goal. Yeah. I mean, that's our goal. Basically, um, when you think about, uh, upgrading. So our vision is we would like to not just create tickets, uh, you know, in, in the old days, or, you know, it may still be, uh, the norm for many organizations. When you have a central, uh, form engineering team, a lot of times we generate tickets in, uh, automatically generate tickets by running some program, let's say a, at large scale. And that's how we would deal with security vulnerabilities. And at the end of the day, you expect those individual product teams, owners of those microservices to go and fix those, uh, uh, issues. And then, but of course, and then you also have these teams of, uh, technical program managers chasing down these, these teams. Teams have their own priorities, product pressures, right?

They, they, they're at the end of the day, there's multiple priorities that they're chasing down. So the, the goal here is, you know, let's take it to the next level. Let's create a, a PR or a merge request where everything is validated and, uh, and, and, and verified. So, and just the, then it, it's just a matter of reviewing those changes and, and, and approving them. So we're trying to minimize the work that, uh, uh, the, these product teams would, would need to do. And that's our, uh, approach, uh, that, that we are taking with Tanzu spring runtime in, in the upcoming versions. Uh, when we introduce this feature. I just like, I have, like, I mean, you know, probably smarter minds than me have already thought of this, but you just made me think of a future where, you know, you also mentioned code, uh, like code, code refactoring or code reviews, uh, that are now manual and require, you know, eyes on code. If a code review could be automated via LLM and recommendations about code quality could be automated. And then those could be sort of, you know, a person could review them to see if they agree or not, but at least we could use even LLM for, for code quality improvements. Oh, absolutely. I mean, these are the areas where, um, people are experimenting, applying, uh, uh, generative AI. Uh, you know, we, uh, I worked on a project where, uh, we took the, uh, comments from, uh, code reviewers. And based on that, we automatically created the next revision, uh, that basically it's really not, not fully automating things. Uh, uh, not, uh, but it's, it's an incremental, uh, step towards there as we gain more confidence with generative AI. Generative AI. And, and, and, and, and such tools. So basically, okay. It's made a comment, but then rather than the author making that change, you know, the, the bot automatically takes that comment and, uh, creates a new revision, understanding, understanding the code.

And, and, and the changes as well as the, the, the comment, and then creating that next, next revision based on that understanding. And these are, uh, these are things that, uh, others are, are also playing with or, or, or doing. So I'm really excited about the future, uh, of future of, uh, software development. You know, it's really exciting times, uh, where, you know, developers will be more focused on, uh, more business critical application logic and have these, some of these simpler tedious tasks by, uh, by automated tools powered by generative AI. Yeah. Yeah. Amazing. I think, I, I think you've said this, uh, really, uh, optimistic and, and, um, exciting view of all of the opportunities to, um, really leverage, like make the most of, of a platform like, like spring. And really like really milk it and advance it. And, and, and because generally I feel like we wait for spring to give to us, right? The spring team produces great things and then we use them. But here are all these ways that we can contribute to make spring better, um, from a, from a different angle. I think that's a really, it's a wonderful thing to see that ecosystem growing in this direction. Thank you. Yeah. Uh, and Coté, I, I just want to say one thing that, um, you know, since we talked a lot about generative AI and building generative AI applications, if you haven't given a shot, uh, to, uh, spring AI, uh, you should, uh, play with it. You should try, uh, this, this project. Our goal there is to help enterprise Java developers, uh, add generative AI capabilities to their, their applications. And it's great. And we are getting a lot of feedback from users and, uh, iterating quickly on those. So please, uh, give it a try.

Uh, take a look at spring AI. Uh, it makes it easier for you to interact with LLMs. And, uh, spring data is already great and getting all the data sources. So, and we also have embedding models and, uh, you know, whatever RectorDB that you, you, you may want to use. So it's a great solution, a glue, so to speak, uh, that would, uh, accelerate your adoption of generative AI in the enterprise Java application space. So please give it a shot. Amazing. I feel like I'm going to, I'm going to do that right after we hang up. Well, thanks for being on. It was really fun talking with you. Uh, that, that was enjoyable. Do you, do you have, uh, you know, if people are interested in, uh, well, you know, Cora mentioned a presentation you gave and other things like that, but do you have some little home on the worldwide web that you would send people to, to check things out? Um, I personally do not. Um, I personally do not, but I would prefer, um, if, uh, you know, uh, if you're, you, I'm sure you're all familiar with, uh, Spring IO website, uh, as well as our, uh, Tanzu, uh, Spring page that we, we are keeping, uh, up to date all the time. So, uh, follow us there. And we also have your team is a great team, which, uh, provide a lot of, uh, uh, help and, uh, guidance to Spring developers. Uh, the Sean and Josh and, and, and, and you guys are awesome. And thanks for, uh, doing this and keeping, uh, the community alive. Well, that's good. That's always good to have a, uh, recommendation for our own team as well. So I appreciate it. Well, good. Well, as, as, uh, as, uh, as always, my daughter would like to remind you that this has been Tanzu talk. Uh, if you want to get the show notes for this, you can go to Tanzu talk.com. And, uh, you know, I got to wrap it up cause I need to blow up the surgical glove for my daughter's entertainment and we'll see everyone next time. Bye bye. Thank you.

Tanzu Talk · 🍕 Get more pizza.