Hello, everyone. Welcome to Cloud Native Live, where we dive into the code behind Cloud Native.  So every week we bring a new set of presenters to showcase how to work with Cloud Native technologies and the stories behind them. They will build things, they will break things, and they will answer all of your questions, so you can join us every Wednesday or like this, sometimes especially on other days as well. This week we have amazing set of presenters here to talk with us about designing and operating reliable Cloud services, a view from the trenches. So very exciting for this special program today. As always, this is an official live stream of the CNCF, and as such it is subject to the CNCF Code of Conduct. So please do not add anything to the chat or questions that would be in violation of that Code of Conduct. So basically, please be respectful of all of your fellow participants as well as presenters. With that done, I'll hand it over to our amazing presenters to introduce themselves. Who wants to go first? I'll go first. So my name is Anurag Gupta. I'm the founder and CEO of shoreline.io and one of the founders of reliability.org. Both correlate to my lifelong interest in building highly reliable systems. My name is Niall Murphy. I am CEO founder of a teeny tiny startup in the SRE ML space called Stanza Systems. If you know my name, though, it is probably because of the site reliability engineering book, the SRE book, and or possibly the ML Ops book, which are both explorations of what it means to build reliable systems. Stephen. I am Stephen Townsend. I am currently a developer advocate for a company called SquidUp, who does unified dashboarding and visibility. I did performance engineering for many, many years, moved into SRE more recently, and I have a podcast called Slight Reliability where I share share my learning journey in the reliability space. Perfect. Amazing group of people here with us today. So today we have a great panel format where I will ask questions and then we're going to get amazing answers. But as always, you can still ask your questions to your audience as we go along, and we'll probably have some time for Q&A in the end as well, but ask them away as we go along as well. So first question to everyone here, what does good or great look like when discussing reliability? So we only have an hour, right? Yes. Yeah. So just off the top of my head, I don't think there's a context insensitive answer to this. Like I don't think there is one answer which just fits everything. And I expect most people in the industry wouldn't be surprised to hear that. I will say there's a couple of fundamental questions you have to be addressing or addressing to a sufficient level in order for this question to kind of mean anything to you really. The first one of course being how much does the org care about reliability? Like if it doesn't care at all for whatever reason, like there might be arbitrary reasons, then good or great doesn't really matter. I would say though that making sure the basics are kind of done well is always going to be a foundational thing you have to have before figuring out what good or great looks for you even make sense as well. And that stuff like are you measuring what it is that you're doing? Have you decided organizationally how reliable you should be? Like if you haven't decided that and you're just getting, I suppose, whatever the native platforms will deliver to you, then you have a huge decision to make about precisely what to improve where. And like are you resourcing it sufficiently? Do you have the right number of people, the right kind of people, the right resources, et cetera, et cetera. There's a lot of folks who are even struggling with the basics before we come to the question of good or great. I will say though that if you do define or if you do have the right measurement infrastructure in place, if you have defined what your levels of reliability should be and if you are sufficiently resourced to meet those levels, well, that looks pretty great for my point of view. Great. So I'd say great to me means that your system is running at a level basically indistinguishable from a hundred percent. So it's a receding horizon. You can always get better. Now here I'm talking about reliability, not availability. Sometimes people confuse the two. They talk about their fleet wide availability but that ignores things like am I getting errors back from the system? Is the performance out of whack? And I often find that people take a fleet wide availability goal and then they claim they did really well even if like one region was down for an hour. That has happened to me with some of the services I used to work on at AWS with the services I depended on. And your customers just don't care about your fleet wide availability. That's an internal goal. What they care about is their particular experience. Were they able to check out?  And in the expected time without a new drama and ideally without having to code against a bunch of error cases due to efficiencies in your software. I think the ultimate goal of reliability is to support an organization to meet its objectives, whatever they might be. So because reliability just for the sake of being reliable, I don't think necessarily is enough. I mean, it needs to have a purpose behind it. So I think maybe good reliability is when the org is achieving its business goals, the customers are able to achieve the outcomes they set out to achieve. The ops team enjoy their work hopefully or are not totally stressed out by constant incidents and fires burning all the time. The technology is easy to operate. Incidents are manageable. And of course the technology is also reliable and performance well enough to do what it needs to do. So it's maybe a bit fluffy, but that's my take. Yeah, it's a good fluffy take, no worries there. Perfect. So next up we have the next question which is tell us a story about a particular or unusual reliability failure that you have seen. Was it a failure of design, implementation or operations? Oh, I'm gonna flow on. So I have a story, this is actually from my performance testing days. So I was, and it was the system which was sort of on the side no one was thinking about. It was a system of record, used to be a mainframe. Over the years it got upgraded and it got put into a mainframe emulator running on a Windows server. And at one point we needed to take some of the data that system used and put it in a big cloud repository. So this mainframe system which was emulated would call to the cloud to retrieve customers or something like that. Turned out that we didn't know anyone knew this but the mainframe emulator which also its own database was an SQL server was considered an external component. It would make calls externally to the cloud and there was a performance issue. It would take like 15 seconds to retrieve a customer. The thing is that those calls were single threaded so that when it was making a call to the cloud to retrieve a customer the entire system would freeze for every single user for 15 seconds. It couldn't even reach its own database to do anything.  And I don't know, when I think back in it I think it was, yes it was a failure of design. Probably more, it's more of a failure of too much technical deed. The system which hasn't been cared for for maybe a decade or more and it just hasn't been thought about. So no one knew about it anymore. So when we're introducing new cloud stuff to the old world and not thinking about and understanding how these things are going to end right. So I spent about eight years at AWS. I saw a lot of failures there. And I'd say the biggest ones were almost a failure of imagination where the system had an error path to deal with the resource becoming problematic but it wasn't able to deal with the at scale case where the failure cascaded. So for example, the week before I joined AWS there was a huge outage in Dublin due to a lightning strike. And that because so many different machines went out at exactly the same time we had this remarrying storm and where every machine was trying to remarry to some other machine that was trying to remarry to it. And there just wasn't enough capacity and nothing was going through. And the reason I call it a failure of imagination is because we all can see and code against the things that everyday things that happen all the time. The question is really thinking about what's the largest scale thing that you're going to go and deal with? Is it a region? Is it an availability zone? Is it a hundred hosts? I don't know, but designing for that is really, I think, incredibly important when you're designing reliable systems. Well, you must have seen a bunch. Again, the margin of this call is too small to contain all of the things. I actually, in a rare example of bone trumpet blowing, I actually run a podcast called Getting There with Nora Jones, the CEO, founder of jelly.io which actually goes into very much detail about incidents and tries to examine them under the framework or LFI framework or a socio-technical systems framework or a safety two lens. There's an emerging movement about how folks actually analyze and respond to incidents which is making quite a lot of inroads into the SRE community in particular but also in hospitals and like chemical engineering and aviation and a whole bunch of other fields where the standard reaction to incidents can be possibly a little bit more blameful than we might like and the organization doesn't learn as much as it would otherwise but in terms of kind of bite-sized stories, like I've loads, I suppose there's the time that somebody de-referenced a pointer incorrectly and everyone saw the data for customer zero. That was pretty cool. That was not so good because obviously customer zero did not want to show their data to customer one through empty million but it was relatively simple from a kind of a contributing factor point of view like the code got changed and pushed. The difficult thing was figuring out what the correct privacy and legal response was now that you have this data which shouldn't have been accessed by other folks then there's the ones where the technical thing is maybe clear but you're working internally or externally with folks who might have some trust issues with the framework of authority that you're dealing with and so you have to kind of establish trust in the middle of an active incident. I have one with a public sector in Ireland where the technical cause was actually relatively clear from day zero and was something to do with traffic routing but folks on the call weren't in a position to believe that a large organization could make guarantees about how their systems were performing that the smaller organization was kind of ready to really absorb. So there was primarily a social conversation rather than a technical conversation and then a little bit like I suppose Anorak's story early in the days of S3 the AWS system used a gossip protocol to tell other machines where the data lived and so if for example a system or a data center lost power and all of the machines came back up at one time they will go hi, I'm machine X I have chunks one through 70 million and hi, I'm machine X plus one and they would all tell each other and completely flood the network and they would completely flood the network even worse because there was an assumption that this network which was actually split between two data centers had exactly the same bandwidth characteristics on every point to point link which of course is not the case if you're going between two data centers. So that was fun. Perfect, a good variety of fun challenges and failures there, great to hear. But with these experiences in mind what design recommendations can you share for delivering services with maximum availability? I'll start. So my first take is you should automate everything and that you can. So because we've done a decent job over the last 2030 years in improving quality. And so I think it's now time to provide that same sort of engineering rigor to reliability as we did for quality and have things go through pipelines, inject failures, see how they're handled simulate large scale events to see if the system can heal. So I feel like the more this is software the more it scales, the more you can manage it like it's software as opposed to people and processes intrinsically hard. People change processes. Sometimes they're followed and sometimes they're not. I think maybe the biggest challenge right now is just how distributed our systems are and how many components are that need to talk to each other. So we talk about zero trust for security. I think in a way we need to start thinking about reliability in a similar way. So maybe being careful about the vendors that we choose to connect to and making sure that they're reliable because at the end of the day you are only as reliable as the dependencies that you depend on. That's a whole nother way of thinking I think. And also realising that there are going to be maybe dozens of components that you're out of your control that you depend on. I'm gonna say yeah and building sort of degraded service around that. So if this thing goes down have a backup plan or provide degraded service. I think that's one thing. And I guess the other thing is of course having really effective observability and that's easy to say the word observability but I think being able to pinpoint what you know to understand and see clearly what's happening in a really complex distributed system. It's hard, it's hard to get right but when you get it right I think it makes a big difference to improving reliability. Yeah again there's an absolutely gigantic amount of stuff we could say here. It's even a struggle to keep it to 56 minutes. So I think I'd start off saying like there's a bunch of things you could do with different levels and some of the levels are maybe relatively tactical or code focused or whatever. One thing that believe it or not contributes a lot to reliability problems is have you checked the return code from your system call or your HP request or whatever what happens if that does not complete and the information that you were hoping to get does not in fact arrive in the buffer and you just pretend the buffer is there and has something valid in it and you proceed to crash merely. Like there's all kinds of stuff at that level. Then the level up where you're going, okay boxes and lines, how do they communicate to each other? Is there some kind of resiliency? You can think about there on a design level. There's a, it's not quite a programming language more kind of modeling language.  Of course it's a Leslie Lamporth production from the same folks who gave you or same person who gave you PAXOS another leader election, master leader election kind of primitives. But TLA plus allows you to kind of model state transactions in a distributed system and say, okay, if this goes to here and we message this thing back with this other information, can we prove that this is correct or can we fuzz it enough so that we can look at some potentially, some cases where potentially reliability might be in threat. And actually Amazon used TLA plus in a bunch of stuff and discovered like there's some 39 level stack, deep stack of stuff that actually ends up being problematic a little bit like, I think somebody proved BGP doesn't actually ever converge a couple of years ago or something like that. Anyway, lots of things you can do. Perfect. How are we feeling? Do we want to take an audience question here in the mix? Oh, perfect, enthusiasm, that's nice. So we have Lauren George asking, how do small slash medium sized organizations predict themselves from outages from big public cloud providers without breaking the bank? Is it even possible today? So it depends is the silly answer I'll initially give really depends on what your app is trying to do really depends on what your dependencies are. There's actually a fascinating piece of work from I think Walmart who are in no sense a small or medium sized company but a fascinating piece of work from Walmart who do kind of multi cloud spot pricing for instances for stuff. And that's almost the definition of not breaking the bank I suppose or breaking other banks. But the basic deal is figure out what you're depending on. Figure out if in your application you can use specific cashed results or algorithmic fallbacks or hard coded fallbacks of various kinds. Note all of these may potentially have reliability outcomes that you were not expecting at some future point of time. But if US East One disappears and you are using some subset of stuff but you can limp along with cashed results for a while like actually that's kind of a win. A lot of people are pushing multi cloud at the moment which there's been a lot of discussion about in the industry. And basically the feeling is it doesn't make a whole lot of sense to go copy paste for your infrastructure from one provider to another. They work hard at making sure that you can't actually duplicate that kind of thing a little bit like mobile telco billing models I suppose but the real deal is if you are using a specialized thing that's only available in one provider make sure it's something you can do without for a couple of hours if you need to like big query equivalent. But I'll stop talking now. Yeah I think there's a lot to unpack and answer. Let me add on to it a little bit. So I think the question really becomes to think about reliability the same way that we used to think about security in terms of threats except now the threats are when you lose availability of your dependencies. And so it's for how long can you relate? How do you degrade when that happens rather than fail entirely? Like if you're losing, if you're using Lambda and Lambda goes down entirely you're kind of out of luck. If you are using VMs and a VM goes down you can probably spin up another VM particularly if you've got a warm pool already out there. So it's really a question of tolerating failures and you can't just duplicate everything, right?  Yeah I don't know, I guess my two sense is that if you're a small to medium organization and you're thinking about going multi-cloud have a serious think about the risk versus the cost of what you're trying to implement in the complexity of it. I think it would be a hard case to say that it's actually worth the effort and the cost and there's other things you can do like Nile was saying. Great and then we had a few more questions but I think we're gonna go through some of the pre-decided questions first and get back to a few of those. So Andrew I saw your question about case engineering we're gonna get to it eventually as well as Lauren asked about books or articles and I think that's a great question to maybe wrap up in the end towards if any of our panelists have great resources for everyone to jump into next. And then also I saw the podcast question and I'm gonna send the links to everyone in the chat. So no worries there. And then to the next question which is how do you identify and we saw potential reliability issues before they become your customer's concern? You know, at AWS one thing that we all did even Andy Jassy did was monitor Twitter because at least at the time there was, people would go onto Twitter and ask is that three down or something like that. And your whole goal was to make sure that by the time someone was asking that question you already knew, you already had the event started you're already working on it. Maybe you didn't have it identified the root cause but you're working. And so I think it's a really important question and it's a really important goal we should all have because what you're doing as a cloud provider is, you know, you're taking off, you know, you're taking on the responsibility that your customer would otherwise take on themselves. And so they need to trust you and they need to trust you to care about them in a way beyond what they would do on their own. So, you know, you just need to be really good at this stuff. Well, obviously I think great observability is important. So, and I think that one of the keys there is to focus in the beginning. Let's say you're starting from scratch start with making sure the customer can use the service rather than getting lost in all the myriad of technical metrics and events that you could be tracking and looking at. Cause once you can, if you can't answer that question can customers consume the service then nothing else really matters in my opinion. I think that SLOs are a good way to potentially do that but I don't think you have to do SLOs either but that's contentious but that's just my particular opinion. And I think the other thing that's coming from a performance testing background is to be testing reliability during delivery especially for a new product which maybe you can't just go live with immediately and have load on it because there's no customers at first. So, testing it is a great way to shake out not everything because real customers in the real world do unexpected and wonderful things but you can't shake out a lot of issues and understand your solutions and systems and services better. But beyond, so those are the I think ways you can identify issues before customers do but beyond that there's all the other things we can do to mitigate the impact. The way that we deploy, you know doing deployments like blue green deployments or canarying or rapid rollback and things that can reduce risk there. Learning from incidents not just having incident secure and not gaining something from that because incidents are fantastic in terms of learning and growing as an organization. And also I guess the last thing is really prioritizing the services that really matter the most to your organization and your customers rather than trying to treat everything equally when you might have some administration API that no one uses or it's not important, you know. Okay, so I'm not saying you should do this but there is an improvement loop available to you a little bit like Anna Reich was saying where the answer to what to do for monitoring is you do nothing and you wait for the phone to ring and the phone, hello, sides down, oh, sides down. No, thank you very much. And then you figure out what went wrong and then you turn that into an observability rule and you just do that a billion times and eventually everything is covered, hey, except of course everything is covered. And so you have a billion things to monitor and it's not necessarily clear which seven of the billion things actually matters. So that's a question that you can also resolve with this other magic trick, which is we're pretty kind of big backend people, right? So we think about things in terms of microservices and communicating via SLO or communicating via RPCs and setting SLOs and so on and so forth. That is backend language. It's not front end language. And the interesting thing about the 2023 catch point blameless SRE report is that it says only 35.8% of respondents said that they had client side monitoring that fed into their observability that they could make decisions about. And I think that's the huge gap that can help a lot to plug particularly or to plug observability problems, particularly if you haven't done what's called a CUJ analysis or a critical user journey analysis for your site or your service in some sense to figure out what the actual people actually want to do and kind of instrument that. So lots to do there. Great, good suggestion there. So then getting to the next topic is reliability.org. So why do you see the need for new reliability.org community? So the reason I started reliability.org which is a nonprofit, nothing to do with showing any of our own goods is that building highly reliable systems is something of a black art. And it's mostly informed by just bitter experience. And that's okay at a hyperscaler because they've got lots of people with lots of bitter experience and they get better. But it's a problem for the rest of us, right? And there's just no good place that you can go to offer your thoughts or to get advice. And so that's Twitter kind of used to be but it's less so now. So you kind of want to safe place. You can go without a lot of noise and without a lot of vendors that you can do this. So now I asked other people like Steven to join and yeah, it's early days but I'm actually enjoying the conversation in there. That's great. Anyone else want to add therapy points? Yes, I do. There's lots of nuts. I don't know. Okay. All right, come on. I actually wasn't aware of any other sort of reliability communities out there that were not based around a particular technology maybe or an open source project. So I haven't found one before. So for me, it was like a new thing. Maybe that's just because I wasn't aware of what else is going on. I also think that there's generally been a split between open source communities who are very active from what I see and also these sort of commercial communities of people who are built around technology like AWS or whatever. All right, and so bringing those together I think it's quite exciting and getting those different perspectives. Yeah, I think cross company collaboration is important as well. Yeah, I think we could talk more about that but I know someone in New Zealand who's an SRE and quite a large important organization and he's the only one. He's a waini SRE. So he has no internal community whatsoever. So the only chance for him to get ideas and the bounce ideas is to go out to the industry. And the other hand, he's living in New Zealand. I mean, could be worse. So I hang around a lot in either role focused or conference focused or sometimes technology focused slacks is what it tends to be these days rather than mailing lists or whatever. So I like the idea that there would be a kind of a cross role, cross company, cross industry conversation about this that isn't tied to any one particular thing. And that seems to me to be a win. Great. So how in the future then now that this great new community has started how do you see reliability.org community growing and evolving in the future? Let me start, communities are hard. They take nurturing. They take constantly adding useful or thought provoking content. And it takes creating a safe place where you can offer your opinion even if there's an expert like now hanging out there who might just say, well, my experience it's the answer is 12. And then what do you do? Now it's not like that you shouldn't work but now you want to reach provider or response. The answer is 13. Let's just get that right. Yeah, I mean, I don't know. Communities are hard, things are hard. Maybe it'll be wonderful. Maybe it won't be, I don't know but I will say that I'm increasingly anxious about the future of the SRE profession in a world which is I suppose growing increasingly unreliable. Is that a good word for it? I suppose. And in a sense, I have this whole thing. I talked at SRE kind of a number of times about weaknesses in the intellectual foundation for justifying the value of reliability and so on and so forth, right? So I think those questions are unanswered. I think that part of what's happening right now is this idea that actually things can be worse and it's totally fine or maybe it's not totally fine but we'll just do it and move on. And I think that's like terrible user experience and a terrible abandonment of contracts with the user, right? Like if nothing else, emotional contracts even if they're not kind of SLAs. And so I think that kind of stuff needs attention and generally one of the ways it gets, it makes progress as via cross-community conversations. I also see the potential in the community for mentoring, mentee relationships potentially, something we could extend upon and yet this has already been said. Just the idea of having a place where you can put out an idea, bounce an idea with people with a whole wide range of experiences. It's just fantastic and it can't be, I can't undersell how important that is. Great. And then Stephen, as you were one of the first people to join the reliability.org community, what made you jump right this way in? Yeah, so I work for a smallish company around 100 staff, we're building a new product. We haven't hit that inflection point yet, we're reliability is the key thing. It's more about building the right product at this particular point in time. So I was really excited to be, to have a place where I could go and sort of keep my finger on the pulse and hear what's happening in the reliability world because I'm not getting the chance to do the work every single day. So that's sort of a great thing. And I just really like the vendor neutral nature of it, of the community. As I said before, most of the communities that I've been part of or have heard about have been around a project or a technology. And this is great, I decided I don't know what's gonna happen, it's, you know, it's great. That's amazing. So to everyone here, how can people get involved with the reliability.org community? If you go to reliability.org, the website, you join the Slack, you introduce yourself and then you start contributing. I mean, it's pretty simple. And the more people we got, the more activity there is.  Great. Good answer since no one wants to, I guess add anything. Yeah, perfect. And then now I think we're gonna grab one audience question while we then go next to the other questions here. So Andrew asked before, how trendy is chaos engineering? The practice Netflix pioneered a few years back. And he adds, of course, your news wasn't as popular as it is today, but your takes on chaos engineering. So if you'll forgive me for putting on my kind of copy editor hat or like parser hat and going, how trendy is chaos engineering? Like, do you want a scalar answer, like 13? Or are you saying, how important is it that I should know about chaos engineering or how relevant is it in the industry? I have only my opinion here, like I don't have strong survey data or anything like that. I think one credible group of people who are doing this are verica.io, if you've come across those. They also run the Void database, Courtney Nash runs the Void database of kind of incident data out of Verica as well. But Verica's main thing is kind of chaos engineering. Chaos engineering is really useful. Like it's a really fundamental technique instead of just waiting for things to arbitrarily break in your production and tidying up after it, you go, okay, I'll break a tiny bit of it all of the time. And if I break the right tiny amount of it in the right place, I'll hopefully learn something that I can make progress on with respect to improving reliability in my production without actually having a complete wipeout event. So it kind of in the, if you think of adages or whatever as kind of a tree of possibilities flowing from some kind of single node, then chaos engineering helps you to kind of depth first explore a bunch of potential failure modes that you might otherwise only really encounter after they've set something serious, serious off. It has one particular downside, which is, as I understand it, I've no direct evidence for this, but it has one particular downside, which is people go, okay, so you're gonna break my production and they don't like that bit. They go, I would much rather just wait for it to break completely rather than break it a little bit all of the time, because then the moral failure is somehow not directly connected with my actions, which is not true at all, of course. But there is an issue with having the case for it kind of resonate with certain kinds of audiences. That's all I can tell you. Would it be fair to say that if your engineers are already fighting fires constantly and there's a lot of technical debt that chaos engineering is not probably a good action to take at that time? I suppose you could make that argument. It depends on whether or not the, because often chaos engineering is quite complex to set up because you can't, like you can set up a simple bot that goes around zapping arbitrary VMs every so often, but if the subset of VMs that it zaps aren't performing different functions, you only ever learn the same thing that you were gonna learn anyway, so it's not adding to your additional stock of knowledge. So in order to be really useful for the organization, the chaos engineering has to be doing something nastily and new to you every time. But if you're getting nasty and new things happening to you all the time anyway, like that's not much additional value. So why don't we just do the thing that we're doing right now, which is nasty and new until it stops being so new at which point we can introduce chaos engineering again. So my quick thought is that chaos engineering can be done chaotically, right? You know, where you're just doing random things in the chaos monkey kind of case. And I don't personally find that terribly useful. You know, it's kind of fuzzing compared to thinking very carefully about your testing framework or security framework, but I do think is incredibly useful is fault injection, where you really think deliberately about what percentage of things do you treat as a fault as you call a subsystem. And how well do you deal with those things in terms of retries, in terms of redirects, whatever it is. And that I think can be done in a very careful methodical, you know, the way that you can actually get some use out of because it's very hard to get useful knowledge out of randomness. Great. If no additional comments, hoping on to the next topic, which is what are the top causes of major site outages and how can people avoid them? Yeah, so there's some old data from the second three book suggesting that around 70% of outages flow from change of some kind, like config change or binary change or whatever. So stop changing and everything will be fine. Oh, hang on. Actually, I'm very sorry. It turns out you can't stop changing. Okay, so what we have to do instead is to change in a particular discipline fashion so we don't trigger the unexpected interactions between attribute sets A, B and C on this thing and attribute sets C, D and E on this other thing. And that looks like a bunch of kind of relatively well-known best practices which are still not universally done today, but it's the ICD testing in production, canaries, fast rollback. I once worked in an organization that wasn't able to rollback and sometimes wasn't able to roll forward, which was also interesting. So organizing your productions such that those things can be done is more or less the first step towards tackling that root cause for a better term for most of those outages. This is just purely speculation, but I feel like an increasing, I feel, I think an increasing number of outages are gonna come from the dependencies that we have because we've got so many dependencies and they're growing all the time. So that's, I feel like there's gonna be an increasing source of incidents and outages. You can feel Stephen, you're a human being.  I used to work with a guy and he used to tell me that SRE is DevOps without empathy. That's amazing. Back into better experience, I see. Well, I think about, yeah, at AWS, we used to have a two-hour meeting every week where we'd go through the prior week's outages in important services. And so if I think about the collection of, shall we say, greatest hits that were on replay across those weeks, there are always things like database issues, bad deployments, expired certificates, misconfigured network settings. And it's very similar to what Nile was saying. And what's common across that set is that there's widespread severe impact because they have a large blast radius and that they take time to resolve. So how do you deal with that? Well, one thing is that you plan a deployment rollout so that you control the blast radius. You automate the rollback of changes so that you can minimize the time of failure because it's basically an integral, the severity, the duration and the breadth of impact. And so it's, you can reduce any one of those dimensions that I think make progress. Databases, I mean, we pretty much stopped using databases internally because at least Charlie Bell used to say, it's like putting a switchblade in your baby's crib, just don't do that. It's a complex software that's easy to use and you should stop using it. Just use definitely TB. Opinions may vary. I've written a lot of databases over the years. So something about that. Yeah. Stop using databases would definitely be a message I would not expect to issue from one Anarigup to Esquire. Yeah. I use SQLite at shoreline for all of the bitter experience I've raised. SQLite, like SQLite is awesome, actually. The unit test framework for SQLite is particularly awesome. But like type safety is for Wuss's, I think it's the, general idea. Yes, sorry, stop. I'll stop there. No, no, no, it's good. It's great. It's good to have some discussion. So how do the best people out there manage their cloud environments? When I meet them, I'll let you know. I like, the best people isn't necessarily the right framing for this, right? Because the environment and the resources also matter a lot. And if quotes the best people don't have the right environmental resources to do the work, they'll go to somewhere that does. So like, there's a lot of nuance behind that question. But I would say that a lot of the things we actually talked about earlier in this session with respect to understanding your dependencies, figuring out observability, figuring out critical user journeys, making sure you can roll back. All of those best practices are things that quotes the best people and quotes are either doing, or they've got a good excuse for why not. And sometimes it's a question of picking your excuse. I'll add in the idea of designing for reliability. So, you know, it's like, for example, injecting faults in production, which can be sounds scary. But, you know, it's really a question of resilient architectures which can handle it. So for example, you know, I built Amazon Aurora and it effectively injects a large scale of end every week because it does a deployment, which breaks, which, you know, takes one out of six elements of the quorum out while it does the deployment. And, you know, but it handles it without any drama. And that's just because it's designed to deal with that failure and dealing with that failure means you can also deal with AZ failures or disc failures or a network failures and blah, blah, blah. So, you know, I think that sort of basic design methodology, I'm not saying you should, you know, I'll go do six way quorums, but, you know, the, I think that kind of designing for the fragility of the environments in which we operate is important. Great. So now let's take grab another question from the audience. So we had Luther asking, my company embeds an SRE team in rotation with different teams in hope to work closely with them to improve reliability and monitoring occasionally in house workshops. Any downsides to this approach? Any opinions? I'll take a crack at it and then now can correct me because at least there'll be something to approach. So I think the key question in here is about ownership. So who owns the issues, the failures, how did they escalate the, I've seen orgs that have put in SRE functions, but everything still flows to engineering to fix because it's just a bump in the, you know, in the wire. And that's useless, right?  You're slouching, you know, you're not typing correctly. You know, that's not helping me make things better. So what does help me is that they're actually there shoulder to shoulder fixing things, which I think, you know, Luther's point kind of touches upon the notion of embedding together rather than treating it as a cascade or treating it as a separate retrospective function. Now, you know all about this. Yeah, I mean, there's a huge amount of nuance to this, depending on what the definition of team rotation, different team, et cetera, et cetera. All of those could have a huge impact on what the end result ends up being. I will say I am most familiar with the single individual embedded model rather than the team to team embedding, like team to team embedding seems weird. That's like, that's a partnership model, not an embedding model. I think the weakness of the embedding, the single individual kind of model where you would have an SRE that would go and sit with a team that has a particular reliability challenge or some kind of knowledge deficit or whatever for six months, say, that's a pattern that's very common in Facebook production engineering. Last I was aware. The difficulty with that model is, like the thing it's good at is responding to particular emergencies or lacks quickly. Yes, these 17 teams have some problem. We will send staff out there and they will fix stuff and so on. Yes, like often it does help, but what tends to happen is if you do a lot of these kinds of rotations, you've no real team identity, at least not one that lasts longer than the period of the rotation. And that turns out, even though you might not think it's that important, it actually turns out to be really important with respect to giving people the idea that they can build a career and have a kind of a long lived contribution to long running services, et cetera, all of which are kind of necessary subcomponents of promotion amongst other things. So that's kind of the upsides and downsides of embedding. The other question I suppose that kind of hides behind some of that is, why does the team in question field, they can't do this themselves? Like, are they looking for warm bodies? Because if they're looking for warm bodies, that's generally speaking, not a good sign. It's like, I don't care who they are, just get them cranking out the code now. Well, actually, that's maybe not good. Or are they looking for a specific guided expertise on something in which case, that can sometimes be a bit better? Yeah, it depends, he said, jokingly. And in my last role, we had a different kind of embedding. I guess we were in a enablement team. And so we would spend time with one team at a time, helping them uplift because they asked us to all because there was a particular need. And I guess they worked quite well, but the challenge was that if the team had competing priorities from an organizational perspective, like you must deliver these bunch of features by this deadline, that would just completely blow away anything we were trying to do. Because I just couldn't listen. They were too busy worrying about all this other stuff they had to do. So if the priority isn't there, then embedding is in that sort of enablement is pretty hard. I found it worked really well at AWS to inject a highly skilled person right when the service was launching because typically the service team members didn't really have any understanding of how to operate in production or deal with all of the various processes. And so having someone sort of help them train those muscles helped. Right. So now we can enter the audience Q&A. Not that we haven't taken audience Q&A already here, but if you have any questions in mind, now is the perfect time to ask them because we have a bit less than 10 minutes left. So type them away. And while we wait for people to type their questions, if they are now frankly typing away, let's ask the last question from my side. So it tells about the best. Oh, we have immediately a question. So let's jump into that and leave my question a bit later. So have you found that those with certs, such as Azure, AWS and so forth, are better at thinking through designing and operating reliable services? What's meant by certs here? I think it's cloud certification programs. Oh, certifications. Yep. What's your view? So I have a definite view of this, which may not be shared by other people. He wanted to warn everyone. Yeah, like you say, Lauren, I have no certs. I never met, in 11 years in Google, for example, I never met a single person that had a vendor-related cert. I think that's true. And in general, I'm not saying, I'm not saying you should be suspicious of them. Like there's certificate having people are people who said, this thing is important and I should work towards getting knowledge about this thing, which is a positive signal, like hugely positive signal. But often, like that's an abstract way of representing the situation with respect to certs, the concrete way of representing the situation with respect to certs is often like there's a very fixed set of knowledge you have to have and that fixed set of knowledge might not map onto your problem domain but kind of changes quite quickly as well. Like I know back in the very old days like the networking certifications that Cisco used to do, CCNA and all that kind of stuff, you would spend 36% of your life learning about the difference between type two and type three LSAs in OSPF. And how relevant is that to you really? Probably not that relevant. I suppose it helps to distinguish you from the larger mass of people formally in some sense who have no experience with these ideas but it isn't in any way a guarantee that they will successfully wrestle with your particular problems. Yeah, so I kind of agree with you. I feel like you can kind of have three tiers of people. You know, there's the tier who actually kind of don't know what they're doing and then there's a tier where, you know, they've shown through some sort of certification that they kind of know what they're doing and then you've got this tier that you really want or they really know what they're doing because they're working at it and they're way too busy to get certifications. And so the problem is, how do you distinguish between the top tier and the bottom tier? And, you know, assuming you can do that I don't think certs matter. If you can't do it, it matters a lot, right?  Okay, anything to add, Steven, anything? Okay. And then we have one question from the audience and I also wanna address, Shubhan, you're asking about the profile as a community member. I think there's gonna be a good resources online about how to change your profile around. I think we don't have the time maybe to handle that question here, but I do wanna get back to Lauren's earlier question about any great books or articles can help guide monitoring and observability of automated services so that alerts are meaningful and actionable for teams. Yes, so there is another book, yet another book called the service level objectives book, primarily written by Alex Hidalgo, the SLO book. It has a chapter in it about SLO monitoring, which happens to be written by somebody called Niall Murphy, who I've never met. And this Niall Murphy wrote about how to do pretty concrete steps with respect to SLO-based monitoring and observability. I've been told it's a really good introduction that might be a place to start. There are a lot of other monitoring things, like resources out there. Honeycomb has an observability book, which I think is very good actually. Yes, excellent. Stephen's holding it up now and written by many of my favorite people. And there's also some sections in the SRE books about monitoring as well. And something from James Turnbull, I think a couple of years ago called The Art of Monitoring, which I also think is freely available online. Yeah, loads of places. There's an annual conference called OliFest. You can just go to olifest.org, Oli with the ones. And I think you can still watch them all for free. There's tons of really good content there if you wanna watch those. Monotorama. Monotorama, yeah. The other thing I'd say is that pretty much everyone who's luminary in the SRE community is sitting on Twitter and you could just reach out to them with your questions and they're pretty nice. So I follow a lot of people there and they're pretty generous with their time. So yeah, can do better than reading some dusty book. Great, no, anything's out there and I'll still... I was gonna say that also chat GPD might help you to write your code. And they might be more available than the time of some of the people on Twitter. But yes, folks are generally available. Yeah, perfect. But I think that's all that we have time for today. But great to see so many amazing questions and answers from everyone here. And thank you always, everyone, for joining the latest episode of Cloud Native Live. It was great to have a session of our reliability here today. And also love the interaction and the questions from the audience. And you can always tune in in the coming weeks. We have more great sessions coming up and thanks for joining us today and see you all in the coming weeks.


