Industry executives and experts share their predictions for 2018.  Read them in this 10th annual VMblog.com series exclusive.

Contributed by Mark Brewer is the CEO of Lightbend, Inc.

Java EE Goes Cloud Native in 2018 with Reactive

1. Java EE will get more Reactive

There has been a noticeable disconnect between the conversations happening in the cloud-native camp and the Java EE camp in recent years. Java EE is basically a poor specification for cloud-based deployments. It assumes physical infrastructure - that you're running on defined servers. The old Java specification did not assume bursts of traffic and resources in the cloud that grow and shrink on demand. Java EE was not designed to be truly distributed -- its concept of clustering was little more than a way to create a gigantic monolith, as opposed to pushing workloads out as needed and letting those resources be utilized ‘on-demand'. And Java EE was designed to be blocking and stateful, and introduced some performance and scale issues along those lines. The web-scale companies that pioneered distributed computing in the cloud turned to containers and home-built container orchestration (like Google Borg, which ultimately inspired Kubernetes).

But with efforts like Java EE MicroProfile, the Java EE community is really working to accelerate this process of making Java EE relevant in cloud-native architectures. MicroProfile is basically a bridge to making Java systems compatible with microservices architectures, and companies like Lightbend are getting involved to provide implementations leveraging our microservices platform, Lagom. Now that Eclipse Foundation is the steward of Java EE we see a lot of leaders in the Reactive movement working together to bridge this old on-prem / legacy monolith world to the new world of distributed workloads in cloud-native architectures.  With the inclusion of Reactive Streams in JDK 9, the Java community and specification have taken a significant step towards Reactive.

2. Container, Java and Reactive worlds will collide

Containers and cloud-native often presume bare-metal servers, no JVM, and polyglot development. As cloud-native has taken flight as the way the big tech companies and startups in Silicon Valley build new distributed applications, there have been many unanswered questions from the Java community about how to best participate in this new world of modern application design and operations.

Here's why this will change in 2018 and beyond. First, the hardening of microservices frameworks and architectures--and their creeping into Java EE via MicroProfiles--is making it possible for enterprises to target legacy Java monoliths, to deconstruct them as microservices and run them in the cloud. This will be a huge disruptive force as the massive installed base of Java shops in all industries target these previously inflexible systems and make them more flexible with the cloud-native development styles happening with the net new systems and applications that are being designed in enterprise. The container format itself has matured. The writing's on the wall and near consensus opinion is out that Kubernetes has won at the orchestration layer. So the operational predictability that Kubernetes and containers provide at the server / cluster infrastructure level, and the elasticity, resilience and responsiveness of Reactive system design at the application infrastructure level are the future. And the next big domino that will fall in this evolution will be microservices being pointed at the inflexible Java monolithic applications in production at enterprises that have--to date--felt sidelined in the move to the cloud, but who now have a clear path.

3. The future will be containers and monoliths, Reactive and not Reactive, batch and streaming

The tech industry loves to create false dichotomies. While I believe we are indeed in the early stages of the biggest re-platforming the tech industry has ever seen (on containers, Kubernetes, Microservices and streaming data)--I think what we're really going to see come to light in 2018 is that many legacy applications and systems are running very well in their current form, and that companies are interested to extend their lives, rather than gut or replace them.

We can't be so dogmatic that Reactive is the only way, that containers are the only way, or real-time / streaming is the only way. We're going to see cases where the big Java monolith that's been running billions of financial transactions for 10 years survives--but some of its core services are re-written as microservices to make it easier to reason with, with new applications. We're going to see containerized workloads and virtual machine workloads. And some business answers don't need to be provided in a split-second, where batch jobs on Hadoop will do just fine for the foreseeable future. This big replatforming will target the net new applications and systems being designed, but another crucial component will be how to keep old systems humming, and extract maximum value out of those previous investments.

##

About the Author

Mark Brewer is the CEO of Lightbend, Inc. Brewer most recently served as Vice President of Business Operations for VMware's Cloud Application Platform, where he helped build out their cloud application platform portfolio. Prior to VMware, he was Vice President and General Manager of Enterprise Services at SpringSource, where he was responsible for the packaging and delivery of SpringSource's enterprise (subscription) offerings. Before SpringSource, Brewer was CEO of Covalent Technologies. Brewer also participates as Board Member for several open source technology companies, including Stormpath, LucidWorks and ActiveState. He holds a Bachelors of Science degree from Western Washington University.