MicroProfile and Istio

[Ian Robinson]

Several other threads got into discussions on the potential relationships between app-centric MicroProfile technologies and Istio as a service mesh in which such applications may run. Some of these observe a desire to define expected behaviour where there may be different ways of solving a problem depending on the environment, or an adaptive pattern for delegation of responsibility (e.g. through configuration override). For example, the Fault Tolerance discussion in this thread observes the need to ensure that an application with MicroProfile FT circuitbreaker and failback configuration doesn't get its operations retried at 2 different levels. Issues were opened against the FT spec to ensure we end up with something that works well in such an environment. There are other example too - Kubernetes provides configuration for configuring health-check endpoints, which is then a specific use case for Microprofile health check when running in a Kube environment.
As a result of several observations that we would benefit from a consolidated thread for discussing various spec issues, challenges or desired behaviour when using MicroProfile specs in a Kube/Istio environment  - here it is.

For reference, the FT issue already created are
https://github.com/eclipse/microprofile-fault-tolerance/issues/58
https://github.com/eclipse/microprofile-fault-tolerance/issues/59

[Werner Keil]

Any idea who is behind Istio?

The main contributor with most activity seems from IBM, but is it related to Liberty or IBM?

Aside from that, like samples exist for several vendors and their containers, why not create samples with different profiles to Istio or similar Cloud infrastructures.

Werner

[Mark Little]

https://techcrunch.com/2017/05/24/google-ibm-and-lyft-launch-istio-an-open-source-platform-for-managing-and-securing-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/0e030675-eb90-4122-a9b3-a3316c9830ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Werner Keil]

So "Uber-killer" Lyft. Interesting. 

Funny it shows the picture of a container terminal btw, as I help to get a mostly Microservice-like architecture on Java EE for one of those.

[Ian Robinson]

Werner - I agree with you that adapters/profiles/integrations/samples/whatever showing MicroProfile technologies with other container/endpoint infrastructure is a good idea. I'm picking on Istio here because its one I'm interested in. I feel like I'm having a slightly lower level back-to-the-future moment with application vs container management of EJB transactions - just this time with FT retry policies and health-check endpoints in app-centric MP config vs infrastructure-centric services meshes (of which Istio is one).

[Emily Jiang]

After I have done a bit more homework on Istio and thought about this a bit more, I would like to reactive this thread.

I know we have discussed this quite a few times. Shall I just create a repo to start pulling more people to collaborate? My plan is to invite at least one person from each Spec e.g. FT, Metrics, Health Check, JWT, Open Tracing to work together to build an at ecosystem between Istio and MP.

Thoughts?

Emily

[Ken Finnigan]

Emily,

Do you have any views on what the integration would look like? Or is it still too early?

I recall in the MP Hangout a couple weeks back there was talk of creating a Working Group to start looking into Istio and MP, but I don't think anything's been started yet.

Ken

[Scott Stark]

Emily, During the last MP hangout we talked about setting up a working group to investigate what integrating the MP specs into a service mesh such as istio might look like. I think a repo with discussions with each spec is fine, but there needs to be an overarching abstraction/spec that defines the actors in the service mesh in order for the individual specs to understand what it even means to be part of a service mesh. Also, in my investigation of istio/service mesh, the boundaries between the service mesh and the orchestration layer seem blurry, but do need to be clarified in order to understand how an MP service mesh can be dropped into a given cloud provider.

I suppose a new service-mesh repo is where we can start to capture these concepts with the goal of defining what an MP service mesh looks like, including the impact on the individual specs.

[Mike Croft]

Since Istio is a very new product and there are already multiple service mesh products established, I think it's important to look at other examples, like Linkerd. Istio is a bit wider in scope than Linkerd or the newer Conduit, so I think it's important to consider the whole ecosystem rather than a single product.

I think a working group like Scott suggested is a great idea since I think it's important to figure out where the responsibilities of MicroProfile actually lie and to see if any existing specs could benefit from being adapted in any way.

My impression of service meshes in general is that they are designed to operate without the application needing to be aware, but the idea of something like an SPI for implementers might be interesting. To allow specs like Config to hook into the service registry and pull back endpoint URLs in a way that's transparent to the app developer would be cool.

[Emily Jiang]

Hi Ken,

>Do you have any views on what the integration would look like? Or is it still too early?

The integration will be let Istio aware of MP. Also MP programming model should influence Istio's service capabilities roadmap and vice versa. An adapter layer in the framework is my current thinking. We need to look at each programming model in MP to get our story right. Setting up a working group is a great idea, where I think along the same line.

@Scott,
I think we are in agreement to set up a repo to start doing and talking. I think we need to put some action and make some progress since we have talked and investigated for quite a while now. I am hoping to get a couple of Istio SME to get involved as well.

