MicroProfile and the multi-app runtimes

[Heiko Rupp]

When I started working on MicroProfile my assumption was (and I know I am not alone)

   1 runtime = 1 microservice = 1 app

Now that MicroProfile gains more traction for runtime implementors, there is a clear wish to also support the more classical runtime models that allow for multiple applications.

Having said this, there are a number of issues in the current specs. Metrics for example does not differentiate the application metrics per application (it assumes 1 app only)

Metrics wants to fix that with a way to identify if there are multiple apps deployed and then e.g. prepend the app-name to the metric names to disambiguate.

I am writing that entry, as other specs have similar issues (e.g. how do you provide a config entry 'myFoo' for app1 and app2 ?) and think we should come up with a common solution for all of MicroProfile.

The current thinking goes along the lines of taking the app-name from the context root. If only 1 app is present, context root is / and processing can happen as is.

For cases that the context root can not be determined or the user wants to override the naming, as App-wide annotation

@MpName(name)  is provided, that overrides the (automatically) determined context-root. 

If both are not supplied, the server should abort startup.

Opinions?

[Pavol Loffay]

Thanks for starting this. I like the proposal, especially the precedence order 1. context root 2. @MpName.

The only concern I have is about "illegal" characters in the context root or in the annotation. For example what if the value contains a character which cannot be

used in an environmental variable or a system property name? Then it cannot be used as a configuration property name e.g. foo.app%201=bar.

I want to also link an issue from OpenTracing spec https://github.com/eclipse/microprofile-opentracing/issues/119

The issue in our case is that mp.opentracing.skip-pattern=/foo|/bar explicitly excludes the context path and the value is compared against `UriInfo.getPath()` which is problematic in multi-app runtimes.

We wanted to include context root into the value but it does not make sense for single app runtimes and makes it harder to construct the pattern.

Regards,

[Emily Jiang]

Hi Heiko,

Good idea! I raised this very issue https://github.com/eclipse/microprofile-health/issues/45 a while ago on MP Health spec. I think we should expose /app/health to differentiate multiple apps, similar to Metrics.

Pavol,

Your concern was solved by mp config 1.3. All 'illegal' (non-numberic-alpha) characters will be replaced by _ if you specify the property as an environment variable.

Thanks

Emily

[Pavol Loffay]

On Friday, November 2, 2018 at 12:43:27 PM UTC+1, Emily Jiang wrote:

Hi Heiko,

Good idea! I raised this very issue https://github.com/eclipse/microprofile-health/issues/45 a while ago on MP Health spec. I think we should expose /app/health to differentiate multiple apps, similar to Metrics.

Pavol,

Your concern was solved by mp config 1.3. All 'illegal' (non-numberic-alpha) characters will be replaced by _ if you specify the property as an environment variable.

Thanks Emily, well to some degree  - it can create ambiguity. But I think it's ok we don't have a better solution to that.

[Alasdair Nottingham]

Context root is a servlet concept, not a MicroProfile one. I guess it is one we could import, but it feels like if we do this we are straying into needing to define how these apps will be packaged.

Could we use the ApplicationPath instead? 

Alasdair

--
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/58446215-56ab-4828-8100-e56d61bf9000%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gunnar Morling]

> there is a clear wish to also support the more classical runtime models that allow for multiple applications.

I'm afraid this leads us back to closer coupling of services. In fact, even in recent years of classic Java EE I saw mostly a single app being deployed to one server due to multiple issues with deploying multiple ones. E.g. one service producing an OOME may impact other services deployed to the same runtime, all services having to align on the same runtime version etc.

Or taking health checks as an example, what should the orchestration layer do if one health check returns "down"? Restarting the pod will impact availability of all co-located applications, which isn't desirable.

So IMO supporting multiple "applications" on one runtime is a step back and I'd avoid to do this. It'd be interesting to see what's behind the wish for that and whether perhaps other means can be found to satisfy the underlying requirement.

--Gunnar

[Alasdair Nottingham]

I can certainly see value for metrics in being able to support a 1-n scenario. I wouldn’t call it a microservices one per se, but I can see value in being able to have a consistent way to get metrics from all my apps into a single place like prometeus. So if you have microservices with 1-1 and non-microservices with 1-n it would be nice to have a consistent API and a consistent way to get metrics data so you don’t have one solution for your microservices and another for non-microservices.

--
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/8267be59-3e91-4df0-831b-4dca77294f3f%40googlegroups.com.

[Heiko Rupp]

Am Freitag, 2. November 2018 14:54:29 UTC+1 schrieb Alasdair Nottingham:

Context root is a servlet concept, not a MicroProfile one. I guess it is one we could import, but it feels like if we do this we are straying into needing to define how these apps will be packaged.

Could we use the ApplicationPath instead?

Actually yes, I / we had thought of that, but I forgot it in my list. 

While I had the issue on mind for some time, I started the mail after talking with Pavol, where context-root was mentioned several times.

[Heiko Rupp]

Gunnar,

what I am describing is the reality and not the ideal situation I started (my thinking) with. 
So having a consistent idea on how to address this on a MircoProfile level is desirable and then it should be applied to the individual specs (e.g. the mechanism of determining the application name should always be the same).

When you think about health, then it could be a way that the final outcome can be influenced by a switch that says down is when any one app is down or all apps are down. This switch can then be set from the outside to accommodate the environment that runtime is running in. Or systems like kubernetes could be instructed to only look at /health/app1 and ignore /health/app2 instead of looking at the composite /health. But at the moment, we do not have that notion at all

[Ken Finnigan]

We need to be especially careful in my view with such a shift.

To date, Eclipse MicroProfile has been focused on optimization for microservices development, which implies single deployment per instance.

If we're now talking about going beyond that to handling multiple deployments in a single instance, that changes the playing field in a big way.

This will need extensive discussion before such changes could be introduced

Ken