Microframework to Microprofile
In the old days of JBoss and WebSphere, Spring was considered the speedy framework. If you wanted a full-blown application server you went with JBoss. Spring came along and gave us a customized lightweight framework to do our work.
In the meantime, spring got to be a very big framework, and lightweight is always relative. With spring boot the boot time went up, so now we are looking for faster frameworks. In addition, in the new world of lambda functions, we need frameworks that boot up very quickly.
To name just a few microframeworks, there are javaspark, Javalin, Ratpack, DropWizard (head over to https://en.wikipedia.org/wiki/Microframework for a bigger list).
So what are microframeworks? Usually, they are a bare framework for a rest server, according to Wikipedia: minimalistic web application frameworks. Each one has its own flavor: some have a reactive patterns for defining endpoints, some added integrated metrics.
Microservice Architecture has become very common in most companies. The big question is of course what is a microservice. From the site microservices.io, this is the summary:
Microservices - also known as the microservice architecture - is an architectural style that structures an application as a collection of services that are
Highly maintainable and testable
Organized around business capabilities
Owned by a small team
The main issue is that up till now, all the discussions of microservices were about the size and the independence of the service (deployment and development). What was not covered well is the minimum requirement of the service for monitoring and orchestration. Kubernetis gave to docker a standard way of distributed deployment and scale. A similar framework for viewing all services via a single lense was missing.
Microprofile is a spec that defines the minimum requirements of a services so that open frameworks can monitor and configure all services equally. I would say this is the EJB version for microservices.
The mission is:
An open forum to optimize Enterprise Java for a microservices architecture by innovating across multiple implementations and collaborating on common areas of interest with a goal of standardization (https://microprofile.io/).
So what areas does the microprofile cover? Each version of the microprofile more areas are added. Currently, the basic API’s that your service needs to implement in order to be part of the microprofile spec is:
As you can see, this is the minimum issue that every microserver needs to address.
I would split the spec into two areas. One is for the developer: Rest Client, CDI, JSON, JAX_RS. The second area is for deployment & monitoring: Tracing, API, Config, Metrics, JWT, Health.
The current spec is only for the JDK(since it started in Jakarta). In a world of polyglot, I would have liked the spec to be split into the two sections I mentioned above so that other languages can join the spec. I always felt that systems like GO and python were behind java when coming to integration specs, and now is the time to create a cross-language spec (and for graalvm enthusiasts, I don’t think this is the solution).
For an answer from the eclipse workgroup see: Poloyglot: Kevin Sutter.
Since the microprofile spec is just the api, it is expected that there will be multiple implementations. The major ones are: Helidon, Thorntail, SmallRye (for a list of vendors and specs see: https://wiki.eclipse.org/MicroProfile/Implementation). In addition if you want to start using the microprofiles, see the starter web site: https://start.microprofile.io/.
Microprofile vs spring
As mentioned, spring is currently behind, but would expect to see a try for a comeback. For a full comparison of the microprofile spec and spring see: Building Cloud Native Microservices? Which Programming Model Should I Use.
We will contact you as soon as possible.