See all blog posts
In today’s production environments, it is not only expected, but critical to keep your technology stack as up to date as possible. Staying current helps to mitigate security risks, while also benefiting from bug fixes, performance improvements, and new features and function that can help drive your business’s success. This is true whether you’re deploying to a cloud or locally, and applies regardless of the deployment type, whether container images, VMs, or bare metal.
The challenge of keeping microservices up to date
Updating an application runtime is, however, typically a grueling task to undertake. With each new version, breaking changes can be introduced that directly impact your application, your configuration, or your operations. Breaking changes translate to significant development effort being needed to re-run all the tests and address any regressions. Similarly, the operations team also need to ensure that all their automation still works with the new version, and that it remains compatible with their target deployment environment.
Now multiply these concerns by the hundreds or thousands of deployments of your microservices, each containing an instance of the application runtime, and it’s no wonder that many applications remain on old versions and teams pursue upgrades only when deemed absolutely necessary. This growing technical debt not only delays the benefits provided by newer releases, including security fixes, but can also snowball into making the eventual migration process that much more difficult and risky.
Although container image scanning is improving, containers can further exasperate the problem by obfuscating old, possibly unsupported, runtimes and dependencies. Teams might not even be aware of an aging runtime and the potential security risks it could pose.
Liberty’s zero-migration architecture
This is where the benefit of Liberty’s zero-migration architecture comes in. Zero migration is a core design principal of the Liberty application runtime that seeks to make updating Liberty quick and easy.
Zero migration ensures that a valid runtime configuration from one Liberty release functions the same for all future releases. This means that you’re able to update the Liberty application runtime and gain all the benefits of the newer version: security and bug fixes, performance enhancements, and new functionality and features, but without any disruption to your existing application logic and operations.
How does zero-migration architecture work?
New versions of Liberty only add new capabilities and never remove or change existing capabilities. So the configuration that you create for your application today will work and behave in the same way for every future Liberty version.
Liberty features and versions
Liberty features are what provide Liberty with its modularity. Each Liberty capability is associated with a feature; for example, the Admin Center feature provides an administrative GUI and the Audit feature provides tracking of auditable events. Features are composed of the feature name and the feature version, which you specify in the configuration files (e.g. server.xml file) for the Liberty instance on which the application runs. The versions of the features are not tied to the version of Liberty.
You can upgrade the version of Liberty on which your application runs (e.g. to get a security update) without upgrading the versions of the features that the application uses. Whenever a breaking change needs to be introduced into a feature, its feature version is incremented, but Liberty continues to support all previous versions as well as the new version. This means that you control if and when you want your application to use a newer version of the feature.
For example, if your application is using MicroProfile Config 2.0 (the mpConfig-2.0 feature), it’s up to you if and when you want to move up to mpConfig-3.0, mpConfig-3.1, or any other future versions of MicroProfile Config. Your application can continue to use mpConfig-2.0 while Liberty receives updates, including bug and security fixes, new features and functionality, and performance enhancements.
Updating to a new version of Liberty
Updating to a new version of Liberty is easy. If you use our Liberty container images, all you need to do is update the version tag or image digest to point to the new version of Liberty and then rebuild your image. If instead you consume Liberty via the download packages, there’s several upgrade paths, but one of the easiest approaches is to download the newer zip and use the WLP_USER_DIR environment variable to point the runtime at your application and configuration.
If you use Maven or Gradle for application development, update the version attribute in the runtimeArtifact parameter in the pom.xml file or the libertyRuntime dependency in the build.gradle file, respectively. It’s worth noting that if you don’t specify the Liberty version in Maven or Gradle, it will default to the latest version available in the repository.
Liberty’s 4-week release cadence
A new version of Liberty is released every four weeks. Since the first release of 2019 (19.0.0.1), there have been 12-13 releases each year. To get the latest updates, including security, performance, and bug fixes, simply update to the latest version of Liberty; zero migration means that your applications continue to run as before. You can upgrade from any Liberty version to any newer Liberty version, skipping any releases you’ve missed.
If you purchase support from IBM, you can get security, performance, and bug fixes without necessarily upgrading to the latest Liberty release. Each Liberty release is eligible for 5 years of support. Release versions that end with .3, .6, .9, or .12 are eligible for interim fixes (iFixes) for two years; all other releases are eligible for 24 weeks.
Proactive security fixes (security fixes we automatically make available when we announce a security vulnerability) are made available for the most recent release and also for the most recent two releases of those that end with .3, .6, .9, and .12. For more information regarding support, checkout the Open Liberty support page.
| Support status | All releases | Releases ending in “.3”, “.6”, “.9” or “.12” |
|---|---|---|
Support Provided |
For 5 years |
For 5 years |
iFix Eligible |
For 24 weeks |
For 2 years |
Proactive Security Fixes |
Most recent |
Most recent 2 |
Our prebuilt Liberty container images are rebuilt weekly for the versions eligible for the proactive security fixes, pulling in any Java and UBI fixes that have been released since the previous build of the image. This provides you with a great base image for your application, while retaining control over which Liberty iFixes you want to apply to your image.
Caveats
It wouldn’t be the full story without the caveats. Thankfully, when it comes to zero migration, there are only a few and they mainly relate to important security fixes and circumstances outside of the control of the Liberty developers:
Exceptions:
-
Security fixes: Whenever we perform a security hardening or patching, we try to maintain the existing behavior of Liberty, configuration, or features. When this is not possible, we work to limit the scope of the change to only what is needed to address the security concern.
Out of scope of Liberty’s zero migration policy:
-
Third-party API requirements: Updates to third-party components are not guaranteed to be compatible with earlier Liberty versions.
-
Undocumented configuration properties: Configuration options not documented in our platform’s documentation can cause issues if used—and might even be removed or changed at any time. An example would be any beta functionality.
-
Incompatible Java changes: While rare, breaking changes in new Java SE versions can sometimes affect your application.
But recall from the preceding section that in the event you find yourself unable to quickly move to a newer version of Liberty, but need a specific bug or security fix, if you have a paid subscription, you can still contact IBM Support to receive an iFix that you can apply to your existing supported version. And thanks to Liberty’s continous delivery model, the iFix is included in future releases of the runtime, meaning you won’t need to reapply it once you move to the latest version.
Zero migration vs technical debt
Zero migration not only reduces your technical debt, the overhead of keeping a runtime current, but in many cases eliminates it entirely, allowing you to focus on the higher value items of development and operations.
