Kong, Microsoft, Kuban Attis discussed on Software Engineering Daily


Still extremely fast extremely performance and via plug ins can also be extended to do things that perhaps Kong doesn't do out of the box in a service, mesh deployment. But you're right. The feature set of north south and the Fisher set of east-west is very similar and all the things we usually do in east-west or all the things we do in our. South will have to adopt in more and different patterns. So being able to rate limiting circuit breakers. Al checks being able to keep that late and down being able to observe what's happening within our systems. It's not a concern that's specific to one or another. It's a concern that both nurse out and east west will have to fix and therefore Kong is being used for that today. So is the service mesh model for Kong is it the model of deploying aside car to each of the services and then having a central control plane that the sidecars are communicating with you got it. So you're getting nine deploy Kong as a service mash by injecting Kong as a sidecar proxy to a Microsoft Office. But get spot from agnostic. So you can do that with Kuban Aries you can do that with a sidecar container. But you can also do that on any other platform that supports so conch supports fifteen different deployment methods. We support any. Containers Mazuz feared Decio as we support vanilla Docker. Of course, we support any cloud, Azure, Amazon Google, and we also support bare metal platforms. So basically with Kong, you could start a service mash that runs across Kuban Attis, but not limited to coober nineties, also Imprimis and on machines and any other cloud. So effectively it's a platform agnostic hybrid mash that you can deploy with calm when I've talked to people about service mesh performance is a really big concern. Because if you have for example, a service proxy, that's deployed is a sidecar to all your containers. And it's sitting next to your service in every service. Request is going through that sidecar. For example, if your service proxies written in Java, then even just a pause can really give you a serious performance penalty. And that that can be problematic. If this thing is is a bottleneck to every single service request, tell me about architect, dating the sidecar what you have built in the sidecar turns out that when we built our run time. So like we said engine X low and loo edge it we're able to achieve a great performance in most use cases, Asaba millisecond processing performance. So that same Runtime we've been running for traditionally pay gateway is also so lightweight and so fast that out of the box it support service mash, so that's why we were able to support one run time for both east west and north south. That's pretty cool. That sounds like a bet you were very happy to find that out. Well, it happen for a reason. I guess so I mean is there any is there any material? So what you're saying is basically the same software that is in the API gateway that has been accepting requests from the external internet and doing routing through the API gateway in a performance fashion. You can just retool you can just repurpose that in Assad car to be able to have services communicate with each other. Yeah. Not only that we can do that with a better performance than envoy, for example. Really? So tell me more about like how you think this market is going to unfold because I was guy go to these kube cons, the Cooper, Netease conferences, and there's if there's any water cooler, or like, you know, hot hot topic right now, it's sort of like, what's you know, who's gonna win the service mesh world or do you need a service mesh? So how do you think this world is going to unfold and how big of a market? Do you think there is for the service mesh? Usage, you know, Microsoft disease that are very hot topic right now, not everybody needs Microsoft disease. I mean, Microsoft sees that are harder to deploy harder to manage his anonymous significant premium that developers will have to deal with once the move to Microsoft sees. So it's a great architectural pattern. If we're talking about extremely large use cases that have to be hyper scaled in hyper optimized with micro services architecture. Now, are we talking about Microsoft uses the way, we make that Microsoft's architectural work is with service mesh service mash, it's not at the -nology service mashes a pattern, and so you can implement service mash by using a wide variety of technologies that are available to developers today..

Coming up next