solo.io Community, 12 Aug 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 08.12.2020 Service Mesh Hub Community Meeting

Description

No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).

A

A

Hello, everyone.

B

C

Good morning,.

C

C

All right one, second, let me get the.

C

Notes in here in the group chat and find the notes for this meeting.

C

C

Awesome all right. Sorry, let's see john thank you for all the um agenda topics.

C

Adding everybody else on, let's see, we've got lehigh.

D

C

C

Right all right: do we want to start off with uh we've got a few topics in here for the agenda. John you've got the first three: do you want to go up and pose your questions.

E

uh Sure can you hear me, okay, trying out the the phone option of zoom here?

E

Okay, so I think this is a little bit of a continuation from the discussion.

E

We had uh two weeks back um where we had proposed or talked about some ways to get additional discovery of workloads and services, um mostly more workloads and services, but um into uh service mesh hub and as I conveyed and provided some links last time that was related to some of our interaction with uh nsm, the open source, open source uh project called network service mesh, which uh does things a little bit outside of the the straight cni kubernetes service uh landscape.

E

So that's that was the sort of impetus to for that suggestion, and so I just wanted to really kind of continue that a little bit and and see um if you've had any further discussion on it. Any further thought on how to proceed here. um We have been, in the meantime, um uh exploring an option to just try to do this via the crd, uh the creation of a crd, it's a little clunky and there's some issues that we might run into that's kind of province. Questions later on.

E

But it's really just more of a continuation of that um topic from last week to see uh if you've digested that request at all or or what you think or how we should proceed that make sense.

F

Yes, it does uh so scott vice is not here right now, and I think that he had some uh some uh a lot of the knowledge rv. Can you try to take this.

G

um To my knowledge, we haven't discussed any further than what we discussed in the last few meetings.

F

Yeah you see in the naturals what you're interested is that you have your own system and what you want to do is somehow basically use that as a discovery source like we are doing for kubernetes services or, for instance, um discovery of uh console resources right. That's basically,.

E

Yeah yeah at the highest level: that's um that's what it is and- and I mean there's another a number of ways to to uh skim this cat too. Your crdu offers one way uh if we're. If we, if there was a more flexible way to um discover the services that are created by the underlying mesh via config, that might be another way um or uh the most sort of flexible and extensible way is that if there was some kind of api, that's offered to uh be able to programmatically uh create them.

E

Maybe maybe the crd is that api. Maybe maybe that would is what you'd argue, um which is okay. I think what we're just really trying to figure out is what, uh where things fit, and what's the best way and how to how do we actually proceed on an option that um you know the broader community can buy in on and support uh longer term? Does that make sense.

F

um Yeah sure so I mean basically cork referendum if I understand, but basically you're looking for some sdk or something like that. That will help you basically some api that will help you to create those crds right in the nutshells. You.

E

Want us to run um no, if we're going to, if we're going to necessarily use the cr, if, if the decision is uh just create crds okay, if that's the api that we want where, where the service mesh hub itself uh just uses the existence of a crd to be convey um that workload and service mapping. Okay, then then that's we could probably work with that. um It's not perfect, but we can probably work with that. I don't think we need an sdk to do that.

E

We can figure out how to create that crd, um but but we haven't, you know a a better way might be.

E

You know like offering an api, as pavin has described in a few uh proofs in some of the links that we provided last week, that we can go in and do like a a straight api uh interface into uh your your mesh discovery so that we could create those apis.

E

Let me create those uh services of workloads, so we're not necessarily stuck on a particular way, but we want some get a dialogue and decide. You know what way we can can be supported, so we can proceed with some of our work.

H

So let me ask you this uh here by the way, when you say an api with that api create a discovered resource, because the question is where eventually it needs to get persisted somewhere. So with that api you mean is, is a part of it is persistence or persistence in a crd.

I

If I may take this right, I think in the last call we briefly spoke about. You know having additional discovery capabilities baked in smh like one as to how it works today. Is that you know any of the cluster services it actually recognizes, and if there is a workload which is backing it, then it basically registers as a mesh service and it tries to federate them across the clusters.

I

um What um us and scott sort of discussed last time was, you know, having extra capabilities through either an external service registry like xcd or console, or something else, or you know, smh trying to read uh the istio service registry, which it provides through service entries, for example, and you know just trying to expand their discovery capabilities in smh via just the normal kubernetes um service um as to what it does today.

