Top Reasons to Consider Switching to WildFly Swarm
Top Reasons to Consider Switching to WildFly Swarm
Is WildFly Swarm this just riding the microservices fad, or are there real benefits to adopting WildFly Swarm for your production applications?
Join the DZone community and get the full member experience.Join For Free
The Future of Enterprise Integration: Learn how organizations are re-architecting their integration strategy with data-driven app integration for true digital transformation.
Make JAR not WAR. This has become the catch cry in our microservice obsessed world, and with the recent release of WildFly Swarm, JBoss developers can now get in on the UberJAR action. But is this just the latest fad, or are there real benefits to adopting WildFly Swarm for your production applications? Let’s take a look at some of the reasons why you may want to make the switch to WildFly Swarm.
Upgrading an application server is not quite as simple as it sounds. If you are lucky enough to have scripted the construction of your app server infrastructure with tools like Chef, Puppet, or Ansible, you still have to some combination of the following:
- Store the WildFly distribution somewhere — because the links on the WildFly website are not meant to be used by your script as it builds a server.
- Download, extract and set permissions on the locally installed copy.
- Apply any configuration changes, either with the CLI or by manually updating the XML.
- Deploy your applications.
In contrast, WildFly Swarm provides a much more streamlined process:
- Build your UberJAR downloading the WildFly artifacts from a repository (Maven) that is designed to be available and accessed by your build scripts.
- Permissions are not an issue because you are working with a single file most likely being deployed to a container service.
- Configuration settings are built into the JAR at build time.
- The JAR is the application. Running the JAR means your app is deployed.
The default XML files shipped with the WildFly application server contain a lot of settings that the WildFly team feels represent a good base configuration. Why those particular settings were chosen are often not documented, or are only explained in JIRA comments that you have to hunt around for.
In practice, you will start with this default configuration and tweak it to suit your needs. But this presents a problem when you upgrade because the new version of WlidFly will have a slightly different default configuration to apply your settings to.
If you have gone down the path of applying every tweak via the CLI tool, then there is a good chance that you can apply the same set of changes to a minor upgrade of the application server. If you have tweaked the XML directly, then you are left to diff the config files between versions and import the new default settings into your custom XML file.
From experience, I can tell you the that the CLI tool is quite cumbersome to use, and after attempting to apply configuration changes via the CLI I gave up because generating custom XML using the templating features in tools like Ansible was so much easier and more reliable. But that ease of customization came back to bite me in the ass when I had to work out what default settings changed with new releases of the app server.
WildFly Swarm doesn’t have the same problems. Because the configuration of the app server side is now plain old Java, you have a very familiar, robust and repeatable way to apply your settings. If the default values change between versions, you get those new values for free. Should the configuration options themselves change, you will get a compiler error.
Infrastructure as Code
If you haven’t made the jump into DevOps yet, then there is the potential for disagreement as to who “owns” the application server. Traditionally an app server is treated like a database server or an email server, which is to say that it is deployed and managed by the operations team.
But in the real world, developers often have a better understanding of the inner workings of an application server. A Java EE application server is designed to provide the basis for Java applications, and unless you write Java applications for a living, the nuances of the services provided by a Java EE server can be difficult to understand.
WildFly Swarm places the configuration of the application server squarely back in the developer’s court. WildFly Swarm is just a suite of Java libraries, configured with Java code, compiled with Java tools, and packaged into a Java executable. Your Ops team will want to be involved in the configuration of WildFly Swarm about as much as they want to be involved in the generation of your JPA entities or configuration of your EJBs.
How do you define the state of an app server? It is a combination of the package that was used to deploy the app server, the state of the configuration and the versions and combinations of applications that have been deployed.
Typically an app server is not immutable. Configurations may not change much, but it is certainly not uncommon for apps to be deployed and undeployed without rebuilding the app server itself. This is not to say that an app server can’t be immutable, but just that it probably won’t be.
Individual WildFly Swarm deployments are immutable by default. Deploying the JAR is effectively the same as deploying, and configuring the app server and then deploying a single app. Updating the app also involves updating the app server that it is run with. By using WildFly Swarm, you get immutable deployments of standalone applications for free.
Published at DZone with permission of Matthew Casperson , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.