Do we need for circuit breakers/health monitoring/discovery/etc in Microprofile anymore?

[Hristo Stoyanov]

Some while ago Docker and the container movement started to provide some of the same benefits that Java EE developer enjoyed exclusively to the IT at large. As a result, the need for a full blown Java EE containers started to diminish and core enterprise concerns gradually shifted to Docker and Kubernetes, making a minimal  Eclipse Microprofile more appropriate Java app model.

However, it does not stop here! New 2017 projects such as Istio (IBM.Google,Lyft) and LinkerD further erode the former Java EE turf and implement circuit breakers/health monitoring/discovery/routing/ssl termination/backpressure/fault tolerance  in a somewhat standard and better way (service mesh). 

Therefore, should such concerns be removed from Microprofile, leading to smaller specs, as these concerns will inevitable start being implemented outside the Microprofile apps ?

Apologies if this has been discussed. already.

[Rudy De Busscher]

Hi,

Indeed, everyone is copying the features that Java EE has already for a long time. But those same people are criticizing Java EE for being too heavy.

So, it is a good thing it becomes available outside the Java EE space, but not everyone is using Docker/Kubernetes and will be using Docker/Kubernetes in the near future if ever.

So please let the companies choose the technology which they find the best and are most comfortable with.

And thus,  circuit breakers, health monitoring, discovery etc, is and will be needed/required/useful within MicroProfile.

Just my 2c

Regards

Rudy

[Werner Keil]

Many of the features like Circuit Breakers, Health, Metrics, etc. are simply Microservice Patterns that were applied by the likes of Dropwizard, Spring Boot, Netflix or others. Often very much mixed, integrated or copied from one another, so it is important, that MicroProfile remains as modular and flexible enough, allowing e.g. to use Health or Metrics, but not forced to only use MicroProfile Circuit Breaker, should an interested party and project already work well with Hystrix or something else.

Some vendors, especially Pivotal/Spring/Dell and others try to tie everyone into their stack making it hard to combine them with others, unless they copied those over from Java EE or other frameworks in the first place.

Sticking to a vendor-neutral promise is important to the success of MicroProfile and also whatever might come under the EE4J umbrella.

Regards,

Werner

[Emily Jiang]

Thanks for bringing this up again! It was being discussed a few times:

1. https://groups.google.com/forum/#!msg/microprofile/0L-h7scH4pg/ihrCkufNBQAJ;context-place=forum/microprofile
2. https://groups.google.com/forum/#!msg/microprofile/7obnAXjt3QA/Oem_Qrx2EgAJ;context-place=forum/microprofile

MicroProfile is completely aware of Istio's capabilities, which is why we have created an ecosystem between Istio and MicroProfile Fault Tolerance (see http://microprofile.io/project/eclipse/microprofile-fault-tolerance/spec/src/main/asciidoc/configuration.asciidoc). Though Istio can do some aspect of the programming models, it cannot do all. For an instance, it cannot do fall back in MicroProfile.

My view is that we would rather focus on creating an ecosystem between Istio and MicroProfile programming models, while MicroProfile still go ahead defining Microservice programming model. In this way, any applications can still use MicroProfile programming model to achieve Fault Tolerance, health, metrics etc, when they are not deployed in Istio.

At the moment, I am investigating Istio's capabilities and will open up a new repo to start the ground up integration between Istio and MicroProfile. Watch the space.

Thanks
Emily

[Hristo Stoyanov]

Thanks Emily,
Keep in mind that Istio is in its infancy, but evolving fast (see commit rate T GitHub) backed by Google, IBM, Lyft.

I would consult with their roadmap and developers to avoid Microprofile implementing the same features.

[Emily Jiang]

Thank you Hristo! Noted. Will report back in due course.

Thanks
Emily

[Heiko Rupp]

I think while Istio and some of the MicroProfile specs serve the same purpose, there is not always an either or, but rather a and between those.

Istio as it currently stands uses Envoy sidecars. They can of course intercept calls in and out the application container, but can not see into it.

