What Is - How To

What is Spring Application Advisor? How to Achieve a Continuous Upgrade Culture with Tanzu Spring

RedMonk Video

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

Get more video from Redmonk, Subscribe!

Building Java applications is one thing, but how do you keep them up to date and compliant (especially with Java’s 6-month release cadence)? RedMonk’s Kelly Fitzpatrick joins VMware by Broadcom’s Cora Iberkleid (Developer Advocate) and Michelle Sebek (Product Marketing Engineer) for a quick look at the Spring ecosystem and a deep dive into Spring Application Advisor, which is designed to keep your Spring applications up to date (and to do so at scale). Also discussed: what is a continuous upgrade culture, and how can Spring Application Advisor help your organization achieve it.

This was a RedMonk video, sponsored by VMware by Broadcom.

Resources:

Transcript

Kelly Fitzpatrick: Hello and welcome. This is Kelly Fitzpatrick with RedMonk here with another What Is How To video. Today we’ll be talking about Spring Application Advisor. And with me I have some fine folks from VMware. Cora and Michelle, can you each introduce yourself please? Cora, we’ll start with you.

Cora Iberkleid: I’m Cora Iberkleid. I am a Developer Advocate working with Spring and Kubernetes technologies and it’s a pleasure to be here.

Kelly: Excellent.

Michelle Sebek: And I am Michelle Sebek, I am a Product Marketer and I envelop everything Spring. So from Tanzu Spring to incorporating in the Tanzu platform to K8s and Cloud Foundry.

Kelly: Well thank you both for joining me today. Today we’ll be talking about Spring Application Advisor, which has to do with of course Java apps and the larger kind of Spring ecosystem. For those of you who’ve ever worked in the software industry, you understand that building an application is one thing, keeping it updated and/or modernizing an application, or even migrating an application is a totally, totally different kind of world. We’ll be talking a little bit about that today and to get us started, Cora, over to you, I know you have some thoughts on the Java ecosystem in general.

Cora: Absolutely. Thank you Kelly. Yeah, I wanted to start by setting a little bit of a context. The Java ecosystem has gained a lot of speed in the last few years. We’ve seen a real boom in innovation. Java 8 was a standard for a very long time, and then starting in 2018 with Java 11 and then 17 and 21, those are the long term releases of Java. They’ve really brought in some incredible innovations, things like virtual threads, native images, class data sharing, different API improvements that improve developer experience. And all of these have really enabled us to unleash faster startup times, better runtime performance, and all this with smaller footprints, which leads to greener applications with savings and infrastructure, and just better coding experience for developers. So it’s been an incredible few years from a pure Java perspective, the whole ecosystem has really advanced as well. And these Java innovations in particular really propelled Spring to evolve in certain ways. Since Spring Boot 3, Java has baselined on Java 17. Previous versions of Spring Boot were baselined on Java 8. Java 8, as I said, was a standard for a very long time. So that’s been a jump.

And this has enabled, made it easier for people using Spring to adopt these different Java innovations. There’s also been innovations in accordance with the growth of cloud and containerized workloads. There’s new developments, really exciting things like Spring AI. And again, to make this easier for companies to embrace, Spring has streamlined its release cadence and support timelines. So the question is, how are you managing with this? Right. This can either provide solutions for you and exciting opportunities, or it can lead to an accumulation of technical debt. And it’s a great challenge. And what we’ve seen, there’s a state of Spring survey that we do every year. And this year one of the questions had to do with how many, which versions of Spring Boot you were using. And while there are a large number of respondents who said that they were using versions newer than Spring Boot 3, therefore leveraging all these new capabilities, the same respondents also said there’s still a lot of applications that they have to manage that are the stuck in Spring Boot 2.7, Spring Boot 1 — really old code. And so this really represents a challenge, and it shows that people are having trouble moving forward with these applications.

So from a Tanzu Spring perspective, we want to, as we provide new software and better software for people, we also want to make it easier for people to keep up with these changes. So one of the things that the Spring team has done is published a calendar where you can look up exactly what releases are coming for every different project, and you can see details about what kind of changes are included in every release. And also, besides establishing these predictable and regular cadences of release, Spring Boot, for example, gets released twice a year, Spring Framework once a year. You could also easily find information about which versions are supported to what level. So, for example, if you have a version that’s in the green here, then you would be under OSS support. That’s a good position to be in. But once you fall into the yellow, you’re in a position where you need commercial support, which we do provide. And you have to make sure not to slip into something older than that, where there really is no support available. So these are good things to keep in mind, and this information is really easily accessible.

