Co-Coach Labs. In his time, he's worked as an architect and a developer at companies like Groupon, HashiCorp, Samsung, FreeBSD, and more, including DoorDash. He'll be demonstrating some of his wealth of experience in this area on zero downtime. So expect things like best practices, things to avoid, and much more. Sean, the floor is yours. Excellent. Appreciate the intro. I'm not going to dwell on that too too much. Let's get right to it. So zero downtime. Having spent the fair amount of time in the commercial consumer side of things, downtime is not particularly well tolerated. Whenever you're not able to take an order, you're not making money. It was true 10 years ago. It was true 20 years ago. It's true today, obviously. And one of the big challenges, some of these, the nature of this hasn't changed, right? The things that people are interested in terms of availability. One of the things that has also evolved over the years is the fact that there's less tolerance for getting to zero downtime. It used to be that you could go and build all kinds of artisanal and bespoke availability strategies for your organization, but that would come at a huge distraction, organizational distraction, where organizations are spending their cycles on working on zero downtime infrastructure. How do you go and plumb something? When you're worried about how do you plumb downtime or when you're worried about plumbing inside your infrastructure for data plumbing or whatever else it is, you're not focusing on your core business, which is how you go and acquire and retain customers. So there's a big shift that's been happening in terms of how do you go and iterate? How do you develop your product faster so that you're able to be successful? And especially now that there's a little bit, I'll call it a cash crunch in the startup world and certainly inside of enterprises where people are interested in, how do they optimize the efficiency and productivity of their workforce? Because if you're focused on delighting customers, you're not focused on the humdrum of making sure that your database doesn't go down or making sure that you're able to scale and not worry about how do you partition and shard your information. And then the last one is that's also becoming a thing is who wants to go and learn yet another bespoke database? I mean, there's obviously people in the world that really like padding their resume with lots of different fringe technologies, but at the end of the day, there may be diamond the rock there in terms of something that you're interested in, but do you really want to go and spend three or six months training up a new engineer in order to become productive in your environment? Or would you rather have something that you can drop into your organization that has a familiar look and feel and allows developers to hit the ground running quickly? So these are kind of like the backdrop of conversations that I've certainly had for a long time and a number of businesses bring to us as kind of common themes for us to bring to us as themes that they're interested in hearing more, seeing success stories about. So it's definitely interesting talking to them today. So it's no stranger or not no stranger, but it's obvious that outages are costly. They're actually somewhat common, unfortunately. And everybody just has a threshold, different thresholds for different businesses. Some businesses when you have downtime, it's very, very expensive, both in terms of money loss, but also reputational damage. But that threshold of pain changes and the willingness to go in and put in effort to go and prevent that also changes as well. So here we go. So in order to begin supporting some of this, in order to go and work around downtime or most ordinary downtime, in order to scale businesses, you kind of have this, this traditional stack or layering, like you're back in the in the middle days, you'd have like your three tier architecture, right?  Basically breaks down to this, you've got clients, you've got routing, you've got compute, you've got storage, right? And those are like kind of the four pillars at this point in time. And there's maybe a fifth one that you could argue in the back there about analytics or something to that effect. But, you know, if we spent 20 years, 30 years working on distributing applications, we haven't done that as an industry in terms of distributing our data and our databases. And so that's really kind of where what we do cockroach comes to play. And you want to think that it's been an interesting organizational, you know, thing response to this is organizations have developed microservices as strategies and organizational strategies, technology strategy that allows organizations to scale their workloads, to scale their databases, because in theory, you've got a database for your macro service or whatever you want, you know, name you want to call it, that allows your application to scale within kind of like some, some defined data set or boundaries there, you know, inside of and behind an internal service, you're going to have an API layer that allows you to have kind of like awareness in terms of the touchpoints and these microservices, they have a tendency to be bounded at teams, you know, what that's actually Conway's law in effect, where you actually are carving up your business along your internal team boundaries and your API inside of an organization will tend to resemble your organization. And you know what, that's great. But now that means that as you scale your business, you're going to run into the coordination across different teams. And so all of a sudden, like, you know, the old law on dollars law comes back and is is not just something that is relegated to computers and hardware, it's actually in distributed systems, it's a problem for a different type of distributed system called your organization and engineering efforts. So if you can simplify your tech stack, you can actually potentially, you know, reduce the number of microservices from a scaling perspective, and instead, you can focus on your business value. And, you know, famously, like you've got large examples of these kinds of microservices and just this huge proliferation of this, and really, like, you know, is this a the most productive way to go and build software? Can we potentially do some pruning here of this complexity? What ends up happening inside of an organization is companies will figure out a design pattern, typically, the team that is having the most acute scaling challenges, or is generating the most business value will develop a pattern and in a very, very common pattern, I would say probably 70%, 80%. So I mean, it's really common. Organizations will have some type of gateway, they'll have a microservice that microservice is going to talk to a caching layer that caching layer is going to are the is going to be fronting a database, their service is potentially going to do writes off to an event service like a Kafka. And then, you know, there's going to be some consumer that's going to read events out of this coffee and then going to pipe it off to whatever, like, and then every service is going to take this. And because it worked for, you know, the, what the marquee service or like your tier zero services, and they're going to copy and paste this, this thing, and it's going to become the way and everybody's going to export this, right? You've got this mass cargo culting of architecture that's going to happen across the entire organization. And if you look at this, that may have been appropriate for your big service, right? And it depends on your business and depends on the application. But you've got a fair amount of redundancy. And if you step back then and you look at what your microservices application owners are actually doing, this is some pseudo code, but you've got this, this, you know, kind of predictable pattern, you're going to have some kind of an object, you're going to save a thing.  And then you're going to go and emit an event. And so you've got these three separate touch points. Well, that's great. But, you know, what happens when there's errors along the way, right?  Nobody can escape those three calls. So how do we go and simplify this? Or how do we go and reduce the amount of friction, the burden, the cognitive overhead for getting anything done, right? So if we go and torch a few of these components, we're able to simplify things pretty significantly. You have a microservice, it talks to a database. The database emits events to some kind of bus, and then you have clients that are able to consume things out of a bus. This becomes a very realistic and tractable, you know, architecture, right? You can do whatever it is that you need. And then up to kind of some interesting speed limits, right? If you need caching, and I'm not saying that caching is bad or not necessary, right? Caching is really important. You know, especially like if you're serving cat photos and you have a high fan-in rate to a particular record, and that rate is, you know, in the tens or hundreds of thousands of operations per second, use caching. There's absolutely a place for that. However, a lot of businesses and a lot of organizations do not need a caching layer because the rate at which they're updating an individual record is below, you know, this is our internal speed limit of 2,500 operations per second per row. And if you're operating an application that is existing and running at less than 2,500 operations per second per row, you don't need caching and we'll get into why. But as a result, you don't have to worry about cache coherency issues. And you don't also have to worry about dual rights with this kind of a simplification.  Sure. While you're on the topic, would it be fair to say that in the previous example, the last slide, although we were writing to three different places, at a high level, is this the dual right problem, correct? Yeah. That's exactly it. You've got lines of code. You've got error conditions. And actually, I was just like, as you were saying this, I actually, I said this out of order without even realizing it, that I said cache database and then event or whatever it was. Like if you've got hundreds of call sites or thousands of call sites where you're saving information, the probability that somebody's going to like switch those two, and then you're going to have the cache that's going to be inside out of sync, because there's like some ordering.  Let's say there's a transient failure of, you know, let's say the cache invalidation happened, but then the database save failed for some reason. Like you've got some phantom record in your cache that's going to eventually expire or like, how do you catch that? Potentially, eventually. He might not. Unless you've got TTLs. I was in this exact problem. When I was first adopting Cockroach, one of my questions to Tim Vale, who was a sales engineer at Cockroach a while back was, we had a cargo cult of exactly this. We would write to a database and we'd write to a cache. That's just the way we did it. It was completely cargo culted. His advice was, don't cache. Don't start off by not caching and then only add a cache when you need to. That was hugely interesting for me because I was so ingrained in that cargo cult that I just assumed that that was the way you did it. You had to protect your database with a cache. When really you don't, it should be your database that protects you because it can scale. Now, another question from me that might be beneficial to others is you've mentioned the 2,500 requests per second rule before. How did you arrive at that as a sweet spot? We're going to get into the architecture. I'm going to explain where some of that comes. You're leading to where we're going in just a second. It has to do, in the case of Cockroach, with the way that Cockroach is implemented and its unit of scaling, this thing called a range. An individual RAIM, there's mutexes and locking, and updating a single row tends to light up a VCPU or a core. At that rate, you're not going to be able to get more updates per row because everything is going to be bottlenecked on a single VCPU core. That's where that number kind of comes from. It's actually higher than that, but I just use that as a rule of thumb for most people.  Maybe it'll come back to me later. What you're describing here looks more like the transactional outbox pattern. Yeah, that's basically it. The fact that you just have the simplification, oh, that's what it was. It's like caching. You have to. Why wouldn't you? Your database is going to fall over if you don't have caching. That's premature optimization, actually. You don't know that your database is going to fail without caching. I can tell you right now that it lays bare the fact that needing to cache or the instinct to needing to cache everything is a form of premature optimization. It's real obvious with Cockroach. There's both savings that you get from pulling out of this product. There's bugs, but it becomes real obvious that there's just very little value. You have to be doing more than 2,500 ops per second per row to all of a sudden need caching. It might not be premature optimization for a lot of databases, but it is certainly premature optimization for Cockroach. How is this possible? These seem like big statements, potentially reckless statements. How or why is this possible? This is probably the thing that I want everybody to internalize and absorb at the end of this talk because we have some neat values that we're able to push on the world because we're as a distributed database. The thing under the hood that we're going to get to is the how and the why here. It's super important because all of a sudden it unlocks how and what. As a distributed database, we've obviously got a bunch of layers. I'm going to talk about a couple of these layers at really high level terms so that everybody that's here can begin to internalize and think in terms of what it is that Cockroach does and why this is so powerful. In this example application, we've got a dog's table. We're going to use a primary key, though normally an integer or a UUID, like whatever it is, like composite primary key, totally fine. It just makes it easy for slideware purposes to explain this. You've got a dog's table and we're going to have a collection of dogs and then we're going key value have some weight or some other attribute that we're attaching to these dogs. Under the hood, what this actually means is we take this table, this Postgres table because Cockroach is a Postgres wire compatible database. It supports the Postgres dialect, very small exceptions, but it is like 99% compatible with Postgres dialect. So create table, acts like that, insert, update, delete. It's exact same as Postgres. So walks like a dog talks like a dog, not a duck under the hood or dog in this case. So you've got a dog's table and we take this dog's table and that's the, the, the logical representation, right? So you have like kind of the equivalent of like an extensor or if you're used to that. But what happens in Cockroach is we take this logical representation and we break it out into these things called ranges. And you know, right now today it's 512 megabytes and so we take this table and we kind of chunk it out, ordered based off of the primary key that's like the way that we cluster or store things. And we break that out. So you have this, this distribution of data that starts to happen or is beginning to happen. So you have Carl the Jack that goes to range one and you need a lady to PT, which goes to the next one. And, you know, we're starting to break apart and chunk this data out. And what happens then is we use raft under the hood to replicate this information and to distribute these different chunks of data across different servers. So each server then, now that we've, we've decomposed from a logical or, or virtual to a physical, you know, representation of the data, we take these ranges and then we scatter them across and then we replicate them in the information so that there's no one single point of failure, right? This is important for zero downtime, right? If you have a, if you have some kind of a failure, not going to be impacted. And the reason we do that is because we have replication built in under the hood, totally transparent to the application, replicate the information so that all rights end up on end one in this particular case for range 100. And all the followers have a copy of this. Once there's a quorum right to this information, then the right will return back to a customer or back to whoever your client is. And then similarly, if you've got thousands, tens of thousands, millions of these ranges kicking around, the database will scale, but you don't want to make your application aware of that. And the reason your application doesn't have to be aware of that is because we have a gate, every single node also acts as a gateway. So if your query comes in and hits node one, and the data is not on node one, the node is on node two, it'll proxy the request internally using an internal RPC protocol, perform the query and then return the result. It's not just limited to key value like full WCT, CTEs, like, you know, big analytics queries, it's kind of a thing that we can do. It's pretty neat. And now, because we've got all of our information replicated out and we're doing it, we can also take these copies of the information, and we're smart enough to be able to distribute it across different AZs. And so what this means then is you are now immune from an AZ going down and taking your application offline. All of your information is replicated, you know, replication factor three is the default. So that if you've got one of three AZs that are on unavailable for whatever reason, or you know, something tragic happens, or there's whatever, your application will stay online. It's handled and resolved. The self healing happens at machine timescale, like, you know, seconds, there's like, sure, you may page out to meet space to go and get a human operator to get involved. Not required. It happens and heals, self heals automatically.  But under the hood, you know, they're able to go in and treat it like a Postgres, even though it's not really Postgres. And then like the other thing that's kind of neat is, you know, you've got these extra copies, you've got some built in unit of scaling, I've just duplicated my information, which is great, because now I can go and read from it, and I can scale out really quickly to, you know, thousands of reads per second or up for this individual row, right, or, you know, collection of rows. And you can do that with some some extra syntactic sugar that we have so that you don't get what we call follower reads by default, but you can make use of this whenever you want. And it's really useful for analytics queries. So, and then last thing I'll say about, do you go into detail, I don't think we go into detail about follower reads, would it be, would it make sense to talk about the topologies available at this point, just to give people an idea as to how, because I think a question that a lot of people might have is, I have my Postgres node, I'm talking to this or my Oracle rack, whatever it happens to be. And my apps are quite close to it, proximity wise, and I'm getting good read write times. But the concept of a distributed SQL database, it was quite a paradigm shift for me when I first adopted distributed SQL. And I think there's definitely a great with great power comes great responsibility aspect to it. And I think it'd be interesting to show, because one of our biggest competitors is the speed of light, there's no getting around that if I want to make a query to a database in Singapore, and I'm based in London, there's going to be a latency penalty there. And I think we have we employ different topology patterns under the hood that you can harness. So for example, you can surface a table as a global table, which means the data is available globally with very low read latency at the cost of course, of that there must be a trade off somewhere, the cost of higher write latencies. And you can also partition data, there's lots of different ways you can manipulate your data with just a single line of SQL that you attack on to a creates create table statement to it to unlock this and follower reads is one of them. Sorry, no, no, totally spot on it wasn't something I was Yeah, no, absolutely. Like really, yeah, really happy you're touching on that because if writes happen on one node and you've got followers elsewhere, like you can also do other things with multi region in order to like, you know, propagate these rights synchronously or asynchronously to different regions, based off of what it is that your application actually needs.  Are you doing something that's region local like, you know, orders or deliveries or something that has some natural geographic partitioning that says like I'm West Coast data because all of my users are actually West Coast or East Coast data or whatever it is. Yeah. And just to dive a little bit deeper on follower reads, if you've got data in one in spread across multiple locations and you by default, we would orchestrate the reads and writes through what are called leaseholders of the ranges they own the data that for individual ranges. And if you do a strong consistent read that's not a global table, of course, that would that would necessitate a an internal hop if the if the request that it lands on isn't the machine where the leaseholder resides by toggling on a follower read you're allowing cockroach TV to perform a slightly stale read so you're opting into slightly stale data at the cost of much higher read throughput because you're not having to make that additional hop by default reads happen on the leaseholder. And when you turn on follower reads, it allows the query to be handled by any of the followers that are participating in the RAF forum for a given range. So yeah. So then the last one that typically is not typically but gets asked is like, well, you know, how do how does the database evolve to have to reallocate us? And it's all done automatically. Right. So in this particular case, we've got an insert that's going to come in for a dog named Rudy. And what's going to happen is is we realize and we know that that information is going to end up in range, the pink range in this particular case. But that's going to cause a what we call a split a range split. So the data is going to come in. And we're going to, you know, exceed the amount of in the nut in this case, but like, let's say that we've got 512 megabytes or near 512 megabytes for these ranges here. If that's going to cause it to exceed, it's going to cause a split. And what happens in is all of a sudden that 512 megabyte range turns into two and that second range gets kicked off to some other server. And that allows for all of the application to continue to subdivide and, you know, subdivide as you add more nodes, again, subdivide and distribute. But there's there's two kind of criteria that the cockroach will there's two criteria that cockroach will use for splits. One of them is data size. So if a range is going to exceed 512 megabytes, or the number of queries per second, so there's just a lot of load on a particular range, it'll also cause it to split. And it'll continue to split down to a single row. Right. That's also part of where that 2,500 ops per second came from is if you wanted to, you know, bang on a single row and perform just a bunch of updates, you can do that up to a point. But at some point in time, that cockroach is going to split that down to a single row, and then it's going to end up on a single VCPU, the channeling just that one row. And, you know, you're going to kind of run it bump into this kind of speed limit. And that's where the 2,500 ops per second comes from. But, you know, that is 2,500 ops per second, 24, 7, 365. And that's a really busy, you know, thing. I think it's I know it's higher than 2,500. I'm just telling everybody, like, leave a little bit of headroom, thumb suck, you know, 2,500 ops per second per row. Worth noting that the range split won't impact the right performance. We would allow the range to internally, we allow the range size to grow above the 512, but asynchronously split it after. Right. Yep. It just triggers a split action. And the other one is as the workload splits and decomposes, let's, you know, at some point in time, Cockroach is going to say, hey, I actually need to go and merge to adjacent ranges and it'll re merge and recombine. And the thing that's important about this is the workload and the database and the way that the database structures and handles and moves your data around, it's adaptive, right? There's no tuning. This is all done automatically. The system's doing this 24, 7, 365 for you. No administrator involvement, like there's not hotspots as a result of this. And so what you'll typically see is you'll see the average temperature of the entire cluster, like kind of the heat of operating on distributed database, it kind of rises and falls together at a uniform rate, which is kind of ideal. It's really nice as an operator. So we've got our distributed database now, Sean. Just thinking about zero downtime, like a distributed SQL database in the context of zero downtime. Historically, when we talk about resilience, let's go back to single data center legacy RDBMS systems. Resilience meant having a DR plan, a business continuity plan, whereby you would have a presumably idle infrastructure running a secondary version instance of your database. Can you, can you, do you have experience of running across in those kind of workloads where you've got a DR site, let's say, and what the experience of managing something like that is? Because now we're, now we're operating on multiple nodes and in a distributed SQL database. We're no longer operating in a DR mindset. Our mindset's changed now to a essentially disaster mitigation, disaster prevention mindset, which is quite different. Obviously, you'd want to have some kind of backup process in place. You might even want to, but you're maintaining nodes across localities, which is essentially doing the job for you. What's, in your experience, what's, what are the pains of managing a DR situation? What does it give you in terms of zero downtime by migrating to a distributed SQL database? Your thinking changes, right, unplanned maintenance, unplanned maintenance typically is results in a small blip to SLO because you did have an unplanned failure and it takes a second to detect it. But like no humans involved, right? And so what you're doing is you're spreading out your risk over a larger number of nodes. So there's maybe like some background, like, you know, variance over time. But for all kinds of purposes, you're, you're managing risk in aggregate, as opposed to the risk of an individual asset, right? You don't have to worry about, you know, when a planned maintenance is going to happen. Instead, what you're worrying about is how do you go in and triage the overall health of the overall cluster, as opposed to like, you know, the individual server, right?  And it's like, you don't have to worry about that named node over there or that named instance over there. Instead, what you're worrying about is, is this collection of servers that are all operating together and kind of stitched together so that in theory, you don't have any kind of like meaningful downtime, you are going to see like little blips to your SLO and individual queries, but like, it's spread out across many nodes and many, many nodes, many leaseholders. And so your risk profile goes down. So it is very much a change in thinking. From the basis of our last chat or last topic, we've had two or near identical questions just come in around the subject of schema migration, schema changes and changes to DDL, which I'd just like to address at this point before we move on. The questions are essentially the same and they are, how does availability, right latency get impacted by schema changes? And I just wanted to answer that while I thought about it. And essentially, Cockroach Under the Hood implements the MVCC pattern, the multi-version concurrency control pattern. And that's not new to Cockroach DB, but what it allows us to do is let's say you've got a table and it's got a billion rows in. If you make a schema change by adding or removing a column, we take a cut of that table, we copy it over to a second version, we make the schema changes on that version while traffic is still happening on this, like a kind of blue-green setup. And when that schema changes has completed, we then redirect traffic to the new version of the table. And the follower reads allow us to at any time up to the point of garbage collection, which I believe is by default four hours, we can query from both tables. So if we say select everything from the table, we would get the latest version once the cutover has taken place, the schema migration has completed. But if we ask for something before that cutover took place, we would get data from the previous table. So with the new column, or the column that no one consists. So just wanted to address those. Please feel free to ask, if I haven't answered the question correctly, feel free to rephrase it and I'll keep on going. Back to you, Sean. Yeah, no worries. Great questions. Yeah. So one of the things that we haven't gotten to or didn't talk about is secondary indexes. Those are a thing. You can create secondary indexes after the fact. You don't have to do dual writes and do some kind of migration. The other one is is you can do the alter table, add column or whatever else alter table, drop column. And as Rob said, like that all kind of happens behind the scenes and we present that post grass compatible interface to application developers. So in that regard, like no change, a lot more complicated in terms of what it is that the software has to do. But as far as a user's concerned is nothing like it walks, I got quacks like it does the thing that you were kind of expecting. So yeah, so moving on here. So and but do feel follow up if you got questions or more questions. You know, what we tend to see is organizations go through this kind of life cycle. There's an organizational evolution where organizations come from and work on the single point of failure, single databases, we were just kind of talking about. And what happens then is, is you're like, Hey, I want to move away from this. And so the kind of like the phase one evolution of all this is I want to move from a single service or single, single server, you know, which is kind of a traditional relational database to something that allows me to scale out, get higher QPS, more data, whatever else is, is, you know, rolling upgrades, zero downtime, maintenance operations, things like that, move to a distributed SQL database. And then now that you've taken that leap and moving from a single server to a distributed server or distributed SQL database, then you can begin to take that data and you can stretch it across different regions and get to a multi region cockroach so that you're able to have your data move closer potentially to where your customers are if you're trying to optimize for speed of light and, you know, the distance between an eyeball and where that user's data or customer's data is. And then after that, obviously, then there's a future state where the ability to span clouds is also potentially possible. And that's, you know, typically the most sophisticated of customers that are dealing with that right now. But like it is this journey, and it's a crawl, walk, run, like it's an incremental thing, like first, the first and the biggest value for most core organizations to start with is going from that relational database that's single server or maybe like a collection of like, you know, write or follow or like in a single, where the, in a single AZ where there is a single point of failure, that's really the important thing to something that is a distributed SQL database where there are no single points of failures in that worker. We talk about manually sharding databases, but like the traditional way of scaling a database was I start with one database, I'd never know that I don't know that I have to scale it. And then I manually shard it in order to gain some form or semblance of horizontal scalability rather than because you can only vertically scale your nodes up to a point. We talk about the pain of manually sharding databases, namely Postgre as one example. I gave it a go the other day just to see, just to be able to say, yes, it is painful. And it made me appreciate with distributed SQL how easy it becomes. You don't have to start off with a huge cluster, it doesn't have to be prohibitively expensive, you can start off very small. And as you add nodes and the data rebalances across the nodes, it allows the database to grow with your business. Yeah, there's there's two dimensions of scaling with cockroaches posted just having vertical where you throw more cores and more ram at a problem.  And there's, I don't call it, I don't want to say it's not science. There's certainly reasons for why, but like, yeah, there's, there's a lot more nuance there, because you have these two additional dimensions, you can scale up the individual nodes that are in a cluster, or you can scale out as necessary. So yeah, then you're going back to the availability bit there, you know, loosely coupled systems versus tightly coupled systems, which one would you rather be operating, right? A loosely coupled system is, is what is required in order to move to that kind of like, you know, three, four, five, six, nine's kind of availability. And that's really, you know, what you have, like you have to start thinking in terms of the risk profile and the amount of entropy and the environment. And when you look at what it is that cockroach needs to do, is we're actually abstracting all kinds of, of, of entropy. And, you know, for better or worse, one of the things that happens when, you know, we work with, with organizations is like, there's availability issues, there's network kickups, like, you know, for better or worse, there's, there's going to be network congestion, or you're going to have like a saturated disk periodically. All of that entropy are things that the cockroach abstracts. And, you know, we hide all of that for customers. And that also means that like, you know, when there is a disk stall, it shows up as a cockroach issue. But because like there, there is just kind of back pressure, like when there's a network stall, like that shows up as as car. So fine, but like, somebody was having to deal with that beforehand, and it was potentially not being observed or paid attention to. Now we're able to, to abstract that and hide that because our system wraps multiple AZs, multiple nodes, et cetera, in order to provide this kind of postgres experience, postgres service experience that is being distributed in order to provide the higher availability that businesses and organizations just want, like being able to do rolling upgrades or maintenance in the middle of the day. It's pretty nice. Not only is it just nice, but like, it's important to be able to handle the, the unplanned failures that happen at peak, as opposed to like, you know, the hypothetical unplanned failures that happen in the middle of the night, like bump in the middle of the night. Nobody cares. No, what customers are awake bump in the middle of the day. That's, that's, that's the money shot. That's where what, you know, matters to everyone. So um, and let's see if you have a quick question there, if you want to like, or something you want to inject there. It was about the slides real fast. It was just about the slides being available. I don't see any reason they couldn't be. So I think that's something we can chat about. So the video will be on YouTube off afterwards. Once it's been uploaded. So the slides will be available there, but let me have a, let me have a chat with the team. And once I've got an answer, I'll leave it as a comment in the YouTube video. But yeah, thank you. And I will just, and there's another person who's who's just said that the links I'm sharing in the chat don't seem to be able to be copied. So I will just send those into the Q&A. And hopefully we'll have more luck there. Thanks for letting me know. Okay. If you look at the history here, you can see that like I start, start up this cluster immediately right before we started our demo here. So let's see. Okay. So what I'm going to do here is, is we've got a workload that's doing just some constant workload. And this is a really tiny cluster right now. It's only three nodes. And so we're going to do something that that's reasonably abusive of this system. And we're just going to do an unplanned shutdown, like P kill nine kind of style.  We do this just so you can see that's about what I'm going to run here in a second. And what I'm going to do here is do this and see the impact of that. And wait for the impact. So the cluster's carrying on, you've P killed something in the background. I actually P killed something on one of the workers. So you weren't gonna see that. Now you're going to see it. So what would you expect? So what would you expect to see, explain to the? Yeah. So, so because this was like an unplanned, like just forceful hard termination, you're going to see a drop. And then you're going to see everything recover here. So these are 10 second, you know, this was rolling window of 10 seconds. And the system will detect it that there was a failed heartbeat and it will renegotiate all of its leases and then everything will come back up and we'll be back to where we were slightly degraded just because we have lowered capacity. But like, there you go. Like that is a potentially an acceptable blip to the outside world. You know, obviously this is an unplanned failure, but catastrophic in any other situation that could be catastrophic. And I think it's interesting that the kind of ambivalence with which we can kill our software in demo scenarios, in live demo scenarios, no less, and have the confidence that it's just going to carry on working. So you can see here, you see the ranges here where it says like, Hey, I have under replicated ranges, you know, and noticed and detected this and said, Hey, I've got nodes or I've got ranges without leases. And it was able to recover that kind of machine time effectively with no human involvement. So then we'll, you know, kick this and let everything come back up. And you'll see that there's going to be some more least transfer activity and the node will go back to being available here in a second. And there's two types of there's, there's different behaviors in terms of failures, isn't there? So if the, I think it's called the time until dead or a node is by default, five minutes. So if, if that node comes back up within that, those five minutes underneath, we will use raft to send any data that was missing from that period to the node that comes back up. But if it's dead for more than five minutes, we remove the node from the cluster entirely. And essentially, when you're, let's say your Kubernetes pod comes back online after five minutes, the data would be resynchronized to that node. That's correct. So this is a little contrived in the sense that it's only a three node cluster, but like imagine 100 nodes or like a couple hundred terabytes, like with like instead of 240 ranges, doing this with like 300,000 ranges is an enormous amount of data to have up and running it online. And so having that amount of data online and being managed by a system that handles all of these self recovery, self healing type scenarios is really important for organizations that just don't want to have to deal with downtime. And that's that goes back to the kind of the premise of what it was that we're talking about, we're talking about, like you can kill a node and the node will recover. End of story, right? And there are obviously like interesting complicated situations where this becomes difficult, but like these are all complicated, difficult situations on a good day. At least you've got software that's going to cover, you know, and get you 95, 98% of the way there so that you can have petabytes worth of data online and a minimal number of operators or administrators for that amount of data and database and the number of database clusters or the amount of data online. I think that that that efficiency metric is part of one of the things that I've set it up front at the beginning of the talk, but low number of administrators required to operate this, especially as the number of clusters grow and the amount of data grows like it's the amount of administrators doesn't change as the amount of data grows for a given cluster, typically, you know, and I've been on the opposite side of that as well, and I think that's an important point. So I've witnessed 17 different instances of the same application deployed across disparate instances. I think it's called multi instance architecture and that was a nightmare to maintain. We had 17 instances. If we wanted to perform updates on any of them, that was downtime for every single one of those instances.   And so like, you know, having these kind of tools at your disposal makes this kind of, you know, it's pleasant or more pleasant for operators because you don't have to worry about the Saturday morning, you know, or the midnight update, whatever it is that you need to do in order to, you're basically taking that off the table. It's not a problem anymore, the same way. But it becomes business as usual, doesn't it? It's something you can say. It becomes a Monday to Friday night at five type activity, because especially in larger clusters, like three nodes is like kind of the minimum you'd ever like consider, or is not anything kind of it is, it is the bare minimum single node cockroach doesn't make a whole lot of sense. But if you've got like 30 nodes and you lose a node, after 10 minutes, we hit the dead node timer, like the data will up replicate across all the nodes.  But it's not required, like the workload moves on the data up replicates so that you are have gone from three copies of the data down to two, when you had that unplanned outage, and then it'll up replicate to three.  So and the effect of being able to do this intraday Monday to Friday is you'll have your whole team on hand, as normal, as opposed to having to do things out of out of hours where you might be the only engineer on call, performing an out of hours update, when none of the rest of the team are available to support you, it's better that it becomes business as usual, you can do everything intraday when everyone's available. Yeah. And then it's convenient for, because developers are able to think of it just like Postgres. So, oops, no demo where we did it live. So let's see, I think we're going to move through the last little bit of this real quickly.  And that was accidental complexity that was forced upon us because databases couldn't scale in the past. And now you don't need to, to, you know, engage in those types of practices because you have a database that actually does this. So instead of having to have plumbing, instead of having to worry about how do you do cross shard joins, we're having to take your database and dumb it down from being a database.  Would you rather be doing that? Or would you rather push this information down to a database that has actually tested and built as a database? And now you just interact with it as SQL that allows me or you or whoever to change their focus from how do you perform these kind of like mechanical plumbing operations to I'm going to focus on my business value, right? And it really helps elevate thinking so that you're not thinking in terms of how do I go and talk to shard one to go get information off of shard two to assemble this to go and do some like, you know, join or to add some like complicated business value. I don't have to do that. Instead, it's like, I've got a query, I'm going to go run my query, all the scaling, all the sharding, all that that's all handled by the database. So now I can focus on releasing my new feature faster with, you know, better availability, right? So to wrap up and kind of come back to some of the initial points, just like, you've got something that looks like Postgres, you don't have to train people from, you know, a new new technology, you can focus on productivity, you can focus on increased efficiency because you have a good general purpose database that allows you a cost, you know, a workload to scale without having to go in and deploy an army of people to go in and manage some potential homegrown bespoke solution. Instead, it's, it's, you add nodes, the cluster grows, your workload goes up, you can scale down if you need to too. Like this, I didn't really get into this, but like if you, like your compute utilization, you know, you need to add capacity, reduce capacity operationally, these are all things that are on the table and very flexible. And then from availability, everything kind of is handled at self healing, you know, it's, it self heals at a machine time scale, as opposed to at a, a meat time scale, or when you have to, you know, get a human on the line, because frankly, we're just slower responding to things than computers. So we've just had some more great questions before we wrap up. One of the questions is on, is there any limitation on node data density? And I think that's a really interesting question. We've done some internal testing of this, and we run tests, large scale tests every day, as we roll out our versions and our patches. And I think what we've arrived at on our, and I'll just send a link to it on our production checklist is around four and a half terabytes per node, correct? That took 10. But 10 to thing. And so like, because that four was where we were for a long time, 10, you can do it. The question is, is if a node goes offline, how long do you want to have 10 terabytes of data potentially be in this unreplicated state? And so that's where the trade off kind of comes in. That becomes a business judgment question, as in like risk tolerance, as opposed to like, where does a software support? Because it's not just about having 10 terabytes. And if you think about it, let's say you've got 30 nodes, I'll quickly do the math here. Let's say you got 30 nodes, and you got 10 terabytes. That's 300 terabytes of raw, right? So 300 terabytes raw is a lot of data. That's unreplicated data. So that would be replicated and tripped. Right, exactly. So if you lose and you go to 29, it takes a while for that data to just be copied potentially. And it's really up to your risk profile. I definitely know of customers and clusters, many clusters that are running at that scale. It's an entirely doable thing. They're not using three nodes. But like, it's very much a doable thing. But there is that, that you just have to be aware of some of that stuff. Let's see. And then multi-tenancy, we've got some stuff there with regards to multi-tenancy. We do have, that's a really complicated question and depending on how far you want to go into that, right? Virtual clusters is really kind of like the way that we like to think about this, where you can have a single physical cluster stood up, and then you can carve out multiple virtual clusters. And then inside of a virtual cluster, you can have different database instances. And so we handle multi-tenancy in that way. I don't know. I'm pretty sure that that's in 23.2 in a preview state, and we're working on pushing that out of GA. So that's, but then there's other like forms of multi-tenancy, where it's like application multi-tenancy. And we don't do anything really to touch that with what we're doing with regards to multi-clusters. Just to add on to that answer, we do have a multi-tenancy product offering. So our CockroachDB serverless, or soon to be named basic tier, does support multi-tenancy. And ultimately it's orchestrated via a Kubernetes cluster, distributed Kubernetes cluster. And each tenant will have zero or more, hence it can scale down to zero tenant pods or SQL pods. And they're private to you with an underlying shared storage, which is very specific to your tenant and can only be accessed by your tenant. So depending on how you're answering the question, you're asking the question, there could be different answers, but happy to take that offline if we want to go deeper. There's a lot to pull on that one. So then plan makes, yeah, absolutely. You hit drain. We've got a bunch of hooks and timeouts. And so you can say drain and terminate a node. And actually in this little example, it wasn't set up that way. But if you do a term, it'll actually wait for the number of SQL connections to drop to zero, and then it'll shut down the process, transfer all the leases, and then shut down the process, and then it'll exit the process. And that actually will happen if you just send something, you know, control, so you like send it a term or an in signal, and it'll begin that graceful draining and shutdown. So you don't, you as the operator don't have to worry about all of the new ones there.  But yeah, absolutely. Plan maintenance like that, is definitely a thing. Integrating that into your load balancer, like there's bits there. Yeah. If we don't have any questions, if you scan this QR code, I think Rob, you might know a little bit more about this, but... Yeah. So the definitive guide is an amazing resource, completely free, for you to download. It's in a Riley book.  So keep an eye on our website.  But yeah, the definitive guide is a great source. We've also released the survival guide, which is quite an amusing take on surviving and thriving as a software engineer in the modern world. Well, I appreciate it. Thank you. Yes. Thank you. Thank you very much, everyone. I'll pass over to Candice at the Linux Foundation. Thank you very much, everyone. Thank you so much, Sean and Rob, for your time today. And thank you, everyone, for joining us. As a reminder, this recording will be on the Linux Foundation's YouTube page later today. We hope you join us for future webinars. Have a wonderful day. Thank you. Cheers.


