Every 10 years or so, the tech industry starts revving its engine for the “next big thing.” There’s the initial debate on technical definitions, a volatile period where first movers define best practices, and then a lot of noise from the vendors trying to sell shovels to the gold rush—and then eventually the dust settles and the new form factor becomes reality.
That’s how it played out with the many different visions of utility computing, grid computing and on demand in the early 00’s that preceded the eventual arrival of cloud. Along that path were endless blueprints and specs that eventually led us to today, where anyone can buy compute, storage, networking and more on the public cloud with a handy credit card.
I think we’re seeing it all happen again today with cloud native.
Cloud native is fresh turf defined by Airbnb, Lyft, Spotify, and other webscale giants who grew so fast so quickly. Their pace of developer innovation revealed a better way of doing things that the rest of the business world now wants to emulate. These companies proved that you can leapfrog competitors with a developer-first company mentality by putting a premium on better features and UX (and applications that are responsive in even the highest volume usage scenarios), and by investing heavily in the combination of streaming data and machine learning as a transformative agent for competitive differentiation.
This cloud native approach led the early pioneers to languages (like Scala) that make it possible to do things that simply weren’t possible in the conventions of other languages. And Lightbend’s vision as a company (founded by Scala language creator Martin Odersky and Reactive Manifesto author and Akka creator Jonas Bonér) has been to make this approach accessible to any enterprise working with JVM languages—especially Java developers.
Along the way, Lightbend sought to fill in requirements in the absence of Java EE itself bringing these Reactive capabilities to cloud native development. From our point of view, Java EE was not well suited for microservices or cloud deployment, and did not provide the Reactive approach that systems designed for streaming data require. Its weaknesses in areas like asynchronous were many, and there was no real evident urgency that the JCP process was on the right path to realizing cloud native capabilities for the platform.
But in late 2017, Oracle turned Java EE over to The Eclipse Foundation—and rather than the fate of Java EE belonging to a closed group of vendors, the charter of its governing body (as Jakarta EE) is to reinvigorate Java’s most popular run-time platform with an open source-first approach, and a commitment to truly putting the community into Jakarta EE. And for anyone whose association with Java EE is big, bloated app servers that are not compatible with the reality of today’s distributed computing use cases—the great news is that the vision for Jakarta is a microservices-first outlook, and a simpler consumption model where enterprises can use the best of the platform without having to use all of it.
So what does all of this mean to Lightbend?
We’re embracing something (Jakarta EE) that we used to want to replace (Java EE). Now the right environment is in place to get involved and reinvigorate a platform that has so much usage, and so much potential.
First, we are so excited by the vision of the Eclipse Foundation and its new governance approach to Jakarta EE that we have joined the foundation. Similar to our ongoing commitment to the JVM, now Lightbend has the working model to contribute to and build around Jakarta EE. Lightbend will work with the Eclipse Foundation and the broader Jakarta EE community in bringing Reactive principles to the platform. Initial areas of focus will include adding new Reactive and stream-based messaging APIs and Servlet 3.1 support for Reactive Streams. This will bring modern stream-native and event-driven programming models to Jakarta EE. These features support persistence models that scale well across distributed systems, such as event sourcing and Command Query and Responsibility Segregation (CQRS). Lightbend is a founding contributor to the Reactive Streams standard, and that experience in streaming and Reactive systems at scale presents a big opportunity for Jakarta EE to be the standard for Reactive enterprise systems.
More broadly, we feel like the industry has the opportunity to work together on Jakarta EE to define what “cloud native Java” means and what it should include. Lightbend has seen firsthand that the major looming modernization effort of this century is all of the critical enterprise systems that were built for an on-prem world - monolithic systems on scale up architecture. Lightbend’s own Markus Eisele cited numerous limitations of Java EE’s capabilities in cloud native in his “Nine Neins” commentary nearly two years ago.
And as Jonas puts it:
“Most people that want to modernize their applications hit the ceiling when it comes to the monolith. The monolith can strangle productivity, time to market, development time, and getting features out to customers. You can reach a threshold where you have to coordinate too many things across too many teams in lock-step, in order to get features rolled out at all, when this happens the whole development organization slows down to halt. This forces many organizations to move to microservices, where they can have autonomous teams delivering features independently of each other.
There are many ways you can do microservices. But the naïve way of chopping up services, turning method calls into synchronous RPC calls, and trying to maintain strong consistency of data across services, maintains the strong coupling that microservices can liberate you from. So, what's wrong with that? What's wrong with it is that you've now paid the technical cost associated with microservices—more expensive communication between components, higher chances and rates of failure—but you haven't got any of the technical benefits. So from this perspective, you're now in a worse off position than you were with the monolith.
If you fully embrace the fact that you now have a distributed system, embrace eventual consistency and asynchronous communication/coordination, then you are in a position to take advantage of the benefits of moving to the cloud: loose coupling, system elasticity and scalability, and a higher degree of availability. Here, an event-driven and reactive design can really help, which is why I believe that Java EE needs to embrace event-driven messaging and reactive.”
So together with Eclipse Foundation and the other member companies steering Jakarta EE, Lightbend will bring our unique experiences to the table, and we will be hammering away at what we believe to be the biggest opportunities for Jakarta EE to evolve to meet these cloud native Java use cases. In our view, microservices, systems built to handle Fast Data as a first class citizen, and systems that are built with Reactive as a primary design consideration are the future of Cloud Native.
Exciting times ahead for Jakarta EE, and Lightbend looks forward to bringing our experience in these areas and our own community of Java and Scala developers to the table to evolve the platform!
