This blog aims to give you a short overview of Hybrid Cloud, its benefits and limitations, how to tackle these limitations and finally - why the Payara Platform is the right choice if you are thinking about migrating your business to Hybrid Cloud.

An increasing number of organisations have moved, or are planning to move, to cloud-based hosting and are developing their applications to run in the cloud. However, once it's decided that your next application is going to run in the cloud, there are still a lot of architectural choices ahead of you. Besides obvious benefits like cost reduction, scalability and easier administration, cloud environments bring their own disadvantages and potential risks. In this blog, I'll share with you some tips on how to take care of the most important disadvantages and risks when you decide to build your applications for the cloud.

We will look at the various options for running your application:

Whilst cost is an important consideration when choosing a cloud provider, there are other things that you need to take into consideration before making your decision. To help, here are the top 5 tips for choosing the right cloud provider for projects based on Payara Server or Payara Micro and your business needs.

It is now common knowledge that there are considerable advantages to moving your applications to the cloud. From improving resource usage and agility to lowering operational costs, the cloud can provide your organisation with a competitive edge. 

One of our key goals for the Payara Platform is to enable developers to use the Java EE skills they have honed over many years to take advantage of new infrastructure, architectures and programming models. We fundamentally believe that a managed runtime platform combined with industry standard APIs like Java EE and in the future Jakarta EE is a perfect fit for cloud and containerized infrastructure. Java EE has always separated the development of applications from the construction and management of the infrastructure to run those applications using the concept of deployment artifacts. This has a natural fit to cloud and container platforms including in the future serverless models.

It may be hard to believe in 2018, but there was once a time before Amazon Web Services. In 2006, Amazon launched what was to become the most dominant platform in cloud computing - the Elastic Compute Cloud (EC2). While there were a lot of early adopters who could see the benefits of "Infrastructure as a Service" (IaaS) style cloud computing - a notable example being Dropbox - there were many who were sceptical of the hype around the "cloud" and prompted stickers like the one pictured.

Our Payara Engineers have been working very hard on lots of new features ready for our final 5.181 release! One of the key features we intend to deliver is compatibility with MicroProfile 1.2, which will include (among other things) a Fault Tolerance API.

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. 

Payara Micro supports Hazelcast out of the box, and can be used for clustering. This allows members in the cluster to distribute data between themselves, amongst other things. By default, Hazelcast comes with multiple ways to discover other members in the same network. A multicast discovery strategy is commonly used for this purpose; a multicast request is sent to all members in a network and the members respond with their IP addresses. Another strategy must be employed if a member cannot or does not wish to provide their IP address.

Both Payara Server and Payara Micro can cluster together and share data using Hazelcast. Out-of-the-box, there is no configuration needed, since Hazelcast uses multicast to discover and join other cluster members. However, when running in cloud environments like AWS, for example, there are a lot of things which can stop discovery being quite so straightforward. The key thing is that Multicast is not available, meaning another discovery strategy is needed; the most common generic alternative is to use TCP, but this assumes that you know at least the intended subnet that your cluster members will be in ahead of time.