I

So our sort of discussion was trying to see. If you know we can try to have some sort of capabilities in smh to do this, or you know, is the api. The only way to do this as of now or if anything could be planned for like the next release, or something like that.

H

So if I understand you mean an api internally in service mesh hub to read services off of other registries, like it's, your service entry or a custom one, you need the cd.

I

Yeah, absolutely anything yeah, mostly.

E

H

So and in that sense, there's there'll be no crd at all this stuff persisted in ntcd or console, and we want to kind of support that to become an object inside of service mesh hub.

E

Yeah, so the persistence of the persistence of the object in service mesh hub.

E

It is a little bit of a different, maybe question versus how the um you know how you conveyed the object from somewhere else. So you know in our particular case we we we will we'll persist. These uh have have a persistent store for the uh workload and.

F

E

Service, mappings, okay, that are associated with the network service mesh, um but that doesn't really, as you said, you value you. You will need to persist that um in service mesh hub as well. um So how that's done? I guess we didn't really. We didn't offer any suggestions on on the best way to do that. We kind of thought. We'd uh interact with you more, it's more, you know what is the? What is the means to convey that mapping over to service mesh hub? You know, must it be a crd?

E

Is that the only option um or do we want to um be more expansive? As having said do we want to you know, even even allowing discovery of the services via like some of the istio virtual services that are created is a possible other approach.

H

Yeah, currently, everything is here at these right, so I think, in order to make so service machine assumes, or rather the api, that service mesh app uses internally is the crd right, so in a sense to make it work. For example, with a it's your service entry, we have to create an internal abstraction that would convert one to the other internally and harvey I'll defer to you to do. Do you think there's a good place to do that in the code or how would you go about this.

E

Yeah, well, I said: let me let me stop you a little bit, then I think what you're you're saying is no matter what what what kind of api you offer um it's going to end up mapping back to the crd right, so I I I mean creating a having us create! No us creating a crd is a fairly trivial. You know exercise. So I think maybe what we ought to do here, um at least for uh for the next two weeks is we'll proceed down that path of using the crd.

E

um I think what we got to talk about, then really is how to ensure the crd validation um is relaxed, because, right now it's tied very tightly or at least according to uh scott. I think it was last week tied very tightly to the existence of those workloads in kubernetes, so that.

G

Constraint is only for services for mesh services that are managed by service mesh hub. If you end up creating the crd yourself uh that constraint, there is no such constraint.

G

I I think one aspect of the design that's worth discussing is, if you, if the integration point is for external parties to create their own mesh service crd, you don't get the same discovery capabilities like, for instance, you. It won't you'll, have to manage the garbage collection yourself.

G

um So I think these are some like design points that are worth uh talking about before we move forward with any one approach. What.

J

Would they be first first-class citizens in the rest of the api like that? Yes, they.

G

Would you would still be able to target the mesh service as you would for any of the networking configuration? However, you wouldn't have the discovery capabilities for those manually created mesh services right.

I

I think what we found when we did this testing right is: let's let's say I create a crd manually and in the background one of the kubernetes service is deleted, so messenger. What it does is. It goes through the reconcile loop that okay, something is deleted. I need to update my services. It sees that I created a mesh service manually and it thinks that it shouldn't be there and it tries to delete it.

I

um I have seen that a couple of times- um and I just wanted to check as to you know: how can we make that like um as a first class entry, so it treats um you know even.

F

I

The apps could be backed by sorry. The service could be backed by a proper workload and everything. I don't want um smh to delete that, because you know it didn't discover through its normal discovery process.

G

Yeah, that's a great point, so the post, refactored service mesh hub will scope all of the managed mesh services with labels, so it will only garbage collect the ones that that it has labeled. So if you manually create a mesh service, those will not be garbage collected.

J

So speaking of post refactored service mesh, maybe a service mesh up. Maybe it's a good idea to give give an update on where we are with that and what the plan is for release with the the refactored.

G

Code yeah, so we are very close. We're mostly tying up loose ends. The core of the system is there.

G

