What happens when an application designed for a small user base needs to be scaled up and moved to the cloud?

It needs to live in a distributed environment: responding to an appropriate number of concurrent user requests per second and ensuring users find the application reliable. 

Though Jakarta EE and Eclipse MicroProfile can help with reliable clustering, there is no standard API in Jakarta EE that defines how clustering should work currently. This might change in the future, but in the meantime, this gap must be filled by DevOps engineers.

In this blog, we will cover 10 technical strategies to deal with clustering challenges when developing Jakarta EE and MicroProfile for cloud environments.

Encryption of the data stored within the data grid of Hazelcast (the technology underpinning our deployment groups and clustering in Payara Platform 5) has until now required a Hazelcast Enterprise subscription (see Payara Scales). While this remains an option for those who would like the additional features it provides (such as WAN replication), we’ve begun introducing this particular feature into Payara Server itself to provide it to you without needing an additional subscription.

In Payara Server 5 we will be introducing some major changes to the way clustering is working by creating the Domain Data Grid (see documentation for more info). The Domain Data Grid will be easier to use, more scalable, more flexible and ideally suited for cloud environments and cloud-native architectures. All Payara Server instances will join a single domain-wide data grid for sharing of in-memory data like web sessions, JCache, SSO and Stateful EJBs. 

Taking our introductory series onwards, this blog will look at how you set up a simple Payara Server cluster on Windows using the native remote control protocol, DCOM. We will set up two instances on Windows 10, controlled by a third Domain Administration Server (DAS) instance on Windows 7 via DCOM, and cluster them together using Hazelcast. Finally, we will deploy our trusty clusterjsp application to demonstrate how the data is being shared across our instances.

In order to make a cluster of servers appear as one server, you need to introduce a load balancer. A load balancer will accept a request, and redirect it to one of the members of the cluster depending on a given configuration. A web server such as NGINX or Apache can act as this load balancer as well as a reverse proxy, which allows the web server to load balance requests across the cluster, act as a termination point for SSL connections to reduce strain on the cluster, as well as cache server content for quicker access. In this blog, we will set up NGINX as a reverse proxy and secure it using SSL.

Continuing our introductory blog series, this blog will demonstrate how to add load balancing capability to Apache Web Server and forward to our simple Payara Server cluster. 

A load balancer can redirect requests to multiple instances, primarily for the purpose of distributing incoming requests between cluster members based on pre-determined rules. This could be a simple "round-robin" algorithm, where the workload is distributed to each instance in turn, or a weighted algorithm where requests are delivered based on a pre-determined weight for each cluster member.

Continuando con nuestra serie de blogs de introducción, este blog va a demostrar como añadir la capacidades de balanceo de carga a un Servidor Web Apache y asi re-enviar las peticiones HTTP a nuestro cluster de Payara Server.

Kick-starting yet another year, we are pleased to announce our largest release yet - Payara Server 4.1.1.171. Building on a year's worth of updates and improvements, in this release, you can find 18 brand new features and over 60 new fixes and enhancements for Payara Server & Payara Micro! Given the size of the additions, look out for detailed blogs in the near future. For now, check out below for a summary of the changes in 171 release, and have a look at the full release notes.

In our continuing series on alternatives for commercial Oracle GlassFish features , in this article we are looking at Hazelcast - a replacement for Oracle's Coherence ActiveCache.

Any project, large or small, would ultimately like to follow industry best practices, such as continuous deployment.  In order to support this, applications must be deployed early and often.  This, in turn, triggers downtime and the users get affected by it because they could be logged out of the website, or worse, their work gets lost because the application's intermediate state is not saved - never mind the actual downtime during the application deployment process.

Rolling upgrades solve this problem in an efficient way!