walked through the children's section of the library and found a book that you really would enjoy. If you haven't, you need to give it a try. Keep watching to find out what I'm talking about today. My name is Kyla DiNomingo and welcome to Kyla's reading day. So today we're doing something a little bit different. I absolutely love books and I love reading and I have given my daughter that same love of reading. In the morning we'll ask her what do you want for breakfast? You want toast or oatmeal? Books! And then you'll read a book and she go again, again! Right? And I love it. I'm like girl I'll read all the books to you all day long. And so I wanted to talk about some of the books that we're reading right now. Okay so this is fall 2022. My daughter is almost two and a half years old and we are reading a lot of books to her so that we can get her to expand her taste buds, try different things, get more exposure to different things, okay? This is the stack that we are currently reading and talking about. So my daughter used to love to eat every single thing that she could see.  You put a piece of fish, she's eating it. This, this, that. However, she has started to go to daycare and that changed everything.  It was just us. So we got really comfortable giving her a whole piece of fruit to eat or she would eat everything but the core of the apple and bring that to you, right? And so we got really comfortable with that. She would try asparagus and salmon if that's what we were eating. She would just eat it. And then you have to pack meals for daycare. I did not have kids food for her. I didn't. I absolutely did not. There were no yogurt pouches, there was no applesauce in a cup. We didn't need the convenience items because we were at home. And so I decided to get a lot of books to read to her so that we could expose her to more foods and let her see that eating is a lot of fun. Food is delicious but also food can be healthy. So that's why I picked up these books about vegetables, eating. I know these, this one looks just like the other one but this one is about different styles of cooking and then this book shows that eating can be sloppy and that's okay because food is yummy, right? And then my daughter absolutely loves pumpkins. She thinks they are so great. She really had a fun time for Halloween. We have pumpkins on our back porch. Pumpkins are our vegetable but also you can eat them. We even made a pumpkin pie. This one is a little bit unusual in terms of it's not in this category of like describing foods but this book is so good for teaching her about veggies and foods. Right? So it's a child and I think pops is the grandfather but they spend time picking vegetables. They're grabbing carrots out of the yard so it's really great. In fact this book is where we realized she separates toast from bread, right? Because like she'll point to this and say bread but then if she sees a loaf and some slices she'll call that toast and I was like look at my baby she knows distinctions, right? But this was a really good book for also teaching her that people eat different kinds of foods. You can put veggies together on a sandwich. You can eat them together. This one was unexpected but it really got her to try different things, right? We can say try it. You know look she's trying it with pops. Try it. So that one was really good. This other one opposite to super cute because she knows her letters and so she likes to just spell out the letters on this one but also there's a lot of things that we say to her and we're trying to use descriptive words. You know get that under the chair or put that on the table but then to have a book that's completely about up, down, over, under was really good. Really good reinforcement of what opposites are. And then these last two kids love all kinds of things that are textile. So this one has all kinds of different like feelings and stuff that you can touch but it's also helping to teach her the month and the year. But this one was the absolute standout. Stret baby Stret. Stret baby Stret. And it goes through the life cycle basically of these three little girls who go through like become big kids and then they become teenagers and then it shows them with their parents as they are older. And so I was really happy we picked this up. You know if you've been watching any of the Kyla's Reading Day videos you know that I choose books by their cover. I'm learning how to not do that with my daughter. I want to just like pick books that are good which is why we chose a lot of these. But this one I saw it on the shelf and I was like Stret baby really happy that I picked this one up and she's really been enjoying it. So this was a little bit different but I did want to just tell you what my stuff and baby girl are reading right now. My daughter loves books and I hope it's because she sees books everywhere. We always have books lying around. We take her to the library quite often and I really hope that I can continue to stoke that and that she continues to enjoy books. And if you're struggling with how to expose your kid to more things consider grabbing some books from the library. You don't always have to buy the books just for them to enjoy it. It's definitely a good idea to grab some books from the library. Okay so let me know do you have a kiddo out there and do you read books to them? Have you picked up any of these books and would it make you want to try broccoli because you saw it in a book? So this was Kyla Denia. Thanks for hanging out with me on Kyla's Reading Day. Bye.


