First, I'd like to thank everybody for joining us today. Welcome to today's webinar, Delivering Progressive Delivery with Service Mesh. I'm Taylor Wagner, the Operations Analyst for CNCF. I'll be moderating today's webinar. We would like to welcome our presenters today, Andrew Jenkins, CTO, and Zach Jory, Head of Marketing for Aspen Mesh.  During the webinar, you are not able to talk as an attendee. There is a Q&A box at the bottom of your Zoom screen. Please feel free to drop in your questions and we'll get to as many as we can at the end. With that, I'll hand it over to Andrew and Zach to kick off today's presentation. Great. Thanks, Taylor. Zach Jory here, Head of Marketing. Looking forward to spending a few minutes up front. And the presentation talking about progressive delivery, some of the concepts behind it, why we think it matters, and why we think the Service Mesh helps with that. And then we'll get to the fun bit after that. Well, Andrew will do a couple of demos showing how you can actually use Service Mesh to deliver progressive delivery. So, progressive delivery is an idea. I should give credit where it's due that James Governor of Redmonk introduced a year and a half or so ago. There were a couple of companies that were doing progressive delivery. WeWorks, LaunchDarkly, the engineering team at Target. We're using a stack of tools to, I would say, do a new method of CI, CD around Kubernetes. Things have kind of changed the way we deliver applications. Now, the microservices become all the rage. And the way you build and deliver and deploy Kubernetes-based applications requires a little bit different way of thinking. And that's where progressive delivery comes in. So, these companies that I mentioned, LaunchDarkly, WeWorks, we're using tools like Kubernetes, GitHub, Service Mesh, FingeFlags to roll out software deploys to small sets of users to see how those went and use the learnings from those deploys to, you know, either roll back, didn't go well, or make changes based on what they were learning. When you combine these set of tools and do software delivery in this way, it's really cool because progressive delivery means software deployment does not necessarily meet the equal software activation, which means that just because your dev team is doing deploys doesn't mean you have to roll out those features to all your end users at once. This is very similar. You know these thoughts from CI. I like to think of this as CI 2.0, kind of the new requirements for how you deliver software in the microservices world. CI was really great for the business because it gave the business a way to limit the blast radius around software deploys, so deploys weren't as scary. I think progressive delivery takes that a step further by not only allowing you to turn hand grenades into firecrackers, but also being able to put those firecrackers out very quickly if there are problems and even put a Band-Aid if one of those firecrackers causes a wound. One of the really neat things about progressive delivery is the business actually cares about it. This controlled empowerment idea is around the sense that the business can say when it's acceptable for new code to hit the end user. So dev teams are not constrained by the business. They can still do rapid iterative development. But the business can say we're going to package that all up and we can wait for 6, 10, 12 deploys until we activate that for the end user. This is really cool because it gives the business psychological safety around deploys and I think rapid software development is not as scary for the business side of the house anymore. Deployment is not the same as release. Service activation is not the same as deployment and devs can deploy a service and it can ship, but it doesn't mean it hits all your end users. And this is a great way. So the business side of the house, the application owner doesn't have to put any handcuffs on the dev team. The dev team can keep moving at the pace they want to move at. And the business doesn't have to be quite as terrified as it has been of that in the past. So there are really a couple different pieces here. One is the psychological safety for the business I talked about in the last slide. The other one that's really neat is the fact that this provides a much better developer experience. Decoupling releases from rolling out new features to customers is a really good way for the business to be satisfied without forcing dev teams to comply with business controls and concerns. So that means app owners can say when new features hit users and that means the business can not only feel better about the way things are getting rolled out, but it makes it a lot easier to meet a lot of security and compliance concerns by being able to put some guardrails along the way your developers are rolling out new deployments. So there are, as I said, a few pieces to progressive delivery. The part we're going to focus on the second half of this webcast is about how ServiceMesh enables progressive delivery. Feature flags and rolling deploys are some things. LaunchDark that I mentioned earlier is a great tool to use. Feature flags for progressive delivery. One of the things that we have been using with our customers is ServiceMesh and it allows us to do progressive delivery things like canary and traffic mirroring, which are really cool because you can roll out an experimental service, see how that service is performing with a set of users and use those metrics to decide if you roll out further or roll it back. And so with that, I think that I will turn it over to Andrew here to deep dive a little bit more into how you can use canary and traffic mirroring and do a couple of demos. Yeah, that sounds great. Thanks, Zach. So let's go ahead and take over from where Zach was. So, as Zach mentioned, you've got a bunch of sort of components to progressive delivery. It's all about decoupling the deployment of software from the way that users sort of encounter it. So that way, business can sort of make trade-offs and that can evolve kind of independently of a decouple and let software teams go as fast as they can. However, you still need some stuff to manage how you're going to actually activate it for new users, how you're going to deploy it. And so part of that story is around sort of these new deployment techniques for deciding how you're going to shift traffic and expose it to users. So what we're going to talk about today is sort of demo is canary deployments and traffic mirroring, which is kind of a new thing that a service mesh lets you do that has some interesting sort of opportunities for improving the way that you might have used or heard about canaries before. So what we're going to demo here is using a progressive delivery operator called Flagger. And so this is kind of the Flagger architecture. And so Flagger's job is to deploy a new canary and then shift traffic to that canary based on different criteria. For this demo, we're going to sort of step through ramping some random subset of traffic. There are other options as well. And then Flagger observes what happens to that new canary service, compares the performance of the canary to the primary service, and continues with its progressive deployment and activation of the canary service as long as that's healthy. And if it becomes unhealthy, if the canary is now performing out of spec relative to the primary or relative to absolute markers, then you can say, OK, wait, hold on, this activation is failing. And so we're going to roll back to the primary. We're going to cancel this activation and we're going to let somebody figure out what's wrong, wait for a new candidate version that we can try activating along those same lines. So, and the service mesh tie in here is that for actually choosing what traffic goes to the primary and what traffic goes to the canary, you can use a service mesh to do that kind of traffic shifting. And then later we'll see how you can also do something called traffic mirroring that will let you do a little bit of both before you sort of activate the canary at all. And we'll talk about why that's good or bad. So this is an example of a canary deployment through a timeline. And so what we're looking at here is we've got an old version of service deployed and fully activated 100% of traffic is going to the old version of the service. We've got a new version. It's past, you know, our continuous integration tests. It's, you know, we're ready to go. We're ready to actually use this guy. And it's deployed. It's up and running. And so now we're going to do this sort of progressive activation piece. And so what we're going to do here is you can see we're going to start by shifting some traffic to the new service. And then we're going to pause for a while and measure this. And we're going to confirm that the new service is performing successfully. And if that's, if that is true, then we'll keep going and shift a little bit more. And then, you know, we'll sort of proceed on and on through the progressive deployment until we decide, okay, you know, for our activation thresholds, we've shifted traffic over to this new service. It's performing healthy. Great. And we can go ahead and complete the activation for all users and shift 100% of traffic to the new service. So this is this kind of like shift measure shift measure sort of loop and the service mesh is involved in shifting traffic to the new service, as well as collecting the measurements in a way that we can we can compare. So at this point, I'm going to shift over to the demo and go through what we'll sort of see this in action. So let's see. Actually, I'm going to get out of here. So I'm going to go through this demo. I'll copy this URL here and slap it down in the chat. You can play along at home or try this out yourself. And with, you know, the examples on if you follow that link. And so let's go ahead and look at this. So I've got make sure Prometheus is up and going. All right. And I'm going to shrink this so that we can see sort of just the current amount of time here. So right now I've got my old service running. This is it's taking all the requests currently and nothing is shifting over to the new service. And what we're going to do is I've got so this this up top will sort of watch this is the flagger operator and it's going to tell us what it's doing and why it's just for a step through here. And then the I've got what is called a canary resource. And this is how you tell flagger what traffic to shift where how to work through this this progressive delivery scenario. And so this this canary is going to say, Hey, every 30 seconds, we're going to move one more step through our progressive delivery, our canary deployment. And what we're going to do is we're going to compare the the request success rate and the request duration between these two. The the primary service and the new canary service. These are handles for can sort of Prometheus queries inside a flagger that go and look at the service mesh underneath like aspen mesh that is collecting the metrics from the canary deployment. And then here we're going to say we're going to do every step is going to be adding 10% of traffic shift. And this version we're not going to do the mirroring stuff that we'll talk about later. So we've got mirror set defaults. So What we've got right now is we're running a basic primary service version 2.1.1. We've got our canary configured flagger is sitting there ready to go. And so we'll do is we will try to update this image to be a new version 2.1.2. And I'm going to do this manually and directly in the demo, but you know, in production usage, this is driven by whatever sort of your deployment scenario is. If you're using, you know, get ops, then it's your get ops operator for configuring this. Maybe it's a, you know, a CD system that that's driving this for you, whatever it is, but for the purposes of this demo, we're just going to play around with with updating this image directly. So I'm taking the place of, you know, your get ops operator and I've just said, okay, great, we're, we're now saying that we want to try this candidate image part of code 2.1.2. And I've got a little canned watchers that we can kind of see what's what's going on here. So flagger has noticed the new revision detected. And so it's deploying some 2.1.2 pods. And it's going to wait for those to get started and show up. But right now it's still saying, hey, all the traffic is going to go to this, this primary version of the service. So we'll wait for just a bit and now the 2.1.2 pod is actually available. So pretty soon here flagger noticed and it started shifting some traffic 9010 between the canary service and the pod in the primary service. So I will go ahead and we can take a look over here and Prometheus can lag just a little bit. We'll go ahead and load this guy. We can see that there's a little blip of traffic starting to go over to the canary version of the service. Keep on going. You can see, okay, now we're stepping it up. And if we flip over here, we can see flagger is saying, okay, yeah, we're getting some success. So it's starting to shift 8020. It'll go to 7030 over time. And then we'll end up with, in this case, canary version of the service should hopefully be happy. And we will say, okay, great, this 2.1.2 version is our new primary version and complete the deployment. Go back over here and a little bit more of the traffic continuing to step up on the canary version of the service and starts from marching down on the primary version of the service. Keep shifting traffic. And for the purpose of the demo, I've got a pretty quick ramp here, 30 seconds only on each sort of stage. That's to make the demo go fast enough that it's interesting to watch. In production, you're probably looking at letting this soak for quite a bit longer, depending on how rapidly you sort of do these deployments. All right, so let's go ahead and see it's continuing to sort of march more and more traffic shifting to the canary version of the service and less and less to the primary version of the service. And we're finally at 5050. And so this means that, you know, flagger has now decided that, hey, everything's good. And we're ready to go ahead and make 2.1.2 the new versions. This is a successful canary deployment from flagger. And so it's going to update the primary to be our new 2.1.2 version. And it says, you know, so it's finalizing this canary getting everything else done. And so here it goes, shifting all traffic over to primary. And then it'll start, you know, the canary is now ready to be used again for the next sort of canary deployment. And so we'll see here and take a little while for the primitius metrics to sew through, but then we'll go back to the stage where all the traffic is going to the primary. The primary is now new. It's that 2.1.2 version of the service. There you go. So now it's all shifted over. Traffic is totally shifted to the primary. Okay. So that's a successful canary, canary deployment with traffic shifting. I can show you the next one here is what happens on failure. And so what happens on failure that's pretty cool is so we can shift, we can measure, we can say, oh wait, this traffic is not as healthy as the old traffic. And so we should actually roll back and we can sort of step through that scenario now. And the one thing that I know I have to watch out for here is that I always put the wrong deployment in there. So let me make sure. There we go. So what I'm going to do is I'm going to try deploying an image that I've configured that always gives back an error response. So this is a, imagine this is a busted build that somehow slipped through CI and it's got some bug where it responds with failures to some subset of requests. And so you can now detect this with a canary and we'll see how by doing it with traffic shifting or some other sort of thing, you can limit, just as Zach was saying, you can limit the impact of letting one of these broken deployments get out. It doesn't have to be activated for all users. And you can detect it quickly, roll back automatically. So I'm going to go ahead and try and deploy that guy.  And I've said, okay, we're going to try deploying this new image. And so once flagger notices this guy, he's going to go ahead and start scaling that up. So there you go. So flagger, flagger notices, flagger say, okay, cool, I'm going to execute this canary now. Let's go ahead and scale up that container and get it to be available and then start shifting some traffic to it. Okay. So now that that new candidate bill is available. And flagger is noticed flagger is shifting, you know, 9010 on the traffic here. And here we should see something a little bit different, which is so this this top plot will show only successful traffic that didn't have 500s and down here I'll show you traffic that does have 500s. There's some amount of traffic shifting from the primary over. So here it goes you see a little dip there. You don't see this count up in this view because this is all these are all errors. But what you'll see here is there are now high rate of errors coming out of out of this service. If we go over to flagger, we'll see, oops, halt pod info test advancement success rate is less than 99%. So this is not happy. So we're not going to progress. And flagger will sit there it's going to try a couple times, and then say that this is all busted, and it will roll it will just sort of shift traffic back 100% to primary 0% to canary. And it will mark this canary is failed.  And then you can you just continue. So the next time you have a new build that hopefully has this bug fixed, then you deploy that build and flagger will repeat, but be happy with the canary that time, and then do a successful delivery. And now said, Oh, yeah, this is no good. Routes, you know, 100 zero back, and then left us a note that the canary has failed. And now we can go take action. But we've automatically rolled back. So our production deployment, all of our users are seeing responses from 2.1, the healthy 2.1.2 deployment. And so now we can pause, you know, we don't have to panic, we can take our time to figure out exactly what went wrong. So that's, that's neat. Did that and you've got, you know, traffic all back to the primary. We want to talk about something, something that, you know, we saw this, you know, we thought that service mission opportunity to do something pretty cool. And so we did an experiment to add this to flagger. And this is not committed to upstream flagger yet because it's not ready. We haven't figured out enough about how other service messages do this sort of thing. There's some caveats that we'll go through, but this is the sort of traffic mirroring case. The source code is available. If you go to that demo, you can see the source code. It's just this, this part, this mirroring part is not really probably ready for production usage yet. And we'd like to get it upstream into flagger so that it's available for everybody. Traffic mirroring is cool, because it's a little bit of a difference. So in this mirroring pre stage, we're going to actually duplicate the request. One copy is going to go to our primary and one copy is going to go to the canary. The user sees only the response from the primary. So the service mesh is going to take care of copying these requests. And it's going to take care of taking the response back from the primary and sending it on to the user. For the duplicate that it sent to the canary, all it's going to do is collect the response, drop the response on the floor, but still collect the metrics and statistics about how long it took and about whether it was a success or a failure. But then it's not going to send that, it's not going to send the actual response on to anybody like the end user. It's just going to drop it on the floor. So what this enables, that's pretty cool, is that if the canary is a bad release, you can detect it without actually sending any bad responses back to the end users. So in that traffic shifting case, you know, we said, okay, we're going to shift 10% of traffic to the canary bill, right? And so that meant that while we had that deployment going on, and we were in that 90-10 split, 10% of our users were getting those bad responses. And that's a lot better than 100%, right? This is part of the progressive delivery story where you can limit the activation scope. But, you know, 10% is still more than zero. And so if you can improve on that even more by saying, hey, we're going to do some free testing where we're just going to, like, try to filter out, you know, bad bills in advance of this, then, you know, we think mirroring is a cool opportunity to do that kind of thing. So the caveat here is that the service mesh is going to mirror the traffic by duplicating the requests. And it's going to send one request to the canary, and it's going to send one request to the primary. And so that means that there will actually be two copies of each request that you choose to mirror this way. And so that means that those requests must be what's called item potent. So that means that your system, if it receives a copy of the request, it'll still be okay. And so item potent requests cover gets, like all sort of read operations are naturally item potent, and also special kinds of rights. So if you have requests that are rights, like puts or posts that are semantically kind of like this thing on the left. Hey, deduct $100 from my account, then those are not item potent because you might have, you know, like, when we duplicate the request, you'll get two requests that say deduct $100 from Andrew's account. That will mean that I've been deducted $200. I'm not happy about that. And so, you know, I don't, that that traffic is not compatible. It's not item potent. It's not compatible with this mirror. The kinds of requests that are important are all gets, like, hey, get my account balance. You duplicate that. It's fine. It's a read. Also, here's an example of an item potent right set my time zone to mountain daylight time, right? And if you do another copy of the set, that's fine. Item potency is a good thing to have in your system anyways, because since we're dealing with unreliable networks, we have a hard time guaranteeing that, you know, there's only one copy and it's reliably delivered. This is pretty interesting to a lot of people. So we're publishing a blog this week that goes into a lot of details about what item potent is why you want it in general. And then, you know, that sort of unlocks the door for this mirroring kind of operation. All right. So mirroring, as I talked about, this is this pre-stage. And so this is going to look kind of like the other graph where we've got old traffic up here, new traffic down at the bottom. And so when we run the canary, the first thing we're going to do is a mirror pre-stage. And so here we're going to copy traffic. That's that little blue dotted line there and send it to the mirror. And then once we'll do this pre-stage, let it soak for a while. And as long as that canary is happy, according to the service mesh statistics, we'll measure it here and we'll say, okay, good, we're ready to proceed to the next stage. And so then when you want to do that, then we'll start with the shifting traffic, measure shifting traffic going through the whole rest of the thing. And then, you know, the canary proceeds as normally, we hit success and we say, great, we're good. All right. So let's see this in action. All right. So I'm going to go over here and edit canary pod info. And I'm just going to turn on this mirror property in the canary. And so we're just telling Flagler, hey, we want you to do a mirror stage before you do all the rest of the normal canary deployment stuff. And I'm going to deploy pod info to point. Oops. That's what I always do is I get the wrong one. Okay, cool. So I'm going to deploy 2.1.2. And we will see. Hopefully I didn't talk so long that stern got disconnected. All right. So update that image. And we will go ahead and wait for Flagler to notice. Oh, whoops, I did something wrong, which is I tried to deploy the same image again. So that's Flagler is going to ignore that. It says you're not really doing a very interesting deployment if you're deploying the same thing. So I'll go ahead and step forward one more version here. And so now we've got a canary deployment that we're proposing. Hey, Flagler, we want you to do this. And we want you to do this traffic mirroring thing first. And so we'll go ahead and wait for Flagler to notice. Out of here. We'll go back to Prometheus. That guy loaded up. There we go. So Flagler noticed and is waiting for our new version to be available to do the traffic mirroring. We're going to see down here. This is the command to the service mesh for how to split traffic. It's going to have a mirror pre-stage that's going to run for a bit that's going to do the mirroring stuff that we talked about. Cool. So now you can see it ran. This now looks different. It's going to say, hey, do some mirroring right now. And so we're in the mirror stage. And so we're not actually sending any production traffic to the canary aside from the special traffic that we're mirroring. We're dropping the responses on that mirror traffic on the floor so that we're not actually sending them back to users. And over here, we can see that it's a little bit hard to see here, but the mirror traffic is going to be 100% of the primary traffic. You're going to be the same for the pre-stage. You mirror all the requests in this pre-stage. And mirrored requests when you use a service mesh like Aspen Mesh or Istio that are built on Envoy. Envoy mirrored traffic has the authority or host header has an addition where it says dash shadow at the end. And that's how if you have other tracing systems or logging systems, you can differentiate. That shadow is the clue that, hey, this was actually mirror traffic. And so you can kind of compare. Cool. So the pre-stage just went successfully and mirror traffic completed here. And Flagler decided, hopefully it's okay. And so now it's going to start shifting traffic over to that canary. Flip back and see, yep, canary says it's happy. It's progressing through. It went 90 and then 80 and it's all the way up to 70. It's got a 70-30 split. We're now into that normal canary traffic split scenario. The service mesh is continuing to split traffic according to the commands that Flagler gives to it. And then once we get all happy here, it'll go 60-40, 50-50, and then we're good. So we're up to 60-40 now. We'll wait just a few more seconds and it should go ahead and go all the way back to 50-50. We can see, you know, this is this. So here's the mirror in pre-stage. And then here's the canary ramp up. And then we're about to hit 50-50. And then if that's healthy, we'll go ahead and declare the canary a success. There we go, 50-50.  We're deploying 2.1.3 as the new primary. Once that's finished, we will, Flagler's next step is to go ahead and shift traffic 100% to the new deployment and be ready for, you know, the future. Other deployments that we want to do. Routing all traffic primary, 100-0. Flagler's finalizing. And I think at this point, we don't need to watch the tail end really here. So that's Flagler progressive delivery in a nutshell. You know, pasted into the Slack, the links here for if you want to try this, you know, at home. All the commands, YAMLs to sort of reproduce the same demo you can see right there. Great. So at this point, you know, I think my demo is finished. And I'll go ahead and I think open it up for questions. Great. Thanks for all the great questions in Q&A. Taylor, I see quite a few there. Should we just start going down the list and giving answers? Yes, let's do that. All right. So the first question from a anonymous attendee is, can this be deployed in OpenShift? Yeah. So I'm pretty sure that this can be deployed in OpenShift as sort of a primary, you know, OpenShift has a lot of Kubernetes stuff inside, right? And so the way that Flagler works is it's taking normal Kubernetes workload descriptions like deployments and services and then commanding one or more service meshes underneath to sort of do the traffic shifting. And so you should go check Flagler's page for any of the details around compatibility. But basically those are the two pieces that you need. You need Kubernetes deployments and you need a service mesh. You know, we're Aspen mesh. We love Aspen mesh for that service mesh. You need a service mesh that Flagler knows how to command underneath. Great. Thanks. The next question is what CNI is supported? That's a good question. So this layer, it's independent of CNI. So the trick is that, again, your service mesh is going to be the thing that's doing the traffic shifting. And so your service mesh has to be compatible with whatever CNI you have underneath. This demo, I happened to use Flannel, which is like VXLan underneath. But, you know, most service meshes are compatible with most CNIs. So if you want to operate a layer above that, Aspen mesh does operate a layer above that. And so we don't really care about the CNI. Okay, great. The next question from Jeff is curious if Canary analysis can incorporate metrics from other sources besides Prometheus, such as an APM tool that provides a REST API for getting performance metrics for Canary. Yeah, that's a great question. So Flagler, so let me show you kind of where the metrics came from. We talked about it just a little bit, but it's worth going into here. So this, so Flagler comes in some, so here's where I specified the metrics, request success rate and request duration. These are handles in Flagler's code to say, hey, if the user is running on top of an Istio or an Istio service mesh like Aspen mesh, then you should query Prometheus this way so that you can get the corresponding service mesh metrics back out. And so this is an easy way so that users don't have to bother with all the details of what query I'm going to run against Prometheus and where and all that sort of stuff. It's designed to make that pretty easy, but you can do that yourself. And you can go check sort of the Flagler GitHub repository and documentation for how you would make your own metrics here. You could point them at Prometheus. You could point them, as you say, some other APM tool, whatever you want. You can list more and more metrics here. This is basically a handle to a template that Flagler will fill in with like the names of the deployments and stuff that it's controlling. And so, yeah, you can definitely, you know, go wild and pull in other data sources. Okay, great. The next question is from Jim. He actually asked two quick questions right in a row, so I'll just give you both. The first is, which metrics are you using to make the canary decision? How are you determining if the app is good and ready? And then right after that he asked, seems like failure rate based on response codes. Yep, so there's, there's a couple of parts here. And so I'll sort of go through all the details. The first is that when I said, hey, deploy this new, you know, update the image, here's our new build that we want you to run. That was adjusting a plain old Kubernetes deployment. And so that's the glue between whatever CD system you have and Flagler. And so that plain old Kubernetes deployment in production usage should have all the normal things that you should do for one of those Kubernetes deployments. It should have liveness and readiness checks associated with it. And so once you do that, Flagler controls how many of those canaries to spin up. And it'll spin up one and let, you know, autoscalers take over if you need more. But it'll just say, hey, I want, you know, I want this to be available and it'll let the plain old Kubernetes machinery take care of deploying that. And it's not, you know, just like all other Kubernetes deployments, they're not available to be part of a service until liveness and readiness checks have passed. And so that that first stage before Flagler can even start mirroring traffic or shifting traffic, that first stage is a plain old Kubernetes deployment. And that's great because it means that you can use all the stuff you've already got for managing that for rolling deployments.  So that's, that's the first that's just getting the deployment up and running. Then the next one is going to be how you start deciding that it's it's ready to take traffic. And so that's where, you know, service mesh, Flagler, progressive delivery, canary deployment start coming in. So the first scenario I showed is that, okay, we've got one that's deployed, it's passed, you know, readiness checks. And so now we're going to shift, just start shifting some traffic to it and see if it's healthy or not. And then the extension that we showed was, hey, maybe you want this pre stage where you're going to mirror some traffic in advance.  So this is really about a couple of layers of pretesting so that you can make sure that before it goes out to some subset of your users, then eventually 100% of your users that it's good and ready as you put it. And then you asked about, seems like response codes. So yeah, that's the analysis in the measurement part in the, you know, I sort of showed in the slides here, the shift and measure. So that measurement part is in the demo based on response codes and latency. We sort of showed the example of failing response codes means rollback. And just as I sort of described in the other question, you could choose other metrics for your application. Okay, we have more questions about canary deployment. This one's from Samet. Will the canary deployment work for TCP traffic as well? So for TCP traffic, the trick is that you have to have some way to decide that it is healthy or not. So in theory, this would work for, hey, as long as there's some prometheus metric that we can go grab somewhere, it may be a different metric that, you know, your application layer sort of computes and reports, like the app could be trusted to say how successful or failing it is. That would mean that you'd have to go write your own custom, you know, metric to go find one of those and get it. So it works, you know, pretty well out of the box, like we demoed for HTTP.  And so if it's TCP, if the TCP layer, right, the service mesh can't tell the difference between one request and the next. So the best it could do is some sort of shifting based on connections. And so that's kind of course brand, but you can you can still do it. And the mirroring thing does not work for TCP traffic. As far as I know, Envoy cannot mirror TCP traffic. And since it doesn't understand anything about the semantics of the things going on inside, it's not very helpful. Mirroring is best suited for, you know, layer seven protocols that your service mesh understands. That's a good question. So this one might be similar. You can let me know. But the traffic, which canary probes HTTP in case this is database traffic or any TCP traffic, will the canary still work? Yeah, I think that one sounds like the same as the. Okay, it was the same person asking so we'll just keep going. Is the canary analysis only comparing against static thresholds by default, or is it more intelligent? So this one is configured to compare against static, static thresholds. I'm not aware, a flagger might have more smarts inside of it, but I'm not, I'm not aware of that. Okay. Will service mesh be working across multiple Kubernetes clusters? That's a great question. So it depends on the service mesh. So Aspen mesh, which is built on top of Istio and Istio, other Istio based service meshes do work across multiple clusters. It just depends on the service mesh implementation that you chose. Okay. The next question is, do you have some telemetry features? Telemetry features. Yeah, I see another one. Yeah. Aspen mesh has service graph.  We didn't show that off in this demo. We focused just on progressive delivery. You can head over to our website and get a whole bunch more details on that. And we'd be happy to show this off to you. Set up a call with us or check out our demo or open beta. That just wasn't the focus really of this webinar. Okay. This one is from an anonymous attendee. I think get code state would be different against cluster deployment state when rollback occurred on failure. What do you think of that? That's a great, that's a really great question. Let me talk about what's going on inside of there. So the question I think is so like, if you have a failed deployment, and it might take a minute, but I'm going to try and I'll try to set this to do this and then we'll talk about it while it's going. So you can kind of see what's going on. Oh yeah, let me share my screen again. Thank you. And I'll just talk through it because it might take a few minutes for the demo to catch up. So when, so if you have a bad deployment, a bad canary deployment, then what happens is you roll back. And so the, and then the get code state might be different than what's running in production. And so there's a couple of pieces here with, so one is the get ops sort of half of it. And so that is where what you're trying to do is you're trying to say, I want to manage the state of my cluster all the applications that are running in it. I want to manage that like how I manage source code and get so that I can, you know, sort of code review it, I can merge it, I can review history, all that sort of stuff. And so that that is still supported because the key is that when I did my deployment of the broken image here, I touched this pot info deployment. What happens when you set up a flagger is that the first thing it does is it goes and creates a second deployment for you that flagger owns that is not reflected in your get ops and it or you get repository or declarative view of the cluster. No human has configured this the operator the flagger operator took care of it. And this is the special pot info primary deployment. The contract is that flagger gets to own what pot info primary is running. And that is always the version of pot info, the most recent version that has passed the canary deployment scenario. And so you do have to get used to the fact that what you have inversion control for pot info may not reflect what you have inversion, what you were actually running for pot info primary. And that's why you have to let flagger manage this pot info primary deployment, leave it out of your, your sort of your world view of your declarative config, what you're putting into your get ops operator. You have to decouple those. And so that you do have to you do have to account for that. And so that means that you can still treat your code image and all that sort of stuff. And as you normally do where you're just continuing to bowl forward and create new deployments, and you do have to be careful that you have in your head. Hey, the primary may not be the most recent one that we've published the past CI. It's actually the most recent one that past CI, and also past this progressive delivery scenario. And so if you notice a flag or canary has failed, that should make you uncomfortable. You go make code changes and fixes and try to push a new build through that moves it forward to be so that pot info and pot info primary are both running the most recent version of your code. And you've sort of reconciled that difference. So I think it's totally correct that it should be a little bit uncomfortable that you have canary build that failed.  So I'm not aware of a lot of people doing that what I usually see is people say, Okay, we understand what's happened this canary has failed. Let's go try and move the ball forward let's move forward and come up with a new bill that we think will fix that problem and make progress. Okay, last question is a little bit of a long one from Alexander. One of his services is using web RTC connections between client and service terminating connection will cause bad user experience. The session is typically going on for one or two hours. Is it possible to gradually prevent new connections to be established on the old version and shift new connections to the new service to allow him to remove the old version when there will be no more web RTC sessions open for the old version. Okay, that's a good question. Again, that kind of depends on your service mesh. So, so for Aspen mesh, you know, Istio and Envoy again, the, you know, Envoy will let these for a configurable amount of time, old connections to old services stay open. So, you know, you can sort of gradually shift that over, but you do face this tension of well but if you're not going to shift over any old stuff. If you're not going to shift over anything, you've got connections that last one or two hours, then the soak time in order for you to get enough new traffic to your new connections might be pretty darn long. And so, you know, you might be looking at hey how long of a window do I have to have to get enough new stuff. So, most, I think most service measures support this sort of, you know, hey, let's, let's tail off let's not disrupt existing connections. I know Aspen mesh does. And the others you just have to check. If anybody else has a question to ask please type into the q amp a box now. We can wait like another minute in case anybody has any questions. All right, well it looks like we're done with questions. Thanks Andrew and Zach for a great presentation. Thank you for joining us today on the webinar recording and slides will be online later today on the CNCF website and the link I posted earlier in the chat. We're looking forward to seeing you all at the future CF webinar and have a great day. Thanks so much Zach and Andrew. Thanks everyone. Thanks for joining. Have a good day.


