hi, welcome to dop 229 automating app upgrades and maintenance using uh a new release feature using our newly released feature, amazon q code transformation feature.

um i am vas over there. i am the principal product manager working on this feature.

hello everyone. i'm j shara. i'm the senior sdm running the q transform team engineering side. i'm very excited to talk to you about the new feature released.

uh there's a lot to come ahead. so let's get started.

yeah. so let's go over what we be covering today.

um we talk a bit briefly about why application upgrades uh is a challenge. um you kind of try to balance updating and maintaining and modernizing your applications with actually doing productive business work. um and those things get in conflict and those leads to issues which is where uh some sort of automation, some sort of improvement can help you guys a lot in achieving maintaining your applications as well as achieving your business productivity goals.

so how does amazon q code transformation help you there? we will provide an overview of what this does, what is today available uh and what is coming next and as well as go a little bit under the covers of how we achieve this, how working with amazon scale of 17 years of experience building and upgrading applications, how that helps build this kind of capability that goes that that brings in the gen capabilities as well as some of our knowledge bases, et cetera and provides a better end to end experience.

um we'll also go over some specific examples of the java upgrades capability that we have today and how it makes changes, what kind of different things it can do as well as go over an actual demo of an live app upgrade.

and then finally, we'll cover some of the future enhancements that are coming down the road.

ok. so what is the challenge with application upgrades?

you have uh for enterprises that have been building applications for a while as well as new companies building new applications. uh you start off with a set of state of the art versions or languages that you need to support. and eventually what happens is you have a well working application but then new versions come out of the language, new features of that. uh new features are available. uh you start losing support for the actual versions that are available and this whole process becomes tedious and time consuming to kind of do application upgrades for two reasons.

one is uh a lot of these new features you need to, first of all understand what what's new, what's what's relevant, what needs to be updated, what could be updated? how can it get uh how can your applications benefit from it as well as many of these applications are, have been developed by other teams, other developers, we don't have that expertise anymore. so you need to first understand code base itself.

so you have those two different conflicting things, which kind of delays, a lot of these application upgrades. however, these are things that can't be skipped many times. you have uh versions coming and of support. for example, in java, you have a two year train of long term support versions. so every time you have to go to the new version, even if you don't, the previous versions lose support after after a bit. so you, you don't even get security updates after a bit. so you have to kind of keep doing that.

however, developers as i know a few of them and i have been before and these are not the most productive tasks we want to work towards. these are essential tasks. these are important tasks. these are hard tasks actually, but they also compete with delivering your business objectives um in your sprint cycle. do you prioritize getting that version, dependency, version updated or do you want to ship the new api feature? it's always going to be a conflict, it's always going to be hard.

and what happens is these uh upgrades keep stacking up so that becomes universe. because now more and more of your applications when go out of cycle, your technical debt keeps increasing, you are prioritizing newer features, but you keep having this whole stack that needs to be updated.

well, you end up with security campaigns, you end up with a great campaigns and then you have these top down requirements which just forces you to work on these features, not a great state to be in, right?

so therefore, what can we do this uh uh uh to help with this situation?

um what is interesting is that uh what we learned from working with our own developers, talking to customers, et cetera is that the application upgrades are challenging, as i said, for two reasons, one is that you have to work on an existing code base which uh you might not be an expert in if somebody else might have developed it. first of all, before you even start updating different capabilities, features of this, you need to have an understanding of what the code base does.

so a lot of time is spent in researching that uh researching your own code base as well as researching. what does this new java version uh provide, what is absolutely required um in terms of features that are needed to be changed, deprecated features, then you have a bunch of dependencies that you use uh test frameworks. um other kinds of uh frameworks that you need to upgrade to, they have their own cycle of updating and they have many times introducing breaking changes, which means you need to make updates in your um configuration files. but as well as go deeper into your code base and figure out where do you use that dependency or where do you have to have this new feature replace an old feature, use the new feature.