We are just shoring up the the testing, the unit testing, end-to-end testing porting over the mesh ctl commands and we'll have a decent amount of work to update the documentation and make sure that that's a good source of truth is that on master, uh it's not on master. Yet I think we are a few days away from being able to merge to master and do a pre-release with uh full istio support, but lacking at mesh eks support.

E

Okay, that's great. uh Actually that was one of the other questions we had so um so within a the expectation is on the order of days. We should see little hit master, be able to you, know rock through it and see what changed and try to try out this try out. Would you you mentioned harvey right.

F

E

F

Yeah, so the only thing that is left, as I said, is obvious. As we mentioned he's working on the end to end testing and more, you know robust end-to-end testing. uh We have um a score just merge yesterday, this subset, so that's actually functionality uh like multi-cluster uh subset.

F

So that's something that wasn't actually on the release of master. So that's another feature that we just uh emerged yesterday and then docs. That's the only thing and we're already working with our dark guys. So you know I. I believe that we probably will be in a very good position and by the end of this week,.

E

Okay, great so so I think, based on this, um I think what we should probably do is just focus on the crd creation um at the current time and and see see how that meets our or doesn't meet our needs and um from there we can figure out whether we want some other kind of api, some other kind of abstraction that you've all mentioned um or or not. And then you know talk about that in two weeks out uh what we found or what we think or uh any input you have on direction.

E

Does that sound reasonable.

F

Totally totally so maybe I should just uh give you a little bit more update. So, as always mention app mesh is not in the newer factors, but that's the first thing that we're going to work immediately after so that should come very soon and then eight and hearing the call say hello, eitan he's actually working right now and adding osm so open service mesh integration and is probably will uh you know I don't know you can give a status item if you want.

K

uh I'd say uh end of week: I am uh oops sorry, I am making my way through dependencies right now. So let's say end of week: yeah.

F

So that's another one that we are focusing on so up mesh, as well as a osm or open service mesh for microsoft. That will be the next one, uh working parallel right now and then uh yeah, and then there is a few more stuff that we wanted to add that is kind of like on the way. um One thing is: uh is the um we calling it uh routing based on localization?

F

That will come next, uh so we did the failover, but we want to be more specific on this, so that will come next after it and so on so and vm support, that's the stuff that we are focusing right after.

E

So uh so it's just uh curious- and this maybe also goes to my question on the uh limited trust uh are: is there any design documents or descriptions about you know how some of these things are coming in? How how do you generally manage that, um uh because it would be interesting, as these features are being put together, to be able to look at them or comment on them or even think about how they influence? um You know some of the work we're doing.

F

Yeah, so I I don't think we have a dog sioux valley is here. You can probably talk a little bit about that. We totally know how what? How is that going to look and what we're going to do about, but I don't think that you know, but it was an internal discussion more than actually written one I mean we can probably put something on page. uh What do you want to kind of like a high level, a share, limited trust.

H

For big features, we've done that in the past we created design dock. I believe it's in their repo there's a folder for those. um If you don't know what features um like osm.

F

Are you well, I think that what I what I, what is what I wanted you to kind of like high level talk about how we're going to implement the the limited trust.

L

Oh okay, um one is that what you're looking for just to make sure.

E

Well, so I mean it wasn't as I'm not not trying to be specific uh here or, as for you know, an exact thing. I guess it's just as we're trying to keep up um with what's happening and some of the work that's going on. It's always good to be able to you know, look at things on a on a personal level. If you will of what's happening and contrast it with some of the things that your company or you personally are interested in. So it isn't really a specific request, but it's more like okay.

E

You've mentioned a bunch of features and things you're working on. So how do we what's the best way for us to keep track of how that's going to influence the code base when it hits kind of thing.

D

E

But I mean, if you don't have I mean obviously, if you've been working under a different uh modus operando, you know that's fine. I just wanted to make sure we don't there's nothing missing, uh that we don't see kind of thing.

F

Yeah, so so we have joe here actually so maybe it's important that you will introduce joe joe, is actually running this project, so he's the tech lead uh and I think that uh it just took over. So we will make a lot more organization per se and we'll put more stuff there.

F

uh But uh right now, as I said uh right now actively, we are not working on this, uh but we we have a poc already done and we basically know exactly how it's working just uh you know we need first to finish the refactor, so once that will be done, we will put both people to work on them in the. um If and on on the um is that make sense.

J