Take system health as an example. Of course can Envoy report when no more communication is happening or it sees the application container dying. 

But there may be many other reasons why a server or application may report unhealthy.

[m.reza.rahman]

Personally I don't get the debate at all. Maybe I'm missing something.

The referenced project is obviously not an open standard and probably has no specific integration with Java EE either. MicroProfile is obviously eventually aimed to be an open standard and is intended to be very integrated with Java EE based runtimes.

None of this means this other open source project should not continue on its own trajectory and maybe have some Java EE integrations provided by someone (ideally the project itself).

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.
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/8d0cc8a4-4144-4749-8bfe-7ee596ccacda%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Emily Jiang]

Reza,

We cannot ignore the existence of Istio. We need to ensure the users of MicroProfile and Istio can benefit from the ecosystem we are going to set up, instead of being left alone with a lot of conflicts brought by two technologies. Hence this thread discussion. In some areas, both technologies need to respect each other.

Thanks

Emily

[Reza Rahman]

Against my better judgement, I will continue this discussion...

With all due respect, perhaps I am still missing something. What in practicality does your statement mean? How is this situation any different than Spring DI vs CDI, for example? We didn't stop CDI development/features just because Spring existed and neither did we standardize any Spring integration in CDI thus far.

Whether Spring and CDI "respect each other" is debatable and frankly not really a substantive technical consideration. Perhaps more substantively, these technologies clearly don't "ignore each other" either. They routinely copy each other's features because they need to remain competitive. Is that your actual main point?

Again, what am I missing in this conversation?

Just to be clear, this is an honest question. It is neither my goal neither do I have the time to badger you or anyone else for that matter.

[Heiko Rupp]

I think the difference for example with fault-tolerance is that Istio is a "wrapper" in front of the MP application that is using FT.

If now the target is somewhat faulty and both Istio and MP-FT are told to retry max 5 times, you could end up with up to 25 retries. Here one or both of them need a way to switch it off.

Or for circuit breaker: If the one from Istio has already opened, then MP-FT should not retry, but just also open its circuit-breaker until it learns that Istio has closed its.

[Hristo Stoyanov]

Reza,

None of us have a firm conviction on this, we are just weighting strategic options and what is best for the Java Microprofile/EE4J developers ...

The argument, as I see it,  is this: 