how is, how do you do that typical developer cycle is you do some research on one thing you try and write, you try and get it, get it building, figure out what's breaking uh go to the next feature, go fix that issue, go through this whole cycle again and again, every time you spend a lot of time on researching, which is where like the knowledge base of l ms and other kinds of technologies can help a lot.

it can not only understand your code base as well as have a better understanding of the language versions itself. so you can kind of use those technologies to kind of speed up that portion. but we go beyond that because we can do a better job of iterating through this whole cycle with our automation.

so we can have iteratively go and fix build issues and fix one by one the next issue. so within a certain period of time in minutes to hours, you can have your entire application upgraded without within a single click, we'll go a lot more detail into how that happens.

with our java upgrades in our demo as well as some of the descriptions later on.

so how does q code transformation work?

um essentially, as i said, like we have this application, we have a knowledge base. um we have understanding of what uh features are there. how do we kind of make this work?

well, we try to design as simple an experience for developers as as we expect making it as easy as possible where you work and where you can use it.

so right within our amazon q plus code whisper toolkit plug in, you can use this transformation feature either directly clicking on transform or through the chat interface um uh through the q chat interface.

um you click on transform for an eligible application today. it is java eight and java 11. we will have more versions and more languages coming soon.

um what happens is we upload the code into a secure environment in the cloud that helps us analyze the code.

um we start off with a deeper analysis, not just of the what the code does as well as what are the requirements from the specific versions? you can select java 17 today, we'll have more versions coming soon. but we look at for example, what is the, what is the delta between java eight and java 17 that is relevant here. if you have java 11 and java 17, what is the delta that, that we need to mandatorily update we do those updates automatically through your entire code base.

we then securely build that uh uh code, we see what the errors are and then we iterate through those errors. so exactly the process that a developer follows, except it's all automated end to end.

um the advantages of this are obviously that um and uh a knowledge base and llm et cetera can help us analyze the code faster.

um we can provide the context of an application that might not be there for a developer. so all that time of research is now offloaded to um a automation system as well as this entire knowledge base that is available uh to stack overflow through other types of resources that the developer would have to do when they try to fix those build errors.

well, this is part of the llm already. so we can kind of leverage that and do the entire automation and provide you with a fully built um secure and uh tested code.

we actually take the existing tests that are there in your application code base and validate that those tests also work actually, that helps us improve our code as we fix more errors, make sure that unit tests are passing again.

um what you will receive back is actually just a patch file or ad that you can apply through your ida interface.

so um so the developers remain in full control of what kind of features they want to add um nothing changes on, on their machine and they can choose what to change, whether they want to accept all the changes or whether they want to make modifications to the changes, whatever is is suitable and be able to do the remaining integration testing and push it to production. after the fact, knowing that this is already a validated code, it already works with ja 17 automatically, it already has the new features in integrated it has the dependencies, updated, everything is working as expected.

um as i said, this process in our experience takes from days to weeks depending on how complicated an application is for a developer, a lot of time spending on research, a lot of time mir on those loops of going through that end to end process.

in our experience, we have been able to do it within minutes for most applications uh at less than an hour, usually for even larger applications.

um depending on how uh how big your application is, it would take different amounts of time. but the fact is that once you submit the code, it is not, it is just um uh you can do your other work while waiting for this to finish without any needing for a lot of interactivity and a lot of back and forth um on how to fix issues, et cetera.

um so what does that help us achieve? basically uh you can now obviously enhance your productivity because your java upgrades are now one click, not only does this help with achieving parity, et cetera with, with um the security requirements, but also you get a lot of performance features enhancement automatically because of new versions. and obviously you can further fine tune depending on your application needs uh and, and achieve further enhancements that obviously leads to a better security posture in terms of making sure you are compliant with new versions.

um you have um well, basically you can now tell your security uh campaigns that this your work is done, your critical work is done and don't have to kind of go back to working on more productive things and building new features.

