Microprofile positioning and goals

[Hristo Stoyanov]

Hello,

I wanted to bring for discussion a couple of thoughts on Eclipse Microprofile posture, marketing and reality:

1. Eclipse Microprofile is not for building microservices only!

I see a lot of member of this community doing MP talks that always start with microservices and then link Eclipse Microprofile to microservices. There are 2 problems with this approach:

 a. Many "down-in-the-trenches" developers (myself included) use Eclipse Microprofile for traditional monolithic web apps. For many of us, Eclipse Microprofile is just a high-quality, fast-pace release cycles,  community driven effort to replace Spring, Java EE (no longer developed) and Jakarta EE(not even started). It is the quality of the APIs and the thorough and passionate community discussion that matters and attracts, nothing to do with microservices.

 b. Microservices are controversial, there is "no free lunch" with them and unless you are Google, Neflix or Facebook, you are just fine without them. Many consider them the latest buzz-word soon to pass, as we have seen so many times in the past and currently (CORBA, SOA, ESB .. blockchain, AI). By narrowing down Eclipse Microprofile to just Microservices, we are potentially giving a bad name to this genuinely good community effort.

2. To some degree, Microservices are a poor substitute for the lack of modularization in Java until version 9.

This is revelation comes from Sander Mak, the author of "Java 9 Modularity" book. The conclusion is, therefore, that embracing Java 9 JPMS will solve many of the problems developers resort to Microservices for today.

So, what is the thinking of the Eclipse Microprofile community on modularization? I have not seen anything discussed in this forum. The current state is as follows:

- Every vendor MP sticks to its old legacy proprietary module system for internal modularization. This forces developers to deal with it when it comes to packaging their app + server bits in a Docker image. This is something already addressed by Java 9 JLink.

- Developers are left with JARs or WARS, or the legacy Java EE formats (EAR, RAR, etc where the platform allows to mix Microprofile and Java EE - openliberty,payara for example)

Ideally, the MP community could aggressively embrace Java 9 JPMS, move away from the vendor-specific modules and Java EE legacy Matryoshka-style packaging (e.g. jar in the war in the ear .. ) and remove the distinction between server vendor's and developer's modules. This would open new opportunities to package (minimal) Java apps for containers and simplifies devops a lot.

... Just my 2c

[Cameron McKenzie]

Sounds like a good article for TheServerSide. Anyone know the editor?

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/004ba273-6900-44c6-bc2e-d628f6ac372d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[m.reza.rahman]

I definitely agree it would be a killer feature for Java EE vendors to embrace JPMS as another deployment model.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

[Ondro Mihályi]

I'm not sure how JPMS can replace WAR or EAR packaging, I would be interested in learning more about this.

Apart from that, I agree with you that MicroProfile is relevant for any usecase and not only for Microservices. The proof is that OpenLiberty and Payara add it to complement Java EE and I know that many users do combine it with Java EE. However, most MicrpProfile features were inspired by real problems with MicroServices, so MicroServices usecase is really what drives the development of MicroProfile. The reason why MicroProfile is applicable to other usecases is that we think a lot beyond MicroServices when working on the specifications. And for marketing purposes, it's easier to focus on a distinguishing feature like focus on Microservices than just claim that MicroProfile is better than other frameworks.

If you think that there very few MicroProfile talks addressing other areas, it's a good feedback for those submitting MicroProfile talks. However, many conferences are very likely to accept talks around MicroServices so even if there are more submissions for non-microservice talks, it's not guarranteed that they will be picked by session committees.

Here are some examples of non-microservice MicroProfile talks:

• At OC One about Metrics (in both monoliths and distributed apps)
• At OC One about Jakarta EE and MP
• At OC One about MP and reactive streams
• At OC One about reactive programming and MP
• At OC One about Config JSR inspired by MP Config
• At JCON: "Distributed Monitoring with MicroProfile Metrics, PCP and Prometheus" Day 2

But it's true they I found even more talks related to MicroServices. I don't know whether this is because there aren't enough submissions or because conferences tend to accept more talks about microservices.

[Cameron McKenzie]

Well, I think the project does indeed have a branding or marketing problem that needs to be addressed in terms of the positioning of the MicroProfile. I'd be more than happy to help out with that.