Istio, being backed by the power-combo of Google/IBM/Lyft will eventually become the preferred way to implement the above mentioned concerns (for Java/PHP/GO/Python/C++/C#/Node.JS/Whatever developers).  This is not  like the case of Spring DI vs Java EE CDI, as the odds are not even remotely equal -  Microprofile  won't stand a chance if Istio becomes integral part of Kubernetes (a very likely event, imo) and become widely accepted as  the "The Way" to implement circuit breakers/health monitoring/discovery/routing/ssl termination/backpressure/fault tolerance. 

So, rather than fighting an uphill battle, Microprofile specs can shift priorities and re-focus on "other things". I for one, would like to see more focus/progress on:

- How do we get rid of EJBs and move the useful parts to CDI.

- How do we get rid of WARs, EARs, RARs on the user side artifacts, and all proprietary module systems on the server side (JBoss Module, GlassFish OSGi, OpenLiberty EAS, whatever) and move to just Java 9 JAR modules.

- Deprecate the whole concept of UberJars and start using the new Java 9 jlink facility instead.

[Alasdair Nottingham]

What is an Open Liberty EAS?

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/9d7ffd26-b1c3-4197-8f01-c56a22294c14%40googlegroups.com.

[m.reza.rahman]

Just so I (and probably many others here) know, who is the "we" here that is making these decisions that most of the work now being done as part of MicroProfile should stop in favor of this new library becoming or not becoming something some time in the future?

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

-------- Original message --------

From: Hristo Stoyanov <hr.st...@gmail.com>

Date: 11/16/17 9:48 PM (GMT-05:00)

To: Eclipse MicroProfile <microp...@googlegroups.com>

[Reza Rahman]

I am really trying to understand this, so please bear with me.

How is what you described any different from a MicroProfile application when used in say a Netflix OSS based environment? If it is worth it to still invest in these MicroProfile features despite the existence of Netflix OSS, what makes this new library so much more special? Should the MicroProfile folks not have just created some CDI integration libraries over Netflix OSS and called it a day? Similarly all that would be needed going forward is just another set of CDI integrations with this new library? Why ever bother with the additional work to create vendor neutral APIs at all?

What am I missing here?

[Hristo Stoyanov]

Reza,

No offense taken, and I am really not trying to dictate decisions, nor I have firm convictions myself one way or the other - sincere apologies if my thoughts came out that way!

My concerns is that Istio may have looked like a little new library mid-2017 in the same sense that Docker looked like a little obscure Linux experiment back in 2014, and Kubernetes - an unlikely orchestration engine just an year ago! These things change fast and the turf of container/orchestration/service mesh is highly contested and unpredicatble, with the losers (Docker Swarm?) to make up 99% in the aftermath.

... Since you mentioned Netflix, and as a sign of things to come, it is interesting to look into the reasons why Netflix decided to no longer develop their pure Java client-side, load-balancing, fault-tolerant IPC library Ribbon in favor of non-Java, generic gRPC by Google. 

Now, looking into Istio, I do notice the early signs of a winner :

- open source, backed by Google&Co

- massive amounts of daily commits in github with large number of contributors.

- frequent releases, moving very fast.

- platform/language neutral, taking circuit breakers/health monitoring/discovery/rating/auth/load balancing/etc completely out of developer's concerns. 

- integrates with Kubernetes (which itself pretty much killed off anything orchestration-like as of late-2017), Consul, Nomad.

- comprehensive service mesh model (that overlaps with parts of Microprofile).

- ultra-performant, robust HTTP2/TLS Envoy proxy, which is likely better than Jetty, Tomcat, Undertow. Even better than HAProxy, they claim.

Of course I may very likely turn out to be wrong ;-). it could be LinkerD, or something totally out of the left field. But a java-centric solution (such as parts of Microprofile) is less likely to stand a chance.

Peace,

Hristo

[Guillermo González de Agüero]

That exact concern was discussed at the beginning and from what I remember, the decission was to create a simple API that can act as a wrapper with Netflix underneath. I think some parts of WildFly Swarm MicroProfile implementation are already using Netflix libraries under the hood.

In that cases where the alternatives are Java libraries, it's easy to wrap them. The ideal solution would be that e.g. MicroProfile annotations could configure Istio or wathever solution finally wins there. Initial Java EE 9 plans by Oracle already had a "Containers integration" spec which I guess would handle that kind of situations. I haven't looked as Istio and I don't know if anything of this is possible, so I'm just thinking out loud.

Regards,

Guillermo González de Agüero

--
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/a064a145-3cc4-4af6-9fa7-d8873c123057%40googlegroups.com.

[Emily Jiang]

3 points here:

1. I think not every app will be deployed to Istio. History has shown "No matter how powerful a technology is, it cannot suck in every consumer." (my quote:o). With MicroProfile programming model, it caters for all applications. It is striving to ensure the apps written once, run everywhere (let it Istio or not).

2. If the app is in Istio, Istio can choose to use app's QoS (e.g. health, Fault Tolerance, metrics, security) or overwrite app's config and use Istio's own one. However, Istio cannot see the detailed business logic, so it can only do certain things. For an instance, in some aspect, e.g. fallback, Istio has no clue which alternative operation to fallback on. Only app knows. Also, Istio cannot do threading style of bulkhead. Heiko also pointed out: Istio might think the pod is ok but the app inside the pod knows more. In this case, Istio should use app's health status instead of its own. It is nice to compliment each other. Hence the ecosystem is key.

3. To move even further, to Guillermo's point, it might be better for Istio to utilise MicroProfile APIs somehow for an even tighter integration.

