Migrating Applications to Platform Core

Hello and welcome to this video of migrating to Azure Platform Core. My name is Simon Ritter. I’m the Deputy CTO at Azure. Before we get into the demonstration of how you can migrate particular applications, it’s worth spending a little bit of time talking about what Azure Platform Core actually is. At the base it is builds of OpenJDK, we call these Zulu. So we download the source code from OpenJDK project, that’s where the Java platform is developed. We take the different versions that we support, download the source code and the build scripts, and then we generate a binary distribution, which you can install on your machine to run your applications. One of the very important things about what we do in terms of delivering that distribution is that for all the versions that we can, which is JDK 8 onwards, we will run the TCK tests. Now the TCK stands for the Technology Compatibility Kit. This is part of the Java standard. If you look at the Java community process each version of Java has what’s called a Java specification request and part of that is a specification of the Java platform but there’s also a set of tests that you can use to verify that the distribution you create actually matches that specification. There’s over 150,000 tests and we pass all of those for the versions that we provide. And that gives you a very high level of confidence that what we’re delivering is functionally identical to any other version that is TCK tested. Many people are still using the Oracle JDK. So what you’re getting is a functionally identical version of Java to the Oracle JDK. In addition to providing binaries of the distribution, we also provide updates in the same way that you would get for other distributions of Java. Updates to Java are provided four times a year, January, April, July, and October. What we do is we take the changes which are made to the current version, and that’s the way they’re developed, and we will backport those to versions that we continue to support. Right now, that’s JDK 6, 7, 8, 11, and 17. What we do is we take those changes and we backport them for all security patches and all bug fixes where applicable. The reason I say where applicable is because obviously if there’s a feature that’s in JDK 19, which doesn’t exist in JDK 8, then there is nothing to backport. But everything that is applicable will be backported. We make those available very quickly so that if you need to use those to maintain the security or the stability of your applications, then you can. Another thing that’s very important about Platform Core is that we provide two versions of each update. First of those, often referred to as a CPU or critical patch update, is one that only includes the security patches. The idea behind that is that if there is a critical vulnerability that needs to be addressed very quickly in the Java platform, then you use the CPU which has small number of changes. You can test your application quickly, make sure that it starts up, basic functionality works, and then deploy that update into your estate so that your applications are as secure as possible. The second version of the update, sometimes referred to the PSU or Patch Set Update, is all of those security patches plus everything else. Any bug fixes, performance improvements of the source code changes. And that will be very different in terms of size to the CPU. CPU is typically anything from a couple of patches up to maybe 20 at the maximum versus the full update will be several hundred changes. Because that could impact on the stability of your applications by having the CPU available, you can roll that out to give your systems maximum security and then take longer to verify that the full update doesn’t have any impact on how your application runs and then deploy that when you’re happy with that. So it gives you maximum stability for your applications as well. And really it’s about giving you the user maximum level of flexibility. In addition to this, we also have a normal support organisation. If you have a problem with the Java platform, you can contact our support team and they will help you with that. Potentially, if need be, they can generate a change to the JDK and then deliver an update, including that for your application. When it comes to migrating an application, I’m going to do a demonstration of this in a moment, but it’s worth just talking about how to do this. We very strongly recommend the idea of doing this in two stages. Let’s say you’re running your application on Oracle JDK 8 update 202. That was the last freely available update from Oracle. We would say that it makes the most sense to actually change from using Oracle JDK to using Zulu builds at the same update level. So you would do a like for like migration and you would install Zulu JDK 8 update 202. That way, you know that the source code that we started from is identical. And so the functionality will be exactly the same. When you’re happy that there are no differences in terms of how your application runs, you don’t need to recompile code, you don’t need to make any changes to your code. Then when you’re happy with that you can do a second install and this time you can install the latest update. In this case at the moment, it’s JDK 8 update 352. That way, if there are any changes between update 202 and 352, which might impact on your application, you won’t be thinking, oh, this is a result of changing from using the Oracle JDK to using the Zulu JDK. As I said, very much recommend doing it in this form. And we’ll see in the demonstration why that is actually very relevant. To demonstrate how easy it is to migrate applications JDK to the Azul Zulu build of OpenJDK. I’m going to use two different applications and I’m going to use platforms which are very common in terms of web servers. First thing I’m going to use is Apache Tomcat as a servlet engine and then I’m going to use JBoss from Red Hat which is an application server. To demonstrate this, what I’ve done is to create a very simple application running on Tomcat, which is a form which I can type in an airline code and that we’ll call a servlet, which is then going to use a JDBC connection and a MySQL database. So it’s got a little bit more sort of reality in terms of what people are going to be using for their applications in production. If I type in the code for a particular airline and submit that to the servlet, what I’m going to see is the name of the airline printed out. So that’s worked with the shareways. But I’ve also provided the information directly from within the JVM of what the name of the vendor is, Oracle Corporation, and the version which shows that we’re using JDK 8, update 202. That was the last freely available version from Oracle. Now if we want to migrate to Azul’s JDK, what we would very strongly recommend is to do a like for like update. install, meaning that we will use update 202 rather than going directly to the most recent update. There’s a very good reason for that and I’ll demonstrate that in a moment. Because I’m going to do it in two phases I’m also going to show you two different ways of installing the Azul JDK. First of those is to download a specific package from our content server and if I look at where I am. What I can do is I’ve created a simple script to download that just to save me having to type it all in. As you can see here I’m going to use curl and we’re going to use the azure content server, download JDK 8 version and update 202 for Linux on AMD 64. If I execute that script what we’ll see is it takes a couple of seconds and we will now have in this directory file for installation. I can very easily install that using the dpackage command and what we’ll see now is that will install the Zulu8 JDK. If I look in the directory which is user directory created and that’s the install directory that’s used for there. This is the same one that’s used by default for Linux distributions. So having done that what I now need to do is reconfigure my Tomcat to use that new JDK. So this is really the only thing that you would have to do manually and I can do that by changing the acceptor default Tomcat 8 directory and in there you will see that JDK which is what the one we saw being used, date 202. If I comment that out and uncomment this line here which points me to the userlib.jvm directory with the new installed JDK. What I can now do is restart my Tomcat instance using system control. And that will then restart Tomcat 8, takes a few seconds. And now we can go back to our application, call up the airline search again. This time we use a different code. And now what we’ll see is that we’ve got the name of the airline. Great. But we’ve changed to using the Azure systems JDK and we’re still using JDK 8 update 202. All of this is good. So the application works in exactly the way that we expect it to. This is this is showing just how simple it is to do the migration. Really isn’t anything very complicated about it. update to the latest version. I’m going to do that in a different way. I’m going to configure my Linux environment to use the repository that we have for packages so that you can do a direct download without having to download the package separately. To do that, what I’m going to do is use a specific key for the Azure repository. And if I just show you what happens there, all it’s doing is adding a specific key that then enables us to use the apt command directly. So I will execute that and that will add the key that I need to do that. Once that’s completed what I can then do is download and install the application directly by doing apt-get install. and this time I’ll simply say Zulu8-JDK. So that’s going to install the latest update. I don’t know which one it is but it’s going to install whichever one is the latest. If I do that obviously I’m going to answer yes and then it will install a number of packages because it installs the JRE as well as the JDK, everything that’s needed for that. And again that just takes a few seconds as you can see that’s quite quick. and now we have the Zulu8 installed. If I look in the user lib jvm directory again what I’ll now see is in addition to the Zulu8 AMD64 that I have which I installed manually I’ve also got Zulu8CA AMD64 which is the name that we give to the directly installed package. If I then want to modify my Tomcat instance again I can modify the install of the Tomcat configuration file. And once again, what I’ll do is I will commit out the line, which has the old one on, and then I’ll take that one. So now I’m pointing at the freshly installed JDK. I will then restart my instance of Tomcat. Again, it takes just a couple of seconds to do that. And once that’s completed, I can now test my application again. This is a very important part is testing your application and we can see that we can provide the code for our airline. And when we do this, ah, now this is where it’s very important to see that. like for like update install first because if we had gone directly from the oracle JDK8 update 202 to the Azul JDK 8 update 352 which is the most recent one we would see this the application stops working we’ve got a problem with a communications link failure and if you have done that you might be thinking to yourself oh that means that the Azul JDK is somehow different to the oracle JDK and it doesn’t work my application doesn’t work with Azul that’s not the case we saw that with What we’re seeing here is a result of a change that was made in one of the updates. So whether you were using the Azul JDK or whether you moved to the Oracle JDK update 352 you would see the same thing because it’s in the OpenJDK source code repository. And the change that’s been made here is related to transport level security in terms of which versions are enabled or disabled by default. I deliberately used an older version of Tomcat, Tomcat 8, which is using TLS 1.1. And if we go into the user libjvm and we go to Zulu 8. if we go into Zulu 8. In there is a JRE directory and if we go into there we can see we’ve got a lib directory and in there there’s a security directory. Within there we have java.security file. And if we edit that and we look for TLS, what we will find is that there is a configuration detail here, which is the algorithms are disabled by default and listed in the disabled algorithms is TLS version 1 and TLS version 1.1. So if I delete both of those, so they’re now enabled by default. and save that file. What I can then do is restart my Tomcat instance again. So now I’ve restarted it with the TLS 1.1 enabled again. And now if I go back to look at my test and. submit the same details. What I’ll see is now the application works because TLS 1.1 is enabled and I’m seeing that I’m using the Azul system and I’m using update 352 which is the latest one. So as we can see here this is very important to understand that we can we could do the update straight away to the latest one but we might see problems due to changes in terms of the individual updates. So it’s better to do 202 to 202 and then move to 352. In terms of being able to provide older updates, we can do that for different updates if you want. Not 202, we can go back older than that if you want. So that’s the key thing there. Now what I’m going to do is show you another demonstration using the from Red Hat. For the second demonstration, as I said, I’m going to use the JBOSS application server and run the sample application that comes with that. The first thing I’ll do is go to the install directory where I put that. And in there is a bin directory. Within there, we’ve got a standalone shell script, which we can use to start up the application server. So if I run that. then that will take a few seconds just to start up all of the different parts of the JBOSS application server. Right, so now we’re ready. What I’ll do is I’ll just scroll back up so you can see that in terms of the environment, we can see that we’ve got Java is running the user Java, JDK 1.8 update 202, which is the Oracle version. And now what I can do is I can come to the JBOSS application test application. and what we can see here is we’ve got a number of fields and it’s the usual thing of you know entering some information which I’ve already done in the past so if I register that then the application works great so we know that it’s running with update 202 from oracle what we now want to do is to stop that application so we’ll hit the ctrl c on that one and then what we’ll do is we’ll edit the standalone dot shell file and we will change the Java version from the Oracle one. Again, this is the only manual thing that we would need to do is to change the explicit Java version. This is not always necessary because if you have only one installed version then it will often just pick this up by default, but I’m doing it manually just to show that this is how we can do this. So we’re now going to switch back to using the one that we installed and not going to go through the installation process again because that’s not really very exciting. So now if I run that and we’ll start that up again, again just a few seconds to run through the normal setup procedure and yep so now we’re ready again scroll back up so you can see that now we have changed here the Java environment is now using Zulu8CA-AMD64 which is the one that we if I go back to the JBOSS test application and that will clean the database every time you run it, so I can just add you the same user again with the same details, register that user and everything works. So in the case of the JBOSS application server, because we’d already changed the TLS and made that change, then there was nothing that we needed to do, it’s simply a drop-in replacement and it works in exactly the same way that we expected it to. The overall thing here is to understand that the process of moving from the Oracle JDK to Zulu JDK is really very straightforward. All you’ve got to do is basically install it and then any configuration that you might have manually in terms of the Java home environment variable with the Java environment variable is the only thing that you would need to change. As I said, often if you’re just using the default installed JDK, when you install the new one, that becomes the default and so it will pick that up automatically. But if you annually. So very simple, very straightforward to migrate from Oracle JDK to Zulu JDK. So as you can see, Azul’s Zulu builds about JDK, Azul’s platform core provides a very straightforward way to be able to move from Oracle JDK to a different distribution of Java without having to make any significant changes in terms of your application, maybe some configuration changes if you need to. resolve things that have changed between updates. Otherwise, very straightforward, very simple to make this migration. Thank you.