Zoltan asks, what are bullet proofs? A team of researchers has published a paper entitled bullet proofs, short proofs of confidential transactions, and more. It describes bullet proofs as a new, non-interactive, zero-knowledge proof protocol with very short proofs without a trusted setup. What does it mean? How does it work? What will be the practical benefits? A highly technical question. Thank you for asking, Zoltan. Let me try to explain this as best I can. Confidential transactions is an invention that was published three years ago that allows you to encrypt the amount in a Bitcoin transaction. By encrypting the amount, you can break a very important source of information leakage, where analytics companies can track amounts. In an answer to a previous question, I mentioned CoinJoin, where lots of people participate together in a transaction. One of the disadvantages of that is, unless you are all trading approximately the same amount, it's very easy to track which input belongs to which output because of the amounts involved. Confidential transactions is meant to be used together with coin mixing strategies to create very anonymous and private Bitcoin transactions, whereby no one can track who is paying what to whom. Confidential transactions encrypts the value.  If you use that together with mixing, you can't really tell which output corresponds to which input. It makes it much more robust privacy. You might be thinking, if the amount is encrypted, how do we know they didn't spend money they didn't have? How do we know they didn't create new money from nothing? The technique used in confidential transactions is called a zero-knowledge proof. A zero-knowledge proof is where you prove something is true without knowing some underlying information. In the case of confidential transactions, you can use a special type of math in the zero-knowledge proof, which allows you to add the inputs and outputs and show that they add up to zero. Basically, show that the amount of the inputs and outputs are equal and add up to zero without knowing what these amounts are. This seems impossible. Trust me, the math doesn't make it seem any more possible. It is quite confusing and very difficult to understand, and I don't really understand it. But what I do understand is that if you encrypt values A in the inputs and B in the outputs, you can then apply a proof that says A and B cancel out each other, and the sum of them is zero, so that you know that there is an equal amount of inputs and outputs, no new money has been created. The specific zero-knowledge proof that is used in confidential transactions is called a range proof. You can prove that a number is within a certain range without knowing what the number is. Bullet proofs are at development, because one of the problems with non-interactive zero-knowledge proofs is that they tend to be very large. They use a large amount of data. If a transaction with confidential transactions that contains these non-interactive zero-knowledge proofs could be 20 kilobytes, compared to a normal transaction with, say, 200 bytes, that is not a very good trade-off. You have a lot of privacy, but in return the capacity of your blockchain just decreased tremendously, because the transaction just became a hundred times larger. What the authors of that paper achieved, and it is an interesting read, although you might find it challenging, is that they achieved a much shorter proof, so that you can prove that the numbers in the inputs and outputs are within a range without using as much data, without making a very large transaction that then reduces the capacity of your blockchain. It's a very incredible development in cryptography. It's once again a demonstration that Bitcoin and the crypto ecosystem in general, and the research that's going on, is pushing the boundaries of cryptography, it's generating new cryptographic knowledge and discoveries in science every single day. The practical benefits, as you asked, is that we can get confidential transactions with much shorter proofs, which allow us to encrypt the value of a transaction, so that we can gain greater anonymity without that transaction being enormous in size.


