Being Java cloud native means more than containers and microservices
Many traditional developers are worried that the cloud-native trend is leaving them behind. Fortunately, help is on its way to make existing code more Java cloud native compliant.
Enterprise software developers toiling away at the development of traditional server-side applications that get packaged in WAR files and deployed as EARs need not fret about being left behind by the Java cloud-native trend.
"People always need to reinvent themselves and learn about new technology as it arises," said Chris Aniszczyk, COO of the Cloud Native Computing Foundation. So having a day job that involves working extensively with Servlets and JSPs doesn't excuse you completely from ignoring the industry trend toward the development of microservices and the packaging of those microservices in software containers. But even if your applications are deployed as WAR files through the WebSphere Administrative Console, there's still a good chance that what you're doing will achieve some level of Java cloud native compliance.
Enhancing the Java EE stack
Aniszczyk simply can't see any of the big vendors not updating their software stack to make it as cloud native as possible. "I think that eventually the plumbing of a specific type of stack will update itself to run on cloud-native technology," Aniszczyk said. "Software platforms will be updated under the covers."
People always need to reinvent themselves and learn about new technology as it arises.
Chris AniszczykCOO, Cloud Native Computing Foundation
Whether it's due to complexity, available fiscal resources or even prioritization, Aniszczyk understands that it's not always possible to convert every legacy application into something that's cloud native. "I spend a lot of time in JVM land, particularly dealing with the modularity of Java applications and the difficulties associated with breaking up monolithic applications," Aniszczyk said. So he understands that monoliths morph into microservices overnight.
But the big vendors themselves will be working hard to make it easier for their Java EE offerings to adapt to a Java cloud-native future. "They're doing a lot to make sure their underpinnings will scale on their cloud platforms," Aniszczyk said of the established vendors in the Java EE space.
Observability and analysis players listed in the CNCF's industry landscape. CNCF projects are highlighted in green.
A Java cloud native philosophy
But that doesn't mean Java EE developers should rest on their laurels, delegating the responsibility of achieving cloud-native status to the architects of the environment. Software developers and enterprise architects play a key role in moving toward a cloud-native future. Slowing the tearing down of any monolithic applications is a first step. Externalizing the applications themselves is another.
Next steps include developing new features and enhancements as microservices that can be deployed into standards-based software containers such as containerd, rkt or Docker. Another strategy organizations should use to set themselves up for a cloud-native future is factoring out isolated logic into serverless components that can be implemented as easy-to-access Lambda functions.
Starting the Java cloud native journey
"There is such a slew of cloud-native technologies out there," said Aniszczyk, referencing the CNCF's Cloud Native Landscape diagram that valiantly attempts to note and categorize the various different offerings that might become part of an organization's cloud-native strategy. Grouped into categories such as platforms, provisioning, infrastructure, runtime, orchestration and management, the landscape diagram certainly provides a comprehensive look at what's available, but it can be a little intimidating as well, because it lists about 20 different databases and about 50 different observation and analysis tools. It's almost enough to make you think that the container and microservices landscape is ripe for vendor consolidation in order to make charting a path into the world of cloud-native development a little bit simpler.
But as intimidating as the Cloud Native Landscape diagram might be, it achieves the goal of demonstrating that there are many different entry points for those interested in making the shift away from traditional Java EE application server deployment and toward the use of PaaS, SaaS or other cloud-based tools.
So traditional Java EE software developers need not fret too much about how well their current applications will fare in a world where everything is deployed to a container and hosted in the cloud, because the software vendors who deliver the application server software will do as much heavy lifting as they can to make their systems cloud native. But at the same time, with so many options and different entry points available, Java EE professionals should be constantly looking at strategies for making the code they write and the applications they deploy more cloud-native-compatible.