I think we should be exploring the 2 and 3 on establishing an ecosystem rather than one defeating the other.

Thanks

Emily

On Fri, Nov 17, 2017 at 6:50 AM, Guillermo González de Agüero <z06.gu...@gmail.com> wrote:

That exact concern was discussed at the beginning and from what I remember, the decission was to create a simple API that can act as a wrapper with Netflix underneath. I think some parts of WildFly Swarm MicroProfile implementation are already using Netflix libraries under the hood.

In that cases where the alternatives are Java libraries, it's easy to wrap them. The ideal solution would be that e.g. MicroProfile annotations could configure Istio or wathever solution finally wins there. Initial Java EE 9 plans by Oracle already had a "Containers integration" spec which I guess would handle that kind of situations. I haven't looked as Istio and I don't know if anything of this is possible, so I'm just thinking out loud.

Regards,

Guillermo González de Agüero

El vie., 17 nov. 2017 a las 6:13, Reza Rahman (<m.reza...@gmail.com>) escribió:

I am really trying to understand this, so please bear with me.

How is what you described any different from a MicroProfile application when used in say a Netflix OSS based environment? If it is worth it to still invest in these MicroProfile features despite the existence of Netflix OSS, what makes this new library so much more special? Should the MicroProfile folks not have just created some CDI integration libraries over Netflix OSS and called it a day? Similarly all that would be needed going forward is just another set of CDI integrations with this new library? Why ever bother with the additional work to create vendor neutral APIs at all?

What am I missing here?

--
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/a064a145-3cc4-4af6-9fa7-d8873c123057%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/Uey0paqQgR0/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAG1ZpUaGb-TjuE3yb56sRAhVn7QxH%3DWejebrMm6p-o2iyc1_%3DQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Thanks
Emily
=================
Emily Jiang
eji...@apache.org

[m.reza.rahman]

Can MicroProfile implementers kindly comment on this?

If these MicroProfile features are just facades over other implementations (presumably also including a "native" implementation), how does the user specify which implementation is to be used? In particular what if a user does not wish to use the likes of Netflix OSS or Itsio let's say to avoid implementation lock in. Are MicroProfile "native" implementations available in all cases?

Is any of this reality now or just something in planning? Can you actually use Netflix OSS as a MicroProfile implementation layer today?

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

-------- Original message --------

From: Guillermo González de Agüero <z06.gu...@gmail.com>

Date: 11/17/17 1:50 AM (GMT-05:00)

To: microp...@googlegroups.com

Subject: Re: [microprofile] Re: Do we need for circuit breakers/health monitoring/discovery/etc in Microprofile anymore?

That exact concern was discussed at the beginning and from what I remember, the decission was to create a simple API that can act as a wrapper with Netflix underneath. I think some parts of WildFly Swarm MicroProfile implementation are already using Netflix libraries under the hood.

In that cases where the alternatives are Java libraries, it's easy to wrap them. The ideal solution would be that e.g. MicroProfile annotations could configure Istio or wathever solution finally wins there. Initial Java EE 9 plans by Oracle already had a "Containers integration" spec which I guess would handle that kind of situations. I haven't looked as Istio and I don't know if anything of this is possible, so I'm just thinking out loud.

Regards,

Guillermo González de Agüero

El vie., 17 nov. 2017 a las 6:13, Reza Rahman (<m.reza...@gmail.com>) escribió:

I am really trying to understand this, so please bear with me.

How is what you described any different from a MicroProfile application when used in say a Netflix OSS based environment? If it is worth it to still invest in these MicroProfile features despite the existence of Netflix OSS, what makes this new library so much more special? Should the MicroProfile folks not have just created some CDI integration libraries over Netflix OSS and called it a day? Similarly all that would be needed going forward is just another set of CDI integrations with this new library? Why ever bother with the additional work to create vendor neutral APIs at all?

What am I missing here?

--
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/a064a145-3cc4-4af6-9fa7-d8873c123057%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.

[m.reza.rahman]

