
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.