More than just microservices?

 

First, the project name includes the word 'Micro.' Today, any time someone hears Micro they think MicroServices. I certainly do. Is the MicroProfile designed specifically for developing and deploying microservices? I think that is definitely the impression most passing observers have, and I don't recall anything out in the wild today that does much to dissuade people from that opinion. Anytime I hear about MP, it's about a RESTful web services packaged up in Docker and deployed to the cloud.

 

What does the 'micro' in 'MicroProfile' mean?

Or does the term 'micro' in the project's name just refer to the platform, indicating it is small and lightweight and a good base for everything? If that's the case, that message is not getting out there to the community.

 

When I open the Eclipse MicroProfile document from the site's landing page, I see a document that talks about JAX-RS, CDI, and REST. It would indicate to me that you shouldn't even be creating a SOAP based web services with MicroProfile, but only REST based ones. Can I be blamed for jumping to that conclusion?

 

And how do you add JSF to an MP project? How do you add Java MVC? It would look to the casual observer like it's not supported. Or is the idea that people should use the MicroProfile and simply add the version of JSF they want to use to the POM and off they go? Same with JAX-RS? 

 

In fairness, Spring Boot suffers a bit of the same problem. I published an article recently on creating a Spring MVC app using Spring Boot and people seemed surprised that you could use Spring Boot for something other than microservices. I'd be happy to write the same article using MicroProfile and JSF? Or maybe Java MVC (JSR-371)? But what would be the right way to do it?

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/adc62c87-1b07-4922-acfd-4f80670edd7d%40googlegroups.com.

[Markus Eisele]

Hi Cameron,

I believe you pointed out a couple of important things that will become more relevant with the Jakarta EE specification gaining more traction.

I've always though about the Microprofile as a 'Micro' specification. Something that gives you a suitable runtime for container deployments. Somehow the working version of the web profile. Turns out it also can serve microservices within a certain architecture. And the intent was for sure to complete the missing 'outer architecture' pieces for this to become more easier. E.g. Configuration et al.

I think it would be more than interesting to explore the positioning of microprofile together with Jakarta EE and as a standalone effort.

If you need a helping hand, I'd be happy to contribute.

M

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/adc62c87-1b07-4922-acfd-4f80670edd7d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAJgnatHPsgNgT9nqMf1aDF86ytXkihkWGkL%3D6JyVcZ8nbSLUSw%40mail.gmail.com.

[Mark Little]