ok. so that's a high level overview of what um code transformation does and how we believe it can help you uh accelerate your productivity, taking away a lot of the undifferentiated work um that is essential but uh but could be automated and we hope and we believe that we can achieve a lot more product gains for you by using this feature.

so that's a high level overview. how does it work actually in practice?

uh i'll hand off to my colleague just who can go a little bit more detail about what's under the covers.

thanks vws.

so as you heard from vs amazon qq code transformation is being has been built to solve a lot of challenges that we ourselves also saw in uh with java grades with other kind of frameworks, etcetera. and i'm gonna talk a little bit about behind the scene, how it works.

then we were building the q code transformation product. we tried multiple techniques. we tried a some program analysis techniques, we tried rule based upgrades, we tried lm techniques, we tried some other air techniques. and what we found is what worked best is a combination of these techniques depending on what aspect of the, of our workflow stage of our upgrade stage we are talking about or what aspect of our system we are talking about.

so i'm going to give you a little bit of a view of that. so this picture kind of shows a 50,000 ft view of our system as you can see the way that our workflow works is we take your source code. and the very first thing we do is we build and test the the application as it is. so we want to make sure that we can build it with the java version that you have

So today we support Java 8 and 11 upgrades to 17. So we might build it with eight or 11 depending on uh which Java version your application is using.

Once we are able to make sure that the building test is done, then we go on to the next part of the workflow.

One thing I do want to point out here is that we, when we take your source code and are running it through this workflow, we don't store your code, we just take it, run it through the workflow. And at the end of it, the code is gone. That's one aspect.

Second is we do support CMK which is customer managed keys. So even in temporary storage as we are building and testing the code, we have to kind of keep it in temporary storage for a little while while we are working on the code. Even there, you have full control over what key we use to encrypt while it's in temporary storage. And at the end of it, of course, we delete it. So you have complete control or access to the code while we are working on the code.

So once we build and test, then our workflow jumps in. Our workflow is composed of like two or three different steps which I'm going to walk through. But first, I want to talk about a knowledge base.

The reason I want to talk about the knowledge base is it's the core piece on which all the other steps of the workflow are dependent on. And this knowledge base to develop it again, we had to use a combination of techniques, no single technique work for us. So we used a simple rule based engines to go and mine various open source repositories, various open source applications where which may have already been upgraded from 8 to 17, 11 to 17. And our internal applications which are which we have a huge number of course, because we in Amazon, we use Java a lot and we were able to mine our own applications also which had been upgraded from 8 to 17 or 11 to 17.

So combination of that allows us to allowed us to build up knowledge based the knowledge base itself. Ended up, we ended up using like I was mentioning rule based techniques, but we also ended up binding and parsing some of the data using LMs to be able to extract the knowledge in a format that our rest of the system could use.

Ok. So let me go through example of what a knowledge base can do. Now, I'm not going to show you the internals of how we store the knowledge base and how it looks like. But I'm going to walk you through how we use the knowledge base or what kind of aspects the knowledge base helps with.

So this is one example where we need to upgrade our dependency, Jackson core. So our knowledge base might say something like uh Jackson core range of library version 2.x to 2.y needs to be upgraded to 2.12.5 or some other version. And depend and based on that knowledge base, then we can apply this upgrade automatically using our engine. So that's one aspect of one example of knowledge base.

Another type of knowledge base example where we use the knowledge base is to fix errors. So many times, even after you have done the upgrade, you might run into errors that have to be fixed. And there again, knowledge base is helpful where the knowledge base can tell us, hey, if you run into this error, these are the examples of how somebody else had fixed them in the past. And these examples can direct our LMs or other models in the right direction to fix these errors.

So this picture kind of shows our overall workflow. So now I'm going to walk through the workflow itself, the details of the workflow.

