What is Istio? It's a service mesh. Great. What's a service mesh?
Nick Chase - September 24, 2017
I don't know too many people in the technology space who don't have an opinion about the fact that after 35 years, we're about to get a sequel to Bladerunner. Bladerunner presented us with a technological future that was so fully-realized that many of its signature visuals, such as animated billboards and video calls, are so common today that kids who are the age I was back then probably don't think twice about them. The thing about Bladerunner, though, is that because it was so fully-realized, it got people like me thinking about what COULD be done, if we just put our minds to it.
For a lot of years, that's meant large applications -- and a lot of sustained work. But not anymore. One of the consequences of our technological plunge into cloud native architectures is the emphasis on microservices-based applications, which means that a single service can provide immeasurable benefits to multiple applications -- sort of the ultimate "code reuse" use case.
But when you've got an application that consists of dozens, hundreds, or even thousands of these individual services, how do you manage that architecture without having your app -- or at least your sanity -- run completely off the rails? What we need is an architecture that provides a way to connect, manage, and secure these microservices, while also providing load balancing, authentication, monitoring, and so on.
If such a thing existed, you'd want to get involved, wouldn't you? Of course you would. Well, here's your chance.
Istio is an open source project that does all of those things, and on Monday, September 25, they're having a user-testing "hackathon" event. We thought we'd get the details directly from some of those involved in the project, so we spoke to Google Software Engineers Douglas Reid and Mandar Jog, who are helping to lead development efforts.
Nick Chase: Gentlemen, thanks so much for taking the time to speak with me today. So for those who don't know what Istio is, please explain it.
Mandar Jog: Istio is a service mesh that provides cross-cutting functions that all micro services environments need (Learn more about what is a service mesh by reading our guide to Istio). So for example, you need traffic management. You need to find those services that you need to reach. Someone needs to decide who can talk to what service.
Then there is observability, which is basically the telemetry and metrics. So you need to find out how many times something was called, and get maybe get traces as well. Logs come in to the same area.
Then there's policy enforcement, which is access control, or any kind of specific policy-making decisions about whether a particular service would talk to another service, and under what circumstances.
Finally, Istio Auth provides identity and authentication, so that's service-to-service authentication and a central authentication on which you can actually base your overall identity and authentication story.
Douglas Reid: Those are some of the functional things, but to take it from a different perspective, I like to think of Istio as the product of user experience at Lyft and IBM and Google in deploying, managing and serving software in a distributed environment. This is sort of the set of best practices that we've learned over the years the hard way about things that make it easy to manage systems at scale, especially in distributed systems.
NC: So basically what you have is this sort of cloud of microservices and Istio is a kind of a request orchestrator?
MJ: Istio sits in the gap between these different services. It intercepts the request then does all these things that we talked about earlier with those requests.
NC: So I hear Istio and Envoy talked about at the same time alot. What is the difference between them?
DR: Envoy is a component of Istio. Envoy is the proxy that sits alongside services. It is the data plane layer of Istio. Istio also comes with a control plane, which is called Pilot. Pilot controls Envoy deployments and helps configure them, and also Mixer, which helps make policy decisions. Envoy calls out to Mixer at request time. Pilot also controls the deployment of all the other pieces that Envoy uses to secure traffic.
NC: Is Istio sort of staying off in its own corner, or are you building relationships with other projects to create an ecosystem?
MJ: Definitely. For example, LinkerD now works with Istio. They can call out to Mixer, so basically LinkerD, in the simplest terms, can replace Envoy as the request interceptor or as the proxy, and then just as Envoy calls out to Mixer to make policy decisions, LinkerD can call out to Mixer to make policy decisions. And then Nginx is also it's also working on, or already has kind of announced, that they're also going to be talking to Mixer, so you can use Nginx as your proxy instead of Envoy.
In fact, the protocol between Mixer and Envoy is well defined and published, which means that theoretically both of those are replaceable. So as Istio, what we really define is that configuration surface, and how Envoy is talking to Mixer.
DR: Mixer has sort of adopted Prometheus as it's built-in metrics reporting mechanism, but we also have plug-ins for StatsD, and I'm sure there will be plug-ins for other sort of proprietary metrics and telemetry solutions. And it's not just metrics logging. We're going to start working with quota systems. We have a quota system. I think it's built on top of Redis at the moment, and we expect to see a lot more third-party development as we enable the ecosystem for adapters to be written so there's some of that relationship with projects.
MJ: Also, on the policy side, Istio is working with several other partners. So for example Open Policy Agent (OPA) is one of the first policy adaptors that we are coming up with, so you can write your your policy in this new semi standard language as the community works towards a standard.
DR: And the other project worth mentioning is that Istio is working closely with the SPIFFE effort to support SPIFFE as the auth protocol for Istio.
Me: So Istio is really sort of the overarching umbrella.
MJ: From an operator's standpoint, Istio is the configuration that the operator interacts with. You can configure Istio to do network functions, and there are a set of network functions that Istio supports, such as routing rules and destination policies, as well as other things on that side. Then on the policy management and on the metric side, there are other functions, which are pluggable. So as they grow, Istio can support them. So that's kind of the umbrella of Istio.
There is also the matter of how the proxy is being configured. Pilot also exposes a configuration interface that Envoy calls out to, so that's kind of the third interface. The umbrella defines things in terms of interfaces and protocols, and then we have implementations of all those components in action for a working system.
NC: So what it what this Istio user hackathon all about?
DR: So as we work towards the next release of Istio, we're getting closer to what we think are release candidates for all the components, and we are writing up the documentation and all the changes we've made over the last couple of months. This event is really to get early adopters to take a look at it, try to run through the documentation, tell us where we might have certain bugs that need to be closed before we consider the release blessed, and see where feature gaps are and so we can start planning for future work on Istio.
NC: What is the next Istio release, and when do you expect to have it?
DR: Our goal is to have it ready by the end of September.
NC: Do you have need to have like kubernetes experience or any other particular prerequisites in order to participate in this event?
MJ: Some kubernetes would be helpful but it's not required. We have setup instructions, and we will kind of walk you through how to set up a kubernetes cluster and get things started, so that it shouldn't be a real impediment.
NC: Are there any particular hardware prerequisites?
DR: What I think what we're going to do is Google is going to provide a bunch of experimental projects so you can set up clusters, so you shouldn't need to provide any hardware. I think IBM is going to do that as well on Bluemix, so there should be a fair amount of available infrastructure for testing. So you need a laptop and the ability to run Git, or even just the installer and that should be enough. So I think there aren't any real hardware requirements that I know of.
NC: Once this release is out, where do you think Istio is on the production-ready scale?
MJ: Istio 0.2 is the release where we have enough features that people can actually get something done, so I'm really looking forward to feedback. Production-readiness, performance, and all that are goals for 0.3.
DR: In some ways, it's like the difference between Istio and Envoy and the various components. Certain components of Istio have been used in production environments, and we are well aware of their characteristics. Others have gone through big rewrites over the last couple of months as we learned some things, and we're still starting to get a feel for what needs to be hardened and what needs to be addressed. So depending on what you're trying to do with it, you might have different opinions about production-readiness. I think we're getting close to beta-type status, but we're not quite there yet.
NC: So where do you think Istio is going?
DR: Well, the Silicon Valley answer is that ultimately Istio will help power all of the world's services, but I think we're we're a long way from that. We've got a lot of stuff to do before we get there. I mean one of the features that we were doing for this cycle was just an enabling of VMs that aren't part of any Kubernetes cluster to join a mesh. So we want to keep working on doing that and expanding to more environments, as well as supporting multiple environments at the same time. Sort of a hybrid scenario. So those are some of our near-term goals.
MJ: I think Doug covered the really long term and the near term. There are several intermediate goals, but they they kind of get into the nitty-gritty of what's what's important. One of the things that we really would like to see is a is a robust kind of vendor community that is building on top of Istio, or on the side of Istio. There are certain things that Istio does foundationally, and we would like to see where those belong to the stack, and then there are also areas and tasks on the side of Istio, and we would also like to see something come up there.
DR: We're really focused on getting more community engagement. We've been trying to get stuff out, but I think we need to start focusing more on how do we enable community, how do we excite the community, how do we meet the community's needs now that we've sort of got the initial foothold out in the world?
NC: So what do what kind of engagement do you need the most in the community?
DR: We could use development support, documentation support, design support, process support...
MJ: We also want to see people do scenario testing to see whether the things we think are relevant are relevant to what people are actually doing. Then we'd like to see people actually trying them out and giving us some feedback. We would really like to get feedback, especially on configuration because that is the surface that an operator touches, and that is how an operator interacts with the system, so so that that feedback is extremely valuable to us
Also, Mixer has an adapter framework, which is the extensibility mechanism for Istio, and it's how you can write new adapters to enable new functions. That has gone through a big rewrite between 0.1 and 0.2, so it's another place where we really want feedback from users. For this event it's unlikely that we'll be able to get that feedback, but I'm just kind of laying that out there. For 0.2 these are some of the things that we really want some feedback for
DR: There's a lot of stuff that we want to see happen but probably don't have the experience to make happen ourselves, like the expertise to make this work on Amazon's Cloud or different environments like that. I think we could really use community support. So that's what I'd like to see.
If you'd like to participate in the user testing hackathon, you can sign up here to get instructions and access to donated hardware resources. Missed the date? You can still help out by executing the test tasks and providing feedback.
Interested in Istio? Join us for a live demo on April 4, 2019. Learn how to use Istio to control traffic flow without changing your app!
For a lot of years, that's meant large applications -- and a lot of sustained work. But not anymore. One of the consequences of our technological plunge into cloud native architectures is the emphasis on microservices-based applications, which means that a single service can provide immeasurable benefits to multiple applications -- sort of the ultimate "code reuse" use case.
But when you've got an application that consists of dozens, hundreds, or even thousands of these individual services, how do you manage that architecture without having your app -- or at least your sanity -- run completely off the rails? What we need is an architecture that provides a way to connect, manage, and secure these microservices, while also providing load balancing, authentication, monitoring, and so on.
If such a thing existed, you'd want to get involved, wouldn't you? Of course you would. Well, here's your chance.
Istio is an open source project that does all of those things, and on Monday, September 25, they're having a user-testing "hackathon" event. We thought we'd get the details directly from some of those involved in the project, so we spoke to Google Software Engineers Douglas Reid and Mandar Jog, who are helping to lead development efforts.
Nick Chase: Gentlemen, thanks so much for taking the time to speak with me today. So for those who don't know what Istio is, please explain it.
Mandar Jog: Istio is a service mesh that provides cross-cutting functions that all micro services environments need (Learn more about what is a service mesh by reading our guide to Istio). So for example, you need traffic management. You need to find those services that you need to reach. Someone needs to decide who can talk to what service.
Then there is observability, which is basically the telemetry and metrics. So you need to find out how many times something was called, and get maybe get traces as well. Logs come in to the same area.
Then there's policy enforcement, which is access control, or any kind of specific policy-making decisions about whether a particular service would talk to another service, and under what circumstances.
Finally, Istio Auth provides identity and authentication, so that's service-to-service authentication and a central authentication on which you can actually base your overall identity and authentication story.
Douglas Reid: Those are some of the functional things, but to take it from a different perspective, I like to think of Istio as the product of user experience at Lyft and IBM and Google in deploying, managing and serving software in a distributed environment. This is sort of the set of best practices that we've learned over the years the hard way about things that make it easy to manage systems at scale, especially in distributed systems.
NC: So basically what you have is this sort of cloud of microservices and Istio is a kind of a request orchestrator?
MJ: Istio sits in the gap between these different services. It intercepts the request then does all these things that we talked about earlier with those requests.
NC: So I hear Istio and Envoy talked about at the same time alot. What is the difference between them?
DR: Envoy is a component of Istio. Envoy is the proxy that sits alongside services. It is the data plane layer of Istio. Istio also comes with a control plane, which is called Pilot. Pilot controls Envoy deployments and helps configure them, and also Mixer, which helps make policy decisions. Envoy calls out to Mixer at request time. Pilot also controls the deployment of all the other pieces that Envoy uses to secure traffic.
NC: Is Istio sort of staying off in its own corner, or are you building relationships with other projects to create an ecosystem?
MJ: Definitely. For example, LinkerD now works with Istio. They can call out to Mixer, so basically LinkerD, in the simplest terms, can replace Envoy as the request interceptor or as the proxy, and then just as Envoy calls out to Mixer to make policy decisions, LinkerD can call out to Mixer to make policy decisions. And then Nginx is also it's also working on, or already has kind of announced, that they're also going to be talking to Mixer, so you can use Nginx as your proxy instead of Envoy.
In fact, the protocol between Mixer and Envoy is well defined and published, which means that theoretically both of those are replaceable. So as Istio, what we really define is that configuration surface, and how Envoy is talking to Mixer.
DR: Mixer has sort of adopted Prometheus as it's built-in metrics reporting mechanism, but we also have plug-ins for StatsD, and I'm sure there will be plug-ins for other sort of proprietary metrics and telemetry solutions. And it's not just metrics logging. We're going to start working with quota systems. We have a quota system. I think it's built on top of Redis at the moment, and we expect to see a lot more third-party development as we enable the ecosystem for adapters to be written so there's some of that relationship with projects.
MJ: Also, on the policy side, Istio is working with several other partners. So for example Open Policy Agent (OPA) is one of the first policy adaptors that we are coming up with, so you can write your your policy in this new semi standard language as the community works towards a standard.
DR: And the other project worth mentioning is that Istio is working closely with the SPIFFE effort to support SPIFFE as the auth protocol for Istio.
Me: So Istio is really sort of the overarching umbrella.
MJ: From an operator's standpoint, Istio is the configuration that the operator interacts with. You can configure Istio to do network functions, and there are a set of network functions that Istio supports, such as routing rules and destination policies, as well as other things on that side. Then on the policy management and on the metric side, there are other functions, which are pluggable. So as they grow, Istio can support them. So that's kind of the umbrella of Istio.
There is also the matter of how the proxy is being configured. Pilot also exposes a configuration interface that Envoy calls out to, so that's kind of the third interface. The umbrella defines things in terms of interfaces and protocols, and then we have implementations of all those components in action for a working system.
NC: So what it what this Istio user hackathon all about?
DR: So as we work towards the next release of Istio, we're getting closer to what we think are release candidates for all the components, and we are writing up the documentation and all the changes we've made over the last couple of months. This event is really to get early adopters to take a look at it, try to run through the documentation, tell us where we might have certain bugs that need to be closed before we consider the release blessed, and see where feature gaps are and so we can start planning for future work on Istio.
NC: What is the next Istio release, and when do you expect to have it?
DR: Our goal is to have it ready by the end of September.
NC: Do you have need to have like kubernetes experience or any other particular prerequisites in order to participate in this event?
MJ: Some kubernetes would be helpful but it's not required. We have setup instructions, and we will kind of walk you through how to set up a kubernetes cluster and get things started, so that it shouldn't be a real impediment.
NC: Are there any particular hardware prerequisites?
DR: What I think what we're going to do is Google is going to provide a bunch of experimental projects so you can set up clusters, so you shouldn't need to provide any hardware. I think IBM is going to do that as well on Bluemix, so there should be a fair amount of available infrastructure for testing. So you need a laptop and the ability to run Git, or even just the installer and that should be enough. So I think there aren't any real hardware requirements that I know of.
NC: Once this release is out, where do you think Istio is on the production-ready scale?
MJ: Istio 0.2 is the release where we have enough features that people can actually get something done, so I'm really looking forward to feedback. Production-readiness, performance, and all that are goals for 0.3.
DR: In some ways, it's like the difference between Istio and Envoy and the various components. Certain components of Istio have been used in production environments, and we are well aware of their characteristics. Others have gone through big rewrites over the last couple of months as we learned some things, and we're still starting to get a feel for what needs to be hardened and what needs to be addressed. So depending on what you're trying to do with it, you might have different opinions about production-readiness. I think we're getting close to beta-type status, but we're not quite there yet.
NC: So where do you think Istio is going?
DR: Well, the Silicon Valley answer is that ultimately Istio will help power all of the world's services, but I think we're we're a long way from that. We've got a lot of stuff to do before we get there. I mean one of the features that we were doing for this cycle was just an enabling of VMs that aren't part of any Kubernetes cluster to join a mesh. So we want to keep working on doing that and expanding to more environments, as well as supporting multiple environments at the same time. Sort of a hybrid scenario. So those are some of our near-term goals.
MJ: I think Doug covered the really long term and the near term. There are several intermediate goals, but they they kind of get into the nitty-gritty of what's what's important. One of the things that we really would like to see is a is a robust kind of vendor community that is building on top of Istio, or on the side of Istio. There are certain things that Istio does foundationally, and we would like to see where those belong to the stack, and then there are also areas and tasks on the side of Istio, and we would also like to see something come up there.
DR: We're really focused on getting more community engagement. We've been trying to get stuff out, but I think we need to start focusing more on how do we enable community, how do we excite the community, how do we meet the community's needs now that we've sort of got the initial foothold out in the world?
NC: So what do what kind of engagement do you need the most in the community?
DR: We could use development support, documentation support, design support, process support...
MJ: We also want to see people do scenario testing to see whether the things we think are relevant are relevant to what people are actually doing. Then we'd like to see people actually trying them out and giving us some feedback. We would really like to get feedback, especially on configuration because that is the surface that an operator touches, and that is how an operator interacts with the system, so so that that feedback is extremely valuable to us
Also, Mixer has an adapter framework, which is the extensibility mechanism for Istio, and it's how you can write new adapters to enable new functions. That has gone through a big rewrite between 0.1 and 0.2, so it's another place where we really want feedback from users. For this event it's unlikely that we'll be able to get that feedback, but I'm just kind of laying that out there. For 0.2 these are some of the things that we really want some feedback for
DR: There's a lot of stuff that we want to see happen but probably don't have the experience to make happen ourselves, like the expertise to make this work on Amazon's Cloud or different environments like that. I think we could really use community support. So that's what I'd like to see.
If you'd like to participate in the user testing hackathon, you can sign up here to get instructions and access to donated hardware resources. Missed the date? You can still help out by executing the test tasks and providing feedback.
