
Throughput was less of a concern, and we found it roughly the same after making the jump. These gains made native Java an ideal fit for environments where size and startup times were crucial, both in cost and performance.

Containers were less than 50MB (compressed) in size and ready to accept requests in less than 1 second. Startup times averaged 15-30 seconds, and only a handful could be run per node due to already tight resource constraints.Īfter moving to Quarkus, the native executables produced were notably smaller, started significantly faster, and used fewer resources overall. Regardless of functionality, containers were always ~1GB+ in size because they needed a JVM and included a full set of dependencies (used or not). Our platform, originally developed using Spring Boot and Drools, has been redesigned from the ground up to use only Quarkus and Kogito and deploy mostly native Java executables.īefore switching to native Java, running an increasing number of Spring Boot services in a cloud-native infrastructure was becoming challenging, not to mention costly, at scale. Logicdrop develops an all-in-one platform for business automation and data intelligence that enables enterprises to design and deploy their own solutions into the cloud. Making the move may seem overwhelming at first, but it is not that different from traditional Java development today. This approach minimizes risk and will help build confidence as the technology further matures over time.

It is also the ideal opportunity when developing new services or breaking apart larger monolith applications into smaller services.Īdopting native Java does not have to be a "big bang" approach - it can be done one service at a time.

Native Java is the perfect fit for Kubernetes, microservices, and serverless components.