Next question is from Way2Fit. Can a 10 to 15 minute trigger session every day be beneficial for muscle gain and fat loss if the client has time restrictions with work? Yeah, trigger sessions have tremendous value. They're the best for that. They're incredible for that. So a trigger session essentially is a short, and I usually say eight to 10 minutes, right? Eight to 10 minute mini, and I use this word lightly, workout. But essentially what you're doing is you're doing a load of moderate intensity workout. You're aiming for a little bit of a pump. It's like a pump session. Yeah, or you can make it more mobility focused. And you do it shortly. And ideally, you do several of these a day, two or three of these a day. When I do trigger sessions every time, it's like within three or four days I could tell a difference in my muscle shape. I could tell a difference in fat loss, energy, everything. How in depth did you go in the book in this? With trigger sessions? Yeah. I didn't talk about trigger sessions. Oh, you didn't at all. No, I kept it very basic because we're talking, and here's the thing. Actually, it's kind of an advanced technique. Yeah, and here's the thing. Like in the resistance training revolution, I talk about sets, reps, tempo. Like, you gotta imagine the average person that you're talking to. Their first introduction to weights in general. But I mean, trigger sessions are not advanced in the sense that they only benefit advanced people. No, no. It's just you gotta get the basics first. It's an advanced concept, right? Yeah, no, that's what I mean by that. But yeah, no, it's great. And you know, back in the day, we didn't call it trigger sessions, but I would have clients do, hey, I tell you what, every morning, why don't you practice and do three sets of 10 body weight squats, which is kind of easy for you? Just do that in the morning. Or at work, every two hours, I actually used to do this with quite a few clients, I'd have them have an alarm that would go off on their watch or something. And every couple hours, go ahead and do five minutes of this particular band exercise. And they would notice improved productivity. They'd notice, you know, a little bit of strength gains that we would see translated into our workouts. You know what? Who was it that did the greasing the groove? Was that Pavel? Who was Pavel? Yeah, Pavel did that and then Rich Piana, I forgot what he called it. Feeder sessions. Yeah, very similar type of a concept, right? And you know, in terms of Dr. Ed Thomas, he applied something kind of similar, it was more basic exercise calisthenic type stuff in between for school. So they would take breaks, like lots of like planned breaks, where they would have these physical poses and different exercises that they would do. And they in turn had some of the best performance and numbers out of anybody in any kind of competitive state around them. Yeah, yeah, no. And you know what the biggest, so when I did them the first time, and the story goes, I witnessed blue collar workers in my family who had muscular body parts that correlated to their physical job, right? So, you know, like a male carrier, they all had great calves and the mechanics of my family had great forearms. And the reason why I thought of trigger sessions is like, if you're a mechanic for 30 years, yeah, I'm sure the first few months your forearms get sore, but after that, it's now you're adapted, it's a low level intensity activity.  So I thought, okay, there's something to this. When I applied it, I did not expect to feel and see some of the other benefits which were cognitive and energy-wise. It was like, I would just feel so sharp. I mean, one of the reasons why we work out before we podcast now is it makes us so much sharper. I mean, just throughout your day, just do five minutes of exercise. So when you got me doing it, I actually took our bands and I would keep it downstairs where my TV room was at and just hang it in a closet door that was in there. And I just made a habit of like, if I sat watching, you know, two hours of TV or something that to just, because you know, you start to feel lethargic and sort of on a weekend, right? It's maybe it's a Saturday, I kind of slept in, kind of chilling. Then I catch myself where I've been just like into the couch forever, feeling even more lethargic. Now I don't even want to go get like a full workout in, hopping up and doing a trigger session, completely change my thing. The same thing.  And it was like gold. And it's so easy because you're not committing to like a full workout. It's literally 10 minutes long, if that. And it just takes, and it's not really hard, but how you feel afterwards is amazing.  Nothing even close to intense. And here's the bet. I mean, in my opinion, here's a selling point.  Just do them on a, you know, I'd say five days a week, do you a couple a day, watch what happens to that weak body part. It responds very, very well.


