Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2019 (Barcelona), 21 May 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Lightning Talk: Using Istio's Mixer for Network Request Caching - Zach Arnold, Ygrene Energy Fund

Description

Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io

Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects

Lightning Talk: Using Istio's Mixer for Network Request Caching - Zach Arnold, Ygrene Energy Fund

Service Meshes (and Istio in particular,) have helped application developers off-load a good chunk of logic surrounding network requests. Our microservices should be as close to pure business logic as possible, but what happens when we add so many services that our network requests are dramatically slowing the application down? The natural result is to look for some caching of requests on either the client or service side. Enter Redis, Memcached, and other caching tools all to help reduce network calls and overall latency. All of this comes with implementation penalty reducing the purity of our services. We will demonstrate how Istio's Mixer component can be used to cache requests at the request level and how that can keep your application fast, without ruining the purity of your services.

https://sched.co/MPgT

A

I've never stood still so I will do my best, but if I keep going like, don't blame me, okay quickly, the section that you will skip if you ever watch this on YouTube who or what is why green? We sell money, and that is what we do. We finance specifically clean energy improvement. So basically you want to put solar on your house. You can pay it back through your property taxes. That's really good! It's also the word energy spelled backwards. I did not know that until six months into my own child.

A

Okay, let's talk about the humble micro service. Theoretically, this is great with absolutely zero drawbacks, as we all remember from hearing about micro-services the first time, amazing buzz phrases like loose coupling and dependent management and all the other stuff that we say that we love about microservices and an artist rendition in the bottom right hand, corner of what a microservice looks like, but at least for wide green.

A

This carries a considerable cost: adding network hops, complex, debugging scenarios, authorization, authentication version, coordination between api's management burden for third party dependencies, especially when security patches come in for other frameworks and I'm assuming many others. So we end up having application architectures that look roughly like this. This was taken from an actual network request in one of our micro services, so my understanding of web-based services is essentially that there's a lot of stuff. That's the same. All of everything that you see in Orange likely doesn't change from service to service.

A

I need to turn this way so that I can see it with you. Basically, we all have hardware that runs things. We have languages system, libraries operating systems and runtimes. These are like servers and containers kubernetes things like that. We have web frameworks, third-party extensions things like Ruby on Rails or Java spring or other frameworks, and then AB things that are more specific to our application or things that are specific to language. Implementations of web based services.

A

So performance things like resilience, hystrix comes to mind and honestly, thank goodness for the amazing developers and companies contributing as much as they have they've made it basically super simple for all four of the bottom things to be the same for all of a and very standardized, but the problem is the top.

A

Is the only thing that really ever changes so in my mind, that should be the only thing we've worked on, but unfortunately we spend most of our time in the bottom for justifying why we need to rewrite everything because of some new thing that happened in the middle, like a new framework, came out a new version of a JavaScript framework that we now need desperately. We need to put in ok. So what's the point?

A

Well, I'm not leading a revolution in micro services, I'm, just hoping that maybe one less thing becomes a problem for people and simply can we use a network tool like sto to handle one of those things and here's an arrow to point to one of those things that I was talking about SEO by and large part quick show of hands who, when I say the word sto knows roughly what I'm talking about?

A

Ok, so that's most everybody for those of you don't if if kubernetes is I'm, sorry, if yeah, if kubernetes is the kubernetes of running runtimes, then sto is the kubernetes of networking. Essentially it's just another thing that runs lots of things and orchestrate stuff and I was not expecting the Ovation at that point, so the application-specific performance and security and resilience, and all that good stuff is now wrapped up into a nice DSL and implemented in this sidecar pattern.

A

That's very complicated at first, but then, once you get used to it, you tell yourself that you really like it so right now: sto handles request, routing retries fault, tolerance, authentication and authorization, but it doesn't handle request. Caching and I'll explain why that matters in just one second, actually, the second. Why would you care, because you can delegate request to the network things like long live, JSON, payloads or other things that matter that don't change a lot that impact the performance of your system.

A

We end up writing things like Redis, Redis, extensions or evey cache in the case of Netflix or memcache D, or things where we're implementing all of our own stuff. So, right now, there's work in progress with on void filters to basically allow for response filters. It just basically means that we can have a layer of network caching that has a TTL think of it like a DNS record, but for JSON. So here's a practical, compelling use case.

A

These are real wide green services that really do things and but they're very simple, and they look clean and and and that's the difference between that and what actually happens. Service areas basically contains this gigantic JSON payload about everything that we can do to service a jurisdiction at Y green.

A

We can basically charge people for money that they borrow from us and essentially that has to be called by all of these services all the time and it's a one megabyte payload that basically doesn't change, because it moves at the speed of government and that isn't going to change a lot. So what? If? Basically it ends up? Looking like this, where one time it actually does request it, and every time after that, it takes microseconds for the response to happen.

A

I think that that could improve the resiliency and if you are interested, please hop into the ISTE unarmed boy community. Thank you very much for your time. I ran out.