IoT, virtual reality, blockchain, AI and machine learning are the software solutions of the future. All of these apps produce and consume tons of data. The amount of data is now exploading lika a data big bang. Two factors are most critical for all of these apps: best possible performance, and lowest data storage costs. Today's database systems struggle to keep pace, are very expensive in the cloud and challenging with cloud-native microservices and serverless architectures.
Innovation in the cloud-era is about driving efficiencies, agility, and greater opportunities to deploy workloads to the cloud of your choice. Join us as we explore critical challenges faced by organizations in their move to cloud-native architectures along with the innovation in Java standards, including MicroProfile and Jakarta EE, and emerging technologies that help them build and deploy their applications on any cloud, faster and with better performance.
Jakarta gRPC aims to do for Java gRPC services what JAX-RS did for REST: it makes them easier to implement, by allowing developers to annotate service classes and methods, and by generating client-side proxies automatically, based on the annotated Java interface. It also allows them to integrate and play nicely with other Jakarta specs, such as CDI and Config, which is something native, proto-based gRPC services do not do very well.
A long time ago in a java galaxy not far far away, a war rages for years now. A war between the forces of the monoliths and the microservices, leaving untold numbers of Developers and DevOps frustrated in their wake and whole teams and projects devestated. In between these heated conflict, the Microliths and Microservice Monoliths want to brin reason but only achieve more confusion and suffering...
There is hope though and some real world beacons can show the galaxy how peace and equalibirium can be achieved!
Microservices are used more and more but many of them need to access data. Using a database is well established but also slow as data need to be retrieved from an external system in another format and structure and thus requires a mapping.
How does one choose to architect a system that has a Microservice / REST API endpoints? There are many solutions out there. Some are better than others. Should state be held in a server side component, or externally? Generally we are told this is not a good practice for a Cloud Native system, when the 12-factor guidelines seem to be all about stateless containers, but is it?
Microservices have become a prevalent architectural approach to developing applications. Moving from a monolithic application to multiple container-based services has many advantages. One of the largest is dynamic scalability; spinning up and shutting down instances of services to adapt to dynamic loads is very cost-effective in a public cloud environment.
For JVM-based applications, running in a managed environment using JIT compilation, this provides additional challenges. Primarily, this is around the time required for a service to warm up and reach the optimum level of performance. To address this, we have seen various approaches such as the Graal VM and Quarkus that use an AOT approach rather than JIT compilation.
In this session, we will explore the pros and cons of both approaches to help in understanding the tradeoff between initial performance and overall
performance. At the end of the session, you will have a clear idea of how to approach your Java microservice design from the AOT and JIT perspective.