While some celebrated the birth of the United States with festivities and fireworks, others used a day to renew their service. One hundred service members gathered on Bagram Airfield to take the oath of re-enlistment. Celebrating 4th of July here in the combat zone, I think it's important, it goes to show we as Americans, regardless of what's going on around us, regardless of the situation, we find the time to pay respect to our country and to celebrate. The ceremony began with the arrival of the official party and the playing of the national anthem of the United States. Chaplain Suke Kim gave the invocation, followed by a brief history by Staff Sergeant Kelly Simon of the events that occurred on July 4th, 1776. Lieutenant General Joseph Anderson, Commander of International Security Assistance Forces Joint Command, administered the oath of re-enlistment to the sailors, airmen, soldiers and marines at the same time. Once Chaplain Kim gave the benediction, the 10th Mountain Division Infantry Band played the Armed Forces medley. General Anderson greeted each re-enlistee and presented them with their certificate. The men and women from all services re-enlisting together is a sign of unity and commitment to the team here in Afghanistan. The ceremony held on the most important day of history of the United States gave each and every re-enlistee something more to be proud of. Really it goes to show the dedication to the mission and the commitment to the mission not only in our armed forces army, but also the commitment to the mission here in Afghanistan. Right, right. Reporting from Bogerm Airfield, Afghanistan, I'm Sergeant Rodney Roldan.