Coming back on the main deployment it's pretty impressive getting ready to pull back in here shortly the morale and all the crews emotions and feelings are starting to spike. We departed back in June and over these four months been successful down here in the four fleet area of responsibility and just so I know the family members are excited back home the crew is starting to get really amped up and so we're looking forward to you know return from a successful voyage. Big peaks and valleys for the deployment we entered on deployment we got to experience be the first participate in three latoral combat ships operate at the same time doing some div tax and photo exercises and then we also got to our first port visit whereas in the Dominican Republic where we got to host the president and vice president of the Dominican Republic and that was a pretty impressive reception we had on board and fourth fleet actual came down and so being able to see the sailors show off their ship and the pride they have in this warship and then just executing with the jamaican defense force with the Dominican Republic's defense forces and doing those bilateral exercises a lot of good came out of those and the ship was able to show off their signature skills and so those are kind of the memories we're going to look back on with fondness years down the road. 110 sailors we were green when we started our deployment but now we've done over you know two dozen almost three dozen seen anchor evolutions operating in multiple different countries waters with different nations navies supporting bilateral exercises humanitarian disaster relief hosting receptions just a resiliency of the crew to be able to manage their equipment keep their ship underway steaming sustained operations at sea just impressive to see from the very beginning and like I said we're just so excited to be able to bring the ship home get back home to our loved ones and just look back and see how successful we've been.