Now I talked about the knowledge base and how critical is it to our workflow. And this knowledge base itself took a lot of mining. We probably, I would guess mine about 200,000 plus applications to build this knowledge base, which itself is in a big task in itself. And we keep on extending the knowledge base with more and more mining more applications as many applications as we can get our hands on. And it's not just applications, there are other sources also we use for mining this database anyway.

So the first step after we take the source code, we build and test with the Java version that uh your application was originally built in. Once that's done, then we start applying the knowledge base. And again, knowledge based application itself takes a combination of techniques. We of course have rule based systems where or programming less based system where we, those could do simple things like change one version to another. And we have other techniques to do code changes including LM based techniques where we apply the knowledge base.

One other unique aspect of our system is it's not easy to figure out what parts of knowledge base to apply on your application. So just figuring that out just because we have this vast amount of knowledge in our data and our knowledge base doesn't mean that we, we can just randomly start applying everything, right.

So just figuring out what to apply itself takes a takes a set of techniques where we may have to decide, hey, for this application, given these combination of dependencies, the way the code is written, we need to go down this path. When I mean when I say path, what I mean is we may need to upgrade these dependencies. And based on that we may need to change these code paths, et cetera.

But once we apply that knowledge base and after that, we go to the next step of the workflow. But let me first give you an example of what is an application of knowledge base. This is very similar to what I talked about before where one of the big parts of our knowledge base is just understanding the library versions which are which I recommended which library version to upgrade from what? And there again, we use static tools for simple scenarios. Such as the one shown here.

But in many cases, we do have complex things where we have to change annotation in the code because of the library changes or even upgrade some other libraries depending on the library changes we already did or change the code because the API signature itself in library. So that requires more complex techniques than applying the simple rule based system, simple rule based things like using study tools like this example.

So now that we have gone through applying the knowledge base, lot of time, just applying the knowledge base may be sufficient and we may already have upgraded the application. And the way we test that is we will again on the application using Java 17, which is the version we are upgrading to and if everything is fine perfect, then we can give you the final result.

But in pretty large percentage of cases that's not sufficient. What we found is even after we have done all the changes applied the knowledge base, there may be built or even sometimes unit tested. So the unit tests we run maybe one or two of them are failing. And there we have a loop going on what we call the fixed error loop here. Here LLM really comes into play a, a big plays a very big role here, but it's not as simple as providing the LLM, the error and the code related code and asking, hey LLM, can you fix it, it doesn't work. We tried that.

So what as you can see, we also use our knowledge base in this, in this scenario. So we have collected again by trying to by upgrading internal apps, by upgrading all sorts of open source apps. We have collected huge amount of these errors that we run into. Figure out what the solutions are again in automated way by mining of knowledge base, even mining. So the internet stuff and that knowledge base then helps us direct the LLM in the right direction.

So when we ask LLM to fix an error, not only are we saying, of course, we have some unique prompting techniques, the right prompting techniques. But also we provide the right context, which is very, very important for LMs to do the right thing.

And of course, I'm kind of somewhat simplifying the loop itself because it's not as simple as fix the error and then fix the next error. There is some, it's almost sometimes it's almost like a search space that we have to do. And internally we have some techniques to go through the search space which are to fix first, what to fix next and so on. So that's also some things we can look into.

Let me give you some example of how that fix it works. So in this example, the error, once we have upgraded the whole application, once we have applied all the knowledge base, the error that shows up is that we have a java.io.UnsupportedEncodingException that's never thrown in the body of corresponding try statement.

So we give examples of this to LLM, we give this code and LLM is able to fix it and output the fixed code and then we can essentially move on to fixing the next order if there are any left.

Alright. So I walk through a 50,000 foot level view of how the overall system works. We took the source code we built and test using the Java version that you built your application on. We applied our knowledge base. But as we saw, that's not a lot of time sufficient.

We have to, we may still run into errors either in build or in unit test that we have to fix. Maybe because the APIs signature changed, maybe because something else changed. That was not in our knowledge base. And then we work with LLM to fix these errors.

