 Welcome everybody. My name is Luca Villa. I'm a solution architect for that and And I am Giuseppe Bonocorrema solution architect too so Thank you for coming To this presentation about the east your real words scenarios Through this presentation, we will walk through this Topics, so we will Discuss about we will do a brief introduction about the technology itself and its features and then I will Hand over to Giuseppe who will discuss the interesting part of the presentation so they the real world use cases Istio Well, this comes from the needs are to to face a complex challenges when you have to move your workload to to cloud To cloud infrastructure where the developers that need to adopt a microservice approach And the the operator need to face multi cloud and And the hybrid Infrastructure that grows and become very complex to manage. This is where Istio comes into place it provides a Service mesh that can be layered to existing Distributed application architectures and at the same time it's a platform that that provides API and the ability to interact with the existing log back and login backends or auditing backends and so it is Eases the the job for the operators Istio So when you have an architecture of microservices you just need to Deal with the the way all the microservices in Turkey communicate to each other Istio offers the ability to to deal with the rooting of the of these components to to secure the connection the communication between the components and To observe what's happening in in all the the parts of your of your mesh and This is done with By leveraging some External tools like Prometheus from monitoring which is useful for monitoring and alerting grapheina to do time-series analytics and also Kali, which is a web user interface that Provides the ability to have a graphical vision about your network mesh and the finally Yeager Which is for Distributed tracing so One of the strong point of Istio is that it separates the data plane from the control plane so It allows to Manage the interconnection between different microservice different services by Using some intelligent proxies, which are based on envoy. So These proxies are coupled with the each sim each it's each service and They are able to to manage the the rooting between services and to secure them through TLS and This whole happens By injecting this proxies into the pod so without touching the service itself but Coupling the service with the with the proxies itself, which is called the side the car for this reason At the same time we have the control plane where All the configuration stuff happens so the the proxies are configured through the control plane and The all the policies are enforced the all the certificates are distributed and managed and so on so Traffic management happens by Well, if you have an infrastructure that scale you don't want to manage this dynamic this Dynamic within your application because this makes things very complex so the coupling the the infrastructure scaling from your data flow is a lot the Configuration and the managing of your mesh so In this case, we have the pilot which provides the all the configuration in the information for the Rooting and the traffic rules to the to the proxies and in you can set very Dynamic rooting rules so you can do a be testing or you can do Canary deployments or gradual or loud or you can even Do failure failure recovery by setting timeouts or Setting some circuit breakers and finally you can even inject faults to test the resiliency of your infrastructure to to false and to To set to test the compliance to the recovery policies Istio Assumes that all the traffic that comes into the mesh are passing through a proxy an envoy proxy this allows to to set this dynamic rooted policies so a be testing or Our canary deployments also for the user facing services At the same time you can set any in egress gateway so a proxy for the outgoing traffic Which is not mandatory, but it's a strongly suggested because in that case you can deal with failures even to the traffic that is flowing to external services and You can also do fault injection and test the behavior in that case And the pilot is responsible for Keeping the fresh list of the services that are registered with the platform And to make this transparent to the application itself And also to the to the invoice proxies So it's a pluggable architecture and For instance here we see that it interface with to Kubernetes and it provides the Service of the service discovery to to the proxies so that the proxies can have also Always a fresh pool for doing log balancing for instance Istio also provides a an interesting set of security features it provides strong identity and Transparent Encryption between all the services Provide also the company policy enforcement so and authentication and auditing All these components all these features are provided through the components that you see in the control plane so you have Citadel for instance, which is responsible to deal to manage all the certificates and keys generation and refreshing The pilot that is responsible to provide the strong naming for the services and and access policies and authentication policy authentication service and the mixer which is responsible for Authorization and for auditing and So the the goal of Istio is to provide a Secure by default mesh where they all the the burden of keeping the infrastructure secure is Taken away from from the application itself and to some extent also from the operators as we said then the mixer is responsible for auditing and all the authorization part so it interfaces with a set of Pluggable backends like logging backends quarter backends and so on and So it even in this case it The focus is on giving more control to operations But the same at the same time keeping safe the the application part from all this As we have seen at the beginning all this is complemented with the a series of tools one is keali, which is the user interface for for Istio and it provides some visibility graphical visibility of the the topology of the network and from different point of view and you can also Look into the configuration objects of Istio these are just a couple of Screenshots, so here you see the namespace graph and where you have already at first glance when a set of informations like like the status of all the roads and the objects and the statistic about the errors and This is a versioned application graph where you can see different version of the reviews Service and how they are interconnected The last one is a Yeager, which is for distributed tracing this gives the ability to to do Very detailed tracing about the the the mesh and the application and So you can see here there is an example you can search by service or or something else and you can see all the traces that are child and Every trace is compound of different spans and you can dig into every single trace and You can see Where most of in this case most of the time was spent during the operation Thank You Luca. So I'll look at told you very clearly. This is the interesting part of the presentation So now I feel some pressure about this and I've also got a spoiler about my slides So this is not so good. So joking apart as I was saying I'm a solution architect Which means that my day-by-day job is going into customers and trying to explain this kind of stuff in a Comprehensible way for also for non-techy stuff and the wall idea behind this presentation is that All we said with Luca so hold the infrastructure about the Istio and side cars and proxy and whatever This is something very interesting for techie audience But what we feel is that the customer is very interested in this project and we need to link back This from features to what the customer really needs and what the customer really want to do So it's not all about the technology. So the side car the proxy and all the kind of stuff But is what they can do with this and so the idea is you find a lot of Information on the net on the internet about how Istio is done internally But let's try to have a look at the use cases what the customer can really do And this is the reason why a lot of customers are really interested and reach out to us as a solution architect has read that To to understand when Istio will go GA because they feel that this can solve in an elegant way that they're real use case But let's have a look at this scenario. So Look I was telling us One of the most important things in Istio is that you can inject policies and you can drive your traffic in an Advanced way so you can do advanced routing as you can say as you can see in these lights We are trying to put this kind of template in which we have a Graphical way of seeing the flow of the traffic then we have Some words about use case and how often how common it is how often you can see this at customer So this is somewhat a bit common and what it doesn't mean advanced routing It means that you can request by request of course giving some kind of Configuration we will see how you can route some specific kind of traffic to different version of the software And this is something very important because as you can imagine this can drive a lot of very different Advanced deployment scenario. Let's have a look how you can do this in Istio This is of course a subset of the rule you have to inject is not something copy-pastable, but it's just to give you a glance So one one of the ways to do this is to inject a rule in what in in in this rule You just inspect the the request coming and as by example in this example You can match another an HTTP header so the idea is that you can find another called by example IP location because Some something else in your chain is doing a geolocation and is the injecting this this header and you can route all the Request having this other to a specific version in this case version which was as you can see We are imagining two different version of our website as an example and you have everybody going to a version and Users are users coming from the burn area coming to a different version So what is inside this? Why this is interesting because can enable a lot of different advanced releases? first of all is as in our example of before is a Geographic adoption of the stuff many of my customers are banks and they want when they release a new stuff Open up just for for the offices in Italy open up just for the office in check Just to understand how is going on or maybe because in that version there are some feature related to a specific Low or something that has to be enabled just in one geography You can do this without touching you without using basically feature flags or without messing with your with your external Of balance and you can do that just driven by code and if you think about that you can Also have something specific for I don't know user profile You can have that some specific demographics goes into your into your specific version of your of your software And this is commonly named as many of you already knows blue green deployment a specific Version of the blue green deployment called a be testing is something very relevant as an example for online shopping In which you can do you want to do? Business testing against real data So as an example if I'm an online shopper and I want to put a specific button of a specific color And I want to test the conversion of this I will set more or less with that version You can do it and this is a very specific use case of blue green, which is called a be testing The last one which is something that we had in real life. We had a bank asking for this is a Specific sub case of API versioning we have banks that are this point of sale devices on the field They have it from different vendors and maybe they have to do a release for I don't know Security features or because they have a firmware update, but they want to do it on specific Vendor point of sale, so they don't want to do it for everybody and also in this case inspecting as an example for The the the agent of the of the point of sale So in the HTTP header they can inspect which the vendor is and serve a specific version with a specific patch Just for this device so they can manage to have in production Multiple version of the same application and in an elegant way drive specific audience to a specific version Can I release in many of you already know that so incremental release? This is not driven by a specific demographic or a specific kind of request, but just to test how your New version is reacting against real life traffic So this means that as in the in the mines they have a camera They can test if the new application will die because there is gas or not This is what is happening with cut with cannot releases You have a rolling an incremental release You have 1% of your traffic and you can test how your application behave then 2% and 3% up to 100% and it's very easy to roll back if something goes wrong This is how you do that in in Istio, so you add these weight parameter and you can just load balance and having In this example you have 1% on version 2 and 99% on version 1 of course, but you can roll this What is the real world scenario behind this of course you can test application response against the real world stack So you can have the wall Stack of application meaning Real database real, I don't know the integration system and stuff like that And you do that with true traffic in a controlled environment. So just 1% of your of your Customers or you can evaluate your impact on downstream stuff So as an example, you can understand if in your release you are introducing some kind of regression against SQL queries on your database or you are doing some computational stuff Which is heavy and you don't want to that to do that Less common you can have the traffic mirroring. This is very interesting You can with a simple attribute mirror all your traffic against another version of your application also in this case And this is Somewhere mentioned it does dark launches So you can have that all of your traffic all of your customer data goes into your real life Version but also into another version you have a shadow copy of our application and even in this case In an easy way you can test your application against real life data in this case You do you will not have the impact on your customer base because the traffic is mirror So your customer goes into the real application, but the traffic is also copied onto a shadow copy You can do this in a very easy way using the mirror Attribute so as you can see you have version one and version two and the mirror attribute and What's inside of this of course stress testing against real data also in this case But you can also use it in functional tests So you can do a test against the same input and understand if your application behave in the same way So it's kind of let me say end-to-end testing and you can have the guarantee that your refactoring is going well as an example Fault injection, this is something very difficult to do without Istio You can basically in every point of your service mesh We have seen before you can inject a specific HTTP fault or you can inject a specific delay and so you can simulate Stuff going wrong into your infrastructure This is something that is very hard to do in a real-world scenario without Istio Instead with Istio you can specific this fault directive and you can see You can specific the HTTP status you want you can specific the percentage of requests that has to fail and basically you can also use a match so you can Specific saying which kind of customer has to get this failure And this may be useful to implement a cause monkey like environment so you can inject specific failure and you don't don't have to Have a specific version of your you don't have to ask your developer to do this injecting I don't know feature flex or stuff like that, but from behind of your of your application you can inject this Last but not least ACLs. This is something that security ask every time when You have a customer which is trying to go from a monolithic application to Microservice or at least to split their monolithic application into different application They want to understand how they can put this kind of security directive into something that it was supposed to be Just one process before and in this case You can of course input policies look at all that's before that you can manage to input security policies on Every basically service every network span inside the the Istio service mesh. So This is something that you can do With this kind of configuration so you can use an handler you have to declare a rule This is something a bit more complex to implement Of course, this is just a sample, but you have to fiddle about to implement it But the idea is that you can give to your security department the visibility on what is going to Upend inside your network. So they can for each network span specifically say who can communicate with who and What it has to be denied and it's more granular than than what you can do with Kubernetes by design by default without Istio We also collected a couple more use cases One more use case is a rate limit in this case You may have a downstream system an external service which is Expensive and you want to limit the number of requests coming into that external service And you can do this with this is not so common, but it's somewhat something interesting It's not so common because usually you want to do rate limit from from the the calls coming from the external of your network but in some cases you may want to do it inside of your network and The real-world scenario as I was saying is to prevent Some expensive system in terms of of money or in terms of computation to be from being called too much from being over called This is something not so easy not so easy to to implement with the rules You have to declare a couple things more is a configuration Which is a bit more complex than we've seen before but nevertheless is something that it's interesting to implement with Istio because it's Completely configuration control so you can have it on your own And last but not least you can implement circuit breaker, of course everybody here know what circuit breaker is, but simply you can Basically avoid an external system, which is not responding in a good way from being Futterly called and from starting to impact all your application So you can just isolate the fault to a specific network span and you don't have this fault to be propagated to your Complete application basically and The effect is that you can increase resiliency because your wall application will be protected And on the other side you can also support the link of default service because if you have an external service or also a pod Into your Kubernetes network, which is starting to behave in a bad way You don't want to keep calling him because you can worsen the situation So you can just isolate the failure and let give them the time to reboot or whatever it's needed So this is about time for question if you have You can do it also at an MSPACE level of course there is an overhead But the idea is that invoice lightweight enough to scale up to I don't know maybe Hundreds of quads, but I don't think there is any kind of real-world data so far on very big mesh So I I think that Could be painful not only because of the overhead of each side a car But also because of the traffic that will span on your network because every side car will have to As an example send packets back to the open tracing staff or we'll need to from time to time refresh the policies So I think that for very huge network you will probably Know not want to inject a side a car on every point of the network, but of course. Thank you for your question Yes, please. I think there is some yaml to do that Yeah, there is also some documentation you can in theory do it also on But it's very heavy in on on resources Probably with top issue for it will become a bit better. Yeah, thank you for your question I do think like you that there are a lot of overlap that probably with time there will be solved with a bit Especially I agree with you that there is an overlap between network policies and and what is provided in Istio Even if I think that probably what you can do in Istio is a bit more fine grained because you can in theory deny or accept any specific quest any specific Request coming based on the content of the request. Sorry. We will we were Looking at HTTP other but you can do something different also because Istio has the authentication Embedded so you can look into the the credential. So probably is a bit more granular about the The overlap with the middle or stuff There is an overlap with fuse for sure for something as an example fuse Better camel provide its own circuit breaker, but it's implemented in a different way because it's embedded into the application instead with with Istio it's It's in the in the sidecar. So Different architecture probably the same use case about three scale I know that there is a project of integrating three scale with Istio The main idea here Taking apart the names is that in theory API gateway should be used only for traffic coming from outside into inside and Istio should be used it for the intra cluster traffic. This is low time I think and also I think that right now most of customers are looking into API management Mostly for authentication and reporting not for all the other stuff you can do with Istio As for real-world use case. I have at least two customers looking into Istio Of course, I don't have any production experience because it's not GA so far The two use cases are the one about point of sales So customers which has I don't know maybe thousands of points of sales and they need to Manage different version and now they do it Completely manually and it's painful and the other one. It's more about Visualization because customer when they start to split up their application into Different microservices. They lose the visibility into the flow. So for troubleshooting or I don't know Performance tuning is painful and this is probably the most interesting thing for my customer advanced releases and Monitoring let's say or at least having a bird's-eye view or what's going on into their Kubernetes mesh Any other question in theory can be linked into the User itself because you can authenticate the user against Istio. So yeah, it maintains sort of a session You can do like that in theory Istio can manage the the encryption for you So yes, you can change encryption and policies of I don't know advanced routing. Yeah Mutual TLS is one of them the security features that Istio provides And you can choose to encrypt Or not the traffic between all the microservices or all your services Personally not as I was saying personally, I don't have any production experience I would expect to be less than 10 percent. There is a bigger panel effort in Performance of all the components which are involved especially The ones that are in the middle like the the proxies of course and the impact is quite tiny but the the goal is to improve farther Performance of the As you can imagine some of the stuff can be cached as an example the policies and all the telemetry stuff can be cached some of the stuff can be done in a sync way like the All the monitoring stuff all the tracing stuff But nevertheless you will have an op more in your in your network connection So I would expect any way some kind of penalty. I I expected this to be as small as possible Yeah, this may be more or less relevant depending on the kind kind of application that you are dealing with so in Normal application that are not very Bound to network performance This can be not relevant of course in other cases this can have a begin Understand That's a good question actually Maybe a couple of weeks ago. We had a customer which was was asking about Having an intrusion prevention system into the service mesh. I'd never seen anything like that About debugging. I think that in some controlled environments you can do something because At the end of the day in voice is a C++ component So I expect him to have some kind of debugger that can be attached or at least some some logging of course But this is for sure something very interesting to explore. I think no more questions. So thank you for your time