Catch yourself in the awareness that your mind is racing, stop in that moment, look down at your feet, your feet are always in the present moment.  And you want to even thank yourself for the awareness of that. Then identify that you're safe. And what it is you want next. What you want or need. I use the example of sometimes we actually need food in order to feel grounded, but you, you may be in the midst of a creative project and it's just feeling so much or business decisions or any kind of decision and it feels like too much. So just want to chunk it down identifying the what and the why the why is the emotional piece.


What's up everybody, Jason here for Jaspy's case brace.com 21-22 panini impeccable basketball mixer three box break Two rounds since each number one just sold out and again guys this features two boxes of impeccable Asia edition and one box of impeccable Hobby 15 totals buzz everybody gets your round teams NBA now. This is part of the promo. So we actually sold out the promo so Actually, I have to take this one off the board, but that is a promo spot for this break here, too as well So we already put the list of names for the filler that we sold out But for the hobby customers, we're gonna copy and paste the 15 names onto this Monday promo here All right, so there you go. We did the filler there now. This is the impeccable thing right here So there you go. There's the 15 names there and now we officially sold out our first promo break So there you go one down we got one two three four five six seven More to go and we have till Monday guys. We have a couple days So appreciate you guys. So good luck everybody there So again now I'm gonna double up your names, of course because you guys get two random teams and then there's the names and teams Let's roll it You got a two and a three. Excuse me five times One two three four five There you go five times two three five Carl at the top done a car at the bottom now.  Do you want to trade Carl? I don't know if you're looking for a specific team Not I'm gonna close it or Nick maybe trying to specifically look for a team If both of you guys are obviously watching I'm assuming no Alrighty, so it is two boxes of Asia edition and one box of Javi and It's crazy because obviously they look exactly the same. I Actually showed this to my wife. I said right before I brought him over I was like what's the difference between both of these boxes and she's just like I don't know I don't see anything different, but I'm sure you guys see it right in front of you guys faces, right? That's the only difference right there. That's the Asia stamp right there for Panini Asia products. So this is the one hobby box Ends with 23 too as well. And then of course these are the two Asia boxes But if you didn't really notice that you would think they're exactly the same box, right? It's like nothing different about them besides the stamp So we'll go with the two Asia first and then we'll go with the hobby edition after that Carl Strong will foam in this All right, so has a little chip on the bottom corner, but that's a Zach Levine For the bulls We have a de Montess a bonus and we have an exclusive Asia red of Evan Mobley The last one there for the Cavaliers, which is going to Carl. We have a Corey Kesspert to 18 Nice one there That is for the Washington Wizards Go to Carl and then we got a redemption. See what we got here Elegans, rookie Jersey autographs Asia card number 118 Tremend that is okc Thunder and Okc that is Carl. All right, so there's the first Asia box Let's do the second one Hoping Scotty Barnes, right? I feel like he's been a redemption a lot We have a Trey young and a DeAndre eight Jalen Suggs for the Orlando magic. It's going to Nicholas Corey Kesspert to 88 autograph My Carl like we got him in the first one. Yeah to Kessburgs with a half and another redemption And this is Trey man again. That's gonna be wild rookie autographs Asia number 11 It's Keon Johnson, which I believe Keon is a spur clipper He was a clipper, but now with Portland, but it doesn't count Clippers up next this one here. This is the hobby edition though. So this one's a bigger bigger boy right here They go Kawai Leonard. That's a purple number to 75 Hobby edition What is this a Corey Kessper break Jesus another one there for the Washington and Washington Wizard sorry and John Collins is 75 See y'all come and we got a redemption right at the top See y'all come number to 99. I guess let's go with the redemption first stainless stars autographs purple car number 14 nice Moises moody. That is for the warriors Golden State Warriors that is Carl and I believe purple should be kind of low-numbered as well Brad Daugherty 299 Dale Goodrich Number to 25 for the lake show. That's what a car as well. You guys CJ McCollum number to 25 and Whoo, nice way to end it off here. How about a Jalen Green? 14 out of 99 nice and Jalen Green Houston Rockets. Oh Nick look at that Nicholas with that one.  That was the impeccable break there. So that is the impeccable mixer And again, we post it up another one as well If you guys want to run it back Jasper's case breaks.com still a lot of good stuff hiding there though guys We still have the metal card potentially Of course some bigger rookies on both cases, of course as well with the Asia and the Javi edition as well. So appreciate you guys


