One major issue when developing modern enterprise applications is the "works on my machine" problem: when an application works well on your machine but is not functional in production or even on a colleague's machine. An even more prevalent problem is to maintain the quality of ever-changing applications during development and maintenance. 

This is especially prevalent when Jakarta EE applications are developed and not properly tested in an isolated and cohesive manner. Proper integration testing helps to avoid both the "works on my machine" problem, and ensures developers can change the application effectively without breaking it. However often teams struggle with it, due to a lack of standardized testing solutions and the unpredictability of real-world conditions. 

Here, I present an effective method for Jakarta EE integration testing, using Payara Platform and Testcontainers in my example.

We are launching a new video series: Quick Fire Java with Payara! The first episode sees Payara Product Manager, Rudy De Busscher, discuss "Hype-Driven Development"; software investments based on "buzz" around a trend or product, rather than whether it actually works for your specific use case. 

We are all familiar with Microsoft Azure, Google's GCP, or Amazon's AWS platform for running applications in a public cloud. But there are also other, lesser-known platforms like Alibaba Cloud.  And while many don't know this platform, it is by far the largest one in the Asia Pacific region and even the third largest cloud provider worldwide. Alibaba Cloud has some interesting features.

In this blog, we explore some aspects of the platform and how it can be used with the Payara Platform.

As part of Closed Beta testing, we offeredJakarta EEexpert, Java Champion,bloggerand podcaster,Adam Biena trial of our next-generation cloud-native application runtime,  Payara Cloud. 

He went on to discuss Payara Cloud as an alternative to HelidonandQuarkus; a 'serverless server'. He included it in hisMid-Year 2021 Observations and Reflectionsand created a video with hisinitial thoughts. Read our previous blog, rounding up his comments so far,here.

At theJ4Kconference this year, he went into further detail. He told viewers:“I really like the idea [of Payara Cloud]. Why? Because it is the opposite of where everyone is going with smaller and smaller runtimes, you can go that route or another route.” You can now view the video of this talk to watch him demonstrate Payara Cloud live and see how he reached this conclusion.  

Adam Bien is a well-known expert in the world ofJakarta EE. He is a freelancer, author, Java Champion andblogger, providing resources and training materials, and is host of theAirHacks.FM podcast - where he regularly talks to the leading experts in the Java and Jakarta EE community, with recent guests including PayaransLenny PrimakandRudy De Busscher. 

As a long time user of the Payara Platform - regularlyrecommending it as a solution to GlassFish problems - we were keen to offer him a trial ofPayara Cloud, our next generation of cloud-native application runtime. Payara Cloud offers an easier way to run Jakarta EE apps on the cloud, allowing you to simply select your war, click deploy, and watch your apps run - automatically, like magic!

As part of our Payara Cloud Closed Beta testing, we offered him a trial of the software. He created a concise video showing his experience using serverless MicroProfile and Jakarta EE on Payara Cloud. Watch it now to find out what his first thoughts were in his own words.  

There is a lot of interest in the server-side Java community around using ahead of time (AOT) native compilation provided by Graal Substrate VM to drive down memory usage and cold start times of Java microservices. While these frameworks are technically interesting, the claim is if you spend time rewriting your Jakarta EE applications to utilise these new frameworks, then you will substantially reduce your cloud operational costs. First, by enabling the adoption of a serverless deployment model and second by reducing your containers' memory usage. 

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.

Microservices architecture allows developers to apply best practices for larger systems learned over time with containerized Jakarta EE (Java EE) application deployments in any environment: on premise, in the cloud, or hybrid.  Using Payara Micro in the cloud offers benefits ranging from reduced expenses, seamless integration with cloud platforms and tools for management and automation, to automatic and elastic clustering. 

All companies are software companies, and businesses will always experience the challenge of keeping integrations between users and applications scalable, productive, fast, and of high quality. To combat this, cloud, microservices, and other modern solutions come up more and more in architectural decisions.

Here is the question: Is Java prepared to deal with these diverse concepts in a corporate environment?

Yes, and to demonstrate how Jakarta EE and Eclipse MicroProfile work very well and in the cloud, the Payara and Platform.sh will work together on this webinar. Watch and make your conclusions.

All companies are software companies, and businesses will always experience the challenge of keeping integrations between users and applications scalable, productive, fast, and of high quality. To combat this, cloud, microservices, and other modern solutions come up more and more in architectural decisions. Here is the question: Is Java prepared to deal with these diverse concepts in a corporate environment?