@Mike, we will take Istio to start with, but with not limiting just to Istio. I had a quick read on Linkerd and will do a bit more reading.

I'll create a doodle to see how many people want to attend the group and take from there.

Emily

[Emily Jiang]

doodle pool to set up a workgroup and timeslot for the kickoff meeting: https://doodle.com/poll/y2vh2pat5cpekfkq to find a slot to kick off the discussion.
I suggest to create a repo with microprofile-service-mesh to start raising issues and put ideas there. Thoughts?

Emily

[Mike Croft]

Thanks, Emily. I can only make the 5th Feb out of those dates (I'm on a trip until 1st Feb) but, as a general point, either Wednesday calls or Monday calls would work for me.

+1 to creating the new repo (+ Gitter), it's a helpful way to work even if we won't immediately be working with code.

[Emily Jiang]

Thank you Mike for your support! After the kick off, we can do the weekly meeting. Thank you for letting us know your availability!

I'll go ahead to create this repo if no one objects and then create a gitter room. I will notify on the list in due course so that we can all create issues there and start conversation.

Emily

[Ken Finnigan]

Unfortunately for me none of those dates or times work.

But if at least Scott is there for the first one, I'm ok with not making it.

Ken

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/34d13d5a-cb24-4c12-aae3-3baf05ec72c6%40googlegroups.com.

[Werner Keil]

Happy to share, Anatole and I in the AdBoard found an Istio talk (by Google I recall) among the most appealing proposals for the DevOps track of DWX 2018. 

Not much on MicroProfile or EE4J this time (e.g. last year's multiple speaker Ivar did not notice the CFP ended although I mentioned it here) but at least a JSR 382 talk has very good chances in the Java Track. And most likely another one on JSR 375.

Werner

[Emily Jiang]

Thanks Ken and Werner for your message! By the way, I have raised a ticket (https://bugs.eclipse.org/bugs/show_bug.cgi?id=530426) to get repo microprofile-service-mesh created.

Emily

--
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/7obnAXjt3QA/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/0f46360c-4973-4c0b-be68-0f0af9bc74e7%40googlegroups.com.

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

--

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

[Emily Jiang]

Schedule the kickoff call for 5th Feb 2-3pm. Please see MicroProfile calendar for dial in details.
Thanks,
Emily

[Emily Jiang]

By the way, the repo https://github.com/eclipse/microprofile-service-mesh was created today. Feel free to log issues there.

Thanks
Emily

[Emily Jiang]

We had a great kick off meeting yesterday and during the meeting we created a number of issues. We have 12 issues so far. We have allocated the issues to Scott, Mike and me. If you have any issues, please create them there. If you would like to take any issues to work on, please comment and grab them. Please visit the repo (https://github.com/eclipse/microprofile-service-mesh) and join the gitter room for any interim discussions.

I have also created a repeatable weekly meeting for the workgroup. The meeting will start on 19th Feb. Please visit MicroProfile calendar (https://calendar.google.com/calendar/r) for more details. 

Thanks

Emily

[Scott Stark]

Emily, can you make the https://docs.google.com/document/d/1D1d9LZe0gG1Z_c6zaaOv2T_uDxudeSW75VuKHHb6QMk/edit notes editable by everyone?

To unsubscribe from this group and all its topics, 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/0f46360c-4973-4c0b-be68-0f0af9bc74e7%40googlegroups.com.

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

[Emily Jiang]

oops. I thought I have given edit access right to the public already. Try now.

Emily

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/de22b1c7-982d-419a-a1db-4a180fea45c0%40googlegroups.com.

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

[Alasdair Nottingham]

Hi,

I’m wondering what the implications of this are for MicroProfile implementations. Normally if we add a spec a MicroProfile implementation would be expected to implement it. In this case I think Istio is built on Docker, so if we add istio support does that mean you can only implement MicroProfile in Docker? What would that mean for implementations outside Docker. 

Alasdair

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/612843fc-9902-441e-8ae8-794b479320c4%40googlegroups.com.

[Mike Croft]

I would expect that the ideas coming from this would be enhancements for people who happened to be using a service mesh rather than a restriction. So, for example, we may want to add a new ConfigSource which could view a service mesh's service registry or something - it wouldn't prevent the Config API being used outside of any kind of orchestration/container platform, but be an option for those who do.

Alasdair

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.

[Emily Jiang]

reminder: weekly call in one hour. Please join if you are interested in this activity. Please see MP calendar for joining details.

Thanks
Emily

Alasdair

To unsubscribe from this group and all its topics, 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/0f46360c-4973-4c0b-be68-0f0af9bc74e7%40googlegroups.com.

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

--

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

--
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.