People can google for more but as at least one other person on this thread pointed out, microservices is what pushed various vendors and Java community members to kickoff MicroProfile (https://microprofile.io/faq) even before it became Eclipse MicroProfile (https://projects.eclipse.org/proposals/eclipse-microprofile). There’s lots of information out there and I don’t agree that we have a “branding problem”. Clearly MP can be used for other use cases but microservices with enterprise Java is the main thrust.

Mark.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAKYV%3D%2B92juFaxzf7-ReGQrQxGys9NXnrwLZp%2BOM_115K_O4NOA%40mail.gmail.com.

[Andy Guibert]

Thanks for bringing up these questions Hirsto! 

>  To some degree, Microservices are a poor substitute for the lack of modularization in Java until version 9.

Java 9 modularization (JPMS) is for modularization within a single JVM, whereas microservices are for modularization across multi JVM/machine applications.  I don't see microservices and JPMS interfering with each other in any way, since they solve different problems.  I would argue that if people are able to replace their microservice architecture with Java 9 modules, they had added needless latency/complexity to their overall system with microservices, and never should have adopted microservices in the first place.  

I do think that it is valid to use microservices and JPMS at the same time, so we should look for ways that MP/JEE can embrace JPMS. However, based on my experience with JPMS, it will not add much value in an application server environment since the MP/JEE APIs are already separated out from implementations and provided by app servers.  Additionally, in OpenLiberty the API/impls already have the same degree of encapsulation that JPMS would offer, and I'm sure other app servers do the same.

One way I can see JPMS helping out is in the "reliable configuration" aspect.  Currently, vendors either provide all functionality all the time (has negative performance impact), or they allow you to explicitly define which APIs you want in some vendor-specific way.  In OpenLiberty you do that by enabling features in the server.xml.  If apps leveraged JPMS, we could use the module-info descriptor as a way to flag dependencies on various pieces of functionality in a non-vendor-specific way.  For example:

module com.example.app {

    // Suppose we have these well-defined module names for JAX-RS, CDI, and MP-Config

    requires javax.ws.rs;

    requires javax.enterprise.inject;

    requires org.eclipse.microprofile.config;

}

Then, an application server could inspect the module-info of this application and see that it requires JAX-RS, CDI, and MP-Config capabilities.

As for application packaging, I think it would be nice if we can continue to move away from EAR/RAR formats, and more toward JAR format.  Right now most applications can be deployed as WAR files, which is sort of a happy medium IMO.  The Java ecosystem has strong tooling support for building WAR files, and Java EE 7+ has really reduced the need for special XML descriptor files.

[Hristo Stoyanov]

Cameron,

Thanks for sharing your thoughts ... 

In my case, I don't use JSF/MVC. Many developers stopped using them as well. I use GWT/Errai, which lead to a very modern  SPA app, while staying 100% in Java. (Side note: I wish Google/Red Hat did better job of promoting GWT/J2CL/Errai in the Java enterprise community, so that Java developers can compete better agains no-Java client-side technologies such as Angular and React)

I also tend to use OrientDB for a database thus avoiding the need for JPA. 

I guess this gives somewhat the biased impression that you can develop a traditional web app by simply using what is included in MP. But it is possible!

I do struggle with limitations of MP though - soon I will need Concurrency (which  is why I follow the MP Concurrency thread). I had to resort to JCA to add OrientDB since MP lack standard way of adding server components (Side note: why cant we have standard "server-wide" CDI scope? Then we would not need JCA and will have standard server extension mechanism). Fortunately OpenLiberty allows for this mix of MP and Java EE!

In summary, even though this is not common, monolithic traditional web apps are still possible with MP. 

[Hristo Stoyanov]

Thanks Andy,

I agree that in some cases you do need Microservices. I would actually point you to this very thoughtful talk, which explains the "Microservices vs JPMS" matter much better than I could in an email thread.

Having spent considerable effort to learn how to manage OpenLiberty, I wish:

1. I did not have to learn and deal with server.xml to specify which MP features I need. I would have loved to be able to string together all the OL MP modules I need on the module path like this: 

  java --module-path ./ol ./my-app-modules --module com.MyApp

... Or, if I needed to pack them it up in a single super-lean docker image of JVM+OL+My Stuff :

  jlink --module-path ./ol ./my-app-modules --add-modules ol.boostrap ol.cdi-2.0 ol.mp-config-1.4 ... --output /docker-folder

2. I did not have to learn how to write XML tags to add OL "shared libraries". I could just add more modules to my setup.

3. I could add none-OL MP/JAVA EE modules (like hibernate) by just adding it to the module path.

4. I could just use JARs (or "exploded JARs" during development) for my modules. I wish there was no difference between my app modules and the OL supplied modules! There would be no WARs, ERAs, RARs ... just flat plane of module jars.

Obviously, this is an ideal "future JPMS-enabled" OpenLiberty server (or Payara, Wildfly Swarm ...), which is much simpler, portable and flexible. I brought this topics here since MP tend to move much faster, and developers won't have much patience for the progress pace of the Jakarta EE process (which arguably is the place for changes like this)

[Hristo Stoyanov]

.. and btw, here is a sketch of an "enterprise/mp" module definition with module-level annotations:

//Java modules can be annotated!

@Application(com.example.MyApp.class)

@Servlets{MyServlet1.class,MyServlet2.class}

@Filters{...}

module com.example.app {

    // Suppose we have these well-defined module names for JAX-RS, CDI, and MP-Config

    requires javax.ws.rs;

    requires javax.enterprise.inject;

    requires org.eclipse.microprofile.config;

}

[John Clingan]

Coming off of PTO so trying to catch up. +1 on this. We do *not* have a branding problem. To to microprofile.io and look at the tagline - "Optimizing Enterprise Java for a Microservices Architecture".  

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/adc62c87-1b07-4922-acfd-4f80670edd7d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAJgnatHPsgNgT9nqMf1aDF86ytXkihkWGkL%3D6JyVcZ8nbSLUSw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.