So I heard I heard just be qui before you. You know. I heard two different things there, john one is you know what is what are the things that that we're working on and what are the? What is the heads up that you can get before like it gets into the code base so that you all are aware as well. So you know in part so that we don't duplicate efforts right if you were to look at these same things as well. So that's one I would say up until now.

J

We've loosely been using asana kind of internally right now, but you know, I think, there's there's probably room for discussion about. What's what's best for that, um but then the second thing is and then more specifically around the design docks. We have done design docks in the past um for the purpose that you started hinting at where you know, especially in the community here where others might have. You know an interest in what that implementation looks like and can bring other perspectives.

J

That would be useful to include in that in that implementation, um and I I don't want to speak for engineering like as, like you just said joe. You know joe's going to be leading this, um but I think we're open to um figuring out a good solution for both of those.

M

Yeah absolutely um go ahead. Sorry.

E

No no go ahead. No.

M

Yeah uh I'll, let you say that uh hi, I'm joe um I'm going to be uh sort of like assuming some project management responsibility on the service metro project, uh as I'm ramping up technically, with, like the current state of the new refactor, and uh also kind of getting a grasp on the way that we have like sort of managed. The various work streams going into service mesh hub um yeah, like that's gonna, become my responsibility to make sure that we're communicating out to all of our users and other stakeholders.

M

um You know what exactly we're working on and what our plans are um and, like christian said, I think that that's gonna contribute a lot to our like technical direction as well um and just like making sure that we get as much input as possible from folks like you on this call and anybody else in the github and larger community, like those processes are going to be evolving and any input you have as we go would be more than welcome.

E

Okay, yeah, no, that that's great, um it sounds like you you're already. You already anticipated this question and working a plan to um try to help um help move. You know make it clearer um more. So let me try to be a little more specific on on the request that um both lehigh and I were kind of interested in so the limited trust we talked about that before you said that there had been some plans and some design talks about that. That's a model that you know we're very interested in as well.

E

That's one of the things that we think is very important to the work we're doing so. We wanted to understand where that's at and even try to help contribute to it if possible, but we're kind of at a loss for okay. What's the current state, uh is there anything already been done? um How would we?

E

How would we help in that specific case? So maybe as a sort of specific example of what I was trying to ask generally is: let's talk about limited trust and how we could get more details of what if anything's been done there and how we could help. You know move that along, if not that make sense.

M

Yeah for sure, um like today, the way that uh you could contribute to these conversations is unfortunately, like literally in conversation in this meeting um and like that's absolutely uh like a note taken on our side that we need to like be better about having like public-facing documentation uh and design docs, uh and you know even just like holding discussions and github issues about um you know the plans that we have and how we're going about implementing them.

M

For this specific case, I think that you've all uh would be able to describe the like pocs that we've been running internally uh and the conversations that we've been having um but yeah as far as where that conversation is happening right this moment uh it's in calls like this, but that is something that we'll be improving.

E

F

We can just follow up the models that there was in community before us, like what stu is doing with all the scenes, which is. We should just basically follow what's already in place by other community. If this is something that you guys will feel comfortable with john.

E

Yeah yeah. No, that's that's! That's yeah! Absolutely that you know uh we would feel comfortable with that. I mean we're not trying to mandate any particular way, we're just trying to make sure we can follow along really more than anything.

F

For sure evan said that I also talked to vijay and we decided that we're going to make an internal meeting between you guys and us. So we will be able to do that as well.

E

Yeah he mentioned that, um but I hadn't heard of anything is that something that uh um all right? Well, let me talk with the uh v joy and figure out how we move that along. We can try to help put that along as well.

F

It's just going to help a little bit with the spreading the work if it makes sense, like I mean you know, if you wanted to contribute.

E

F

Fantastic okay.

J

I think, with the time that we have um it might it. It is worth since we're all on to talk about the limited trust, the way that we're looking at it and get feedback from you all.

E

That would be great.

H

Yeah, so with limited trust, the problem is that one mesh does not understand the other mesh's identity. Primitives right, one can use spiffy and another. You can just use the sand, for example.

H

So the way we thought about going about fixing that is exactly creating a component that will bridge these identities and that component will also have to do access control decisions that are on the cross mesh boundary.

H

If that makes sense, so it's kind of the high level I don't know if we want to go deeper or uh for feedback. So far,.