It doesn’t mean that it’s easy to apply these changes and move from gray to yellow to green. Right. It’s still a challenge. So from that perspective, the whole industry is moving forward. There’s a technology, an open source technology called OpenRewrite, which is essentially an engine to automate the refactoring of code into newer and newer library versions. This is general technology that applies to different languages, but of course it includes Java and Spring. And the way it works is that it takes recipes that determine how code has to be upgraded and applies the recipes on your code. There are open source recipes available, but they only cover about 19% of the different Spring project versions that exist. And so again, from a Tanzu Spring perspective, we’ve committed to creating additional supplementary recipes that cover the remaining versions and building a product on top of this to make it easy to apply these changes in a way that is sustainable and it can be incorporated into your CI/CD processes to really establish what we refer to as a continuous upgrade culture. This technology, so these recipes are delivered as libraries. So again, if you, you can access these open source libraries or obtain access to our supplementary set of libraries and they’re really easy to apply. They integrate, for example here with Maven or Gradle. And at this point with that intro, I want to hand it over to Michelle to give you a little bit more insight into specifically the Spring Application Advisor product.

Michelle: Yeah, we’re really excited about this because as Cora had mentioned, we’re talking about the trend across the industry. And then when we talked to our Spring community members and users in that State of Spring survey, over almost 1500 people completed that survey. So you see that it trends along with the industry. What’s nice about Spring Application Advisor is we allow you to effortlessly upgrade your Spring applications at scale. So this is primarily a developer tool for seamless, incremental and complete Spring repository upgrades. Yay. And the reason this came about is because this is something that we’ve heard many customers and many users say this would be nice if we had. No one wants to do manual. You want to have where it’s automated, where you just do it once and forget about it. This is also efficient and you have that automatic, manageable pull request, you have step by step migration and you have short lived branches which isolates these branches for clear changes. And you’ll see that image to the right. Cora’s going to go deeper with that, with our demonstration in just a minute. So if we flip the page to that, because that’s, what is it?

Okay, we know what it is, but why, why do you want this? And really, you know, we talked about driving tech debt down, increasing productivity, we’re increasing security with those automatic updates. You’re going to be in compliance with the regulations that are needed, those continuous pull requests that upgrade your Spring dependencies and fix Spring API breaking changes. We also have regular small updates. And that’s where you remain current without disruption. Right? Because we know sometimes if you have those major releases once a year, then you have to spend a lot of time to upgrade. We also see that visibility. You want to see what is your full stack and where am I in jeopardy? Where’s my vulnerabilities? What we do is we minimize the CVE investigation. You have faster time to resolution, which means you always have an updated build ready to release, which reduces time spent on CVE investigations and you enhance your operational efficiency. So keeping your operation team focused on the innovation rather than the fire drills, and you know how that goes.Once we do something as a developer, we just wait to see is it going to work, is it okay? Do we need any fixes? This is going to give us more time to focus on that innovation.

Now, Spring Application Advisor empowers your team to not only stay ahead of the security vulnerabilities and enhance productivity, but it should become seamless and it’s a proactive, and it really reinforces that modernization and that continuous upgrade. With Spring Application Advisor, that is part of our Tanzu Spring. And what that enhancement is, is that includes support as well as all the other things that were included recently. Name changed, it was Tanzu Spring Runtime. Now it’s Tanzu Spring. And that’s the commercialization of that. And that’s where you get your Spring Application Advisor. If we flip to the next slide, this just gives you a visual. I’m a very visual person here. How do you streamline it? How do you go from a pool to a portfolio analysis? It seems overwhelming. It’s not. We’re simplifying your path to innovation. We automate it. Cora’s going to show you how, and you can develop your innovative software solutions without spending a lot of time doing this. And Cora, you want to show them how?

Cora: Absolutely. All right, so let’s go to a demo. All right, so Spring Application Advisor is composed of three main components. We have a CLI, we have a server, and we have a UI. From a CLI perspective, the CLI is called advisor and has two main commands. We have build, config and upgrade plan. The server, we have it — I have the address stored in this environment variable so that all of the CLI commands pick it up automatically. But we can just verify that it’s running by hitting the actuator endpoint. So that’s running. The UI, I’m going to show that to you in the course of the demo. So the very first step is to evaluate your application’s dependencies and the tools that it uses. So I’m sitting here in a directory with a Spring Boot application, and just so you can see here, looking at the pom file, we are using Spring Boot version 2.7, and this happens to be using Java version 17. So the first command we would run is this advisor build-config get. And so this is going to evaluate the dependencies that are used by the application and it’s going to produce a SBOM file, a software bill of materials file.

