Transcript
Grzesik: My name is Andrzej Grzesik. I'm a principal backend engineer at Revolut. I'm proud to be a Java champion, proud to be a JavaOne Rockstar, and have been involved with various software initiatives around the world.
Java Release Cadence
During Java 17 release activities, Mark Reinhold has blogged on his blog that he would propose to ship an LTS release every two years. That's a major change. The upgrade path I propose is 8 to 11 to 16 to 17. Soon, it is going to be 11 to 17. There are no new features being discussed in depth in this talk. Which version of Java are you on? What did we get? We got a viewpoint. Now let's ask the Twitter community or use some other existing Twitter polls, we can see that there is a progression towards the newer Java versions, which is also awesome and expected. Then this happens, which is blog posts by New Relic, summarizing their experience about Java versions being used in production, and that those are slightly different stories slightly more oriented towards Java 8. Then we have this which is a JVM ecosystem report by Snyk, which suggests 11, and 8, and 15 are all very popular versions. The bottom line is there is no single answer. There are many viewpoints. I don't think there is one person in the world that has a unified objective view on which Java actually is how popular. I don't think there is even a point in getting that answer. There is plenty and people are using different ones because everybody migrates at their own pace. That's normal. That's what we expect, and that's ok.
Which Vendor?
There is another dimension to this question, which is vendors. Vendors are a thing, or the choice of a vendor is real. As you can see from Snyk's report being used here, AdoptOpenJDK seems to be the most popular JDK running in production among the people who responded to Snyk's call for questions. Obviously, there must be other organizations who didn't participate, which means there is definitely multiple vendors and multiple JDKs by different vendors available. The difference between them is primarily in support, maybe in which organization you work in, maybe in which versions are being supported. Apart from that, they are all Java. The software that runs should just run. They might have some magical superpowers when it comes to GC for example, or maybe they are running a version not supported by somebody else.
Java Upgrade
Let's talk about Java upgrade, and let's talk about the Java upgrade first in the context of a financial organization that did it in 2019. We have to have this awesome vehicle, and with its power, we'll go back in time. How did we deploy Java at Revolut, when the migration was taking place? We were using CoreOS, which is now obsolete, end-of-life'd. It doesn't exist anymore. One VM, one Docker container with the production workload, and apart from that, some other containers on the same VM. This is how we rolled. This is now already pre-historic. T-Rex is happy to know all of it.
Why Upgrade?
Why did we even decide to upgrade? It's within the motto of the company to get things done. That's one. Another aspect is we have to keep moving forward, and we have to keep things working, which means if there are any bugs in the older versions that we would get fixes for later. This is not something that we would be very comfortable going to as a situation. Yes, let's do it. We would have to upgrade anyway, which means why wait, if you can do it earlier and be done with it. Another aspect is we wanted to have the new features. We wanted to have access to the fixes. Another aspect is, new Java, that means new features are available. That means curious people will want to work with us, which is an awesome thing if that gives us an edge at hiring. Why not use it?
There is another reason, JSON. JSON, and especially Java 8 to 9 transition. This happened. It used to be that strings were Char array based, now strings are byte array based. The consequence of that change if your string is based on a standard ASCII Char set, then it's going to take half the space for storing the characters within a string, which means reducing memory pressure, which for a lot of the JSON out there is going to make a difference. That makes JSON happy. Upgrade and Ops and obviously, in our context, a startup working in the cloud, trying to be modern. We have a lot of Ops, we have a lot of automation, and developers take care of many of the infrastructure tasks, which means they upgraded their own applications. We didn't have to throw things over the wall. There were no hot potatoes being passed around. For us, DevOps work on specialized projects.
Java 11
For us, 11 upgrade, or 2.11 upgrade was specifically this one. We did it to all applications. When we were done, everything in Revolut was running Java 11. Somebody could ask, why didn't we upgrade to 9 or 10? Because they were no longer maintained, and we actually wanted to migrate to 9 and 10 but we couldn't because of library compatibility. Then when we finally could, 11 was the current thing and 12 wasn't available. That's the story. We also had to make one more change, which is go away from Oracle JDK towards OpenJDK. Why? Because Oracle JDK didn't allow to redistribute and make your own images without a license and to generally run in production without a license. This is something that changed in Java 17. Java 11 or any other Java that you want to upgrade to, you have two options. You can do it with the whole house and the kitchen sink and run and compile and do everything on the new one, or compile on the old one, run on the new one.
We did the, everything migration, runtime and tool chain for all the applications. Sometimes, this is not really the best option out there. Sometimes you will be running new Java in production, but you will be using the old tool chain. When would that be the thing? If you were running some of those, as of March 2020. Why? Because they were not compatible with anything newer. That's the thing, community and all of the ecosystem of libraries and tools and solutions takes time to upgrade. That was a perfectly valid reason to have this dual mode of running. Now we're in a much better state. This is a picture painted to me by the official websites or bug trackers of various projects. What you can see here is that if you are in the Hadoop or Cassandra ecosystem, you might have to wait for running Java 17 across the board, but otherwise you should be good. This is a major difference compared to, for example, September or October last year. Today, Spark and Hadoop are Java 11 centric, with the note that Spark is now 17 friendly.
What's to Come?
What's going to happen in the future? There are serious changes happening. Kafka 4 is going to drop Java 8 support. Spring Boot 3, Spring Framework 6 will require Java 17, as in they are going to use 17 as a baseline. Hibernate 6 already requires Java 11. jOOQ intends to baseline to Java 17. If you're using any of those frameworks, or the framework that you're going to use has a component, which is one of those, you will be forced to upgrade, or else. Obviously, this isn't happening overnight. The old versions are still going to be maintained for some time, or are being supported by the open source community, or maybe somebody is going to backport things. The shift in feature and enhancements production is going to go towards the new version. It is a good time to start your migration from Java 8 to 11, at least.
How to Migrate
How do you migrate? I suggest you have a look at build tools that you're using, because they have a few things that will help you there. There are two elements in the bin directory of your JDK that are going to be very helpful. One is called jdeps, which shows module dependencies including internal API usage. If you need to migrate, you can scan it, you can scan your application with it. It will tell you if they're using something that you shouldn't, or maybe something that's going to go away. Deprecation is going to be shown by jdeprscan. Obviously there are Gradle and Maven plugins available. Now, speaking of Maven, how do you enable a newer JDK version on Maven? Probably use a better compiler version than I have on this slide. Apart from that, set a source, set the target and you will be good.
Speaking of two handy things, Maven versions plugin, display plugin updates. As you can imagine, displays plugin updates. If your build has not been maintained by many or recently, just use it. There is a similar thing for versions called display dependency updates. Self-explanatory. Very useful if you're using Maven. For Gradle, if you want to use Gradle with Java 11, v5 is good, v6 is good, v7 are good. If you need to upgrade Gradle because you're behind, my recommendation is upgrade one version of Gradle at a time, because otherwise this is going to be a large chunk of work. That's just that. Gradle and Java 17, it used to be a thing, but now Gradle and Java 17, since October, they were available. As I mentioned, since version 7.3, it actually works perfectly well.
Mockito at first started supporting Java 11 in 2.20.1. Then there were multiple releases and multiple lines mentioning JDK 11 support. Why do I mention this? Not because I need you to memorize those numbers or they are in any ball or form significant. It's just to show that sometimes JDK compatibility comes in stages, or there are things discovered as a community adopts the new version of libraries. This happened to Mockito. This happened to jOOQ. jOOQ was a particularly uneventful migration as in we just migrated and we were happy. It is going to support JDK 17 in 3.15. They are going to also have an API based on the records and the conventional branch at first. If you don't use jOOQ, I wholeheartedly recommend. It's awesome if you do.
Flyway, a toolkit for managing migrations of your database. Supports JDK 11 since version 5.2. We've actually had issues in there, so we moved back to pre-JDK 11 supporting release, and then we moved to 5.2.4, and then somewhere further. Such journeys are also possible and normal. Since I mentioned JDK updates and some of you might still be on JDK 8 which means you have JAXB as part of your JDK, those are now removed. JAXB is no longer part of the JDK, past 11 and later, which means you have to add it as a normal dependency.
Languages
Now languages, because most of us are probably not only using Java in our applications. Groovy. Why would I mention Groovy? One reason is Grails, because there is a website that I manage that actually is based on Grails. Whenever there was a Groovy update, we'll try to take it in. Also, Groovy is the foundation of something very popular, which is called the Spock framework, which is awesome for testing. Java 11, Groovy supported that since version 2.4.16. Then Java 17 since 3.0.9 or 4.0, which means right now, as of today, you're perfectly happy to run Groovy with Java 11 or 17, and it should work. Scala, for us the migration story was just switch versions of the JDK because Scala just worked. Scala did say it upfront that they do not enforce the module system. That's not an issue for us because we do not use the module system at Revolut. Also, Scala already talks about supporting Java 18, and they just do. Kotlin supported JDK 9 to 12 since 1.3.30, and they also support JDK 17 since 1.6.0.
Dependencies
Now dependencies, because obviously, your application is most likely having some internal dependencies, libraries, how do you even approach it? How should you approach it? For us, every application or most of the applications are relying on an internal library which manages database connectivity, and entity model lifecycle, and actions, and flows. This depends on something called Commons. For us, we started compiling the applications, so the outer most layer with the newer JDK. When source was compiling with both JDKs, we started to run tests using the new JDK, and then we started to run the application using the newer JDK. Then we went down the onion.
A couple things worthy of mentioning. Switching from 8, you'll have to change your GC logging flags. Some flags are going away. How can you best figure it out? How can you best know what goes away, what is current? There is a cool website, chriswhocodes, which mentions flags, and tracks flags across multiple different versions of JDK. It's awesome to sanitize and to understand what a specific version and a specific release means or meant. I suggest you use that if you need to examine especially more convoluted precious set of flags. There is also a command line linter for JDK runtime, which is quite nice and useful, especially if you have a lot of things to migrate, or the applications that you are looking at migrating have a lot of legacy stuff.
Some other issues, 8 to 11, time precision in the JDK changed. Basically, the difference is that now we can have more digits in the precise time output, which means if your unit tests or any other integration tests expect a specific precision, you will have a bit of solving. It's nothing wrong. It's just the enhanced capability by Java to work with higher precision, which means most likely have your own intermediary layer that allows you to inject clocks of a chosen precision. Especially useful for timing, testing, or anywhere else, because that's generally a thing that you should do in your software anyway. Don't do instant.now or rely on system clock, do it through some sort of an accessor so that if you need to mock it or if you need to do anything to it, you can. There were bugs in many places. There were bugs in the compiler which got fixed. That's normal. That happens because JDK is made of software. There were some bugs that actually manifested themselves only in production, especially around generics. Usually relaxing the generic captures allowed us to solve that.
Life with G1 by Default
Then there is this thing, life with G1 as default. G1, default garbage collector algorithm from 11 onwards, too long, didn't read version is awesome. No problems, just do it. Of course, our context in which I'm saying that is, services which do not have high frequency low latency requirements. We operate human scale software mostly, so that was really not a problem for us to adopt it. We're quite happy because that means that people do not have to spend time investigating GC logs. This is really a changing thing, it reclaims multiple developer days in general. If you want to start using G1 at JDK 8, the important thing to resay every now and then is that G1 in JDK 11, is a different G1 than the one in JDK 8. Similarly, G1 in JDK 17 is going to be a slightly different beast to G1 at any other, because garbage collectors are being worked on. I will not quote features and changes from memory, but they evolve and that's something that you should check and test.
The big difference is since JDK 11, full GCs in G1 are multi-threaded, actually since JDK 10. Human-perception pauseless for heaps up to 32 gigs, entirely possible from our experience. Maybe if your software is special, that won't be, but we basically stopped caring about this because we don't have to. Less problems requiring GC logs are almost exactly zero, and faster out of memory failures, which is also useful. That's something that we noticed. Because of G1, when we moved to 11, some containers started dying on us, because resident set size of a Java 11 process would be slightly higher, compared to 8. We had to adjust Xmx and Xms, and we would be getting our out of memories faster in 11 than 8, which is actually good, because then you can restart and adjust.
Language Features Adoption
Language features adoption, this is the biggest one that I'm going to put on a chart. Within almost a year, var became very popular in a single project, basically it became a standard in which we write it. Why is that a thing? Because var speeds up reading and if it's obvious to read, people like using that. We like it. Another thing, since 9, underscore is a keyword. If you're familiar with other languages you would like to use underscore as an identifier of something that you don't really care about, but there is a workaround. The workaround looks like that. That's basically a double underscore. That's a perfectly valid identifier, feel free to use it. Another aspect good in modern JDKs is Java Flight Recorder event streaming, but I'm just going to signal it.
Java 11 to Java 17
Let's have a look at a migration from 11 to 17, which is a recent story for us. This recent story goes through many different JDK versions. Some of the features are only highlighted, but I'm not talking about them too much except for this one, maybe. If you need concurrent mark and sweep, then it is going to be removed in 14, or it actually has already been removed in 14, which means it doesn't affect us because we are running G1. If it is something that you use and depend on, then there might be a limitation for you. Or you might want to explore ZGC. JDK 15 removes Nashorn, mentions ZGC properly. It's not in a testing mode. Then introduces text blocks. Text blocks are something like that, if you're used to other languages which do string interpolation and so on. We do not have that in Java, but that's progress. The good thing is with a fast release cadence, maybe there are going to be some evolutions to those.
JDK 16 migrated to GitHub, started to do pattern matching, started to do records. Records are a thing that are very good for us. A record in short allows you to convert the left to the right. That's awesome. If somebody distrusts me, yes, it's not exactly one to one, because I didn't type it exactly to be one to one, but you can see the difference in the code volume, and this is the important change. Important thing with JDK 16, and this is the reason why I mentioned a migration from 11, if to 17 directly doesn't work, then maybe have a mid-break at 16. It's because 16 starts to strongly encapsulate JDK internals by default. That means you have to add this flag to run with 16, if you still need to touch them, for some reason, or the libraries that you use have to touch them for some reason. Then 17 has a continuation of this JEP. The continuation in 17 requires a different flag to access the internals. Sealed classes, great thing for API designers, and something to do with the serialization filters.
How to Upgrade
How should you upgrade? In my opinion, the best way to upgrade is 8 to 11, then to 16, then to 17. This is probably going to change to 8 to 11 to 17 as the year goes on. Because JDK internals are strongly encapsulated right now, 11 to 16 migration is going to show different things and less things than 11 to 17, which means sometimes, if a 17 drop-in replacement isn't going to work for you, this is a recommended workaround. Colors in the IDE. Awesome. Click here.
The Performance
Obviously, somebody might ask a question about what's the performance of the JDK after the upgrade? Did we notice any performance gains? Yes, we did. There are performance improvements being continuously added from one JDK to the other. This is something that is very exciting for us to use and to observe, obviously, the growth that Revolut enjoys is consuming those performance gains. There are some benchmarks available on the internet. I have not vetted them, but there are definitely some that also claim something similar.
Modules, and JDK Version
Do we plan to use modules? No. Because we prefer to segregate our APIs through services and modules that sit in different repositories, and to publish the API, which means we do not see a need for modules to roll this out across the whole company as of today, at least. Which JDK are we using? OpenJDK.
Why Upgrade at All?
Why would you even want to upgrade? One good reason is because you are going to observe performance improvements. That means that the bigger the environment you are running, the cheaper it becomes, especially if you're running hundreds or thousands of JDKs or JVMs. One percentage point of less memory consumption, for example, can translate to a significant amount of dollars. That means that if you're in the team that can own the migration and claim the success, that's a very comfortable place to be in, a very low hanging fruit. You can actually do more with less. With the increasing energy prices and the pressure towards optimal solutions or more energy efficient solution, that's an important aspect of what we do. Another aspect is developer attractiveness. There is a lot of developers who like to work with recent things. If you say that you run a very recent modern JDK, that is going to increase your attractiveness compared to other employers.
Another aspect is some of the libraries are going to force you to upgrade, or if you want to use the recent libraries because maybe you are going to start running new projects or maybe you want to look like an attractive employer, that is going to be a thing. Obvious low hanging fruit, JVM bug and security fixes. Release by release, they come and enter the new JDK, and then the new JDK. There is going to be an increasing number of libraries that are in the open source, non-commercial versions or maybe just open source versions because they might not have a commercial version, that are going to leave JDK 8 behind at some point. I do not expect this is going to happen massively this year. At the end of this year, we're expecting Spring Boot 3, Spring Framework 6, which are going to be two major milestones for Java 17 as a baseline migration. Then new projects starting with those are going to rely on Java 17, and so on. That's going to be a good step forward and a good justification.
Another aspect is lower operational requirements. If you're running non-specific or just services, maybe microservices serving human requests or serving mobile requests, a backend site like that. That means that you will have an easier way of dealing with modern JDKs. One reason is Java Flight Recorder event streaming. Another aspect is the internals are also seeing some tuning. Then not having to worry about the garbage collector for the situations that do not require very high throughput from the applications are very relieving. That means that people do not have to spend time worrying about this because it just works. This is an awesome feature, and an awesome behavior from the JDK DMS. I think you can just use and it just works. I like that. On the other hand, if you're in a team that sits with very specific requirements, then you will have to do your research. There is no change for you there.
Upgrade Path
How should you upgrade? If you have to do upgrade today, probably 8 to 11, maybe 8 to 17, if you can. The proposed upgrade path we've already described. Then there are two scenarios that I will mention. If you have a fleet of microservices, probably I would suggest following Revolut's approach, application by application, migrate forward. Then, when most of the applications are migrated or all of the applications are migrated, migrate all of the internal libraries. We didn't go with emitting or compiling to target the old JDK versions at all, because we didn't have a reason to do that. Our software can, following continuous delivery, be deployed regularly. If, on the other hand, you're running a JVM which is completely isolated from any networks, maybe it's happily sitting on a boat, maybe it's powering a sonar data pipeline. Then the performance improvements are definitely something that might be interesting for you if time is of the essence. Then this is probably one of the few scenarios in which I can imagine you don't really have to upgrade. If it has been running happily for the past eight years, or five years, or whatever, then it might. You can find companies that will still support Java 8, who will still support Java release 6 or 7 as well, maybe even older. That is going to cost if you want the support. If you're stuck with an older component, until they upgrade, you will have to live with that. Then they are going to see the pressure because most of the community, most of the library ecosystem is going to move past the Java 11 checkpoint.
Should Non-LTS Releases Be Considered?
Another aspect is, should non-LTS releases be considered? Absolutely, because they can make a difference. An example that I know a lot of people have experienced is G1 in JDK 13 and 14, has started to exhibit much more controlled latency and much less jitter with regards to timing, or GC duration, compared to JDK 11. Those changes, those improvements are coming, JDK release by JDK release, which means if it makes a difference for you, absolutely take it in. Also, there is this company, Azul, which I use as an example, which offer support for JDK 13 and JDK 15. Two intermediate releases between one LTS to the other. That might change as we go forward towards the model that Mark Reinhold has proposed, but we'll see.
Questions and Answers
Cummins: When should you migrate? As you said, the answer is always going to be, it depends. Is now a good time to migrate?
Grzesik: The answer always remains, it depends. If somebody is on 8, and they can do that, they should migrate to 11. Don't look at 17 if you're already in an organization that is slightly behind on the Java version. It's ok. People do that. We know why that happens. There is a bazillion of reasons why this is an option, but 11 with the libraries going to baseline on 11 means, prevent the problem that will happen if you lag behind, because those libraries, they will have some catch-up phase in which people will be frantically migrating. Avoid the panic. Do the effort. It's relatively painless. At Revolut, it took one or maybe two people working together not exclusively on this problem, maybe across a period of a couple of months. It's reasonably doable, especially if you approach the problem and can approach the problem. You will have to spread out the effort across the applications that you have to work with. The sooner you chart the ground, the sooner you know what you have to deal with.
Can you speak a little about the legal issues you mentioned? If I remember correctly, the legal issues were specifically about the Oracle JDK license in version 11. Oracle JDK the one that I would download from Oracle website had required the production license, or required a contract with Oracle in order to create custom images, and in order to distribute, for example, custom Docker images like we do. The very easy solution for this is using something like OpenJDK, which is on the binary level, you run exactly the same JDK, but there is no requirement to have a contract attached. Just use OpenJDK and you're good. Or maybe use one of the other options, or you can use Eclipse Temurin. The Adopt JDK runtime [inaudible 00:38:02]. That's just that. Nothing scary. I know it sounds scary when you mention legal, but I have to mention it because if you kept running what used to be the default Oracle JDK in prod, you would risk being in breach of contract. That's something to be avoided.
How did you anticipate any potential issues before migrating? Did you use any tooling to support the analysis before diving into the effort?
Yes. We could see how much of the deprecated APIs we have to go through. That's one thing. We have an amazing tool at our disposal, as in Java is a compiled language. If it compiles or getting it to a, everything compiled state is already a good step forward. That was available for everybody. There is the jdeprscan, so the deprecation scanner, especially if you use some of the internal inside the belly APIs from Java, then you might get different results. For us, there were just a couple of fixes that needed to be done. The good thing is, if you approach the problem right now, you're in a very comfortable situation, because most of people have blogged about how you can work around the 8 to 11 upgrade because of this issue or that issue.
Cummins: Do you have a sense, and this is probably a tough question unless you kept super detailed records, which no one would, of how many of the problems you were able to catch just with the compilation and how many ended up turning up as nasty surprises in testing, and how many ended up escaping all the way to prod and then being really nasty surprises?
Grzesik: We've had some situations in prod. Changes around generics resulted in runtime exceptions materializing in prod, because they would pass tests. That was unexpected. The good situation for us, we had a lot of tests. When you looked up the error, you'd see that captures don't match. One option of going or troubleshooting that is, ok, can we write those captures differently? As it is, in one of the slides in the example, we ended up using wildcards. I think question mark, question mark, instead of something more specific, which is not ideal, because you would like the type system to support you. As a workaround, it's a quick and easy way of just going to 11.
Anything else in production that was crashed? Nothing from memory. I would certainly not call it a painless or relatively painless process if we went through hell and mayhem, but we didn't. It was good and it was better. The important thing is about the containers and memory consumption as in G1 versus anything else. The overall sizing differs, but that's just an adjustment. If you're using configuration as code, you're going to adjust it. That's it. The work is done. It's not difficult or insanely non-trivial to troubleshoot. It's running out of memory, so what do we do? We either reduce the heap size or you give more memory to the container. Then if the problem goes away, and is stable, everybody's happy. That was exactly our situation.
Are there any JDK specific tooling which can highlight issues before they show up in tools such as Black Duck?
Open source compliance tools, that's what Google then suggests. Software composition analysis. We're using Snyk, so security issues, the ones that we have to fix are usually associated with libraries and dependencies, just because of the JDK change. We were not on the very much forgotten early builds of JDK 8. We were on reasonably up to date JDK 8 build. We have the exact version in there. We are not leaving stuff behind, so we are trying to minimize the entry potential for malicious people, just because we are using an unupdated JDK, because that is a threat vector and you have to minimize it, and we want to minimize it. We have a security team who looks after all of our software. We also use Snyk to scan for things.
Cummins: Intuitively, you would expect that the number of vulnerabilities would go down as you upgrade rather than up, just because the nature of these things is that they have more time to get discovered in the old versions.
Grzesik: This is why I say as of today, as in JDK 11 is a perfectly comfortable state to migrate towards because it's been battle proven, for three years plus, which means I do not expect major things to materialize. It's a safe and well adopted baseline. Hadoop uses that. A lot of other tools also use that. I would encourage people to. If upgrading is super difficult in your organization, just plan to upgrade to 11, then the next time you have to do it, it will be an easier process.
Cummins: What about the LTS releases? Because I think they can sound a bit scary. Are they beta releases and should we treat them in that way?
Grzesik: That's a thing that happens. Java 11 is an LTS release. LTS means long term support, but the 12 and the 13 and the 14 and all of the other JDK releases they go through very thorough testing, and they go through exactly the same thorough testing phase. If somebody wants to migrate to 18, it's a full quality, perfectly correct JDK version, trustworthy, and so on. I will put it in production. I actually have some sort running in production. Not in Revolut, massively just some of my afternoon projects. Yes, I trust it. When 19 comes out as a general availability release, I will trust it because the JDK team has a lot of tests. They have a compatibility kit that verify that Java is doing what exactly people expect from Java, unlike some other scripts. Yes, LTS release, a very good choice, and any other Java releases also a very good choice for running things in prod.
Cummins: If the only difference is the length of support, if your organization has an appetite for upgrading more regularly, then you can still stay fully supported. You just have to be doing that upgrade.
Because you mentioned how long it took your organization to do the upgrade, which was super useful. Do you think there's a cost difference between those two patterns of, let me wait for as long as possible, and then do a big upgrade, and let me hop from LTS to LTS.
Grzesik: With the cost model, it depends on what the organization is inside. For us, we are a modern organization, we move quickly. It's part of the nature. It's part of how the organization rolls. We don't have a terrible lot of third party software to upgrade. If somebody is or has a lot of third parties that they have, then obviously, the situation is different, if you have a lot of software that you might have through third parties or other vendors. Or maybe they need to do the changes because of contracts between organizations. Obviously, the situation is going to be much more complex. Then you can start small, start with at least some application so that you can see how it goes, and what are the benefits? We've seen size, and I mentioned some with performance and some with reduced people overhead, as in, we don't have to look after those JVMs in a business application setting. As in, nothing ultra-high frequency or just high frequency, it's human latency levels.
See more presentations with transcripts