A

So if I understand this correctly, um a request would come with say to cluster b with an identity from from cluster a, and there would be something in the in the cluster that can tran that can transform the identity of a to b or.

H

That can so it will not transform the identity, but it will come to be with the identity of the gateway right because the gateway is in cluster b, but the gateway will also make a decision if cluster a because the gear is the only part or the only piece here. That knows, what's cluster a and what's cluster b and it can make the decision if service a from cluster a is allowed to talk to service being cluster b.

A

Okay, based on what and how do you configure the envoy on service being cluster b, to allow that as well.

H

So I'm going to service b will need to be configured to accept traffic from the gateway and the gateway itself, and that's something we're still discussing internally will have its own policy that it will enforce.

H

A

So how does the the packet comes from a yet? Does it does the gateway do anything to it, or does it simply for orders.

H

It essentially re-encrypts it right, but the tcp connection stays the same, but it initiates a new ssl connection to service b.

H

E

Oh, so, okay, so it's going to actually terminate terminate the ssl and then uh re-initiate it. It was your thinking.

H

Yeah exactly unless you know all meshes agree on an identity, primitive, something like spiffy. For example, uh we have to kind of.

H

We can't really translate an identity without re-encrypting right, so that led us to the conclusion that the gateway needs to make the auth decision uh if both meshes have two different identity mechanisms.

A

As a follow-up question on this, have you managed to prove this out in a poc and if so, what have you used for an ingress gateway? Maybe we can look into that further.

H

I think we had a poc back a few iterations, not not with the current version of service mesh hub. uh We used just android just to do a poc.

K

No, we sorry you've all just to jump in for a second. We did this with istio and linker d and and we used glue yeah, but on android, essentially right, yeah.

H

Yeah I mean it's.

K

Envoy right, it's it's basically envoy, but we're really good at configuring glue, so yeah.

H

K

H

You yeah adam did that so thank you for jumping in there.

A

I think part of my question is that I haven't figured out how to get an envoy to both terminate ssr connection and start a new one when proxying the packet.

K

Oh yeah, I mean separate, I mean this is a bit of a digression, but we I mean we could easily show you how to do that with glue and like we. We do that with glue all the time. I do that for some of our bigger new features like failover and all this stuff I mean this is this is something that you can accomplish in glue very easily.

A

uh If you can point the meta documentation in this chat or during the solo slack channel for smh, that would be great yeah. Let me go find it. Thank you.

E

So have you so have you explored all the um the the envoys ability to associate um sds on a per cluster basis? Has that been something you've explored at all for this or have any advantages here that you've thought about.

H

Right question: what do you mean? What was that on a per cluster basis, yeah.

E

So envoy supports the ability per cluster per envoy cluster to specify an sds server or an sds source. I guess I should say so that so where, where it's going to run its secret discovery, service or or who it connects to for secret discovery service, so that doesn't necessarily solve exactly the identity issue, but it does allow an easy way for to get certificates for different clusters from different places.

H

E

Makes any sense.

H

In do you mean that client certificate.

N

I I think, I think, what john's trying to say is or describe the mechanism that say if smh had a um almost third source of identity or or its own umbrella of identity for services. For the the actual connection between services, you could potentially have the envoy instance. That's acting as a gateway use, something in smh as a sds source for um for the for for specific cluster targets and um in envoy config.

H

But in order to connect to service b, we need to use a certificate provided by the target mesh.

H

So I don't know if we can create our own source for certificates.

J

So you could theoretically keep so. You could theoretically keep a central source of what are the certificate chains for all of the clusters that you manage, but I think that's a little bit separate. um You know, then translating the identities between two different.

J

uh You know sources of identity, so in other words the sds will be useful if we can, if you just if you want to load the certificates into envoy, but that's that's not um that's not yeah.

N

I mean, I think, the solution.

J

N

Yeah yeah, I I think that's where we're trying to understand the options um on being able to sort of have that federated identity model um and and what we could make use of at the envoy level. To accomplish that, I mean I, so it would be akin I guess, to having the something in a in each target cluster that trusts um the the source from the other cluster. I guess when we because we know who's allowed to talk to who, um at that level.

J

It's essentially what you're describing is what the the spiffy yeah.

F

J

J