This file happens to be in a CycloneDX format, and we can see that it contains three different sections. The git metadata section has things like the git commit, of course, and the repo. The tools I can show you shows which version of the Maven wrapper we’re using, Java version as well. And then the SBOM section has a whole bunch of information about all of the different dependencies used in your application. So we’ve extracted good information. Now we can optionally upload this information so that we can visualize it through a UI. So let’s go ahead and do that. And then let’s open this UI. So here’s our application repository. We can see that this application has six critical vulnerabilities. It has 25 libraries that need to be upgraded, and that represents a high effort because they’re quite old. And it has 15 libraries that are out of OSS support, in commercial support. So this is pointing to the exact git commit in the repo that we’ve analyzed. And we can get a visual of this with pie charts that are easy to read, can be shared with security teams or management teams. And for every library that’s evaluated, there’s further detail.

So for example, we can look at this one which has 14 vulnerabilities, and we can see that not only does it include Spring libraries, micrometer libraries, but it’ll also include any transitive libraries. So that’s how we get information about logback or snakeYAML for example, and each one of these links to the NIST vulnerability database. So you can really get deep information about every vulnerability that’s been identified. So going back to the demo here, once we have that evaluation, we can now generate a plan for upgrading this application. So now we use the advisor upgrade-plan get command, and this tells us that we need to upgrade this. It recommends that we upgrade this in four steps. So this is one differentiation from just using the open source recipes. The open source will upgrade all of your code in one go. And so being able to break this up into different steps and manage these as separate git commits, separate pull requests, test them separately, do code review separately is really going to make a difference in your success. So the next thing we want to do is apply these steps and what the tool actually does is it only ever applies the very first step.

After you apply the first step and make those changes, then you have to regenerate the plan based on the new state of the code, which would give you these three assuming no other changes have been made to the code. And so then you would apply the changes and get the second one done and so forth until you finish the plan and you’re at the end and you have upgraded code. So in this first instance I’m going to apply those changes and I’m going to do it just here on my local machine and I’m going to manually commit and push those changes to the repo. So I’m just saying advisor, upgrade, plan, apply. So again it takes that first step and it’s upgrading the source code. So we’ll just give it a minute to finish that and we should quickly see, okay, we can evaluate the differences. So if we go into git diff we can see it upgraded our Spring Boot version. It took out versions where they’re not necessary because Spring is managing those versions. It upgraded other versions where that’s not happening. It also went into the code. It changes some of our imports. It changes any kind of APIs that have changed in these updates, et cetera.

It takes advantage, this is taking advantage of a Java 17 multi line string option, et cetera. So it’s made some code changes. I’m going to go ahead and commit that and push it to my repository and then of course I can have any kind of testing applied to this before I decide to build and put this in production. So now you just rinse and repeat. So we’re going to regenerate the build configuration information based on the new state of the code and also generate the build plan. And so our expectation now is that the new upgrade plan that is generated is going to have just three steps. So we’ll give that a second to complete. And there we go. So now it’s just got the three steps. And so this time when we apply changes, what I’m going to do differently here is I’m going to say dash, dash, push. And I’m also supplying a token. In reality, because my token is in this environment variable, git token for PRS, I really actually don’t need to — it’ll pick it up by default. So I just put it in there so you could see it. So we’ll let that work.

And so what this is going to do is apply again the step one that’s shown in the previous, in the latest upgrade plan and then push those to the repository as a pull request.

Michelle: So really you upgraded that in 13 seconds. That portion of it.

Cora: Yeah.

Michelle: That’s pretty fast.

Cora: I didn’t even have time for a coffee break. So you can see that this created a new branch right here. And it also created a pull request. So let’s go take a look at that pull request. Here it is. So we can see that three files were changed. And you can see again we upgraded to another version of Spring Boot. And again some library version management changes and some API changes, some property name changes. So all of that was done for us automatically. Presumably this would go through a testing process, et cetera. And so then we would be ready to accept those. So I can just kind of merge that, confirm that merge, and I can go ahead and delete that branch. We don’t need that anymore. So now when I go back to my code… Okay, so we’ve merged that PR, we’ve done that. Now I’m just going to reset my local copy to match what I’ve just done remotely. And now again, we repeat that again, we’re on our third cycle out of four. So now I’m just going to go ahead and regenerate the configuration information that represents now the current state of the code.

And I’m not going to print the upgrade plan out. I’m simply going to go ahead and apply it. And we should have that result pretty quickly. This again, I’m also doing this locally. But yeah, you’re right to point out, Michelle, that it just takes, you know–