Hey, this is Brett with Summit Auto and Fond du Lac Wisconsin. You're new and used sports car headquarters and today I'm excited to show you our very first 2021 Dodge Challenger that we have received to our lot. This is a 2021 Dodge Challenger RT scat pack Wide body with the shaker in hell raisin with the plus package This thing has got just about every option that you could get on These RT scat packs and it is awesome really good looking love the hell raisin color That was a new color for last year and this is our second hell raisin that we had We shoot all of our videos in 1080p 60 frames per second So if you have HD capabilities on your computer tablet or smartphone device Turn them on right now because it is definitely your best way to check out the looks styling color and options of the vehicle before seeing it in person If you want to check out all the photos on this vehicle in the upper right hand part of your screen as a link to our website Click that and check us out there.  You also get the fender flares with the wide body The shaker package is actually what gives you the little bees on the side The shaker package also gives you of course the shaker hood and the shaker hood scoop This one does have HID headlamps led running lights and when we turn those on later, it's really cool How they do it they light it up in here.  We'll check that out in just a second. You also get these six piston SRT Brembo brakes on this vehicle you get the slotted rotors and We'll check out the original window sticker so you can see all the options on this car If you want to fast-forward through this you can if you want to pause it to check out all the options feel free I'm not going to go through everything, but most of it 2021 Challenger RT scapac wide body hell raisins the color you get the 392 v8 Which gives you 485 horsepower?  It's kind of like a suede I guess it's a synthetic suede But you also get the real leather Napa leather seats both these seats are heated both these seats are cooled And you get a power driver seat We'll take a quick look at the back seats since we're right here anyways Latch child safety system same materials used back there and those seats do fold down for extra storage Auto headlamps you get the bright pedals down there that power tilt and telescopic steering wheel and Power windows power locks power mirrors and memory driver seat. There's your flat bottom on that steering wheel We'll hop inside here turn the ignition on so that you can see All the options and the instrument cluster We'll turn the lights on so we get a little bit of a dimming there You have a compass outside temp display You also have a digital speedometer the seven inch LCD display there that white faced instrument cluster We were talking about with the black rings around it That's what they were talking about on the window sticker the heated leather wrapped steering wheel you get thumb pads right here cruise controls you get the paddle shifters Bluetooth audio controls information center controls and once again that flat bottom steering wheel Now this one has the 8.4 4c radio it's going to have the factory navigation right now. We're on the SRT Performance pages you got the different drive modes you got the performance pages on here You also have the factory navigation system. It takes a second to load those performance pages But when it does it's pretty cool Because you have zero to 60 times you have your torque power you can do your history on there You have your different Engine horsepower torque ratings oil pressure. You have your g-force which is pretty cool while you're driving to see Acceleration and when you're going around with corners and stuff and then you have your different gauges here You can swap those out so you can change that to read whatever you'd like and then you have your different timers here So 60 foot 330 foot eighth mile quarter mile thousand foot Last best really cool Accelerating and braking zero to sixty zero to a hundred Just a lot of cool stuff that you can do which would be a lot of fun in a car like this So that's the performance pages you get AM FM and Sirius XM radio get the traveling service for five years Also has the factory navigation system Of course, and then you have your heated seats cooled seat buttons You have your heated steering wheel button and this is also where your backup camera is going to show up Which when we started I'll show you that Down here you have your different drive modes you're which will then in turn go up here To the drive modes right there. You have your launch control Back up parking sensors. You can turn those off your stability control If you don't like doing your climate up there You can do your climate down here and then you do get volume and tune controls the eight speed automatic transmission you get that Leather stitched dash This one does have the power sunroof on it Map lights home link buttons for your garage door security systems and lane systems assistant SOS, and then you get that rumble be Stitched into the backrest of the seats, which is pretty cool All right, so we're gonna start it out We're gonna take a quick look under the hood First I'm gonna show you the backup camera Which works nicely This car sounds really good. I Would personally like to thank you for checking out the video today and hopefully from this HD video You have gotten a really good look at the car Checked out all the options Checked out the color under the hood. We have the 392 6.4 liter v8 hemimotor 485 horsepower 475 foot pounds of torque Get that shaker hood Shaker hood scoop Get the shaker sticker on the hood and of course you can see right through Powered by SRT Get the cold air intake Now these headlights are really cool Notice the Dodge logos in there. They look like checkered flags just by Glanton at them You get the HIV headlamps. They are super bright. No fog lights on this one I don't think you'll need them know the car is low enough and those lights are bright enough But you also get the halo rings around there for the LED lighting and We'll check out the tail lamps here as well Since we have all the lights on and then we'll do one more final walk around to the car that classic Challenger back end and once again, thank you so much for checking out the video remember to like subscribe and share and We do videos just about every day I'm always in here videoing researching Checking out cool cars cool trucks for all the people on our channel and To see more pictures of this car or one of our other 450 new and used cars trucks SUVs mini vans Wranglers challengers chargers Mustangs Corvettes Camaro's you name it we got it go to that website right there www.summitauto.com full pictures and descriptions of every single vehicle from two locations all at summit auto comm and if you like to check out more HD videos you can go to youtube.com slash summit auto number two like subscribe and share on this video and all the videos that you see there in fact In a second you will see link to subscribe to our YouTube channel on your left link to more dodge challenge your videos like this And I'm right if you've not been to our website on the bottom link to this vehicle on our website Click those check us out and we're super excited to be offering the 2021 Dodge Challenger RT scapac with the wide body and the shaker hood and hell raisin purple. Thanks again for checking out the video


