Cloud native application development does rarely have the luxury to select one platform/runtime/language and often necessitates multiple technologies, e.g. serverless, reactive, MicroProfile, etc. How should organizations go about implementing cloud native applications based on all these technologies? Come and learn about the strengths and weaknesses of different cloud native technologies and how you can combine these without sacrificing efficiency, stability and scalability.
MicroServices, MicroProfile, EE4J, & Java EE
With the right tools, building scalable applications can be much easier than it seems. Eclipse MicroProfile allows you to build such applications easily and you get a variety of options to scale them if you add distributed data grids. These can become a backbone for building horizontally scalable services, while at the same time providing flexible caching to scale up their performance vertically.
During 20 years, we have been accustomed to Java EE (previously J2EE) managed by the Java Community Process. Not all of us were fully happy with this situation: we have often been frustrated by its slow process and its sometimes bloated specifications. But at least, it was considered as a long-term standard. In less than 6 months, everything has changed and now, we have Jakarta EE managed by the Eclipse Foundation. Who could have imagined such a change in a short period of time?
So we have recently started moving algorithms to separate microservices from a large Eclipse RCP application (which by the way is tens of millions of lines of code - so we have our work cutout and it will take a long time). It would be great to drop by the conference and show you some of the design of software which we are using to deploy scalable scientific and engineering algorithms using cloud technologies like DCOS and Kubernetes backed by AWS and Azure.
When the Eclipse Microprofile initiative was started in 2016, it only took about three months before version 1.0 was launched. From day one, there were four different implementations from four different vendors available.
And the progress does not stop there! Whereas version 1.0 was a subset of Java EE specifications, the following versions bring additional technologies useful for building microservices.
Current version contains APIs and implementations for:
Conventional wisdom has it that Java EE is a bad starting point for building Java microservices, but conventional thinking isn’t relevant to the new wave of applications. It isn’t that Java EE isn’t a good choice (after all, most microservice frameworks build on parts of it); it’s that it hasn’t been growing fast enough to address the problems microservice architecture presents. Last year several Java EE server companies and Java user groups got together to start the MicroProfile initiative to help kick-start an effort to solve these new problems.
Planning to build microservices? The best practice of building a first-class microservice is to follow 12-Factor app. But how to fulfill the 12-factor app rules, e.g. how to achieve externalise the configuration, fault tolerance, etc? Come to this session to build a 12-factor microservice using MicroProfile programming mode in half an hour with live code demo.
MicroProfile defines Config, Fault Tolerance, Health Check, Metrics, Open Tracing, Open API, JWT security, etc, while Istio has Fault Tolerance, Tracing, etc. Will they conflict to each other? Come to this session to find out the work being planned to build an ecosystem for MicroProfile and Istio and how to make MicroProfile-based microservices the best performed microservices in Istio.
Already we can see and feel that the development of "Java EE" after the contribution to Eclipse will be different from the past. We are seeing enthusiasm and participation from the various teams at an all-time high! But, what will be different after these contributions to EE4J (Eclipse Enterprise for Java) is complete? Come to this session to learn what's changing, besides just the name... :-) I will give you an overview of the projects already transferred and what projects are left. I will also give an overview of the new and updated processes, as well as what processes still need so