Was you know, uh maybe maybe more generically, not not specif, spiffy, specific yeah and and how do we solve it at that.

N

Like more like more yeah, the evolve was, I think, describing like a true gateway, identity gateway, because.

H

Let's see yeah, that's exactly the problem, if all meshes agreed on spiffy or another identity mechanism, but we wouldn't have this problem right.

E

A

Proposition is if we could configure specific envoy workloads with specific certificates, regardless of cluster, so have two trust domains in a cluster that can communicate with one trust domain in one cluster and another trust domain. You know.

F

And in another cluster sort.

A

Of like that, that makes sense.

O

So basically, having.

A

um You could register you could define the trust domain as being the class workloading cluster. A can talk with only a certain resource in cluster b because they have established a trust mean between the two of them, not between the two clusters right yeah, because if we're talking about limited trust, that's the most limited you can get.

J

Yeah that makes sense and then like, like you've, always saying that the the gateway would live in one of those. You know the the target cluster and would know and be configured and instructed by let's say service measure to you know: to have the capability to do that: identity, translation to to link to make to make that trust boundary. You know that the server the service in that target cluster part of that trust.

J

E

Okay, so I I don't know: if does anybody else from our side have a more question, but I mean I think at a general level. We understand what you're doing um I I guess. Maybe the question would be if the specific areas that you're looking for help with- um and maybe we could take that offline via that other meeting eat it. But I think um we would like to try to get some people more directly involved and contributing to um the code base.

F

F

Definitely so john, maybe me and you need to talk somehow and kind of like said it.

E

Yeah, maybe um maybe, but I I'm not the uh I'm- a technical guy, not the guy- that controls the resources either. So it's uh uh we probably should oh we'll figure it out I'll I'll talk about after this media. At this meeting and figure something out.

F

That sounds good, as I said for the meantime, I think that uh you know you guys know what we're working on it next right. So the limited trust the you know, bring backup mesh, osm and then uh also the the routing based on localization. That's the stuff that we're focusing on right now.

F

E

So I I hate to bash anybody in this call, but um osm is fairly fairly new right, fairly green yeah.

F

So so I mean this is this is uh the reason we're doing. It is very, very simple.

F

I believe that in the nutshells eventually uh they're going to you know like the question: if, if a mesh will succeed or not to me, it's based on, does it add an audience to use it is there is a purpose already for someone to use it and osm will be eventually being used because it's being used in azure right, that's, basically what they're going to do so, all the clouds, the 3b clouds they're, going to have a match and they're going to use it and they're going to use their own mesh and therefore I believe that that's going to be something that will catch eventually.

E

um Well, I mean that's part, that's that's why this project exists more than anything.

F

Exactly but there is a lot more more more service measures. That's why I'm less optimistic about right. I think that they will not survive or I think that they will disappear by the end of the time. I don't think that though osm and upmesh is one of those. I think that sto up measure you know sm will be here to stay.

F

I believe that believe that ashikop, it will be something like, in my opinion, one like nomad. It would be an alternative that people will use, but it's not going to be the most people right. It's like exactly like, nomad right people using it, but it's not kubernetes right. So this is the way I'm looking at this. So when I need to target what is you know, you know what is the future of this project? That's where I'm tempting to do.

F

Of course, if you guys think that there is other project that you know other mess that are more interesting, you know this is a community project. Everybody can end. But to me this is the one that I I feel comfortable about. Putting resources on. Does that make sense.

E

Yeah, no, I I mean I would agree with you from the public side they're all going with their own specific meshes and that's likely. I don't see that changing. um If, if it was to change, istio probably had the biggest lead, so it would have been. You know a gravitation toward that, but that's not happening. um I guess the part that you know has a very keen interest to us. Is you know, as the on-prem type data, centers and cloud environments start building meshes, you know, do they use link or d? Do they use istio?

E

Do they converge to one I mean? That's, that's the part. That's the wild card right, yeah.

F

I think that, right now by far sdo is the most mature uh and stable one I believe like when we are. We have a lot of customers, the customer. You know we are on the field constantly. What we're hearing constantly from our customer is sto. That's the only one that you know.

E

Did you mean that.

F

Probably will be the one that most of the people using and then I will argue that if they will go to azure or if they're going to you know, do to aws, they probably want to use natively what they're supplying that it's probably not going to yeah.

J