Hi guys, this is Jason Zach from Nathaniel School of Music. In this lesson, we are going to talk about a topic which I am very passionate about. It may not be directly related to the piano or the music theory and the ear training stuff which our channel you could say is known for, but it's something which has helped our channel without which our channel would have probably gone nowhere. And why you need to know music technology, music production as a creator, how it can inspire you and how it can also take your creations to the next level.  Hopefully this lesson can get you inspired into the field and also give you reasons why you would want to get into this field of technology. Is it for you or can you just kind of get by by just being happy as a piano player or a guitar player. So in this lesson, we are primarily going to focus on why we need a home studio setup and why we need to get into the field of music technology, music recording in general and the hope also if you like this video let us know in the comments. This will be the start of many more. We would be getting into DAW recording software which are chosen to be very affordable. We can get into mixing, mastering and arrangement techniques which is actually how our school started. We started as a recording studio in a jam room and then we started doing classes in Bangalore and now it's become this YouTube channel and everything in the past has not stopped. It continues to go pretty strong we think. So the first and foremost reason why you should get into home studio recording or improve your music audio quality or capture your recordings in any form is because of something which I found personally as a musician just out of college. I was jamming with many friends especially a guitar player and a few drummer friends as well who are damn good musicians you should definitely check them out. We've been jamming for years and years throughout our college but at that time it was around maybe 2003 to 2008 I guess where I did my engineering and around that time I'm sure you'll agree the iPhone didn't have a great recording feature. I don't even think it had one to be honest. Phones pretty much had that snake game. I'm not that old by the way but I was in an era where you have this Nokia phone and you just play that snake game throughout your college.  So the first thing which got me to get into recording tools or any form of recording gear is to record any one of my thoughts or any of my ideas which you would call them as sketches something which you created during an informal jam or in some cases I would think of some ideas in my college days in the classroom and it's just lost because a lot of these ideas are sort of like air. It just comes and it goes so to speak. So one of the foremost reasons why you should learn some kind of recording is whenever you sit on the piano is to capture those thoughts no matter what. So it could be just a jam. You're jamming with a friend or you're jamming alone. It could just be for about half an hour or even five minutes or the moment you have an idea you want to capture it. But then the challenge is you're going to capture those ideas with what. What do we have these days to capture our thoughts? We have a mobile phone. We have mobile phones which capture video as well as audio through voice memo the voice memo inbuilt application. I'm sure you'll agree that the quality of that is not going to be so great because a phone first of all most likely will pick up in mono and it's going to pick up audio with everything in the room so it's also going to pick up your fan, your air conditioner if you have one on it's going to pick up the kitchen noise if you have a pet well the dog barking could also would also get into your recording so well clearly recording on phones has a lot of limitations but it's great if you're outdoors or if you're singing something to yourself for later transcription or later recording you can always sing it into a phone. So definitely you would want something to improve your existing audio quality and have the ability to just capture the moment. So if you have a loved one, a family member or if you're at a concert, if you're at a local cafe and you like the artist you watched or if you're in your church you may think to yourself, hey maybe I can do a good service for those musicians if I capture their gig or their concert but I don't have that equipment. What is the bare minimum thing I need? Well you need some kind of a recorder and you need to learn how to record. So you can use audio technology or music technology to capture the moment so to speak. So if that happens why can't we capture the audio moment? Why does it always have to be visual?  So I remember so many cases where I've sung ideas into my phone I've somehow found a mic to record it into a computer and if I did not do that I would never get that song or sometimes an idea could come to you from nowhere you could be walking your dog, you could be having a shower you could be brushing your teeth and the second you come up with that thought you need to respect it and you should not leave that idea. So have the ability and develop an ecosystem to capture the moment whenever it hits you. You do not have to be a professional music producer you just have to be a musician who values his or her work. So that's another reason why you would want to get into a home studio environment. So now coming to what we normally do in home studio settings you have a few of your favorite songs. Let's say you've learned a few Beatles songs or a few Bollywood songs. Now you want to put a stamp you want to put your stamp on it and you want to create some kind of a rendition and you know how it is with YouTube and Instagram these days. Almost all musicians are on those platforms but the ones which tend to thrive or the ones which survive well I feel are the ones which look good and sound good. So the people who maybe get their video shot well but then if your video shot well but the audio was captured from let's say the video DSLR camera or the mobile phone was put somewhere there then you don't serve the purpose because yes you have good video but really inferior audio. Invest some time into learning how to record and capture audio in the finest quality and it's not too difficult. All you need to do is get yourself a sound interface or an audio interface as we call it get yourself a couple of cables download a software a lot of software these days is free so you don't have to spend too much on that. You can use this software called Reaper which is open source so initially for learners you don't have to pay for it if you are not doing any commercial work at least you get the full blown version of Reaper. You need to get some tech keep it ready and get used to it. So let's look at a scenario where you are a piano player and you have learnt something. Now if I have learnt some song or some cover I have arranged it, I have prepared it my way now I need to record it in the highest quality or a decent quality so off the top you get yourself an audio interface take the output of the piano keyboard connect that into the audio interface or the sound capture device you need two cables and then that is connected to the computer and then you record that and then no amount of ambient noise dog barking or the kitchen or the AC recording because it has gone through the cable into the computer you can also record piano data through MIDI as we do for our YouTube lessons we use MIDI a lot because it ensures that we have ultimate control over our ecosystem so if you are recording your own songs let's say as a vocalist you may also want to invest in a good microphone if you are a drummer you may want a basic setup to help you record your drums well it could even be one mic by the way you know so any instrumentalist would need to figure out their tech in order to develop some content on YouTube and you don't want it to be a kind of a work in progress first year it sounds okay it's simple equipment and in some cases it won't even cost you much you might just need to pick up a mic or a couple of cables and just learn a few software and what if you want to take this the next step if you want to produce your own composition an EP, an album the good thing about today's industry is you have the ability to just sit in your home studio which could be your bedroom you can actually call your bedroom as a home studio as I've done for almost a decade now I just have another room in my house which is set up as a studio room so in a sense I'm still in a home studio so there is nothing inferior about a home studio these days a home studio can record drums in its highest quality it can record vocals it can do any kind of project even non music you can do films you can do radio production work you can do podcasts you can do all of this stuff in your home you just have to allocate one room for this particular work so if you have a goal of releasing an album or an EP hopefully sometime this year you need to get started right away and get some tech ready because you don't have to run around finding different studios to record and travelling and all of this stuff you can do the whole process from your own home it could be your garage or your bedroom or whatever you can record you can arrange you can use MIDI you can edit the song you can mix the song you can master the song you can even distribute the song you can upload it to the internet on Spotify or Amazon music or Apple music through your own work like you can invest in some kind of a subscription and get it out there you also may be an individual who likes doing film work you may like to do music for film maybe a short film a documentary maybe you would like to do background scores or a song for a movie a jingle or any kind of commercial music for that matter so you can use your production skills or your production knowledge to do any of this work and be a lot more hireable and be a lot less dependable on many people so I find a lot of people after an audio course or maybe people who are young they want to kind of work under someone and they think that there are many studios who we can write to and send emails to but the truth is you can do it on your own you can just say I'll do it in my own home studio and if I need some help maybe I need the help of a singer as I always do because I'm not a singer or maybe you need the help of a flottist a violinist or a guitarist can always hire these individuals yourself and it's your project and let's look at a very important factor cost all you need is one room you don't have to travel anywhere and remember cost we measure in terms of actual cost in terms of actual money put into the job we also measure it in terms of the amount of time you're taking to do this particular job we have a lot of stages in music production we have recording editing mixing mastering arrangement drum programming string arrangement this that we could potentially deal with about twenty people now all of those would be probably in different studios you'll have to do different zoom calls with different people then they'll give you files which you may not actually like or you may have a lot of changes so you can save your time a lot and also a lot of money because you'll be spending something for the recording person you'll be spending something for editing person the mix engineer the mastering engineer so if you can learn all this on your own you become a one woman or a one man show doing all this stuff and if ever you need other people you can plan it in your own financial planning sheet spreadsheet probably and say ok I have this much budget for my project why don't I now see ok I can probably hire someone who I know maybe it could be a friend who could do who could kind of do a collaboration you know which could be a win-win for both of you and so on and so forth so cost saving is a very important reason for you to get into this field just be good enough to record ok and it's always nice to be in control over the entire project and I find that if I don't know production or when I did not know in the earlier days it was very difficult to move forward the thoughts in my head were never coming out as a final release it was always controlled by so many other individuals sometimes in a bad way sometimes in a good way but then if it's a bad communication or if the collaboration didn't work you have no way to tell them how to get it right because you don't know production so to be in control is a very important reason you need to get into music production and I have a few more final points for you musicians out there who already do music who already perform on stage why you would want to get into music production and record rather than just being a band who jams and performs on stage first off in most of our concert environments these days we have in-ear monitoring systems and in these in-ear monitors you can send at the very bare minimum a metronome so your band can practice on metronome and that can train you for the final recording it can also train you for the concert what you could also do for the concert apart from the metronome is have what's called as a backing track so you can have some elements of the studio recording be taken on a wave file or an mp3 file which is also possible and played into your in-ear monitors as well as the audience so maybe you're a 4-piece band and you feel that you need tabla in the song you don't have a tabla player so you could probably record that and send it out to your audience at the concert and we call this as backing tracks you can also send out the metronome so if you're a solo performer you can think of this as a a minus one performer so if you're a vocalist you could make your own sort of instrumental tracks which we call as maybe carry ok tracks and you know how carry ok tracks are you never get them in the same scale it costs money and the quality is always like really really inferior so it's nice for you to have that control if you're a solo performer to make your own tracks so to speak now even if you're a professional musician wanting to produce a song but you don't want to get into the whole process recording editing mixing mastering at least we should get your idea what we call as a scratch track the bare minimum scratch track to be then given to a producer or a sound engineer or a studio or other musician so learning production is very important to get that initial canvas going that initial structure so what will be the initial structure the tempo of the song the time signature of the song feel how are the beats getting divided so a recording software can help you with all this and then what do you record as a scratch to me if it's a song with vocals it would have the vocals throughout the song it would have one polyphonic instrument at least which would probably be the instrument you play piano or guitar or banjo whatever it may be so record that keep it as a scratch track balance it a bit and then give it out to different people so even if you are not involved in the process 100% at least learn scratch recordings as we call it and at the end of the day whether we like it or not technology is always going to be the future it's going to be the only way to propel ourselves forward almost everything music can be aided and be made a lot more efficient through technology so learning gadgets learning apps learning which is the best microphone it's always going to get better just like cell phones will keep having versions of the iPhone everyone wants the latest gadgets so it's the same thing with music production as you have this awareness of technology and the way things are moving forward it will enhance the quality of your music for sure and more importantly it will also improve the efficiency you will start doing things a lot more faster so if in month number one you can make maybe one song if you use the right technology and if you learn everything well you can start doing a lot more songs you can do five or six or maybe more and to leave you with a final word why would you want to get into production or technology you have to also think of it kind of artistically in a sense if you are a mix engineer or a music producer or an arranger or any person who is controlling many instruments or many tracks as we call it you will just think that all of those are the raw ingredients for your eventual dish that you are cooking so in a way you are the cook of the song you are the guy who is responsible for the songs success so to speak yeah right Jason so I am not saying you are but you get that feeling you get that sense of responsibility you feel very passionate about the work because everyone is dependent on you so if a band or a choir or anyone gives you a project they are relying on you because you are the last stage you are the last line of work so ultimately it is your work which is going to carry that song forward so learn technology well learn music production well or music technology and in future videos I am going to give you a good summary of what gear you might need affordable gear gear could be divided as hardware and software and also how you can manage your computer well you may need some computer equipment some devices some accessories and all the tools to just get things done by just sitting in one spot and you know I want to record vocals ok let's get this done I want to do some piano let's get this done I want some virtual some synthesizer school so in future videos on our channel we are going to definitely delve into all of these things so do let us know specifically in the comments what you'd like me to cover do you want to learn a specific concept of music production like EQing or editing or compression or reverb or whatever it may be do leave us your thoughts in the comments we are trying to take this forward as a lot of you have requested for it when we did this post actually around New Year's time we actually asked what more would you like to see from our channel and almost all of you were talking about music production and how to record and you know music technology so you asked and hopefully we've answered so do leave leave a note in the comments with what you thought about this and what you'd like to learn in the future and take it from me learning recording if not anything is a lot of fun being involved with music production is a lot of fun and our youtube videos or anything we do even the riffs which we do the amount of music production and maybe even the video production work is quite a bit actually it's not just a camera shooting me and we just kind of put it out there's a lot of work which goes on behind the scenes and if you are a person who'd like to get involved with that space then let's get it done on this channel together cheers thanks for watching catch you in the next one


