The Cloud Native Java Modernization Path Looks a Lot Like Reactive
Reactive is how you design a modern application to take advantage of unlimited scalability in the cloud. Check out this interview to learn more.
Join the DZone community and get the full member experience.Join For Free
“Cloud Native Java” is a new term being used to describe the innovation path for Java (the language) and Jakarta EE (the run-time) that serve 10 million worldwide developers. In this Q&A, we speak with Lightbend CEO Mark Brewer to learn more about the ways this audience of developers has been underserved in the cloud and streaming data use cases, what the modernization efforts look like, and how the Reactive and Cloud Native movements relate.
DZone: What are some of the major challenges for legacy Java in the face of cloud modernization efforts?
MB: There are two main facets that are really difficult for traditional Java shops in today’s cloud modernization efforts.
One, historically, they haven’t had to deal with data in its raw form — meaning, they use SQL queries, and often those were pre-populated by the data team who understood the structure of the data. In the cloud, it’s a live stream of datasets in raw format, unstructured by definition. Developers no longer have anyone helping them parse it.
Second, the architecture of how systems and applications are built around data has changed. Specifically, they are now a set of distributed services in the cloud and have to be able to process these large volumes of data. And, they have to be elastic. This bears lots of new complexities that a traditional Java developer didn’t have to think about in the old world of just looking at how many threads does my app need? Now, this whole cluster has to scale up and down with the data that needs to be processed. There are more moving parts, and there’s more complexity.
The skill set that you’re talking about at the traditional Java shop is often not conducive to the architecture models of modern, cloud, and data-centric applications.
DZone: Lightbend has advocated that microservices architectures are really the optimal approach to building streaming data systems. How do enterprises modernizing for data-driven use cases in the cloud typically approach this transition to microservices?
MB: Most enterprises begin by slicing off services, the so-called “strangler pattern,” breaking their monoliths up vertically, service by service, and moving from synchronous to asynchronous in their move to a more cloud-native friendly model.
One of the common perils on this journey is when teams take a monolith and break up the Java code into services with method calls between the services via HTTP over REST. As a result, they just get a very big monolith. That can work with a limited number of services, but you can very easily hit the ceiling when you try to scale.
And, you have the same challenge as you do with streaming — how do you move to async and resilience as a natural piece in the lifecycle of the services? How do you deal with things like having each service have their state fully isolated? And, then, now you can’t use transactions — what do you use? And, what do you use to bring consistency back on a distributed scale? These are the types of challenges that start to arise with streaming data use cases in the cloud.
Once you see this convergence of real-time data into your business applications, the need to embrace failure goes up by a factor. You’re dealing with data that are not persisted; it’s on the fly. And, you need to know that the system keeps processing it. If you can’t because of blocking, you not only have an application that isn’t responding to requests; you have a risk of lost information. That data is a stream — it’s not a SQL query that gets re-run. Clearly, the application gets more complex with these stream-based systems.
MB: Cloud Native Java has a rather loose definition, but it’s trying to distinguish from the old monolithic physical infrastructure world that’s commonly associated with Java. Now, you’re designing from ground-up to run in the cloud, and if that’s true, then what practices do you need to employ? To me, that’s what this Cloud Native Java conversation is about.
Reactive is how you design a modern application to take advantage of unlimited scalability in the cloud. If your application is monolithic, you get none of the advantages of the cloud. Java, if it’s to have a future, needs to understand that you need to do some things differently and in a Reactive manner to take advantage of the cloud, and certainly to be successful with streaming and real-time data-driven uses cases.
Opinions expressed by DZone contributors are their own.