And at the end of it, we provide you a patch file which is the upgraded code that you can apply to your application and essentially get a fully upgraded application.

Um after that. Ok. So now I'm gonna switch to the demo.

Mhm. Alright. So the demo itself is going to take a little while to run. So I'm gonna kick it off and then we'll switch to a window where uh I've already updated the application.

So before you start using our product in the IDE and we support in IDE, NVS code in the IDE, you need to install AWS toolkit plug in and under the AWS toolkit plug in, you'll see a transform button and that transform button is what you need to use. Or you can also use the chat window in which you can say /transform. That's the other option. And either one of these options, you choose, you, you, you can start your transformation.

One of the other things I want to point out is that we do need you to sign up with IAM because we use IAM identity center credentials here.

"And your admin may actually have to enable the Q preview features because preview features are not available by default. And then we may have to go in the console and enable these features. But once these features are enabled, in this case, of course, I've already enabled everything and I'm ready to go, I can click on the transform button to get it started and you'll see a pop up coming up here.

And right now, the pop up only gives you one option of essentially Java 17. But in future, we are working on other kind of upgrades, etc. and I kick off the transformation. So when the transformation kicks off, what happens is it first makes sure again, the same steps I've walked through are happening behind the scenes where we are building the application that will try to apply the knowledge base and then we'll try to fix errors if there are any.

Since this is gonna take quite a while. In this case, it takes about uh 10 minutes for this application. I'm gonna switch to another window where we have, I have already updated the application. So once you finish the upgrade of the application, you see the status right here in what we call the transformation hub and you can always switch to it by going to the AWS toolkit and click it on transformation hub.

And here within this, one of the aspects is looking at uh we generate a plan first. So let me go to the plan. So if you look at the plan, the plan is very similar to what I mentioned earlier and which is essentially we upgrade your dependencies in code, applying a knowledge base, then we build it Java 17th and see if there are any errors and we fix those errors. And as I can assure you in the workflow, we do quite, we might do this iteration like multiple times. And in this application, actually, there are multiple iterations and that's why it's gonna take about 10 minutes for for the whole job to finish. Because building test cycles, multiple building test cycles, take time.

Once we run through the plan at the end of it, you will also see a transformation summary which kind of talks about what we did. So for example, in this case, the system chained three files, one the pm, which is of course for upgrading any dependencies, etcetera, and then some other code files. And we are, there's also after we are done, one of the thing I want to point out is your project likely already. It has selected the jdk 1.8 because you are building in jdk 1.8. So you would need to go in the IDE settings and change it to use jdk 17 to be able to build in jdk 17. And so that's summarized right here.

And the way you look at what the different, what, what uh upgrade results we gave you is through the D. So that's what you have to apply on a project to be able to build in java 17. This is, this is the D you are built into Intel that we use here in this example. So if I click on any one of these files, for example, this one, you can see the code changes like I changed somewhere. I mean, we changed some of the imports, we changed some of the annotations to be upgraded because the annotations don't work with uh old java eight. I mean java 17 code anymore and we change some other pieces of code here.

Ok. So, all right. So yeah, so this is still as you can see going on and in this window on bottom, right is all the updates are coming in. What we are doing so you can get a view of what is happening in the back end behind the scenes.

Ok? I'm gonna switch back to the presentation.

All right. So we did a demo and we went through uh the whole workflow and it's very easy to use. As you can see, you just click a button and the end of it, the whole process has gone through and we get a final result.

So I'll, I'll give you a couple more examples of upgrades of specifically of code, the kind of things we fix. So in this example, for what it shows is that we applied all the knowledge base and we ran into some compilation error and the compilation error was that uh we could not find the system and the compiler could not find the method, the symbol secure.

So we pass the knowledge to LM we asked to fix it and it comes out with the corrected code where it adds the secure equals false. And we can move forward with the upgrade. At that point, we are able to successfully finish the upgrade. We may have to fix other errors too.

