The migration of Java EE to Jakarta EE, in vendor-independent Eclipse Foundation stewardship, was meant to usher in a new era of open standards and community-driven enterprise Java. It resulted in freeing the platform from the exclusive grip of Oracle, and laying bare Java’s destiny as enterprise-friendly open-source.
But moving the underlying specs to a vendor-independent platform didn’t somehow eliminate cloud deployment problems. Cloud Vendor Lock-in is the new, evil problem Jakarta EE developers creating Jakarta EE applications have to deal with these days. While the standards themselves are open, the platform ecosystem on which to deploy cutting-edge, scalable Jakarta EE services leaves the developers reliant on proprietary cloud providers once more.
The Illusion of Vendor Neutrality
Jakarta EE’s best achievement was the deliberate shift in governance. This was because Java Community Process (JCP) was slow to move and paternalistic and required Oracle-led commercial direction.
- The Name Change: The name change from
javax.*tojakarta.*packages was not just rebranding but a symbolic as well as legal clean break, allowing the platform to change faster with contributions from organizations like IBM, Red Hat, and Microsoft. - True Open Source: It allowed quick innovation on specs of interest to cloud-native development (e.g., Jakarta RESTful Web Services, Jakarta Security, and Jakarta Convergence). The specs are open to see, may be implemented for free, and do not lock into technology at the code level.
But with cloud computing, vendor neutrality is no longer code-defined.
The Cloud Lock-in Challenge
When a Jakarta EE developer deploys a Jakarta EE application onto a big cloud platform (e.g., AWS, Azure, or Google Cloud), they immediately encounter extremely proprietary tools and services, while the application has been written based on open standards.
1. Proprietary Abstractions (The Platform-as-a-Service Layer)
To deploy an application correctly, developers are invited to take advantage of the cloud platform’s proprietary services:
- Managed Services: Instead of hosting a Jakarta EE application server (like WildFly or Open Liberty) on a bare virtual machine, developers are driven towards using Managed Services (like some managed Kubernetes environments, or vendor-specific capabilities). The managed ones are more maintenance and cost-optimized but are based on unique APIs and configuration specific to that particular cloud provider.
- Messaging and Data: Jakarta EE applications today extensively interact with cloud-native data storage (private NoSQL stores) or message queues (e.g., AWS SQS or Azure Service Bus). Although Jakarta EE specs target the interface (e.g., Jakarta Messaging), setup of the underlying infrastructure—and hence the performance tuning—is highly cloud provider–dependent.
2. The Kubernetes Trade-off
Whereas Kubernetes is usually the vendor-agnostic platform of choice par excellence, even its use remains heavily customized by cloud providers (e.g., Azure AKS, Amazon EKS). A Jakarta EE container travels through proprietary networking features, load balancer, security rules, and service mesh integration which pose migration problems.
Complete Jakarta EE platform re-hosting (monitoring, scaling policies, and logging) from the first cloud provider to the second cloud provider entails substantial rework akin to de facto lock-in at the operations and infrastructure level.
Charting the New Landscape
Best strategic benefit with Jakarta EE for application developers equates to responsible stewardship so that one would not replace Java EE lock-in with cloud lock-in:
- Vendor-Specific Code Isolated: Vendors ought to be permitted appropriate usage of proprietary cloud APIs, isolated into suitable modules or interfaces. This minimizes the rewrite that must be done in the event of any future migration.
- Emphasis on Portability: Leverage open-source platforms like Docker and Kubernetes regardless of the cloud-vendor’s most abstracted, managed solutions. Utilizing open application servers like Open Liberty or Quarkus, which are hyper-optimized for startup and memory usage performance, can allow your Java code to run portably on any runtime container.
- Adopt Multi-Cloud Strategies: Architecture to support numerous cloud providers from the very beginning, even though only one will be used at first. This places the application of shared, vendor-independent infrastructure tools and practices.
Jakarta EE succeeded in freeing the code. The community must now also free the cloud implementation.