Realizing the Potential of Cloud Native Serverless Jakarta EE

Jakarta EE is well-placed to leverage the strengths of serverless and cloud native processes. But many myths and misconceptions surround these concepts. What do they mean, and how do they apply to Jakarta EE?

In this companion piece to my upcoming EclipseCon talk, I will explain these terms, how they relate to Jakarta EE, and how Payara Cloud provides a Jakarta EE-specific solution.

Cloud Native and Serverless Provide External Infrastructure and Management

Cloud native refers to a way of running applications that “exploits the advantages of the cloud computing delivery model.” The cloud computing delivery model can be understood as infrastructure on demand: infrastructure that you don’t manage, that can expand and contract, and that you can access rapidly. 

This contrasts with alternatives, such as on-premises data centers or virtual machines, where changes to scale take longer and are more difficult to implement. Cloud native exploits this elastic, software-defined infrastructure style.

Serverless, meanwhile, does not refer to a lack of a server, but rather to using a vendor that takes care of server issues on the behalf of customers. Developers concentrate on developing the business-logic code and creating the application itself, though the extent to which infrastructure tasks are dealt with depends on the provider and technology of choice.

In the past, the term “serverless” was applied to using a cloud service — such as Amazon Elastic Beanstalk — to automatically provision the necessary runtime. For this process, you upload your application to the cloud and the service provisions appropriate infrastructure in a way that provides load balancing, scaling, and failover. This, in terms of automating best practices, ensures that your application meets your non-functional requirements.

Serverless has also been used to describe a Function-as-a-Service (FaaS) architecture, such as Amazon AWS Lambda. For this approach, you write functions which contain only your business logic and upload them to the cloud, and then pay per function invocation.

With the above two examples, some of the infrastructure tasks related to a cloud native approach are managed. However, you will still have to undertake significant work to prepare your application. With AWS Lambda, you would have to build an enterprise environment, a VPC, a JAX-RS endpoint, and an API gateway, at the very least.

We would like to introduce a further approach that takes advantage of the way Jakarta EE builds a ready-to-deploy application, separate from infrastructure. 

Jakarta EE Separates Infrastructure From Application Code 

Jakarta EE works differently compared to other frameworks, such as Spring. Jakarta EE is packaged into a standalone Archive file. Your EAR or WAR contains application code, third party application dependencies, and, optionally, deployment descriptors. 

You also don’t have to build your own runtime with Jakarta EE. It works on the principle that the runtime infrastructure will handle tasks like logging, configuration, security, and metrics. Infrastructure code is separated from business-logic code and dealt with by the Jakarta EE runtime.

By separating the infrastructure from the application code, your application can be deployed unaltered in many environments. You can take your WAR or EAR file to many different runtimes and infrastructures, from a Raspberry PI to a cloud, with little to no alteration. This differs from Spring, where the runtime is packaged with the deployment code.

This translates well to a cloud native approach. Your JAR or EAR file is already separate and can be moved to an external infrastructure managed by a provider relatively easily. 

Though containers are not essential to a cloud native approach, they will often be involved, and container images are built from three layers — an operating layer, an application server layer, and the application layer. With Jakarta EE, the application layer is separate from the application server tier. This means containers can be built more quickly and small changes can be made more easily, and rapidly pushed to the cloud.

A microservices architecture is often used with a cloud native approach, though it is possible to have one without the other. This is because it is easier to set up each new microservice/instance in a cloud environment, most of which tend to have specific management options for running several instances, like a centralized dashboard and automatic scaling. 

Jakarta EE is also ready for the wider adoption of microservices, with the MicroProfile project (also stewarded by the Eclipse Foundation) producing a set of specifications designed to complement Jakarta EE, which provides the functionality commonly needed when developing microservices. 

Payara Cloud Bridges the Gap Between Jakarta EE and Serverless Deployment

With a cloud native approach, though, there are still tasks involved with moving and managing your application onto an external infrastructure, including: 

• Provisioning the Kubernetes resources
• Setting up the routing and networking aspects 
• Providing the SSL certificate for your endpoints

A serverless approach involves using external software to manage some of these tasks. If you are already avoiding infrastructure tasks by choosing Jakarta EE, it is also likely you will want to avoid these infrastructure tasks when they relate to the cloud. 

Payara Cloud is a new serverless approach, where most tasks are managed for you. All you have to do is deploy your WAR file, as you would deploy to your Jakarta EE runtime — only this time, the tasks related to a cloud native approach are also dealt with. 

Payara Cloud runs on Microsoft Azure, building a runtime on Azure Kubernetes Service. The software takes the user’s WAR file, packages it into a Docker image with Payara Micro — our microservices runtime — and completes all YAML, builds container images, creates a pod, deploys it on Kubernetes, updates the API server to manage ingress on Microsoft Azure, and even creates an SSL certificate for the application. 

You can then integrate this with your external Kubernetes platform, whether that’s OpenShift, Rancher, or Kubernetes itself. 

Overall, Payara Cloud delivers a more comprehensive serverless experience, where more of the infrastructural tasks are handled for you. 

See a Payara Cloud Demo at EclipseCon

A key Jakarta EE concept is of a deployable application that’s isolated from infrastructure. It makes sense to extend this for a cloud native world and automate the processes involved with moving to an external infrastructure. 

Payara Cloud is a way to do this, further shielding your developers from the time-consuming infrastructure tasks, and freeing up time to write business code. 

Find out more in my talk at EclipseCon — on Tuesday, October 25 at 2:30 p.m. — where I will provide a demo of Payara Cloud to show just how easy the process is.