At wide receiver this week, I love Tyler Boyd to also bounce back. I talked about Dalton earlier facing Number Fires' lowest ranked secondary, and obviously Tyler Boyd gets that matchup as well. He's averaging 8 targets per game this year, and he's got a 21.4% target share. Those are both good numbers. But he'll also see a nice matchup in the slot. Boyd's played 70.5% of his snaps from the slot this season, which is the highest on the bangles according to pro football focus. And when he's there, he'll see MJ Stewart, who's allowing the most yards per snap in the slot this season among relevant corners, and he's one of two slot corner backs who have allowed four touchdowns this year. And remember, the Bucks have had their buy, they've only played six games. So Boyd to me is an awesome, awesome play this week, and he should be in your lineup despite his mediocre week 7 outing.


3D canopy models using Ladar data can accurately predict below canopy light variability by considering forest type, voxel size, and zenith angle ranges. However, estimates of transmitted light often overestimate measured light, with maximum variance in below canopy light occurring at lower values of measured light. The study suggests improvements in modeling parameters and ray tracing parameterization for more accurate simulations. This article was authored by Renato Sufrentes, Dmitri Van Der Zander, Christian Solas, and others.


Alright guys, as you saw from the title of this video, these are not any ordinary sunglasses. These are the Sangstray 2 Hayden 5035 smart glasses. That's quite a long name, but I'm pretty excited to showcase to you guys what this actually does. Essentially, these are Bluetooth glasses that you can use to play back music and also take phone calls with. Let's go ahead and unbox this, and I'm going to showcase to you guys how this works, how it looks, and more importantly, how it sounds. So let's dive straight in. So starting off, these glasses come in at $199. They're not the cheapest sunglasses out there, and they're not the cheapest smart glasses out there, but they are of very high quality, and we'll go and decide to see how much this is value for money. So it comes in this very nice designed cream case, which actually doubles up as a charging case to power the sunglasses. You'll see there at the bottom there's a USB-C port to charge the actual glasses, and there's a LED indicator light there. I'll talk a little bit about the battery life and I'll go through the glasses in a second. Let's see what else is in the box just underneath here. So a few accessories. We've got ourselves some additional nose bits to put in between the frames. We've got a microfiber cleaning cloth for the frames themselves. We have a key ring here, which actually if you screw this off, this is a tiny little screwdriver if you wanted to remove the front frames, because the frames themselves are detachable and replaceable with other frames that you can find on the Sanctuary website. You've got a USB to USB-C charging cable, and you've got a safety information booklet with the user guide right here. So pretty excited to try these out. Let's go ahead and first take a look at the design of the glasses. So let's open this up. There you see the glasses themselves. And you'll see inside as well the magnetic lips to charge the glasses via the frame handles. So let's go ahead and take a look at the glasses.  So a couple of different color options, but you can also change the frames if you'd like to. On each of the handles, on the temples, on the right and the left, you have yourself the Sanctuary logo. You'll find the components of the glasses and the battery inside this metal block here that runs through the temple on each side. If you use the screwdriver that's included in the box, then you can use that to unplug the side handles and replace the frames themselves. The first time you take this out of the case, it will be in pairing mode. The first time I connected it, it shows up there SS2 Hayden. Very quick and easy to connect via Bluetooth. The first time you take it out of the case, it is going into pairing mode. You do get some audio confirmations once it is connected and also disconnected and when the pairing is complete. So that's quite a nice touch. The speakers themselves, you'll notice there's two that are on top of the handles here. So just there on the left and the right, then you'll also have some speakers underneath at the backside here on the curves themselves that kind of fit around your ears. Now, with some of the technical specifications around the audio, this does have AAC HD audio decoding, which provides 24 bit codec to give you some really good immersive experience with the audio. This is kind of like open air, open stereo, which does create kind of like a spatial audio type experience that I've experienced with other headphones in the past. The first time I tried this and played some music back, it felt like I was playing music back directly from my phone speakers. But in fact, they were coming directly from this and it took me a while to understand the music was coming directly from the glasses. So that's how immersive these actually sound because it did confuse me right at the beginning, but I see that as a positive sign. In terms of the lenses themselves, they are nylon HD polarized sunglasses, which can effectively block glare and improve the clarity and contrast so that you can see all of the details at a glance very easily. And a few other specifications just to mention, this does have Bluetooth 5.1 and it does give you a connection distance of up to 10 meters away from your phone. And it is IPX4 water resistant, which means it can protect from splashing water and maybe a little bit of light drizzle when you do use this possibly outdoors when it's raining. So let's just talk a little bit about the battery life. In conjunction with the charging case, this has a battery capacity of 1300 mAh. With that, you can charge the case via the USB-C port in two and a half hours and the glasses themselves can charge fully in about one hour, which is a very quick and convenient time. And on a full charge, you will have up to five hours of constant music playback. If you do use this for phone calls, then you can get up to four hours of phone call time. And then on standby mode, this can last up to 15 hours. So pretty good amount of usage time in these glasses because if you are going to use this maybe outdoors when it's very sunny, you're in the park, then getting five hours of playback I think is going to be more than enough for the amount of time you're going to be using this for. Outside of that, you can just generally use this as a really great set of sunglasses to maybe when you're using that in your daily life. And I will showcase some example use cases of when I have tried that. Now these are smart glasses. So they wouldn't actually be smart if you couldn't control your music directly from the glasses themselves. And there's a few ways you can do that. When you double tap the left temple, this will allow you to access your phone's voice assistant. So I've got an iPhone, so this should open up Siri. If you have an Android phone, it can open up Google Assistant. If you double tap the right temple, this can play and pause music or you can answer and hang up phone calls. If you go back to the left-hand side, if you swipe, this can actually switch between previous and next songs. So the direction back will go to the next song, direction forward will go to the previous song. And then likewise on the right-hand side, the swiping on this side will actually adjust the volume. So you can go volume up and volume down, which I think is convenient because these are all of the commands that you'll ever need when you are using this to listen to music. So I'm gonna place a song here and the phone is already connected to the glasses. So you'll hear the audio coming directly from the speakers on these glasses. And I'll try out some of these commands. Okay, let's try to access Siri by double tapping the left temple. There we go, you can see Siri popped up. It took actually a couple of attempts, but it did work. So now I'm going to pause the music by double tapping on the right-hand side. You hear a confirmation beep that the music is paused. Let's go ahead and continue playing. There we go. I do it roughly around the beginning of the Sanctuary logo just there, and it does work. Let's go ahead and do some of the swiping commands. So from the left side, I'm going to swipe. So swiping backwards towards the end will go to the previous song. If you're already halfway through a song, it will replay it. Go forward, it goes to the next song. Now it does take a couple of attempts, in my opinion. I feel like this could be a little bit more responsive, but overall, the fact that this does work and it can maybe use your songs if you don't have your phone with you. Maybe you're going out for a run. You've left your phone to the side. It's just a quick and easy way to control your music. And then let's go ahead and final test, change the volume. So that was pretty quick. And the volume is going down as I swipe back towards it is. Let's put the volume up. Not too bad. In fact, I do like the design of these. Although you might find that the handles on the sides are a little bit chunkier than your traditional sunglasses, but that's kind of expected if you are going to have smart glasses like this. Let's go ahead and put this on. These actually suit me very well. And these are the type of design that I look for in my purchases of sunglasses anyway. So the fact that I have smart glasses inbuilt into the same type of design that I prefer, I just think that's a quick bonus. So this is what it looks like from the side. And in fact, you can't even tell that they are smart glasses from the side. You're not going to be able to see the speakers that are just there on the top. One thing to mention about the speakers as well, you're probably wondering there's going to be quite a lot of noise leak. These technically are open air stereo sunglasses. So the noise will be coming out, not directly into your ears. But I would say this is tailored for people that may be using this in a very large open space in a park where you're not going to have a lot of people around you or even in your back garden privately. If you go for a run maybe in the sun and you just want to wear this and you have your phone strapped in your pocket or on your side, wherever it may be, this would be very suitable for that. This is also suitable for people that just don't generally like wearing in-air headphones. And maybe their ears start hurting after listening to music for an hour, for example. You eliminate that need with having something like this.  And I'll be testing the phone quality as well because it does have inbuilt microphones in there. The speakers that are on the top of the temples kind of offset the speakers and the audio that comes from underneath that are curved around your ears. The ones underneath give you louder audio coming directly towards your ears and less so from the top to minimize that type of noise leak. So if I go ahead and continue playing a music, I will play it at 50% volume just so you guys can hear how much noise leak there would be. If you are in a quiet space and you wanted to use this outdoors maybe where there's not much ambient noise in the background and there could be people around you. Okay, so this is 50%. And my microphone is just here to the side. So it is very close and it's a very sensitive shotgun microphone. So it will definitely pick up the audio coming from these glasses. But just to showcase to you guys, I am gonna put it to 100%, but I don't recommend anyone using this at 100% because you will guarantee other people are going to hear what you're hearing. That is very loud. So just gonna pause that for a second. And if I can describe to you the quality of the audio, I would say the first time I was listening to this, I didn't know where the audio was coming from because I had my phone in my hand and I thought it was coming from the speakers on my phone and not from the glasses. It's only when I took them off and saw that they're coming from these speakers. That's what made it surprising to me that that gives you that type of immersive audio because it feels like it's coming from all different types of directions. And you guys may have noticed that it automatically pauses once I do take it off my head which does make it essentially a little bit more smart. So let's do one more test again. I'll just put the volume up. You guys can hear automatically pauses but it doesn't automatically play when you put it back. So you'd have to manually start playing again. That's one thing to be aware of which I think is absolutely fine but if maybe they have a second iteration of these types of glasses then that's something that they could implement. All right guys, and the final test that I wanna do is to call someone and get their opinion to see how the audio quality is from the microphone coming directly from the sunglasses. So I'll go ahead and make a call. Switch to SS2 Hayden. Hello. Hi. Can you hear me? I just wanted to test out these new sunglasses that I've got, these smart glasses and I'm using the microphone that's inbuilt into them. Just wanted to check to see how clearly you can still hear me. So it's actually coming directly from the glasses and does it seem like it's maybe slightly worse or slightly better than when I normally would call you from my phone? Okay, and I'm just gonna do one test while you're on the phone. I'm just gonna take the glasses off and see if you can still hear me. Can you say something? Okay, so if I take the glasses off it doesn't put the phone call on hold or anything like that. It just continues keeping the phone live. Okay, cool. That's the test that I really wanted to do. So I just wanted to make sure that the audio is still pretty clear. So thanks for your time. No worries. And I'll speak to you later. All right, bye. Bye. I'll say the sound quality is pretty decent. I've enjoyed using this. I've listened to music while just getting my steps in by going for a walk outdoors in the sun. And the phone call quality I think was pretty good. And I called my friend and she mentioned that it sounds exactly the same as if I was calling directly from my phone. Didn't really notice much difference. So I think that's pretty good. And I just wanted to maybe highlight that you don't necessarily need to use these as smart glasses. If you wanted a really good pair of good-looking glasses for those sunny summer days then these are also very good for that. So I've used this in my daily life as well. So let's take a look at some examples there. So I've got my Sang Stray Bag here and I'm gonna be wearing a sunglasses on this nice warm sunny day. Generally you don't need to just use these to use the sound speakers on them. You can just use them for your daily usage. So if you're heading to the park they make for very comfortable, nice looking sunglasses generally in your daily life as well. And to be honest, I think these really suit me quite well. And I'm so impressed with the quality of these. And I can see why there's a lot of positive reviews on this online. And for me, if I'm just going out and about, for me this is another set of sunglasses that I'm just gonna keep with me at all times, especially for sunny days, especially when I go traveling and I wanna take really nice photographs, this would look really nice with that as well. So for me it's a big thumbs up and anyone that's on the market for something like this then I think if you are a techie then you hit two birds with one stone you get a nice set of speakers when you are maybe going for a run in the sun or if you just wanna get some really good pair of sunglasses this does both jobs. So for me, it's a great job. So with these ones, I can use this pretty much all day when it's sunny up until when it gets to sunset because I see everything so clearly with these on and they're not as dark as my existing aviators which just makes it a little bit more comfortable for me to now use these as my daily driving sunglasses when the sun is out. So I'm quite impressed of how much I can actually use these apart from just using the speakers in them in my daily life. So I'm quite impressed on that front. So overall I'm pretty happy with these. Hopefully that review was very useful for you. The same straight to Hayden, do check them out. Link is in the description. They don't just do these ones, they also do various different options. You can even get clear frames as well. These are detachable removable side handles which you can replace with any other type of colored frames if that's something you prefer. So take a look at the link in the description. Let me know if you guys have any other comments. And before I even got to know about these sunglasses, I wouldn't have known how much I would actually enjoy using these. So I can see myself using this more and more often. Especially in those summer days they make really good for driving. If I'm just going out and I just want to listen to some music, I go for walks quite often as well and just having the sunglasses on and don't have to worry about getting my headphones and charging them up. This is kind of like two in one and it just does a really good job on all fronts. So that's about everything I wanted to showcase to you guys. So if you found that review useful, make sure to give this video a huge like. Make sure to subscribe. I cover new reviews out every week with really cool tech gadgets much like this. And I will catch you guys at the next one. Take care.