Hello everyone, this is Amit Dan of AmitDan.com. Today I'll have another episode of Easy Cooking video and I'll talk about how to cook super seven-food immune booster in 20 minutes. So I have all the ingredients right here and this shouldn't take long, so I'm looking at about 20 to 22 minutes and I'm going to use a frying pan which is going to be like this and this is you know nonstick. So you can do it about 20 minutes if you use a frying pan but if you use one of the pots like this then it's going to take a longer and the vegetables kind of get mushy in it so it's easier to cook when you're using a frying pan. So let's go over the ingredients today. So we have a seven superfood and these are one of the best superfoods you can buy. They're immune booster, they're full of antioxidants, minerals, vitamins. So basically if you're eating these every day or on a regular basis your immune system and it's going to improve, you're going to be healthier, you're going to be you know feeling much better. So basically it's hard to beat this vegetable dish and that's why you know I'm going to show you how to cook this very easily. This is not, it doesn't take a lot of effort so only effort is that you have to go to supermarket and buy these ingredients and some of them actually I'm using, they're frozen, they're not even fresh but you know the reason I use frozen for example the kale which is right here and then the broccoli and I use these frozen because you know they are easy to cook and I tried buying kale you know fresh but it's very hard to wash and sometimes even I wash like you know five ten times I still get some soil in it because kale is one of the foods that is full of soil so it's easy to have you know frozen and you cannot beat machine wash. So let's go over our ingredients one by one and I'm going to start off with the shard so there are two types of shard you can buy one is green shard and one is red shard so this is the green shard and you can see the nice green leafy texture and kind of like a mixed red color and then we have here asparagus and I don't have to tell more about asparagus one of the best superfoods you can buy out there and then here we have rapini rapini is slightly bitter and it's very green and it's a very fast cooking so you don't have to actually cook a lot and you know if for some people they might taste the bitterness but I've been you know using or eating rapini for long so I don't feel bitter anymore so this is one of the foods I or vegetables I eat every day and then here is we have tomatoes and you know I don't have to introduce tomatoes more you all know what is tomato and the benefits and then here we have kale and usually I buy I kill frozen the reason I mentioned you before that you know it's much cleaner if it's frozen and you can see it's like you know deep or dark green with the very nice color deep color and texture and then we have here broccoli this is also frozen but you can use fresh too and then we have here mushroom and this is organic mushroom because mushroom tracks lots of soil and like you know things from ground so it's easy better to have organic otherwise if you are buying regular then just make sure that you are washing very good then we have our main one of the main ingredients of not just a vegetable but any cooking onion and garlic so you can see that you know I cut onion two different ways so for example this one it's kind of almost whole onion but it's cut you can see that you know if I just press it is going to be like you know open and then here I already like you know take it removed it and then it's like you know already cuts in pieces but this is going to give you like you know kind of is going to take a little bit longer in the frying pan to remove from its size and then we have garlic the reason I cut garlic this way because I don't want garlic to melt in the vegetables I want them to kind of stay whole so that's why I cut this way so this is one medium-sized garlic and this is one medium-sized onion and then here we have about one teaspoon of turmeric or some call it turmeric and then we have little salt maybe one teaspoon I usually try to try to go very low on salt and then we have a little bit of red pepper not too much but if you don't like like you know spicy or red pepper you can just skip that and then these ingredients actually it's just kind of in a common sense I can change them or you can increase one decrease another so basically what I cook what I have here this is good enough to fill up this frying pan right here and it's not going to be over the size or you know too small so this perfect quantity for to cook one time and then we have oil and I always use extra virgin olive oil but you know I didn't show you how much oil I'm putting in because you know it's not I'm just going to be putting in about one tablespoon or little or less and so these are our main ingredients so let me just count if we have the seven superfoods because I don't want to miss anything so we have one two three four five six seven so you can see that we have seven superfood and let's the name of the ingredients again green shard asparagus rapini tomatoes kale broccoli mushroom and then here we have onion onions one medium-sized onion not too big one garlic and turmeric and a little bit salt and little bit red pepper and I'm going to be putting in one a spoon of oil so that's the preparation and the ingredients now let's start with the frying pan and then I'm going to be putting them one by one just before I start doing that you have to be mindful about which one you're putting first and which one you're putting later because some of the items here they take longer to cook some of them are they take shorter to cook so for example here we have mushroom which is going to take the longest so I'm going to put this first and then here broccoli is very like you know little time it takes to cook so I'm going to be putting it at the end and then tomato I want them to you know be intact or whole so I'm going to be putting them at the end so I'm going to start with mushroom and then the next ingredient takes a little bit long to cook it's going to be the kale and then I'm going to be putting in the rapini and then like you know shard and then I'm going to be putting in asparagus and then tomato and then broccoli is going to be at the very end so basically once I put in broccoli you can you can say that you know the cooking is almost over because I'm just going to be putting in like you know one minute before a couple of minutes before I finish the cooking so that way broccoli is going to stay like you know still like you know very green and very like in a whole you cannot even tell that it's been cooked so that's the basics of the beginning so let's start turn on the stove and then we're going to start you know putting our ingredients one by one so I have turned on the stove at medium heat which is right here and it's a little bit hot right now so I'm going to start with oil so I'm going to just very quickly put some oil usually I don't you know and usually any measurement to put in oil so I just have it like you know I just know how much I need to put so I'm going to put in some oil and my guess would be that you know this is a tablespoon or lesser than a tablespoon and then you can see that you know the oil is kind of all over right now so I'm just you know spreading it out and you know you can see that this is hot I can feel you know the heat so I'm going to be starting the first thing the onion garlic and the spices so I'm going to be just you know poured the whole thing into here and you're gonna start like you know getting some noise and I might have to turn on the exhaust fan it all depends so let's start with that okay so this is empty I'm going to be just putting it in here and I can see the smoke is coming up so I'm just going to have to turn on the you know vent fan a little bit so there's going to be a little bit noise sorry about that but you know there's no other way so I'm going to just you know put this little bit right here and we're going to see how it works right now so I can do this about like you know a couple of minutes or three minutes just to make the onions and garlic everything just slightly cooked and then I'm going to be starting with the mushroom so it looks a little bit dry but you know once I put in mushroom it should be okay but you know if in case I feel it too dry I might need to add some water but I'm not hoping or thinking that you know I may need to put in some water so I started it just passed about one minute so I'm not gonna wait anymore let me just you know throwing some mushroom right now you can see that noise is changing a little bit so what happens when I'm going to be putting in like you know kale or rapini they have water in it and even the shard so that should be good enough for the water so right now I'm just going to leave it here like this and actually I can just you know use one of the cover for my pot just to you know keep them together so the heat gets evenly spread and it makes faster so I can do that it's not gonna cover the whole thing but that's the way I want I can just like everything inside here and then we'll just wait a little bit and let run so I'm looking at about you know I would say about a couple of minutes or let's say three minutes and in between you know you have to just like you know move them a little bit so it doesn't get burnt you have to just keep an eye and still the heat is that medium so I haven't changed the heat anything and I'll try to keep it that way I don't like to put too high or too low because that's gonna like you know make the cooking faster or slower but when it's at medium then you know it's tasting perfectly the way I want and everything remains not too cooked or not too undercooked so you can see that it's coming very well I can get the spices of turmeric so one thing about the spices is that you know you can usually turmeric can go with anything and it's a very healthy you know another super good that has shown lots of health benefits so I try to turmeric in everything but if you would like to add some more spices you can do so but usually I don't when I cook vegetable turmeric is the only thing I put in and slightly like you know red pepper and actually at the end I might add some black pepper which I haven't mentioned before but you know those are optional you don't really have to but you can if you'd like okay so at this point you can see that you know there's water coming up a little bit and getting heated so I'm just going to be putting in the kale because kale takes a little longer to cook so okay so most of the kale are in here now looking very nicely so I'm just going to cover that again a little bit but it's not gonna be too long and then within another couple of minutes I'm gonna be putting in the shard, rapini and asparagus and then tomatoes and the broccoli is gonna be at the very end so it passed about I would say five seven minutes so I'm just going to wait here another couple of minutes and what I mentioned before you can see that you know water is coming in now I didn't add any water or anything although in the beginning it looked dry but now you can see that you know it's getting a lot of water and even you can see some water here so I'm going to just cover this again and let's wait another couple of minutes so the heat is still at medium and you know it's cooking nicely so I'm going to be starting putting in everything from here so you have shard, rapini and asparagus so I will start with shard and then I'll move on to rapini and asparagus so I'm going to be just putting like this and then we have some shard here okay so all those are done just wait a little bit for the asparagus to throw in and in the meanwhile let's just like you know mix them together and the reason I kept one piece of shard intact just wanted to show you how it looks some people may not you know no shard but definitely you can use the replacement for that and I'm going to cover this again and then I would wait about another couple of minutes so I'm going to just take a look here okay so you can see that you know it's cooking very nicely so right now it looks like I'm okay to go ahead with the mushroom I'm sorry the asparagus so I'm just going to like you know put it on top this way so that way it doesn't get too melted so I'm just going to cover it and now let's wait another couple of minutes and after that I'll start with tomatoes so it should pass another couple of minutes or close to two minutes so now I'm just going to be adding in the tomatoes but I'll just like you know put them kind of right on top and I don't want them to melt it and I'll just like you know move this little bit on the bottom so it doesn't get burnt evenly just I'll spread them out a little bit and tomatoes are here now and so I would say I passed about 17 minutes right now or so it could be like you know one or two minutes plus minus but in that range so right now I'm just going to cover it up for another couple of minutes and then the only ingredients we are left with is the broccoli and after like you know let's say two minutes I'm going to throw in the broccoli but once I put in the broccoli I'm going to turn off the stove because that's the end of cooking and that should be exactly at 20 minutes or it could be like in 21 22 minutes and then the heat from the stove or the heat from the pot should be good enough to do the rest of the cooking so you're looking at kind of another five minutes or seven minutes to from the frying pan heat because it's very hot right now so once I throw in the broccoli I'll just turn it out and that should be it so you're looking at the whole process about 20 minutes because after I throw in the broccoli you can just like in a leaf you don't have to keep an eye on it so that's going to be the end of cooking and the heat which is retaining inside the frying pan should do the rest of the job now you can see that the asparagus is kind of like you know very keeping it's a very nice color it's not melted or it's not like you know too mushy so it still feels strong or hard but it's getting cooked and then the broccoli is doing a good job too I'm sorry the tomatoes is doing a good job it's gonna keep intact but I should don't want it to melt because if you put in broccoli too early it's gonna be all melted and you probably you're not gonna even see any broccoli if you put it put it too first so it's something one of those items you have to put it at the end and let's wait another minute then I'm gonna like you know start putting the broccoli so we have come almost to the end I'm going to just throw in the broccoli right now and after that that's going to be the end of the cooking so let's just you know put in the broccoli and I'm going to just like a touch a little bit on the bottom just to make sure that nothing is nothing fun is going on so asparagus looks very tender and nice and properly they're just blending in so at this point I'm my heat is still medium so I'm just to cover this again and again this and we're gonna cover the whole thing but that's the way I want I just want to keep an eye so I covered this and then right now I'm going to turn off the stove so you can see that you know it's been off and right now the heat in here is going to do the rest of the job so you're looking at another like no five minutes but we should be at 20 minutes since I started the first ingredient so that's why you can cook this amazing vegetables full of vitamins minerals you know antioxidants and all sort of good stuff you can possibly imagine super seven best the best super seven food or super foods you can possibly get or one of the best seven foods out there so that's the end of the cooking so I'm just going to show you the whole thing once it cooled down a little bit so I'm going to show you the final product so but the stove is off now and I'll just like you know wait another like you know a few minutes before I put in everything on a plate and show you how it looks like hi guys this is the finished product so you can see that the broccoli is very intact it's it doesn't even look like it has been cooked but it has been cooked and it's kind of like in a whole and very green and leafy and that's the way I wanted and then we have here rapini so when you cook rapini it's a kind of gets a mushy and you can keep it green but then it's still going to be difficult to chew so that's why rapini looks a little bit darker and then we have the asparagus right here and you can see that you know this is whole intact and very green and then we have tomatoes right here and then you can see the onion the garlics are right here they didn't get melted but onions got melted which was supposed to be and then I have found some kale right here so when you cook kale because it was frozen it was cut into small pieces it kind of mixed with everything else so it's hard to separate them but I was able to do a little bit here and then you can see that this is mushroom so it came out very nicely cooked and whole and then we have here shard and you can tell that this is shard by its red texture and you can see that you know this looks very good as well so this is our again the full dish and the seven superfood full of antioxidant vitamins minerals and we cooked it in about 20 minutes so thank you for watching this video I do have a few more cooking videos which is going to be under the cooking easy cooking playlist so if you like what you see definitely you can check out the other videos and there will be more videos coming up so I'll see you shortly thank you