Good to confirm this is all just speculation on your part and actual decisions are to be made jointly in the open by the MicroProfile community and hopefully an even broader group with EE4J soon enough.

To further clarify my opinion just in case it is not clear already, I think MicroProfile needs to aim to continue to provide a vendor neutral, open standard API for Java developers. How this aligns to these other things that are not actually vendor or implementation neutral should be a secondary concern. Maybe the (distant) ultimate answer is that these technologies should choose to adopt the MicroProfile APIs by themselves or MicroProfile vendors can provide thin adapters where it actually makes sense.

That really has been the underlying thinking behind Java open standards for a long time now. I do not think it is in the best interests of Java developers to deviate from that philosophy now.

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

-------- Original message --------

From: Hristo Stoyanov <hr.st...@gmail.com>

Date: 11/17/17 1:32 AM (GMT-05:00)

To: Eclipse MicroProfile <microp...@googlegroups.com>

Subject: Re: [microprofile] Re: Do we need for circuit breakers/health monitoring/discovery/etc in Microprofile anymore?

Reza,

No offense taken, and I am really not trying to dictate decisions, nor I have firm convictions myself one way or the other - sincere apologies if my thoughts came out that way!

My concerns is that Istio may have looked like a little new library mid-2017 in the same sense that Docker looked like a little obscure Linux experiment back in 2014, and Kubernetes - an unlikely orchestration engine just an year ago! These things change fast and the turf of container/orchestration/service mesh is highly contested and unpredicatble, with the losers (Docker Swarm?) to make up 99% in the aftermath.

... Since you mentioned Netflix, and as a sign of things to come, it is interesting to look into the reasons why Netflix decided to no longer develop their pure Java client-side, load-balancing, fault-tolerant IPC library Ribbon in favor of non-Java, generic gRPC by Google. 

Now, looking into Istio, I do notice the early signs of a winner :

- open source, backed by Google&Co

- massive amounts of daily commits in github with large number of contributors.

- frequent releases, moving very fast.

- platform/language neutral, taking circuit breakers/health monitoring/discovery/rating/auth/load balancing/etc completely out of developer's concerns. 

- integrates with Kubernetes (which itself pretty much killed off anything orchestration-like as of late-2017), Consul, Nomad.

- comprehensive service mesh model (that overlaps with parts of Microprofile).

- ultra-performant, robust HTTP2/TLS Envoy proxy, which is likely better than Jetty, Tomcat, Undertow. Even better than HAProxy, they claim.

Of course I may very likely turn out to be wrong ;-). it could be LinkerD, or something totally out of the left field. But a java-centric solution (such as parts of Microprofile) is less likely to stand a chance.

Peace,

Hristo

On Thursday, November 16, 2017 at 9:13:40 PM UTC-8, Reza Rahman wrote:

I am really trying to understand this, so please bear with me.

How is what you described any different from a MicroProfile application when used in say a Netflix OSS based environment? If it is worth it to still invest in these MicroProfile features despite the existence of Netflix OSS, what makes this new library so much more special? Should the MicroProfile folks not have just created some CDI integration libraries over Netflix OSS and called it a day? Similarly all that would be needed going forward is just another set of CDI integrations with this new library? Why ever bother with the additional work to create vendor neutral APIs at all?

What am I missing here?

--
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/0526833c-b363-40ff-87be-ab8cd9315451%40googlegroups.com.

[Guillermo González de Agüero]

The case of WildFly is I think in Fault Tolerance (don't take my word though). The idea is that they use it internally while you just use MicroProfile annotations. It's the same that happens with Java EE: you compile against an interface and don't bother about the implementation that's underneath.

Other vendors have decided to implement the whole system from scratch, but it's transparent for end users, and not really tied to a specific implementation. It just was taken into account that there were already some good liberaries out there that mightbe used to back it (similar to what JAX-RS 2.1 did with RX).

Regards,

Guillermo González de Agüero

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/5a0eea82.a63ac80a.3cd00.f7af%40mx.google.com.