Michelle: I’m looking at the resolutions, Cora, the resolutions, you resolve dependencies in 3 seconds. 1, 2 and 3 seconds. That’s remarkable.

Kelly: It’s so fast that there’s like there’s not enough time for us to chit chat.

Michelle: Right. Exactly.

Cora: Yeah, exactly. And it really does, it flips the script. So I’m going to do this, I’ll do this one more time. I’m not going to go through all four times, but I’m going to do one more. I’m going to generate the information for the fourth time. But I just won’t do the upgrade. I’m just going to so that you can see it in the UI. But you’re right, it’s really flipping the script. This is so fast. This is something that normally developers are clamoring for time to be allowed to work on this manually. And now we’re completely flipping the script. We’re doing it automatically. We’re allowing this to be automatically tested. So then we can give it to a developer and say, just do a code review, see if you approve, because I think it still demands companies to ensure that they have enough test coverage to trust that their own testing, you know, is enough. Right. That’s another struggle for companies. Right. Having enough automated testing. So as long as you have enough automated testing, you can trust the process and move forward.

Michelle: And doing this at scale. I mean you can do a small, big, medium large, but at scale that’s very impressive.

Cora: Exactly. So this is the next report. So we can see that we’re already at no vulnerabilities, any upgrades are going to be moderate at that point, which just means that the libraries that are upgraded are like a dot change and everything is under OSS support. We can actually visualize this. So we’re in a very good state. And even now there’s one more step to upgrade, which will just bring you up to the absolutely latest libraries. But now from a security perspective, from a tech debt perspective, you’re in much better standing and it literally took a few minutes. So then the question is, as you’re saying, Michelle, how do you do this at scale? You can build this into your CI/CD process very easily. And I’m going to show you one example where it’s built into an application using GitHub Actions. Here’s the definition of the GitHub Actions, but you can see it really just runs these commands that we’ve just been talking about. It does the get of the configuration, this one does publish to the UI, and then it does the apply with the push so that it generates a pull request.

So we can see that in action. Here’s one run of it. We look at the output, we can see it’s resolving all the dependencies, getting the information about the JDK, the build tools, and then it does the actual upgrade. Again just takes some seconds. And then finally it creates this pull request which we can look at and that would then go through testing and then, you know, someone could review it and accept it and merge it into the code. Once that’s merged into the code, this would simply trigger the second cycle and then the third cycle and then the fourth cycle. And so really this is completely automatic and you can bring your code up to compliance very easily. So this is with GitHub Actions, this is highlighting the support for GitHub Actions. The one thing about GitHub Actions, of course, is that you need a GitHub action defined in every repository. You can also go ahead and just integrate this into your CI/CD pipeline, whether you’re using GitLab or Jenkins or any other tool and then it would be completely automated and you wouldn’t have to add anything to any individual repository.

So that’s what I have for the demo. I’ll just wrap this up with a few more slides here, which is just a visual on what we just saw. This is similar to the last slide Michelle was showing. To do this at scale and integrate it into your CI/CD process, you would want to include App Advisor, most likely on your main branch. That’s what would make most sense. So any event like a pull request on any other code that’s been through testing, et cetera, is ready to merge into main would trigger this process. So you’d have a git commit event. App Advisor would first evaluate that code. In evaluating that code, it would determine if there’s any changes to make and it can pull from recipes from the open source, it would pull from the supplementary recipes that we provide through Tanzu Spring. And it can also apply custom recipes that you want to add. Based on that, it would create a pull request. Your CI/CD process would run tests, do any scans you need to do, and then it would be a candidate for a merge through a pull request.

And from a UI perspective, so the UI that I showed you is a temporary UI. The roadmap is to include this in Tanzu platform. And what the UI is going to have is a historical and aggregated view of the state of your applications at large across the organization. And just a couple of references if you want to learn more. We’ve got lots of documentation on this.

Kelly: So to clarify, is this something that folks can go try out right now?

Michelle: Well, I think that’s an excellent question. And the good news is it is available now. Right now we’re in beta. We’re doing a lot of testing. This is an entitlement as part of Tanzu platform and part of Tanzu Spring. So the commercial aspect of it, we’re going through some designs. We’re working with an advisory committee to make sure that when we go general availability, it’ll be available. So I would just use these references or go on tanzu.vmware.com/spring and you’ll be able to find more information there.

Kelly: Thank you. And we’ll make sure to point folks to these resources in the show notes. Cora, Michelle, thank you so much for spending some time with me today.

Michelle: Thanks for having us.

Cora: Thank you, Kelly.

 

More in this series

What Is - How To (32)