I think I think everything is uh that we've talked about in terms of supporting istio and app nash and osm uh is dead on. I also want to point out that, by supporting these multiple meshes and further refining the you know the internal apis that we use to be able to support them in service mesh hub, and you know, try to get uh parity with some of the the features that might exist or or in some cases, lack of lack of exist and in these different meshes it'll make it a lot easier.

J

Let's say: istio doesn't continue to be the dominant uh self-managed service mesh. It would be pretty straightforward at that point to add, for example, that maybe console uh starts to gain market share or whatever. um So I I think right now we're focusing on what we see as the the right ones, but we're always happy to have feedback from from you all or anyone in the community that says actually what you're doing with service mesh shop should apply to these ones over here as well.

N

Yeah I mean I I was just going to add. I think the dry, the drivers that we've seen at least with the customers that cisco's talks to um have have not been which cloud they live in um it. It's been more their um how their skill set with the api that they're already. You know how how much of investment they've already made in in integrating with an api.

N

So um that's where we see istio way out ahead, um maybe maybe that because the concepts are so similar across these meshes, um maybe that's not as big of a deal but um there's a significant.

N

I mean from our point of view that people, the the there seems to be a significant investment already and integrating with the cis. It's the o api and operationalizing around istio. So I can't see like just because I went to app mesh. I mean I went to aws, I'm going to jump into app mesh full. You know fully right like or I went to uh gke or you know that that's kind of how it seems to us, maybe for greenfield where you haven't, started, investing in a integrating with a mesh.

N

uh Then it's yeah, maybe you're you're right the the models around um how how maybe it's wide open right for for how people foresee the future.

F

Do you say that you don't think that if someone will want to use aws, you will use app mesh? That's what you're saying.

N

No, I I said they if they've already invested in in integrating with istio. That's what we've seen that be the driver of they've. Stuck with that. You know they haven't really looked around. I guess even what um the cloud native I mean public uh cloud apis that that are that are native to that environment.

E

I I I think another way to say what tim is saying is that we, in our experience, are early adopters for um servers. The customers that we see as early adopters or the customers we've talked to, who are early adopters of service mesh that also use amazon, um don't show a lot of interest rap mesh because they've already, you know been.

F

E

Time on istio learn how to integrate with it, and you know think they're further ahead. Now.

N

N

Maybe their interest in that mesh is not they're, it's not to replace their istio usage. I guess there's another way to say it right.

F

I think I believe that if you will run an app on aws um app mesh will give you functionality that you will not be able to achieve with this. For instance, serv serverless.

N

Yeah, that's where we see like there's, potentially the the the gateway function between serverless and then I mean like app mesh is is great for for that aspect, and I think that's where we when we've talked to people about aptmesh, it's been all around like serverless.

F

The fact that it's free and it's the fact that it will be seamlessly integrated in the eks. I think that you know it's just this just started, I'm a big believer that eventually, that would be a big. You know a big advantage to one with a abner, and we see that we from our customers so.

J

In the field we do see, we see people who are on this deal today and who have been on in our on amazon and they they have been reluctant or they haven't, moved or put anything on app mesh, because app mesh didn't have the features that they needed, but they are anticipating, and one in particular, is anticipating by the end of this year, that atmesh will have the features that they want and they will actually move off of istio that so that's that's. You know we're seeing we are seeing some of that, but we.

F

J

The folks who, like you like you, mentioned, um who go to amazon and then like edit, was saying that they they do want native. Somehow, better integration with the service mentions they use on amazon, so yeah.

F

Deeper into the services.

J

That amazon provides and istio will never get there, but at mesh will could could potentially and uh that that would be a reason then to to use you know both not not uh starting off thinking that you're gonna use two service methods, but you're gonna use the networking technology that you know best suits the the problem space that you're you're trying to solve. That could be.

F

Smh right, so you really don't care because they that you're going to use will be the smh one and then for you. It doesn't really matter using sdr if using cement, if you're using osm, if you're using anything, it doesn't really matter. That's just implementation details right and you can swap theoretically.

N

Yeah yeah, I mean that that's the attractiveness for us to smh is just um you know that that driver we thought we think we see, I guess, um for the um the complexity around using a service mesh api. um If you're going to invest in that, then why not one that you know an api that works across multiple service mesh types right like that.