I'm a stand-up comic and today we're what it's NASA universe unplugged live chat and today we're going to talk about exoplanets. One of the things NASA looks for is whether a planet is located in the habitable zone around a star. So why is that so important? Check out this video to learn a little bit more and then we'll come back and take your place. The telescopes can find any earth-sized planets around here. I said I'm working, I'm looking here. Like those? Well what do you know planets? Everything here is all bunched up around that star. There's a large planet right next to it over there. A couple more further out. And one right smack in the middle of the habitable zone. So if this one turns out. So that was from the habitable zone and we learned a little bit more. It was also from the expanse. That was Kaz Anvar from the expanse I believe. I'm here with two NASA scientists and you're gonna get to talk to them but let me introduce them. We have Tiffany Kateria. Is that correct? Kateria. Yes good. Okay it's a planetary scientist at NASA's Jet Propulsion Laboratory whose research focuses on the atmospheric structure and dynamics of exoplanets ranging in size from Jupiter-sized to Earth-sized planets. And then on your lower right would be Robert Hurt. He is an astronomer at NASA's Spitzer Science Center who specializes in visualizations of scientific observations and who wrote and directed the habitable zone episodes for the universe unplugged. You guys, I'm a comic. What is an exoplanet? Sorry. No that's fine. I'll take that one. So an exoplanet is a planet orbiting another star like Earth orbits our Sun and the other solar system planets exist in our solar system. So exoplanet scientists so far have discovered over 4,000 exoplanets and so these are ranging in size from Earth to actually from Mercury to even larger than Jupiter. So a wide diversity of planets that have been discovered so far by various techniques which I can also talk about. Okay and so Robert tell me what exactly is this habitable zone that the show is named after? Well the habitable zone is one of the observable things that we can pick up when we look for exoplanets around other stars. It's basically one way you could define it is if you were to put Earth around a star, a different star, how far could it be away from that star and still maintain liquid oceans on its surface. So if we can find exoplanets orbiting a star, we can figure out how far away they are from the star and from observing the star we can figure out how large it is, how hot it is, and how much light and heat it puts out. We can actually calculate sort of a range of distances that would be consistent with having the liquid water potentially existing on its surface. Now it's absolutely no guarantee that there's going to be liquid water and it's certainly no guarantee that the planet is actually habitable. But that was one of the things that we wanted to do with the habitable zone videos is sort of let you travel along with some fictional space explorers finding planets that are in the habitable zone and find out all the different things you have to worry about other than just where the planet is located. And can I ask how do you find exoplanets? Yeah I can take one. So there are many different ways to find exoplanets, a lot of which at least in recently you actually are staring at a star and inferring that a planet is there so it's somewhat of an indirect detection. So one of those is called the transit technique and so a lot of you may have heard about that given the Kepler space telescope and now the Transiting Exoplanet Survey Satellite test, which uses the transit technique to find exoplanets.  And so a bigger planet will block out more light, a smaller planet will block out less light. And so then using those measurements we actually have an estimate of the planet's size. And so we know if it's something more like an Earth or something like a Jupiter. But there are other techniques to find exoplanets like the radial velocity technique or the wobble technique. And so this uses the gravitational tug between the star and the planet to infer that a planet is there. So a more mass. And that's what the, oh, go ahead. And that's what the transit method is. The transit method is like gravitational. No, so the transit method will measure the size of the planet. And then the radial velocity technique I would actually say is a complementary technique because from that measurement you actually get the planet's mass. And so with a mass and a radius, you have a planet's density. So then you know if the planet is more rocky like an Earth or something that's more like a gas giant like Jupiter. But ultimately, what you want to do is take pictures of these planets actually images of the system. So that's a technique called direct imaging. But we've only been able to do that for the most massive, the most giant planet so far, because that's a real challenge for the essentially to block out the starlight so that you can see a planet there. How many pictures of that have they figured out? Just quick question. Yeah, how many? So whereas for transits and radial velocity, we've been able to find on the order of thousands of planets. For direct imaging, so far, we've only really been able to do it for tens of planets. But there are scientists and engineers working really hard to essentially work at getting at the angle you need between the star and the planet to really find. So ultimately, you want to find an Earth size planet in the habitable zone of a solar type star, because that's what we understand in the search for life. And so there are lots of engineers and scientists, really smart engineers and scientists working on figuring out the best ways to to image those sorts of systems. Okay, Robert, did you have something we wanted to add? Yeah, it's worth noting also that for the direct imaging, you're looking at planets that are so far away from their star that they are like proportionally well beyond, say, Pluto's orbit. So it's radically different. It's very, very different than the kind of terrestrial environments we would be interested in, particularly in the search for life. So that's why we rely on these other indirect methods, like the transit method, because they're much better at finding planets that are closer to the star than direct imaging currently. Okay, and we have our first question from the from the internet, you guys, it's at Dr underscore eclectic asks on Twitter, do we miss the vast majority of planets that can't be detected if their transit is not aligned between the parent star and our earth? It sounds like Dr eclectic knows what they're talking about in that question, because those are many words. Who wants that one? I'll take that one. So yeah, I mean, I guess so given a single detection method, such as the transit method, you would run the risk of actually missing out on a lot of planets, because, you know, you also have to find planets that essentially will transit along the star. And so it needs to be in a favorable inclination relative to the star. And it's also harder when the planet is smaller. So that's actually so so ultimately, it's a relative measurement between the pair of the star and the planet to actually detect the transit happening. So essentially, and this actually ties very well into the habitable zone. One of the reasons we look at m door specifically for planets in the habitable zone is because they're much smaller than our sun and therefore the transit ratio between the star and the planet is actually much larger. So it's much easier to find a small planet around a smaller star than it is to find a small planet around a bigger star. And so that's what does it get lost? Yeah, well, it's just a smaller signal that you have to search for. And so it's very challenging to do that. And so that's why m dwarfs and also, additionally to that, the habitable zone, this Goldilocks zone for m dwarfs is much closer into the star than it is to our sun. And that's also what the video shows you. And so given that closer into the star means that it's more likely to transit and we're more likely to see it. So those kind of two couples properties make transit's much easier to look for habitable planets to look for around m dwarfs. But yeah, but that's why complimentary techniques are so important. So that's transit. But using all of these other techniques, radio velocity, direct imaging and other things that I haven't even mentioned, makes it, you know, gives us a better chance of having a more complete sample. Yeah, Robert, you wanted to add something? Yeah, just to add that just to kind of close on Dr. Cleck's question is that yeah, every time we do detect one of these systems that has a transit, we know statistically, there are many, many more that we didn't see because they weren't oriented in the right direction. So so really, we're just getting kind of the tip of the iceberg on exoplanet detection. So we know there's so many more out there. But you know, until we get a chance to take spaceship and fly to some of those, it's gonna be really difficult to detect the planets. Okay, those others that aren't aligned well. Here's my question. So is an m dwarf like an m class in Star Trek? What is an m dwarf? Hi, we'd like to just peel it back. Let's start real low. Because this one, what's an m dwarf? In in Star Trek, an m class planet is a place like Earth is very habitable. But m dwarfs are actually really, really different. They are the smallest stars you can have that are still stars. They start around about 100 times the mass of Jupiter. And basically, if they were any smaller, they wouldn't have enough pressure internally to maintain nuclear fusion going on their cores. But they're also really interesting, because they are the most common stars, there are far, far more m dwarfs out there than there are suns like g type stars like our own sun. So they're very common. But they're very faint. And they're very small. Indoor stars themselves are only about the size of Jupiter. So okay, basically, imagine, imagine the Jupiter system as like its own solar system, that's the kind of things that we're looking at when we study planets around the course. Okay, so that is very small. Now, you should know that Noel James on Twitter has a couple of questions. What are the main aspects required to declare an exoplanet habitable? So it sort of actually depends on who you ask really. Oh, I I'd say, you know, sort of classically, I think Robert may have already touched upon this a little bit.  So we want to search for a planet that might have shared the same insulation, the same radiation that Earth receives. And so that's sort of why we make these comparisons between m dwarfs and solar type stars in terms of where their Goldilocks zones are, habitable by whom or what, indeed. And so, but another aspect may very well be things like the composition. So in the earlier version of the earlier episode, I should say of the habitable zone, they touched upon this as well. So you want the right gas mixture in your atmosphere. So that's the job of telescopes to search for those gases in these planetary atmospheres. So things like water or carbon dioxide or methane or ozone, these are fundamental gases we see in our own atmosphere that we think would be important for the processes of life to evolve on another planet. And those are detectable by telescopes. Now you can detect the type of gas with a telescope that we currently are using. Yes and no. So, so I guess the gases themselves are detectable, but the measurements themselves are very challenging, given that these are very small signals to detect out of a, so out of a planetary atmosphere. And so with the transit technique, for example, you're looking at information from the star and essentially subtracting out all of the stellar information, and then you're left with information about the planet. And so that's a fraction of a fraction of, you know, the signal that you get from the star. And so that's why techniques like direct imaging would be so favorable, because you basically don't even worry about the signal that you're you're blocking out the signal from the star to begin with before you're extracting information from the planet. It's it's independent of one another, essentially. Okay. And now, but oh, so sorry, just to just to close that in terms of the molecules themselves, things like water have been detected, but just not on planets that are potentially habitable. So on these hot Jupiters, these Jupiter sized exoplanets that are really close into their host stars, we've looked, we found water and you know, dozens of those planets. So the molecules are detectable, but so far just for kind of favorable planets that are more favorable given the current telescopes we have online. But scientists and engineers are thinking about the next generation of telescopes that may be able to more readily detect these these molecules. Okay, and when you say habitable, are you I mean, ideally is habitable eventually by humanity, because well, we wish to go to space. But the but what about now like just are you just looking for any kind of life? Robert? Or I don't know, Tiffany? Sure. Yeah, no, go ahead, Robert. Yeah, at this point, I think any astronomer in the world would be overjoyed to detect the slightest evidence of the smallest bacterium existing independently somewhere else in the universe, right? The obviously, we know that life is possible because we're here. So the universe certainly allows life to exist. The one thing that we don't know from a sample size of one is how frequent is it? Is this a you know, a one in 100 kind of odds? Is it one in 1000? Is it one in a trillion? And so our search for life, not only, you know, in around exoplanets, but even search for life in the solar system, the possibility that might have popped up on Mars or other planets or in the oceans of Europa, if we can find independent evidence of the chemicals, the processes of life coming together independently in more than one location, that actually gives us an idea that Oh, yeah, the it might be a simpler and more common kind of thing. On the other hand, if it's even if you have a nice ocean covered planet and nice tides and summery conditions, you know, if then it still only happens one in a million times, then life might be very, very rare in the universe. Okay, now we have another question. This is from Facebook is how many of the over 4000 exoplanets, 4043 exoplanets discovered are located within the Goldilocks zone? And why Goldilocks? What's happening? Okay. Homer question. Yes, please. So the Goldilocks zone sounds like this might be something that is she's looking for the perfect bed, I assume. That's what the it's the Goldilocks story. So that so what is the Goldilocks zone and how many of those planets are located within that zone? Who wants that one? You want to start, Tiffany? Sure, I can I can take that one at least to start. So so the Goldilocks zone is based off of the the story of Goldilocks, you know, getting the porridge either too hot or too cold. And so the same idea applies here in finding planets that are just the right temperature to harbor life to have this liquid water on their surface. And so this is what you know, the habitable zone is really defined as. So of those 4000 or some odd exoplanets that have been discovered so far, roughly about, you know, 50 of those or so I would say are potentially habitable based off of this kind of temperature argument. So these are the planets that are the right size and the right distance from their particular host star that suggests that there might be liquid water on their surface. Of course, we don't know that answer for sure. But these are the best candidates to go out and search for those molecules and other properties that might suggest lights there. One thing I just find so interesting is that out of out of these over 4000 planets now, we still haven't found a single one that's a good direct analog to the earth. Speaking of, you know, the same size as earth at the same distance from a star very similar to the sun. That that is still as many golly locks planets as we found, right? That's still not a direct parallel we found. So that that kind of speaks to just how rare and special I think earths are. And I think it also I think it also speaks to the current, you know, time for which we've been actually searching for these planets because one of the challenges with transits is that you actually want to observe the system transit a bunch of times so that you can confirm that it's, you know, orbiting that particular star. And so for an earth sized planet orbiting a sun like star, given its orbital period of a year, you'd want to observe it for, you know, three or four years to actually confirm that it's there. And so given that it's a small signal and you really want to verify that that planet is there, I think that also just points to, you know, how much more time we need and better techniques to maybe image those things. Instead of Rick, because are we are we in the are we sort of in the first year of finding these? Oh, no. Have there been cycles? No. Okay. I don't know. Yeah. Yeah.  And so the first detections were actually made in the early 90s. And so but those were for planets that are larger on the whole, and using a wide range of techniques. But, you know, in terms of these small planets, the potentially, you know, rocky, potentially habitable planets, I would say a lot more forward progress has been made on that within the past, I don't know, 10 years, five to 10 years. Okay. So it's a routine several cycles? Yeah. Right. Yeah, potentially. Yeah. So, so Kepler and tests have been, you know, operating or have really amplified our number of discoveries, thanks to these, these surveys, given that they're staring at either the whole sky or patches of sky for four planets. Okay, we do have another question that goes very much to the basics. So I of course enjoy this question. Brody, with a bunch of numbers, 889, 58302, hike, he would like to know, how do suns form?  So how do suns form is the real question Brady has? Well, you know, Robert, a lot of stuff did kind of smash together and then start to burn but not like fires, not like on earth. But no, the the amazing thing is that when you look out through the galaxy, you see, you look up the night sky, you see lots of stars, and you think that's what the galaxy is made of is stars. But actually, there's a lot more out there. The space between stars is actually filled with gas. It's mostly hydrogen and helium, little traces of other elements mixed in. But the gas that's flowing around the galaxy, it's not smooth and uniform. It has eddies and currents and places it clumps together and builds up. There are basically you can think of it almost like stellar or gaseous traffic jams that occur in the galaxy, where a little over density occurs. It's like driving down the four or five freeway.  This kind of thing happens in the galaxy too. Sorry, I didn't mean to I didn't mean to give you a trigger warning event there.  But in these interstellar gas clouds, sometimes what happens is when enough of that material starts bunching up, the gravity of everything distributed through that gas starts to actually take hold and pull it together even more. And you get these regions where the density of the gas goes way, way up. And in some areas, if it gets high enough and from the turbulent motions and things swirling around and piling up, you get certain regions where the overall density of the gas is so high that gravity just takes over and it starts collapsing down onto itself. And at the very center of that is where you will get a baby star forming and it will be surrounded by gas and dust, you know, carbon and silicates will form kind of clumping together and make it very opaque and hard to see. But then as that material starts to gather together in the center, any residual sort of motion ends up spinning up the material around it. And all of that other stuff, the carbon and heavy elements that are starting to form that disk, they're the seeds for planets to form around that star. So, you know, basically the planets that we see in the solar system, they were sort of formed from the leftover debris that didn't make it down into the sun. Okay, so the sun is a star, right? And it's sort of remember that video game where you'd roll along and things and stick to it. Anyway, so it's like, it's like that. Hadamari? So essentially, it becomes dense enough that it that it that it has the power, and it's, and it's, it's hot enough and strong enough to become a sun because of the density.  And that's, that's what happens with the star. I can be taught. That's what we're learning. And the burning that goes on, it's not like like fires, it's not like burn isn't really a good word. This is actually process of nuclear fusion, where you, where you get the densities are so high that the hydrogen atoms, like, can smash together so quickly, that they actually overcome their repulsion, you know, they're their electric charges on on nuclei, and they tend to repel each other. But if you can get them close enough, this other force takes over. So we call cleverly, the strong force, they smash together, and they release energy. And so that process of nuclear fusion is what generates the power that lights the star up. Okay, we have a complicated question. Someone who knows about the James Webb telescope. So it's Mongoose sausage, Mongoose sausage, come on. Mongoose sausage would like to know, what more will the James Webb Space Telescope be able to see? And when does it launch? Explain to me what the James Webb telescope is. And, and oh, and then I've also been given a note that they launch is sometime in 2021. Anyway, but what is the James and what do you think it'll be able to see? So the James Webb Space Telescope, yes, is short at JWST for short, or web for short, is essentially the next generation of space telescope to follow on from the Hubble Space Telescope and the Spitzer Space Telescope. So this is being launched sometime in 2021 to do a whole range of astrophysics and planetary science. It's going to really revolutionize our understanding, not only of those areas, but also of exoplanets. And this is largely due to its increased sensitivity, but also the broader wavelength coverage that this telescope will have. And so basically at different wavelengths, the atmosphere will give off different will their different fingerprints in the atmosphere that you'll be able to detect at different wavelengths. So we'll have access to a whole bunch of other gases that facilities like Hubble weren't able to access things like other methane features or perhaps signatures due to clouds. So it's highly anticipated us exoplanet scientists are really excited for the James Webb Space Telescope to launch, because I personally think that the observations that Webb will give us will completely revolutionize what we think we know about exoplanets and their atmospheres. You think you know, but you have no idea. What is that? That's a catchphrase from somewhere. But right. Exactly. The same goes for exoplanets. I think we have, you know, we think we have a vague idea of how these planets are formed and what they're made of. But I fully anticipate that James Webb will will completely, you know, surprise us. Because it's a it's just it's got all the current tech because every time something is is launched, the engineers are making a new version, right? So the the new science that will come back is on. It's it's brand new, right? New wavelengths and new levels of detection. Right. Exactly. Exactly. Yeah, that's cool. Anyway, Tiffany's Tiffany is actually involved in helping design one of the next next generations of telescopes that would be possibly one of the successors to the James Webb. You guys, this is amazing. We are talking with scientists. Are you excited about it? There's more questions. Captain Jean Hammond, do particles that move past an event horizon move faster than light? Since light cannot escape the force of gravity is greater than the power of the speed of light? Oh, that does sound science fiction. What's happened? Who could translate that for me? Robert, this is the, well, this is this is your black whole question.  But so okay, I am far from a black hole expert myself, but I will say at least I can I can state with confidence that at no point will anything ever actually move faster than the speed of light. It's a that's it's a thing that you can strive for, but you can never achieve. And so even as weird as things happen around the event horizon of black hole, where where space time is is curved and stretched so far, it just started so far that light itself can't escape out. Particles will never ever actually exceed the speed of light. It's the the laws of physics are very, very protective of that speed limit right now by it by everything that we've seen. So so yeah, it's particles can go in they the more material you put into the black hole, the more it kind of deforms and the more it expands, but but nothing ever actually quite exceeds the speed of light in the process. I think you explained this to me one other time. Yes, it is disappointing. We have a fun, fun question from the internet at Jack Flapstack. Jack Flapstack has a question you guys. He has a burning question on an exoplanet. Would it be possible to get pancakes any fluffier than we already do on earth? It turns out Jack Flapstack has pancake obsession. When astronomers describe an exoplanet as habitable, what do they really mean? And and then also talk to the pancake issue. Jack would like to know. What do you get? Well, I can only hypothesize I have to admit I haven't seen any peer reviewed papers on exoplanet pancakes or exo pancakes, I guess. But if you look at what happens on earth, I am aware of the fact that if you go to altitude, your your cakes tend to get flatter and your pancakes tend to get flatter because of the low pressures, the the something about the way that the gases are released, they pop out so quickly, the cake kind of gets flat. Now, you could extrapolate that if you get fluffier pancakes at sea level, then you do say in Denver, that if maybe you had an exoplanet that had an even denser atmosphere than earth, that making pancakes there might the bubbles might like a micro bubble even more and give you an even fluffier pancake. Now, I don't think we've tried that. I guess the nice thing is this is something that we could we could verify experimentally, you know, we could we could try to make pancakes in in pressure chambers with different atmospheres, different compositions, and we could actually in principle do that experiment. But I don't know, I don't know, Tiffany, do you know anyone who's looking for a good pancake exoplanet research project?  I really have a hankering for a pancake now. So thanks for that. Could we somehow tie that into our definition of habitability to kind of bring it around to the other part of this question?  No, too soon? Okay. Interstellar house of pancakes?  So exactly. So Corey Palmer, by the way, Vestbinder asks on Facebook, how can we find out if exoplanets have oxygen? Is there? Is that possible yet or? Yeah, so they're actually different techniques that we can use to find out, ultimately, it boils down to telescopes. So telescopes actually can allow us to find out if these atmospheres have oxygen. But with oxygen, given what wavelengths those fingerprints of that molecule exist, we can actually use telescopes, not only in space, but also from the ground. So these big ground based telescope light light buckets, we can also look for for oxygen. And so oxygen as a molecule has different spectral properties that allow you to actually resolve the spectral line at different wavelengths. And so they're basically different techniques you can use with telescopes to try and find this particular molecule. And that's actually, I'd say, a main thrust of research right now, in terms of what sorts of telescopes, what sorts of techniques we can use to find oxygen in in potentially habitable planets, particularly actually around M-dwarfs. Yeah. Oh, cool. I got there was a question that came before we started that I would love to, if you could answer. And it came from at funny, sunny bunny with an eye. Anyway, how much, if any detailed information on a planet's topography, are you able to discern? And that just because of the telescopes, you could, I mean, what would imagine you would be able to get to that? So Well, like, like, like Tiffany said earlier, even when we do direct imaging, it's really, really hard. There's only a handful of planets we've done. And what we're really getting there is just a spec, a dot and unresolved and not actually showing surface features. However, that doesn't mean there aren't some kind of clever techniques that we can start to get at what's going on on the surface. There are certain planets that we've been able to observe, some transiting exoplanets that in addition to seeing what happens when the planet passes in front of the star and blocks some of the star's light, we can also detect when the planet passes behind the star and the star blocks the planet's light. And in fact, we can follow the overall brightness of the system over time as the planet doesn't orbit. And sometimes for a few cases, we can actually see rising and falling amounts of light in the system, which we call a phase curve. And what that is giving us the beginning of like what you could call a temperature map, because usually we've done this in the infrared. So imagine, you know, if you look at the moon and the moon goes through its phases, sometimes it's brighter, sometimes it's dimmer. You can do this by looking at orbiting exoplanets in the infrared and sort of figuring out which part of the light is coming from the exoplanet versus from the star. And then you can start to make arguments about what the temperature map for the whole planet is that, you know, sort of varying across latitudes. And so we actually can start to make start to put ideas together about what planets are made of. In fact, there was a press release that just came out last week on a terrestrial exoplanet, something that was only about 30 percent bigger than Earth, orbiting an M dwarf star, like like the ones we were talking about earlier. But it's so close to the star that it actually we're actually seeing the light of the planet re-radiating the star's heat in the infrared. And we have mapped out the different light that's coming from the day side and the night side of that planet. And from that, we've been able to do a lot of things. We've been able to deduce that it has probably virtually no atmosphere because the night side seems very cold compared to the day side. If there were a thick atmosphere, we would expect temperature that the atmosphere would carry the heat around to the back side, but we don't see that. OK. And then we also, by looking at how bright that planet is in the infrared, we can start to calculate what its surface properties must be like. And it turns out that in order for that planet to have the infrared profile we see, we think it must be basically black, like absorbing almost all the light that falls on it. And the cool thing there is there's really only one common mineral that we see around the Earth and solar systems, something called basalts. You know, think sort of the lava planes in Hawaii, right? Something that's very dark absorbs most of the light that falls on it, but re-radiates it in the infrared. So here's a planet that we can actually, we figure out there's no atmosphere. We figured out that its surface might well be made, have a lot of basalts on it. And while it's not exactly like continents and surface features, it's those first steps at getting at a little bit of that information. OK, that is fascinating. OK, I'm going to do two more questions and then we will have to go, but we'll come back. We'll come back. You'll get to talk to more scientists. It's going to be amazing, you guys. This is very exciting. It is called... You're going to drop some things in the background. NASA Universe Unplugged Live Chat. So it's been very exciting for me. But here's Heather Crockett at Planet Quest. Why can't we see more detailed pictures? Well, you might have just answered this. Detailed pictures of the exoplanet being discovered. I'm sure I'm way out of my league of foot. We can see other galaxies. Why can't we see these other worlds in our own galaxy? So maybe maybe Heather wants to know why we can't get better pictures of Jupiter. Am I misunderstood? Very possible. What do you guys got? Well, Robert, actually, if you want to take this question, too, if only so that you can, because this is a big challenge. So a lot of Robert's work goes into visualizing some of these exoplanets. So we have the challenge of, you know, we can't necessarily see these high resolution pictures of an exoplanet. So what goes into, you know, creating the pretty pictures that the visualizations for planets that you see and say the habitable zone? So I just want to punt it to Robert, so he can talk about that. Well, you guys are having each other's backs and I like it. No, Robert. Yeah, no, it's kind of following in what I was saying before. It's really just a question of scale and the size of the telescope and the sharpness of an image from the telescope really ties to what the size of the mirror basically is in the telescope. And I actually had a great opportunity just recently. I was up on Mono-K, Mount Wilson, looking directly through the 100-inch telescope there. A friend had a birthday party who was listening to us. Hey, Barajan. And, you know, having this 100-inch mirror looking through at Jupiter, while I could see the disc of Jupiter very well, even the moons of Jupiter, I could just barely make out, had some dimension to it. And those moons of Jupiter are very close. There takes like what, you know, less than an hour to get here from Jupiter. Now, the nearest star, it takes like four years to get to us, right? It's so much further away that even with like the biggest telescope we can imagine building right now, you can't get enough sharpness in it to make that little speck of light that's a planet resolve it so that you can start to see those surface features. That's one of the reasons for what we did in our series, The Habitable Zone, you know, and we wrote it as a sci-fi show where we actually got to take a ship and actually go and visit one system after another to give us an excuse to be able to actually look at the surfaces of planets and see what conditions and use what you see in terms of surface conditions to kind of help tell some of the science stories that we are piecing together from these indirect observations, but it's always a little more visceral to imagine what it looks like. So for the time being, I get to have a job like making artwork up on a planet might look like just because it's gonna be a long, long time before we have pictures to disprove any of the art I've done so far. Well, fair enough. And this actually leads into the last question, which Hendrick of Venter has asked, which is can moons have moons and can they be habitable? Tiffany? You want this? Yeah, sure, I'll take it. So this one's an interesting, so I think maybe what he means is, can exoplanets have moons? And the answer to that is absolutely, yeah. You know, even within our own solar system, right? Jupiter has tens of moons. We obviously have one of our own. And that's actually a big driver in the search for life as well. So thinking not only about exoplanets and whether or not they might be habitable, but then also could the moons around, say a Jupiter sized planet be habitable? And so there are some candidate exo moons that have been searched for and potentially discovered. So a lot of, and even within our own solar system, there's a lot of work understanding if, you know, Titan, which is a moon of Saturn, perhaps its atmosphere has the conditions that could, you know, lead to life. The kind of general perspective on Titan as it seems to be somewhat of an analog for Earth early in its history. And so it might have the right ingredients for forming life. There could be, there's been a lot of work on some of Jupiter's moons, Europa being one of them. So it has this icy sheet on the surface and it's been hypothesized that there's potentially this very thick subsurface ocean. So maybe there's a whole bunch of a marine life that lives there. And so those are all mirrors of these planets. And so, you know, it stands to reason that these exoplanets could also have similar moons that could, you know, have these rich environments. Sure. So you think Pandora from Avatar could be real? I know that Robert Heinlein wrote the moon as a harsh mistress, you guys. Here's, my name's Jackie Gation. I'm a comic, I have a podcast. You could find me, whatever, it doesn't matter. But this is all the time we've had speaking with scientists at NASA. You could always learn more at our Universe Unplugged YouTube channel or if you go to exoplanets.nasa.gov. Tiffany, Robert, thank you so much for taking time to explain things. It was very exciting. Thank you very much. Thanks for having us. Thanks, Jackie.