The story of Wildfly Swarm, from a business perspective, is kind of a story of microservices. Microservices are small, isolated, and focused service applications; as an architecture, microservices is an approach that decomposes larger systems into those smaller, focused, isolated services. These services talk to each other through a shared, common API, but are otherwise independent in design and deployment. Microservices, then, are frequently aligned with DevOps – which uses small, agile teams to quickly develop and push software for continuous integration (of systems) and continuous delivery (of software).
But what is Wildfly Swarm, in that context.
Typically (not always and not with all applications, but just typically) Java applications tend to be larger and tightly integrated with related services. Java applications (again, typically) fall into a de facto monolithic design – services are developed together and are tightly coupled, changes to a single service may have ripple effects throughout the entire application.
That has had an effect on how many IT departments use application servers (such as Red Hat Jboss Enterprise Application Platform). Originally, application servers were intended to host multiple applications on a single application server. But in reality, as applications grew in both size and complexity, application servers ended up only hosting a single application.
This led to a mindset of app servers being large, at times unwieldy, entities. Jboss EAP 6 began challenging that perception by modularizing the app server itself and making it much easier to choose what services to use and where to deploy them for optimum performance and scale. But it was still a “traditional” app server in the sense of how it handled and deployed applications.
DevOps and CI/CD have really found a home in containerized environments because the containers themselves are immutable (not changing on the fly) and the environment is manageable and repeatable. You can have the exact same specs, libraries, and package versions in your development environment as in your production environment. That reduces the risk of failures or conflicts when you do production rollouts. Also, containers are lightweight – the only things in the container environment are the libraries, applications, and processes directly used by that container. The resource sharing is very efficient; deploying containers is generally very quick.
And that’s where Wildfly Swarm comes into the story.
Wildfly Swarm is a way of essentially containerizing Java applications. Typically, Java applications rely on a network of libraries and injections, so multiple libraries need to be available when a JAR file is deployed. What Wildfly Swarm lets you do is create a fat jar; it essentially bundles all dependencies (and only those dependencies) into a single JAR file, and then that single fat jar can be deployed in your environment. The only services included for that application are the ones it will actually use, which scales down the size of the app server instance.
The application, through that fat jar-based deployment, is the primary thing; the framework and runtime are secondary.
That mimics the container-based approach to development, only in a Java-friendly environment. It also moves Wildfly Swarm as an architectural framework closer to the original vision for application servers – multiple applications, more efficiently using system resources.
Rich Sharples, the director of product management for middleware at Red Hat, had a really great way of describing Wildfly Swarm: “It gives a glimpse of what we’re looking for in the future.” It doesn’t match every application and every IT team, but for organizations which are looking for a way to take their current Java applications and Java developers into a different, microservices or container-based environment, this is a path into that future.
While this is not yet in JBoss EAP 7, it is something that is anticipated for the future for JBoss EAP and for Java development. More resources are available at the Wildfly Swarm project site or from the DZone flashcard. For a 20-minute intro, check out this presentation from developer Lance Ball, from last December.