F

And I think what we should at least the way I see this. I think that what's interesting in service mesh, is it's it's interesting for sure and giving you a lot of functionality on one cluster, but I think that the multi-cluster will be extremely more interesting. So I think that a lot of the feature that we can do on top of it like fell over, like you know, uh um as I said, rowing based on localization.

F

So that's will be the interesting stuff and guess- and you know, then what are you going to do if you have an app machine as in aws and an sdo in? uh Oh, is that going to work on that right, and I feel that the fact that we're putting this obstruction is exactly that we'll be able to put interesting stuff on top of it, and we will not care about the implementation of this.

F

So a lot of stuff that I can see like, for instance, the loop project that we did before uh you know using a lot of stuff that recording networking and base that can so a lot of interesting stuff, akios monkey and so on. That can come on top of it. It would be very useful if they will all speak the same language and then it's implementation data, no matter what.

B

Yeah, I'm also curious and not very related, but uh there I haven't seen any discussion about traffic director and, uh like the google cloud, seems pretty big and uh I don't know, are there any plans or is there some problems with the integrating with traffic director.

J

So traffic director today is very simplistic. It is obviously it's a managed control plane. It doesn't support the istio apis. Yet, as far as I know, they keep saying that it will at some point, but then, when it does then obviously well, that will will be in in a position since we support the ceo of servicenow to uh to integrate with traffic director and any other additional configs that you might need for for that. But right now it doesn't it's just a very simple um config store for or xtds for, onboarding.

J

B

I

I I had one last question: um I think I guess like when we create the service crd manually right. Is there any way to influence the sql service entry creation?

I

The only reason I'm asking is: we would probably want some custom addresses ap ip addresses to be specified in that service entity which estimates it automatically today. So do you know if I can use some apis to do that or.

K

So that that kind of gets back to like how the mesh service works and right now, as scott mentioned, it's it's pretty, there are aspects of it that are tied to kubernetes services, so you know the way that we find those ips um is via.

K

We. We basically look on the service to find you know, is it a load balancer? Can we use one of those ips? Is it a node port? Can we find the ip of the node? You know blah blah, but potentially a very simple option could be a hard-coded ip or something like that or some. You know some mechanism that we put on the uh on the mesh service. So it doesn't do our discovery mechanism for the ip.

I

Yeah yeah, that's that's cool.

J

And I would say that's how it it's working today and we can and but but the question is actually a little bit more more broad in my mind, um because what at a higher level, what you're asking is what? If we want to be explicit or create our own entries of services, that then can be discovered across multiple different clusters right.

J

So I think, that's more generally the question that you asked specifically: that's you know, that's how istio does it, uh but that in my mind, going back to what it said right when you, when you have this management plane and even the api to support it, you can build things like failover and routing localization like she said, but also service discovery, and you know the identity federation and, like all of these, all of these things that you can build on top of uh service mesh hub.

J

So that is an area that I think you know depending you know, we can go into more about what your use case is, but I I see- and I think we see the opportunity for for solving those types of problems across cluster using using the primitives that we're building.

J

F

Thanks fantastic uh awesome, so I mean we will try to put some stuff in writing to make sure you know kind of like put a little bit more structure around the community uh and again any requests or a you know.

F

Feedback will be very very useful here if there is a way that you prefer that that will be one in life yeah. But I think this is our homework and our action item and yeah and and john I don't know if you are the point person you're, the only one I see because you're the only one with a video picking on you, but uh if we wanted to set up some stuff for some time offline, more kind of like spread the word to be very yeah.

E

I think I think I think we need to, uh as we said in the last couple calls we would like to try to get it more involved. Try to actually do some specific contributions, okay, um and so we need to figure out that process. uh We're not been a little bit uh both on our side and trying to figure out the community structure, how to do that so yeah.

E

Let's talk offline, a little bit I'll synch up with vjoy trying to figure out exactly if he has a model for how to do this or if he his model might be john go go, get it done, but that might be his model, but I better check with them first. So.

F

Fantastic and as I said from our side, it's probably will be me and jonas hey joe running on this, so.

E

Okay, great okay sounds good. I will uh try to figure that out within the next day or so, and uh you know uh contact you.

F

Fantastic awesome.

E

Great. Thank you good.

J

Chatting with you all.

N

A