And there is another example which is a little complex, can get a little complex, which we do. So sometimes when you upgrade, I mean when you upgrade the quote from 8 to 17, you may also have to upgrade from Jaw unit four to Jaw unit five. At that time, all the annotations might have to be changed. Like some of the other accessors might have to be changed. For example, the public was removed. So all those changes we automatically do.

And I can tell you from personal experience that this itself and these kind of things save huge amount of time. I remember before we had this tool in my team, one of my teams, one engineer was given a very large application where they had to, he had to move from J unit four to J 85 and it took almost a week or so of work because it was a very large application to change all the code tested, make sure everything is working fine, fix all the errors.

A lot of it was also research and understanding what, what it takes to move from J at 4 to 5 because nobody is doing it every day. So when you want to do this upgrade only, then you go and look up the knowledge base. So you forget about it after a month or two. So if you need to do it again, you look up again. And that's one of the aspects that we really help with here, which is developers don't have to worry about remembering all this. They just tell our system and we can do the upgrade for you.

So I talked about how the system works. What's the behind the scenes view of the system? Give you a 50,000 view, give you a view of our workflow, how we use a combination of techniques. But of course, this is a preview version, the first version. So we do have certain limitations which we do plan to fix as we build subsequent versions of the product.

Wow. So currently a knowledge base primarily knows about open source packages that brings in some limitations, which is if your application is dependent on other internal packages, we don't know how to upgrade them yet. Right. So what we'll do in that case is we'll upgrade our application all the way with upgrading uh open source packages. But there may still be certain dependencies which are your own internal ones that we haven't upgraded and you may have to upgrade them yourself.

Now, a lot of times what we find is that maybe dependencies are already java 17 compatible. In which case we are, it's ok. But if they're not, then we have to manually, you may have to manually change that. Now we do want to work. We are working on ways to fix that by learning from your code base in future. Uh where we made uh like similar to what codes customizations does where we can take your code, learn from it and make the code generation more custom to you.

We plan to add similar feature here where we can take your code, analyze it, build a knowledge based specific to you your code and essentially be able to upgrade even first party dependencies, which is your internal dependencies. So that's a current limitation.

All right. So that brings me to end of the presentation. So to summarize, right, we talked about uh Amazon Q, we talked about how it can help you. We talked about how it works. Uh our goal really is to help take all the effort away from maintaining and upgrading and patching and keeping your application up to date, which is really the in some ways the least value add for a developer.

I mean, it's, it's very, don't get me wrong. It is required, it's needed, it's hugely valuable. But developers time is better spent on building new features, delivering new customer value. So we want to take that aspect, which is the maintenance upgrade, patching aspect, all that burden away from you so that you as a developer or your team can focus on really delivering features for the customers where you can add the most value, grow your business.

And with this product's help, we essentially help you do this and enhance your productivity with java updates or the step one, but that's not where we are going to stop. Of course, when this stuff is very important to keep your security posture good. Because if you do, if you, if your application still has older versions of libraries, older versions of java, etcetera, you may not be getting the latest security patches, you may not be performing at the level.

I mean, their application may not be performing at the level it should because with new upgrades, performance improvements are also available. Uh we also p announced and this is coming soon is up uh helping your applications upgrade from windows.net to.net core on linux. So that's gonna come soon.

In fact, we internally also use this tool before we launched. As I said, we have also mined internal and external applications, but we also wanted to make sure that the system actually works for our own internal applications. And we were able to migrate 1000 plus java apps in just basically a couple of days with just on an average taking like 10 minutes on each application. But of course, some large applications took much longer.

Now, typically very, very conservatively, each one of those applications would have taken 2 to 3 days frankly, from my experience, anything takes about a week but conservatively, it, it would have taken 2 to 3 days. So doing 1000 applications means almost 10 years of SD effort we saved with just within, we got the equivalent of that in just two days, right?

Ok. So that brings me to the end of the presentation."