Coco Gough versus Yu-Yuan is the third quarterfinal for Indian Wales for the ladies for 2024. Both of our different rows to get to this stage. Yu-Yuan entered the tournament unseated and would take on Gurevra in the first round. There's no problem getting through in straights. 6-4-6-1. The second round she'd take on the number 8 seed, Zheng. This was no problem again getting through in straights. 6-4-6-3. Third round she'd take on Dolahide, who had just beaten Azarenka in the previous round. And after losing the first set, would fight back to win. 1-6-6-4-7-6. And the fourth round she'd take on Kazakina, the 11th seed. And again, after dropping the first set, would fight back to win. 4-6-6-4-6-3 to advance to the quarterfinal. Gough entered the tournament. There's the number 3 seed. And we get a buy in the first round. And the second round she'd take on Burrell. And after dropping the first set, would fight back to win. 2-6-6-3-7-6. And the third round she'd take on Bronzetti. And after a close second set, Gough would get through in straights. 6-2-7-6. And the fourth round she'd take on Mertens, who had just beaten Amy Osaka in the previous round. There's no problem for Gough getting through in straights. 6-love-6-2 to advance to the quarterfinal. These two have actually never faced off before. So it's going to be an interesting meeting, especially with Gough being the overwhelming favorite. Not just with the crowd, but also in the betting. But Yuan is coming off a very good win streak. And has had a couple of really good wins this week against Kazakina and Jung. If Yuan's going to win this one, she needs to just keep her composure. And try not to let the crowd get into this one. Now, she did play Dollarheid, just got through that one, who is an American. So she has been in a situation before, but the crowd might be a little bit hostile. But she has to kind of keep that composure and be aggressive against Gough. Gough's going to win this one. She needs to use her serve and use the forehand as well. She wasn't great against Mertens. Even though she won 6-love-6-2, there was a little bit of a second set slump. She needs to keep her composure for the entire match. Try and get it through this one as quickly as she can. What a fun matchup. Very interesting matchup. Yuan is on a massive win streak. And of course, Coco Gough, one of the favorites to win after Sabalenka losing yesterday. So I'm going to go with Gough in this one. I think it's going to be a close three setter though, because I think Yuan is playing so well right now. She's forgotten how to lose over the last couple of weeks, but I've got to go with the hometown favorite Gough. Let me know down in the comments below who's going to make the semis.


