How do software engineers transition traditional Java EE development into a world of cloud-native Java? Heptio's Craig McLuckie provides insights on transitioning.
Software developers in the Java space have a long history of creating composite software applications, packaging those applications within archive files and then deploying those archives to a middle-tier application server, like JBoss or WebSphere. It's a software development practice that has served the community well for almost two decades. But the emergence of microservices and the proliferation of containers are pushing many organizations away from the creation of monolithic applications and pulling them into a world in which smaller, individually composable cloud-native Java applications are preferred.
Few people debate the virtues of developing and deploying cloud-native Java applications. But for the army of Java EE developers out there with a background in traditional development techniques, the question becomes how to transition into the world of cloud-native Java development.
Embracing cloud-native Java
Craig McLuckieCEO, Heptio
Sometimes, an easy first step in getting familiar with cloud-native development is to take an application that might have traditionally deployed to WebSphere, embed it instead on a lightweight, Java EE-compatible WildFly instance and container-deploy the new configuration. It hardly embraces the ideals of microservices-based development, but it's an easy way to get started, combining the familiar with the unfamiliar.
"You can use containers as though they were virtual machines and create large, packaged, relatively monolithic deployments. There's no reason not to do that," said Craig McLuckie, CEO of Heptio, based in Seattle. "But much of the power from a cloud-native approach comes from composability and being able to piece together much smaller pieces into an environment that's centrally managed."
Identifying individual components
When creating cloud-native Java applications, the software architect should be looking for ways to break down a traditionally built application into smaller, loosely coupled, potentially independent pieces. Traditionally built Java EE applications might have a caching piece, a piece that handles request-response cycles and a piece that performs database operations -- all of which would normally be packaged within a single, individually deployable archive that is deployed to an application server. When creating a cloud-native Java application, a better approach is to factor out each of these components into individual modular microservices.
"The preferred way to do this in a cloud-native environment would be to tease those things apart in three separate containers," McLuckie said. "They can live in the same namespace, they can have access to all the same underlying system resources and they can all be deployed together. And if one component starts to generate an out-of-memory condition, that single component can safely be restarted without touching the rest of the application."
The ability to isolate individual components is obviously a compelling reason to create microservice-based, cloud-native Java applications. The opportunity to introduce opportunities for reuse is another.
Navigating opportunities for reuse
When organizations deploy a number of large enterprise applications to their middle-tier servers, there is often a fair amount of functionality duplication. "Organizations will redeploy the same basic componentry three or four times in three or four different contexts," McLuckie said. "When you see something like that, portion it out, package it up in its own discrete container and then deploy or even codeploy it with the broader application." That's often an easy victory for teams when first refactoring their monoliths into cloud-native Java applications.
To hear the full conversation between McLuckie and TheServerSide's Cameron McKenzie, including more of McLuckie's insights on how Java EE developers can transition into a world of cloud-native Java application development, listen to the accompanying podcast.