And now for your U.S. Army Europe spotlight. Soldiers from U.S. Army Europe and our European allies come together in Grafenbier, Germany to test on their medical expertise and earn the expert field medical badge. 312 soldiers from every single type of medical activity in Europe started this test two weeks ago. 75 finished. And within that group of 75 there were two Germans, two Slovenians, one Italian and two Corman from the United States Navy. It's awesome. It was an unbelievable experience. I realize I can push a lot more limits. My limits are definitely a lot higher now. For more information on the challenges these medics faced at the EFMB competition visit eur.army.mil.


I got a live lizard y'all and went back.  I don't ever sweep up this. See that's a dead one.  Oh look look look there you go.  Hello everybody here. Welcome back to another book review today. We are talking about another Chad Lutzky book Wallflower Why this one hit all? The check all the boxes for me Unfortunately, I did have a few moments when I was reading it that were a little too much for me And I had to put the book down and walk away from it. I'll tell you why in a second Otherwise it would have been a one sitting read the way Chad writes it. It's very quick very punchy Some he's up there with some of the best noir writers Is better than most honestly this isn't a thriller But he's better than most thriller authors working today. The the word choice is damn near perfect And he's just a new favorite author of mine this Personally speaking is my favorite one of his books because I connected emotionally With the main character and his struggle now for a bit of story time Back in 1997. I was I'd already dropped out of high school I was doing a lot of odd jobs and whatnot and I came across a Person that had heroin I don't want to get into too much detail as far as the what I what I went through to you know How we you know booted up for the first time tied off whatever I don't want to go into too much detail with that stuff But from 1997 I worked odd jobs like carpeting Installing carpet actually I wasn't the one installing carpet. I was pretty much just a runner I went and got this got that got this and we would do jobs and then afterwards we would get high and that went on for The longest time until finally that dude died. He passed. It wasn't even a drug overdose It was a heart attack that dude died and have a job anymore, but I did have a nice little heroin addiction So fast forward Many many years. I did some of my best writing during that time Which I hate to say but it's true and some people even say that Stephen King as soon as he stopped doing drugs The fiction got bad. I Think that's funny, but I also think it's you know, I think I think there's something to be said about the completely different writing styles between King as a an addict King as a clean and sober individual. I think there's something to be said there I will tell you one thing is a couple things that make it so much easier to put words down on paper That's caffeine pretty much every writer knows that there's cigarettes nicotine really boost the Imagination for some odd reason and heroin is pretty good too as long as you can stay awake I would write whole sections that I wouldn't remember those early days Unfortunately, it's gonna sound weird that I say unfortunately, but those are some of my fondest memories of being high now The other fond memories that I have are stronger in association to to heroin and that's what keeps me away from the junk Now am I still on you know a narcotic? Yeah, I'm on narcotic pain medicine, but I'm not taking enough to nod off I'm not getting high none of that stuff. So do I still have an addiction? Yes I still have an addiction. Do I still use technically? Yes, I still use But I'm a functional addict Where this goes is not into the area of functionality there's a that there's a very very bleak and upsetting tone to this book that I understand because it was the same The same road I was going down I don't want to ask but but I mean I got to and I publicly if you want if you don't want to talk publicly chat, I I understand but Did you I just got to know did you were you that that that's the question because some of the details in here are Far too accurate. And of course you can ask people these details and you know, you can get you can get that kind of Information, but I think this has a personal ring to it. I remember Quentin Tarantino Actually was John Travolta talking about Quentin Tarantino telling him What being on heroin was like for his role in Pulp Fiction and he said it was like Downing a fifth of tequila and then going and floating on a pool and that's pretty pretty close I still don't think it comes anywhere near the actual effect of heroin, but that's pretty close The closest I get to that kind of thing nowadays.  Are they bad or whatever? Do we overcome them? Do we fight do we push do we conquer or do we let those feelings? Overload us. Do we let those feelings win overpower us and bully us around? Should we have trigger warnings on our fiction? I would love to talk about that stuff down there in the comments below But until next time I have any you have in you spend another book review. I'll talk to you guys there. Bye. Bye. I Cannot express Difficult that was to shoot. I don't know if it came out that way. This is I'm shooting this after the outro section Right right after shooting it. I don't know if it came out it came across as difficult as it was to say But yeah, it was it was hard to talk about. I've told people about my my past and my history before I haven't gone into a whole lot of detail, you know, but from 1997 to 2001 I was strung out and I was strung out until I met my wife I didn't talk about this section enough in the video in fact anything you go into this but the the positive Memories that I have that that overwhelm the the positive memories of heroin and that it's terrible to say I know it is but I really enjoyed that drug My wife and my kids are the whole reason why I am no longer that way My wife especially we met in 2001 and it wasn't a matter. She didn't give me an ultimatum It was a matter of she's not going to put up with that kind of thing because her well She had some issues in her own family She I knew if she found out she wasn't going to put up with that type of shit We met on the internet so we we were talking for a long time Before we actually met each other, you know, we lived like 30 minutes away from each other It there was a long process going up to us meeting and I talked to her a lot And talking to her about her dealing with the the attic in her family And I'm sitting over here going what the hell am I gonna do about these track marks?  What am I gonna do, you know And I really loved and cared about this person even before I met her And I knew I just some just some discussions and some of the things that we talked about it really it it felt Like an adequate Replacement it felt like a better high than the drugs if that makes sense But uh, yeah, I think I've gone on too far and too long Chad if you're still watching this man, sorry I hijacked your review with a with a with a personal story But I didn't want to just keep on repeating the same thing about how awesome you are Definitely my favorite book of yours. I'll talk to you guys later. Bye. Bye