Let me find some place to put this. All right, so, oh, OK, good. All right, so I'm going to, since I'm day three, I've sort of modified a few things. So maybe like the first talk we had, title isn't as appropriate to what we're going to talk about here, but it's generally good. Now, if you've all been watching any of the local TV in your rooms, you've seen an awful lot of political ads. And, but I heard a couple of things that caught my ear. One of them was a public service announcement. Those are the kind of things we put out when there's a storm coming, right? Let the public know what's going on. It's essentially a public service announcement.  OK, makes sense. And at the end of that commercial, a woman, the mom, is walking off the screen.  And she goes, whatever. It struck me kind of. First of all, I never thought I'd heard of marijuana commercial on TV. But that's the same kind of attitude that the public takes a lot of times. With this information we're trying to give them, they're either overloaded or we've talked about this on a number of occasions about the false positives. Oh, yeah, last time they said it was because it didn't. But the other one that caught my ear was an all-state commercial. I haven't seen this one in Louisiana either. The guy says, a 500-year storm comes every 500 years, right? And then he says, in the last decade, we've had 26 500-year storms. But again, I don't think the public gets that either. So I don't know how we communicate some of this stuff. Is this working? This one here? All right, sorry. OK, all right, good. All right, there's forward, there's back, there's forward. Got it. All right, so I thought I'd start by just talking about, so what is risk? A risk is expected loss. And statistically, you can calculate this. The top equation is the way a frequent statistician would calculate it. You have some decision rule, and that determines the difference between an observation and your decision point. And you take the expectation over your data and pick the optimal, the thing that minimizes your error or loss. And in a Bayesian format, you do the same kind of thing, only you have a prior. And I think in our case, an interesting thing here is that prior could be like satellite data that's constantly monitoring the seasonal, monthly, whatever time step you want to look at, whatever the hydrologic parameter is. It might be soil and moisture, it might be precipitation, it might be potential of aperture transpiration. There's a lot of these things that are available from satellite platforms. So that's your prior. And then you have some data that's sampled now, and you can update the prior and come up with a posterior distribution. And in the Bayesian framework, you have a loss function that you integrate over the parameters of that posterior distribution, and you pick the optimal action. Now, one of the interesting things, and we kind of did this the other day in our little DICE experiment, loss function counts. If your loss function is a squared error loss, like ordinary least squares, the least squares kind of paradigm that many statistical parameters are sampled over, then the optimal decision is going to be made at the mean of the data or the posterior distribution. If your loss function is linear, then it's at the median. And so why is that important? Well, a lot of hydrologic things aren't like nice, normal distributions with the mean and the median of the same place. And you've got large tails. You might want to be looking at the median of the response, which gives you 50% of time I'm going to be below this, 50% of time I'm going to be above it, and frame your decisions and actions based on that. The loss function we had the other day, by the way, was an asymmetric loss function. If you incurred a flood, it cost you four beans. If you didn't incur a flood, it didn't cost you anything. So you can actually work through the calculus of all this stuff and figure out what the optimal action would take on any one annual throw. In fact, you could even work in the nine-sided dice thing in that period of 10 years and figure out what the optimal thing is to do every time. So the point is the guys in the back just got lucky. Lucky beats whatever every time, I guess. So all this is models. So what's a model? And a model is an abstraction of reality. We like to think our model captures reality, but we do our best.  And the better you are, the more credit you get for doing it right. But another important part about models, and we've talked a lot about this over the last few days, is that model has to be in the context of some decision support role. So that model has to deliver me information that I can use to take my action, determine what I'm going to do. And otherwise, it's just a model. So models are important to decisions. It has to give me things in the right time steps. It's got to give me things in the right spatial resolution and those kind of parameters. And again, in our case, it implies a spatial domain. So we're talking about a watershed. We're talking about a base in some place, or a coastline, or a lake. Whatever we're trying to model a flood risk in has a spatial kind of domain implied to it. We don't care about the things that don't drain in there, just the things that do. And then, of course, the time element is important. So do I need this information? Well, first of all, the data that I'm putting in my model, how is that provided to me? Is that an annual number, a monthly number, a daily, an hourly, every 15 minutes, whatever. Models operate all these, or data is delivered in all these different scales. Then the models operate in whatever scale they operate in could be any of those. And then the information that comes out of them has to be in a scale that provides me in the time frame that I need that information. So here's just sort of the generic model. You have the output. You have the model itself, which is this F thing. You've got an XYZ, in this case representing sort of maybe the characteristics of the basin. The spatial extent, the soils, whatever it is that are important in your hydrologic model. T, the time thing, again, this is a daily time step. Is it an annual time set monthly? What's important for making my decisions? The part that gets left out a lot of times is the thing on the end. As we focus on the model itself, and the error is just like this nuisance thing that we just kind of want to ignore. So we know our model isn't perfect, but it's OK. But that nuisance thing is comprised of a couple of different components. The error term encompasses the things we don't know, the things that our model doesn't account for in providing the output. But it also includes sort of intrinsic variability in that system. So for example, here, I've got three simple models. Let's just say the flow on the y-axis is a function of the area of the watershed. We can kind of all agree that that's kind of an increasing function. Bigger watersheds have bigger runoff, that kind of stuff. But you can take three watersheds that have exactly the same area on the x-axis. But they're comprised of different things. They have different combinations of soils. They have different slope regimes. By the way, different slope regimes. This is something that I think is fascinating. We do a lot of watershed modeling based on the area of the watershed. Well, you throw a slope in there. If you have a slope in that watershed, then the actual surface area in that watershed is higher. So we never account for that. And maybe that's an important factor in our modeling. So in this case, we've got three relatively identical watersheds. But their intrinsic variability is different because of how they're composed, at least with respect to the relationship between runoff and area. So in the upper left, you've got a relatively low error. You've got pretty good models. You can see the line there. The regression line in the second one is in the same place. But the stuff scattered around a little bit more. So we need to understand, and of course, in the third case, eventually, if your model doesn't do very well, variability can overwhelm it if you need to do more. So let's talk about geospatial models. And geospatial models are important in the context of what we've been talking about all week. Because they're the way we're going to get the things we need, the data we need, to answer our questions, to run our models, whatever. And we've sort of implied a lot of this stuff. The geospatial model is something that the model elements are spatial objects. And those spatial objects can take advantage of geographic information systems, concepts, and data, and technology. And the most important things here are the relationship between these objects, the spatial relationship. So the juxtaposition of elements, what's next to what overlaps what. And that's really important because when we're talking about data, and I'm not sensing guys understand this, right? You've got things that give you data at 30 meters, things that give you data at 10 meters, things that give you data at 1 meter. So you're always dealing with different scales of information. And in the geographic information system, geospatial kind of format, you can combine that information because you can handle juxtaposition. So what overlaps what is known, what doesn't overlap what for that matter then, is also known. And then topology. That's another really important thing, right? I don't care what happens in the next basin over, but I do worry about what's upstream for me. So connecting upstream and downstream, that's what topology is all about. So two kinds of basic ways that things flood. You've got rising water that just inundates stuff. And it causes chemical reactions and whatever. It causes infrastructure to have problems. If you flood a road for a couple of days, it's pretty well known that the foundation of that road is going to deteriorate over time. So that road's going to start buckling and cracking. And so, for example, in Katrina, we made sure we knew where every flooded road was. And we're able to put together our damage assessments and talk to the FEMA people and the government about that. So that's one kind of damage. And that comes from storm surge. We had a lot of backwater flooding in Louisiana. So when the wind is blowing from the east to the west across Lake Pontchartrain, the water level on the west end of the lake could be four or five feet higher than the east end. And that pushes across that little isthmus. We'll see a few maps later that separates it from Lake Marapa. And most of the things that drain into that basin come through Lake Marapa. So all of those basins, all of those drainages that are going to Lake Marapa now have higher water at the bottom. So the water that's coming down the drainage is backing up. And you can get backwater flooding clear into Baton Rouge, which is tens of miles away from there. So that's one of the ways we flood things is this rising water kind of deal. And flowing water, that's a whole other deal, right? Now you've got the force of the water in here. So you've got flash floods, tsunamis. You've got riverine flooding. And I'll talk about this, I guess, a little bit later when we talk about the flood of 2016. But I remember my guys upstairs, hey, we need to know what's going to flood in the Amite River. Can't do that without a model, right? You can do rising water flooding pretty easy. I don't know if anything's catching up here. So rising water flooding is fairly easy to do because the surface is well-behaved. It's got a little bit of play in it, but it comes up from the bottom of the watershed. But the flowing riverine channel type flooding has a slope to it. So I just can't say that if I got a gauge height up here, that everything that's below the elevation of that gauge height is going to flood, is contained in the channel. So let's talk about rising water flooding, specifically storm surge. So actually, on the right-hand side here, I've got a map of the slosh grid, right? The Sea Lake Overland surge from hurricanes. By the way, they now include tropical storms. So maybe they need to call it slots or something now. So that's a category zero storm when you get the data. So you can see this model starts way up in the New England area. It goes all the way down the coast. Actually, I chopped off Texas. But anyways, in that model grid are all the bathymetry and land surfaces and obstructions and things. We actually went out, by the way, the data that was available in that regard, particularly the land forms, even the bathymetry. Some of the bathymetry we had in South Louisiana was last collected in the 1800s. We've had a lot of sediment delivered into the coastal areas. So those are all gone. I think I mentioned something about this the other day about some of the lakes in the Piedmont. The lakes have all filled up from the bottom with sediment. So all of our flood models that are thinking that's a nice sink to hold water, they don't have the capacity they used to have. Anyway, I digress. So your grid has all this stuff built into it. We even went out, by the way, and measured the elevations of those Jersey barriers going down the middle of the interstate so that Hurricane Center guys could work that stuff into their models. This is a very important thing. All these little things become barriers to storm surge, either moving in or out, for that matter, and the effect of timing and ultimate water levels and all those kind of things. I've also included on the right-hand side here some details, the Chesapeake Bay, South Carolina, Coastline, North Carolina, and the New Orleans area. So they do this slosh model thing, and it's a geospatial model. It takes geospatial data. It has a geospatial framework within it, and it gives me data in a grid of polygons that tell me what the water level is going to be within that particular polygon. And it does that in actually several different products. It gives me a set of polygons with a 10% exceedance, 20%, 30%, 40%, and 50% exceedance. So how do they get this, right? So they take a storm and they run it into the coast, and when it hits the coast, it does all of the hydrologic processes that affect storm surge, and they do that a couple thousand times. And so the 10% exceedance is the 90th percentile of all of those outcomes. And then the 20 would be 80 and the 30. So the other important one to me is the 50. How do you interpret what a 10% exceedance means, how does the public do that? How do you interpret the 50%? Well, 50% is pretty easy, right? There's a 50-50 chance this thing is going to happen. I can make a decision on that a lot easier than, well, there's a 10% chance it might be this deep or a 90% chance, which is actually pretty good, that it's not going to be that deep. So that's an issue. So here's Hurricane Nate from last year. In fact, it was about a year ago at this time that Nate was wandering around the Caribbean and the Gulf. Oh, and by the way, I noticed yesterday that the Hurricane Center is watching something in the Western Caribbean right now that they're expecting to form somewhere, maybe down in the area between the Yucatan and Cuba. Got 30% on that one right now. So here we are looking at one of the things I look at as I'm collecting information. This is a Huravak, which is a decision support system. It's right now it's on a Windows platform. They're moving it all into the web now, but it'll be the same kinds of stuff. This is the Winswath representation of Nate at this particular advisory. And you can see that Louisiana is sort of at the edge of the tropical storm force winds, the blue stuff. But Storm Surge, it didn't follow those lines. The Storm Surge is this what they like to call it, a dome of water. It's being pushed by the winds. It's usually pretty heavy on the right-hand side of the storm. So we're in a good spot in that regard and it's gonna be Mississippi and Alabama to get the worst kind of storm surge from this. Another interesting thing, and I'm not sure how well it was modeled, but what was it, Maria? The storm that went up the middle of Flora, on the right-hand side of that storm, was pushing water on shore and flooding things. On the left-hand side of the storm, it was pulling water away and there were boats sitting on the bottom of the bay kind of stuff. And that's not just like you're talking about the pleasure boats kind of stuff. The guys that are trying to run freighters in and out, they gotta worry about the depth of that channel so they don't get grounded. So this is the grid I get. And so remember that big grid that goes from Maine to Texas? I just clip out the part that's important in Louisiana. And this is sort of, you can see kind of the extent of what I get. It's kind of hard to show things, but you can see underneath the landforms, you can see the places where there is no grid cell, it tells you to expect that to be dry. But in the top center of this, you're clear up in Baton Rouge. So I-10 and 12 go across here. They come through Slidell on the right-hand side of the map and run across to Baton Rouge, cross the Mississippi River and go into Houston. That's the major east-west trucking route between the west coast and the east coast and on the southern tier, right? You gotta go up to I-20 before there's a next east-west. And that goes across the top of the state. That's our ultimate route. So now I got these cells and they tell me what the water level's gonna be. In that location. And that's how I do my analysis. So let's talk about what the products are though, because we talked yesterday about how in a real storm event, I don't get operational forecast. So an operational forecast is a forecast that's based on the actual storm conditions, right? So they come up with a advisory every six hours and that sets what the Hurricane Center thinks will be the direction, the forward speed, the strength of the storm. And then those parameters are put into the model and run. And they're varied a little bit to get the sort of stochastic element of all of those things. The storm track isn't gonna be exactly where they said it was in two days. The strength might be a little bit more, a little bit less, those kinds of things. So they run all these simulations, a couple thousand simulations and then they deliver these grids to me. But in that three days, right? So most emergency management, a timeframe start five days out. So at 120 hours. In those three days before that 48 hour first actual operational forecast, I've got what's called moms and meows. By the way, I'll point out that for Katrina, tropical depression 12 formed at 117 hours out. So we were already three hours behind our timeline and it was just a tropical depression. Not even a hurricane. Anyway, and the track came across Southern Florida and it went up the west coast of Florida and it stayed over there. That was Tuesday when it started and it stayed over there until Thursday and all of a sudden it jumped over to New Orleans. So you got to account for track and certain things there. So let's talk about what the moms and meows are because that's how you're making your decision. So the meow is again, a series of simulations given a storm direction, a storm strength, forward speed and tide. They use a mean tide and they use a high tide. And so they run thousands of those simulations. So you've got for every combination of those factors, you've got a cell in the model.  So there's a Louisiana, there's a New Orleans basin which runs from Mississippi to almost all the way across the coast. There's a Vermillion basin which is kind of the south central part runs from maybe the east side of the Mississippi River to about Texas. And then there's the Sabine basin which kind of picks up in the middle of Louisiana and runs into Texas. So that helps them reduce the delivery issues for if you did that for the entire coastal model, it would be huge. And people are not interested in anything but their own stuff, right?  Well, what they did then was they said, well, we may not know all these things so let's take all of them meows and we'll stack them up and we'll pick for each of the cells the worst, worst case or a given category and title regime. So regardless, basically what we're saying here is regardless of storm direction, regardless of storm speed, the mom is a worst case scenario or what we expect to happen. And that may be all you've got for a couple of days. In fact, see if I can do this right. So this colored windswath, that's 72 hours.  So those are the moms and meows that you use for mitigation purposes maybe, for drills for working without perfect information or maybe just informing the public, you wanna get out of the way because this is what could happen. And then the operational forecast come out and again, the operational forecast is the same model. They take the actual storm parameters, read them in the model and calculate what the actual damage is going to be. So what I do then is I get that grid and this is a little piece of State Highway 23 down very near the bottom of the Birdfoot Delta. The end of the road is probably not too many miles south of here which would be to the right. And I can subtract the water level elevation in that slosh cell. I can subtract from that the elevation of the road. So on a two year annual cycle, by annual cycle, but on a two year cycle, we go out and we collect road inventory information. As part of that, we get a point every four million miles. That's 21.12 feet. So we have a location and an elevation. We're using real time network, GPS to pull this down. The RTN guys tell, well, it's like kind of golf ball accuracy. Maybe softball for three dimensions. So we've got a pretty good idea what the road elevation is at these points. And then that gives us a basis to calculate the potential flood here. And I don't know how well you can actually see it, but there are red dots on there which are the high end of flooding. It might be a feet, for example. The lighter dots maybe something, I think I put these in quarter foot increments. So the lighter dots are slightly flooded kind of areas. The black dots, by the way, are places that don't show up as a flood. So the storm surge elevation was below the road elevation at those points. And the top map is the 10% exceedance slosh. The bottom map is the 50% exceedance. So you got a 50-50 chance of seeing this. You got a 10% chance of seeing this other one. And a couple of interesting things. I finally figured this out last week, talking to the road inventory guys. I kept looking at, I kept getting values that had like minus 40. There's no place in Louisiana that's 40 feet below sea level. And there's things that are maybe 20 feet. But I realized, I actually have three tunnels. And those are tunnel road elevations. We got a tunnel underneath the Mississippi River south of Louisiana, one just upstream and one over in Holma. And I just thought those were errors in the data. So now I can start telling people, well, we got to close it. It doesn't matter, by the way, where it floods on this road. If it floods anywhere, we can't get people through it, right? Oh, and what is a flood? So a flood is, or a road closure criteria, our decision rule. Three inches, right? Three inches. And you start getting more than that and cars start going off the road and you have other problem with getting traffic through. Another really interesting thing is that slosh now includes tide, but it doesn't include wave action, all right? So, you know, wave action, what kind of wave action do you think you get with a storm? Three inches, six inches of foot? So it really means almost any flooding is gonna be closing that road when you throw the wave action thing in. By the way, there's a huge area of research on that topic. So anyway, so that's what I'm looking at, you know, at the detail level. This is the same data on the left, 10 at the top, 50 at the bottom, with our district O2, the entire district, which is our Southeast Louisiana group. On the right-hand side is Buris. My sample came from up on the left, right-hand side of that. So this is kind of the local community Buris during Katrina was an urban cluster in the US Census data. That was what, 2005? In 2010, it wasn't anymore. I mean, it just wiped through there and took things out. I drove through that area in maybe October of 2005, and there were trucks up in trees and boats and houses in the middle of the road. You had to go around them out in the field someplace. It was pretty amazing to see what happened from the storm surge. All right, so what are some of the issues? Timing is a real big issue. So I know how high it's gonna flood in this six-hour window, right? But I don't know when that's gonna happen. And two, three, four, five hours of lead time on when I have to close a road and evacuation route in particular, could be very important. This is just not in the data. It's not available. So timing is an issue. Again, the forecast comes out every six hours from the hurricane center, and then the storm surge guys start working on that forecast and in about an hour, they deliver the slosh products. So there's a little lag in that. There are some other issues with the data. So the way they communicate the data to the public, so when you're listening to the weather channel or your local weather guys, they're all reading the same data by the way, right, from the weather service. They may employ some commercial models too, who knows. But they're looking at all this stuff, and what they're being told is there's this above ground thing, okay? So the hurricane center decided a few years ago that people don't understand of storm surge flooding from water levels, right? And, but they would understand above ground level. Well, the problem with above ground level is you're reporting depth, okay? So the water surface is fairly well behaved over fairly large area. These cells could be thousands of meters, but the land underneath them have a lot of terrain, right? The second derivative of elevation underneath them is fairly high. And that causes in these AGL above ground level numbers situation where if you're in a local high spot, it way overestimates your risk. If you're in a local low spot, it way underestirates your risk. So you still gotta know where you are sort of in a relative sense in whatever grid cell you're in, which the public doesn't know that. The public can know, by the way, and a lot of them in Louisiana do, what their base flood elevation is, what their slab elevation, what their house elevation is. So giving them elevation in my opinion is more useful. And it's in my case, I can't use a depth. There's no way to back out the water level elevation and run it against my road points. So I pull down the water level elevation directly and I use that. Another issue I think is this concept of 10% exceedance. I don't know how the public really interprets that. It really does mean that 90% of their simulations were below that. And that's, how does the public understand that? Now, 50-50, and I talked to our engineers about this when we decided how we're gonna use these data. I said, well, let's look at the 50-50 because depending on your loss function and depending on your risk aversion and whatever kind of stuff, if there's a 50-50 chance that this thing is gonna be at this level, then people understand making that decision. The engineers kind of got that. And we look at both. The Hurricane Center guys call that 90%, the 10% exceedance value, maximum regret. And their interest is in trying to get people to be motivated to evacuate. So they wanna give them a high value. I understand that. But these are just some of the issues that happened with the storm surge data. So let's talk about the flood of 2016. And I'll apologize for not really getting what I would have liked to with this, but this is the Lake Pontchartrain Basin. It's got this kind of conehead top over on the northwest side. It's bordered on the west by the Mississippi River. Okay, so the Mississippi River levee starts in Baton Rouge and goes all the way to the south. From Baton Rouge north, there's a bluff, actually, that everything in this diagram on the Mississippi River flows to the east and into Lake Marpar Lake Pontchartrain and then out to the Gulf. A lot of people don't understand that. We're looking at hydrologic unit code level 12 basin delineations, local watersheds. They're called sub-watersheds. And in those sub-watersheds, the HUC system is kind of a hierarchy of things. So each of these belong to a watershed, which belongs to a sub-basin, which belongs to a basin, which belongs to a sub-region, belongs to a region. So the region here actually starts at the Mississippi River and I think goes all the way to Virginia or something. That's the south region. The region on the other side of the Mississippi River goes all the way to Mexico. That's the Texas Gulf region. And the rest of you guys, the 42% of the United States that is upstream from Louisiana, that just comes down between those two little levees and you pretty much keep them in there. There's no interaction. Actually, they're trying to use Mississippi water through coastal restoration processes. They'll siphon out water with sediment in it and try to re-nourish the marsh with it. That little, thin piece of thing between the levees really doesn't interact at all with the local hydrology. So let's talk about this watershed. So Baton Rouge is kind of over here on the left-hand side in the middle. I-10 and I-12 kind of come across the middle of this thing. They built I-10 and I-12, mostly to stay way above like coastal flooding elevations. Although, because interstates were required to go through major cities, they had to dip I-10 down into New Orleans and back up. Most of I-10 is actually on a bridge in the New Orleans area. Not hardly anything's that great. The ones that are get flooded. So this is the basic hydrologic layout. You really can't see what's going on here very well. So let's go to the next slide. So in this slide, I've gone to the next level up in the hydrologic units, the HUC-10 level. So each of these HUC-12 sub-watersheds are now colored by the watershed that they belong to. And you can kind of see here now that there's a sort of a drainage pattern on the far left side. And we kind of stripe our way down through that sort of conical upper part of the watershed in a North-South sort of fashion. And then we start at some point moving to the East. And this is part of what caused the flood. Okay, the 2016 flood, I don't know how many people said, oh, they never flooded here. We, well, I've lived here for 50 years and we never had a flood. We lost something like, you know, 60,000 vehicles because people saw water in their yards. By the time they got the stuff together, the car was flooded and they couldn't get out. It was a fast-moving flood. It came from all directions. One of the most amazing things is on one of these basin boundaries, one of my friends lives right below the road that he lives on is on the ridge between two basins. It's down towards the Amy River. And this house got flooded downhill. I don't think a flooding coming like that, right? It came over the top of the basin boundary just north of him. His house sits maybe six or eight feet below the road level and it cascaded. He had white water coming over the edge of that into his house and, of course, now he's got flowing type damage. So anyway, so, and this is the sort of geospatial things. Like the arrangement of these things is important. So what happened with the inputs? The inputs were like 35 inches of rain over night kind of stuff. We can't even, we can't even design for a storm that's that big. You couldn't afford to build the highway high enough or the building strong enough or whatever. But what happened is over here on the right-hand side in the Big Bend area of Florida, there was a low pressure system that kind of wandered around the Gulf. Never got a name. It wasn't strong enough to become a tropical storm, even a depression. And then it just kind of sat over there. And my original thought, and this is again where the spatial and temporal stuff comes in. My original thought was when I look at the rainfall patterns on this, what I'm gonna see is this counterclockwise circulation centered around that low that's off sitting over Alabama and just constantly whacking us. There's a really cool site at University, I guess it's Iowa State University, where you can download historical data rainfall in five minute time increments. And then again, we're gonna talk now here about some time things. So what I found when I started animating the rainfall across this basin is the rainfall actually pretty much came in from the Northwest and across to the Southeast.  But remember this drainage pattern. Drainage pattern is these sort of North-South troughs that contain the water within their boundaries until they got down to where they made a left turn to the East and met the backwater flooding coming out of the Amy River and stacked up and then went over the lip of the basin. We just don't see that kind of flooding. I mean, that's just, it was very, very, very odd. The other thing that I thought was really important when I started looking at the precipitation animations was a time step. So if I did an hourly time step, I saw one thing. But if I cranked that baby up and looked at what happened every five minutes, what I was seeing was these big red things that popped up and maybe only lasted for five or 10 minutes. But those things were raining at just incredible intensities. I went to work on Friday morning, which would have been, I think, the 12th of August and almost got flooded out, getting to work in downtown Baton Rouge. They eventually told us, don't come to work. You know, when you started 6.30, you're at work for everybody else as to make that decision, I guess. So I got a call that evening from the Secretary of the Department of Transportation saying the Weather Service wants to know how high the bridges are on the Amy River and the major rivers on I-12 that come from Slidell. It's kind of a shortcut, so you don't have to do it down to New Orleans on the interstate system, because they think that those things are gonna flood. So I got out my road points and now that's the elevation of the bridge deck. So I had to find an engineer that could tell me, you know, what's the bottom? Take about six feet off of those and that'll be the bottom of the bridge. Well, there's a gauge right upstream on the Amy River from where I-12 crosses. That gauge, I think, got up to 46 feet. The bridge, the bottom of the bridge was 29 feet, okay? But remember, we're talking about a riverine flood. That bridge never flooded. And the Under Secretary, the decision maker people at DOT kept saying, you need to do me an inundation map. I can't do an inundation map in a riverine flooding situation without a model. I have to contain that stuff within the basin boundary and I have to know the elevations along the sides and it's not just a 2D thing. So I guess I don't talk with those guys much anymore. So here's a cool thing I did. There's a product in the ESRI suite of products called Schematics. And I actually did this a number of years ago. The watershed boundary data set tells you what watershed you flow into. So I can build this flow network and I can actually visualize things this way that you can't by looking at this kind of a representation and certainly not over here, right? You can't tell what goes where. You can kind of get an idea this way. But when I build that schematic, that flow diagram, if you will, I can know where everything flows. In fact, it was amazing to me. I lived in Baton Rouge for 20 years and I didn't realize that almost all of the things that go into Lake Pontchartrain go through Lake Marlpov first. Nice little settling basin. But you can also then create a schematic that's more of like an engineering diagram of this network. And you can see where these points are correlated in between the geographic schematic on the map and the engineering diagram, let's call it on the right, and where those basic choke points are. And those are the kind of, we talked about visualization. These are maybe some of the tools that we could use to identify places that are gonna be important in a hydrologic event like we had in Louisiana. So time was a big issue. And again, just visualizing things. I didn't see the red spots like I saw. I didn't see them at one hour time steps like I saw them at five minute time steps. So, we need to understand some of those concepts. So this is actually the diagram in a little better, little bigger picture. So you can, for purposes of say flood routing or maybe the local floodplain manager or something or other, you can get an idea. And of course, actually you can put the gauges so you can identify where gauges are along this network. One of the cool things on the network is within the ArcGIS platform, you can actually trace things upstream and downstream. So it has the topology built into it. And I believe that is it. Thank you, Jim, for this very nice and technical account. Somehow it was very important to link it to modeling and everything because there's a lot of stuff we just assume in our models but we can't really test them in a context like this. But I probably should have had a concluding slide that said, and this occurred to me in one of the breakouts yesterday is, you know what, we've got a whole lot of hind casting we can do, right? We can go back to these different events and look at the historical record and say, doing an expected value of perfect information kind of analysis. If I'd have known at this point in time what it really did other than what I knew before we got to that point in time but I made a different decision. And then talk about the things we need to make those decisions. I think something like this could be a use case almost like a benchmark study to see with different models, do we get this right or not? I would be very surprised to see that we get this right but we could learn a lot of lessons. For instance, how is, when you get this above ground elevation on the roads you actually need to count also for maybe the rack points are moving to the black points and you can only do that as Jim pointed out to the, or 3D, I don't know, model. You know, another, in the GIS business I've developed some concepts over the years which was three rules of GIS. The first one is everything you know is wrong, right? And that's because everything we do is a model, right? It's not reality. So we have to accept the fact that we've modeled reality and that there's some fuzz in there that we can't account for. So don't think of your boundary lines, your grid, your soil polygons, all these things as being perfectly located because they're not, don't even think about it. Any quick questions like one or two we can take before others introduce crack? Oh, no, we get another one. Nope, yes? Specifically for the storm surge. Well, okay, I'm monitoring gauges all the time. I've put together some, actually there are RGS online story maps that you can look at current gauge information. So I'm looking at those where that comes in handy. We have had issues and I think this is important to bring out because we've talked about the credibility of what the information we're trying to communicate. We've had some issues in past storms where like the LSU guys that run an ADCERC model they wanna get their model on the table and they wanna make decisions. It turned out that their forecasts were really pretty bad. But, and you don't want people doing unauthoritative forecasts and sending them out to the public. In this case it was even worse because it was going to the governor and the emergency operations guys. And it just confuses them. And I think another thing is we talk about storm surge, expected flooding above normally dry land. So what does that mean? I think people would really rather hear a decision than a data point. It get out now, because we think you're gonna flood really bad. Rather than, well the water's gonna be 10 feet there. Coming back to the communication issue that was pointed out so many times doing this. Any more question? Yes, the last one, yes. That's absolutely true. Keep in mind that NOAA does the storm surge stuff and the USGS or the weather service. So there's some of those kind of issues. If you know anything about NOAA it's a very compartmentalized thing, right? There's guys that do the track. There's guys that do the strength. There's the guys that do whatever. And they're different people. And they kind of, I don't know I have this vision that when they set an advisor out they all kind of come together and say, well let's do this, let's do this. But trying to deal with flooding coming out of the gauging system and combining that with the storm surge that's a real difficult problem. Always figured it out. Thank you. I think we better move on to keep it in time. So thank you, Jim. Albert, do you want to? So it's the important thing to think about.


Firstly, I'd like to say thank you for allowing me to present today. My name is Alexander, I'm Alex, and today I'll be talking about just in time Python, FAS, functions as a service platforms with Unicraft, and the premise of this talk essentially is, actually a little bit about me, I'm a PhD student at Lancash University was just over the channel in the UK, co-founder and maintainer of an open source project Unicraft. Occasional Twitter, so I use Twitter, I'm also on GitHub naturally and professional, so I have LinkedIn. But the premise of today's talk and to get into how Python is involved in everything here and how functions as a service is developing into the 21st century and how things are looking in today is that higher cluster utilization and with decreased operational expenditure. So basically, to break this down, you know, we want to spend less to do more. We want to run, you know, our microservices in the cloud, we want that to be cheap, we want to be able to run more of those same services on maybe less hardware. We want to use less physical resources, less virtual resources. And so, and this is I think a pretty common theme, I think we can all sort of agree on this idea and this topic and we can try and find and see a lot of things that are moving in that direction. In sort of the developer space. So that's kind of the premise of today's talk and I'm going to go into how we can achieve this with one strategy for the cloud, which is today's talk. So let's talk about the bloke problem that applications have in the cloud. And the problem is that you have your application that you want to put into the cloud or you want to run an edge service or something. And it's comprised of your Python app, but it's also comprised of the Python runtime, the container runtime, if you're running things with containers, it could also just be the process manager of the operating system. And it can't quite see it, but it does say operating system underneath. But yeah, so you have a very big stack actually. And if you've built an application and you're using libraries, whatever, you usually have a good idea of what are in those libraries. Or at least the functionality that's going to be occurring in your application, which means that there are actually quite a lot of things in the typical deployment that aren't actually being used. Right? For example, you might never actually use SSL in your application. Not that you should, you probably should, but you get the premise you might not be doing an encryption type function within the application that you're building. It applies to any other type of operation, but encryption or all these other sort of standard applications or libraries that you might be aware of or might want to use would still be available in most deployment scenarios. And they're typically also very much available within the kernel, within the operating system, right? The shared libraries are almost always there. And the kernel almost always has functionality that's part of that system that you just can't really remove. So when you look of your actual application, it's doing what you want. Great, fantastic. But it's not doing other things, which it could do, but there are libraries there that are on being unused. And this is actually part of this premise, right? This is a problem with the cloud is that you want to get more use out of the hardware and the virtual resources that you're trying to run, but you're actually packaging in other things that you don't need. So here is an example of how we can try and remove these things. So today I'm going to talk about how we can do that in one way to approach this problem. So this is where I get to introduce you Unicernals. This is something that I've been researching for a while, something that I work on pretty much every single day. It's an amazing sort of technology that I really believe in, and I very honoured today to be able to introduce you to the topic. Maybe you've heard of it before, but if you haven't, I'm very honoured to be able to tell you about it. And so the Unicernal model is a sort of idea of looking at the full stack of your system, right? So if you think about your application at the top, this application has third-party libraries that you are aware of, you know, Python, you're importing things. Those are those libraries, but there are also libraries within the operating system itself. These are shared objects, so like lib as a cell or anything else. And then you have the monolithic kernel underneath that facilitates the runtime of everything else, including your application, but also maybe other applications or other runtimes, etc. And then this finally then sits on top of a platform, so this is like a hypervisor, or if it's deployed in the clouds, or it could be XAN, it could be KVM. And then that finally sits on top of hardware. So we look at this whole model, and we break it down, because when we break it down and we introduce this idea of a library operating system, we can then start to pick and choose exactly what we want to run into. And this is what a Unicernal is. So you take all the different components that you do need, and not the ones that you don't need, right? And through a process of compiling it, linking, etc., through this build process, you get a Unicernal. And a Unicernal is this bespoke image, is a bespoke in the context of a cloud, is a virtual machine, and you can also deploy it as an edge. You can put it on a Raspberry Pi, for example, and then that Raspberry Pi would only ever do that one thing. But it only has the application-specific libraries, the kernel-specific libraries. It's targeted directly for that platform, and it has only the code that's necessary to run on that particular piece of hardware. Which is the case that actually most kernels might usually get architecture-specific kernel binary images, but usually they have additional code in there to allow for different platform runtimes. Okay, so this is the kind of model that Unicraft offers. And so maybe go through some of the key characteristics of Unicernals. So there are a form of compile-time specialisation, meaning that you can think of it like through the DevOps pipeline, where you have your application and you're bundling it with PIP and you're getting ever all the dependencies. Finally, you're building it and the output is the final kernel image, right? You're not taking that image and then shipping it and then putting on top of something else. It is the final artefact in the sense that it is going to be running as a virtual machine. They're very lightweight. I'm going to get into a little bit later about how lightweight they are using comparisons. I have a unique property of having a single shared address space. So in most monolithic kernels, user space and kernel space are two different spaces that result in checks for privileges. Do I have the permission to read this file, for example? This is a check because they are part of two different memory address spaces. In the context of the Unicernal, this is one of the same because you know that your application is wanting to read that file, for example, or is wanting to perform this particular type of operation. It is allowed to do that because it has been bundled together. So there are no syscalls. A syscall is open, a socket, a close, etc. These are usually a barrier, a check that performs, I think it's around 300 CPU cycles, of just like can this user space program do exactly, yes, okay, can it, not, whatever, it returns an error or doesn't, and then continues. Because this syscall is now a function call, it's like four CPU cycles. It just hops to the functionality that it needs to go to. It has no other functionality that is not necessary, right? And there are no daemons that are running in the background, no system libraries, and there's no SSH, for example. So a big attack vector for a lot of virtual machines is that SSH is just left open, for example. So these are some of the characteristics of Unicernals, naturally platform, hardware specific. Unicraft, which I'd like to talk to you today about, is a library operating system and a Unicernal development kit. It's open source. You can find it at Unicraft.org. We're also on GitHub. Please do check it out. And we have a lot of CLI tooling that is written in Python, so hopefully it can fit in the theme of what this conference is all about.  So we have quite a good sitting in the community as well. To talk about the community, Unicraft has a foot in a lot of academic institutes. So we do publications once in a while that do a lot of measurements and explore certain properties within the library operating system model. And some of these are the partners as well, the university partners, where you can see the methodology and like why we're approaching library operating systems in the way that we are. And I think every time that we've had a paper that has had sort of experiments in it, those experiments are also open source. So you can check them out on GitHub. You can run the same experiments and see how they're formed and why we're getting, when we do comparisons, the same or different or better. A performance of security, et cetera. We have quite a big active community of contributors and sort of constantly on a day-to-day basis we're like seeing new contributions and sometimes people add amazing new features out of the blue. So it's really amazing to watch. And we've been sort of steadily growing over time. So if you could start us on GitHub, this would make this chart better, please. Yeah, okay. We also have a very good Discord. Community is very active and there's also a lot of conceptual channels. So if you're into operating system stuff, there's a lot of students on there and professors are also mentoring who have a lot of experience. And so we talk about sort of how best to implement, for example, a particular internal library, a lot of stuff going on at the moment, for example, S&P, what are good abstractions for S&P that are platform independent. It's really amazing to watch, but this is our Discord channel. Okay, so the next few sets of slides are basically to do with like to show how Unicraft compares to other existing technologies. So Unicraft has provided better performance compared to other implementations of Unicrinal projects. There are several others that exist that we are aware of that are basically, they also, you know, they have their own unique ways to approach the problem of the library operating system. But this graphic also shows a comparison against Linux and Linux. So this is bare metal Linux, just sort of a user space. In this case, it's Nginx that we're running on Linux and then we just perform a throughput and a latency test on Nginx. So we run it on Linux, then we run it inside a virtual machine and we also try different implementations of platforms. We also have Firecracker on there. When it comes to memory consumption and storage, because you're only using the minimum amount of resources that are actually necessary to run your application, we find that there are much less, you know, we can use a lot less resources to run the same application. And so compared to Docker and compared to Linux as a micro-VM, right, you have to actually use, we really tried to squeeze it, right. We tried to make the minimum amount of resources possible. So we really deleted things with inside Linux, for example, to try and make sure that we weren't trying to make the experiment as fair as possible. And because it's such a well-defined, well-compiled source and the resulting artifact is very minimal and very lean, we can sort of get quite good memory consumption. And here we do a comparison. You can just see if you pull the official Docker image for Python, the same version as well. The official one is like 335 megabytes. And then trying to be fair, I pulled the Alpine version for the latest. There's 27 megabytes, but we have, when you compile Python, sort of the Python interpreter, and then you compile that against Unicraft, the final image, including the file system that contains the same Hello World programme and all of the standard libraries that are inside of Python. The final result is 5.2 megabytes. So part of our team really love diving into trying to make things performance. And this is the latest result that they were able to get. This was NGINX, but they were able to show P99.99, like latency, which is absolutely crazy. I've never seen it before, comparing Unicraft with Linux and to show that this is sort of... I don't think the lines are showing up, but it's like between 5 and 2 milliseconds is the difference between Linux and Unicraft. Comparing virtual machine monitors, and so Camu Solo 5, which is sort of historically a Unicurnal virtual machine monitor, recently Firecracker as well, comparing the boot time of a guest image that it comes from. And this is just Unicraft. We've seen as low as 3.1 milliseconds booting the virtual machine image on these virtual machine monitors, or via these virtual machine monitors. So if you tune your Unicurnal to a specific way, you can really exploit, for example, not having to initialise so much memory, you can do it statically if you know you're only going to use sort of much amount of memory, which means that you don't have to preemptively do things. And because there's no system D, for example, there's no initialisation of additional services, it boots straight to main. Okay, so because we're a library operating system, and because there are a lot of libraries within the library operating system, there's a lot of optimisations that you can tweak and do throughout the place. So you can choose different settings within different libraries to exploit, for example, the use case that you're trying to use for your application. And a couple of, like, default high-level optimisation techniques you can run on Unicraft, or link time optimisation, dead code elimination, dead code elimination, and even combining them. And you can see that we can even reduce the image size further. So which means if you're, like, transporting the image across a data centre, it's much less throughput on the wire. Because you're not bundling a lot of additional services, whether it's in the Docker container or the virtual machine, because it's a Unicraft and you don't have any of these other stuff, you have a much smaller reduced attack surface.  There's no background processes, there are no additional ports that you wouldn't be aware of. Because there are none of this, the attack surface is much smaller. But because you're dealing directly with the kernel and your application is sitting on top and you're tightly coupling the two, and because they're bundled together, you can exploit a lot of additional security properties. For example, address-based layer randomisation, arguably as well, because if you do use virtual machines and you do run things as a virtual machine, you're exploiting the lowest level of virtualisation. So this is sort of deemed the most secure privilege. Usually when you see deployments in the cloud, containers are usually deployed on top of a virtual machine anyway. And so the virtual machine still sort of represents the unit of security that is sort of experienced within infrastructure service providers. As a project we also have a whole bunch of other security implementations that are being worked on at the moment. So this is a sort of a listed example. It's actually a little bit out of date, I just took a screenshot from our documentation. Several of these have made their way to become upstream. And we're constantly seeing new different ways to increase the security of the project basically. So what is Unicraft support? Naturally Python actually was one of the very first applications that we got running on Unicraft. But we support a whole bunch of other languages and libraries and applications. And actually this list is not exhaustive because we're binary compatible. So if you have a binary compatible, if you have built something in Linux that is a binary, you can actually just load that into Unicraft and it will do jump call between instructions. So this is how it sort of talks to the kernel. We also support a number of different libsies. So we have a built-in libc called noLibc which is like the minimal amount of libc we found to get a kernel running. And then we support out-of-the-box Zen and KVM and then as well as Arch. I'm actually arm these are the sort of the built-in. If you clone the repo, this is what you get out of default. This is what you can configure. But as a sort of larger ecosystem, we support NewLib. We have arm out-of-the-box, but muscle. We're going to have muscle as a libc. This should be, I think, in September. So in about two months, we'll have muscle support. And this basically opens the door for a lot of things for us because it's a lot simpler and nicer implementation, at least in our opinion. And then we have ongoing support for the busy being built at the moment, Hyper-V and RISC-5. So you can see here, we have some screenshots of Unicraft booting and running on Hyper-V on VMware. And then out-of-the-blue open-source contributor came out and was like, hey, I made RISC-5. It was just like, awesome. Okay, cool. So that's that. And you can run it, of course, on a Raspberry Pi and other. You just build this as an abstract interface you can build against any hardware platform. So with regard to integration, so we have a number of different toolings and ways that you might think, okay, look, it's a kernel. How do I work with a kernel? This is out of the breadth of my gamut, et cetera. But we have tools and services that can make things much easier so that it doesn't seem so scary. I know that when I started, I was like, oh my God, what am I doing as a kernel? So we have, first of all, VS Code, VS Code integration. And basically here, you can already search for it on the VS Code marketplace, where you then sort of load it up and when you're building a project, you can then see on the side the libraries that you might want to add to your kernel, to your unique kernel, right? So on the explorer side here, it will load up and show all the different libraries that have been loaded. And these are like third-party libraries that you might necessarily need. So if you're importing something from PIP, and it says, maybe you've done PIP before, it's like, oh, I'm missing this thing, so you do apt-get install, whatever dev, headers, this is the equivalent, but through VS Code. I'll skip through this due to time. So our main tool is called Kraft. This is written in Python. Not only is it a CLI tool, but it's also like an API, so you can import it and you can build Unicernals sort of programmatically. It allows you to manage multiple libraries from different sources, whether they're getRepos, et cetera, manage the versions, et cetera. You define your Unicernal through a specification file, a YAML file, that just says, look, I want to target x86 on KVM, and these are the libraries that I need. Most likely you'll need newlib, Lwip. These are sort of standard libraries for Lipsy and networking.  In fact, I can even quickly show you with a short demo. Here I have a Python application. It's a Kraft file that you see here, and then I have a file system that I've made through virtual AMP. So if I tree FS0, right then to this, you'll just see that you'll have Activate, et cetera, you have the pip binary. Here I have my Hello World Pi program, and then sort of all the standard things that have come through pip, et cetera. And then I can do Kraft menu config. This is when Kraft's installed, and then it opens up something like this. If you've ever built a Unicernal, it looks a little bit similar. It's a very simple sort of terminal user interface.  And down here I can even go down and customize the Python 3 build itself. So I can choose whichever extensions I would like. And then it's just a case of Kraft build. Or maybe I should show you what the Kraft file looks like. So here I just sort of specify config options, sort of things I would like. If you follow the tutorial, it's all out of the blue, out of the repo on the readme, you'll be able to see it's just a couple of installs, or like CLI calls. And then this is all there already. I've just kind of done a fresh clone. You do Kraft build. Or maybe I should do it fast. You'd never saw that. That's because I did control C. And then it just sort of zips through and just compiles all the stuff. So these are all the libraries that I needed to build Python 3 as a unicranol. And then I should pop a binary. And then a binary you should be able to boot as a virtual machine. So here it's just linking, linking the extensions. Can you guess it's like a shell script that is part of the install. If you do pip3 install on the Kraft repo, it will be installed as well because it's part of the setup tools. Then I'm just pointing to the kernel. So dash k, I'm passing in a file system.  I'm giving it 128 megs of RAM. And then I'm saying hello world is my mate, like my first positional argument is like hello world.py. So if I, well that was boot. So now it's booting from a ROM, there's unicranol and this is hello world. So I can then just change this for example, hello world. Or if I do the same thing, you'll see it there. Yay, okay. So yeah, so this is just the installation of dependencies that you need to get everything to run. This is part of the tutorial on the documentation. And there's just pip3 to get this as sort of the repo where Kraft exists. I'll skip through this. So we also have Kubernetes integration. It's something I wanted to get into. This is what this functions as a service comes to. And I'd like to talk about another one of these sort of problems with the number of abstractions that you see in typical deployment. So this is a typical function as a service deployment with openfaz where you have and with Kubernetes through faznetes. And so you have the system, two system pods that are mingling on top of container D. Then you have a faz namespace that's mingling on container D. And then you have fazD which is a binary that invokes the different functions that you would like to run. And so here, this is how the request comes in and sort of jumps through all these different services. And the problem here is that we have all these levels of virtualisation. You're sitting at the hypervisor, you've then got the OS on top of that, the OS is managing all the... It's not just managing container D, fazD is also managing SSHD, etc. Container D, fazD, whatever, they're managing things on top of this. And then inside of your service, ultimately you might even be managing more stuff. So there's lots of levels of virtualisation here, lots of abstraction, lots of slowness, right? The performance might not be so good because you're sort of going all the way up. So if you can run something as a virtual machine on top of the hypervisor, right? You're going to be using a lot less resource. So if you close it to the metal, you're going to be providing better service, quality of service. I'll skip this if it lets me. Yeah, okay, cool. Prometheus, I wanted to show that we, as a kernel, we have integration with Prometheus so you can see the runtime of your services. Building this as a library as part of the deployment. And then debugability. As a kernel, you might think, okay, wow, okay, how do you debug a kernel? Well, you can do printf just like any other programming language inside of the kernel. So there's some nice debugging libraries that you can sort of enable. So in that menu config that I showed you before in the terminal, you just go to the debug stuff and enable all the debugging stuff and then you start to see lots of verbose messaging as you boot stuff. And you can even enable unit testing, which we have inside of the kernel. And you can also do profiling. So we have a number of tools that allow you to see the runtime of your application on top of the runtime of the kernel. So you can see which system calls are being run on there as well. Yeah, I think that's about it. This is the Unicraft project. Thank you so much for listening. I'll take any questions. I was told to say that the mic is over here if you have any questions. Thank you. That was a really great talk and a really great tool. So my question is, because I wasn't the first part of the talk, but my question is, so is there actually a difference between user space and kernel space as in usual OS? No, there's no separation. So this means everything runs in kernel space, right? That's right, yes. Okay, so how do you leverage things like ASLR? Are you just basically putting things randomly in memory? I mean, as it's usual with your ASLR? So with ASLR, it's done at compile time, where we understand the application. In this case, it would be the Python 3 interpreter and the rest of the kernel, and this is where it occurred. So is there some actual ASLR that is going on when you boot the application? Or is it like once it's compiled, whenever you deploy it, the other systems are all the same? So it's a really good question. This is current ongoing. It's best to have a conversation offline about this. Cool, thanks. Hi. I've seen you mentioned other new girls. I wondered if you compared it to Gromine, which used to be Gromine. Oh, GralVM? Gromine, no, we haven't. And if you have ever considered using, well, for security purposes, the SGX enclaves. Yes, so we have a Google summer of code student working on enclaves right now. Cool, yeah. Hello, a great talk, very interesting. So in the demo you showed that you were editing the Python file and running without the company. Yes. In which case do you need to recompile the... So you don't have to recompile the kernel to get... So what I did there was I have 9PFS. 9PFS is sort of a network protocol that then talks to the host. And so it basically it read through a network protocol a mounted volume that was the file system. There are other ways to make that file system available to the kernel. For example through initRAM. And so I could package that file system that you saw that had the helloworld.py program as an initRAM file. I would then boot that as the initRAM. But there are other ways to do it. You could also package the initRAM with the kernel into like a QCOW2 image, or actually we have ongoing work to make this available as OCI archive. So it's compatible with the rest of the sort of Kubernetes and container space. And we have a tool that makes this possible where it looks like a container. It feels like a container, but actually it's a unique kernel. And we'll be releasing more of these tools in September open source. All right, thanks. All right, thank you. Thank you so much. Thank you.


Welcome to JSA TV and JSA podcasts, the newsroom for telecom and data center professionals. I'm Barb Mitchell coming to you today from Data Cloud 2022 here in beautiful Monaco. And joining me is Michael Wall, SVP of construction and development for Europe for Prime Data Centers. Michael, thank you so much for joining us. Good morning, thank you for inviting me. It's great to be here right in person at Data Cloud 2022, I think record attendees at this year's conference and everyone's very excited. For those of our viewers who may not know you, I think we know you well here at JSA, but for our viewers who may not have had the opportunity, can you tell us a little bit about Prime Data Centers? Yes, so Prime Data Centers is a data center provider on both wholesale and hyperscale. We formed in U.S. in 2017 and we've seen our first building was in Sacramento. We've seen some amazing growth in the U.S. around Silicon Valley. That was probably our niche market, our core market. And we now expanded last year and now we're seeing a very big trajectory this year in the U.S. So yeah, that's Prime in a nutshell. Yeah, and I mean, exciting things happening, I think at Prime, I had the opportunity to see you on stage the other night as the proud recipient of the Data Cloud Global Awards, Regional Data Center Excellence for the Americas. So congratulations, first of all, on that. Can you tell us a little bit about what led to that award? Yeah, so many thanks. We're very proud to have received that reward. We were happy also to be on the short list.  From our perspective, for a particular project that we had in the U.S., which was on a very short delivery period, which had some manufacturing or delivery issues, which we were able to absorb and still deliver the project on time was a great achievement for the team. And now to be rewarded for it, I mean, we're super happy. So thank you very much. Yeah, congratulations. It is a huge honor and well deserved, I think. And so you mentioned earlier, just some of the expansions that have been taking place in the United States. I know that you mentioned California, but I think you've expanded into other markets to support the hyperscale customers. Can you talk about that? Yeah, so we have a large facility in Chicago, which we were brought out into the news. We have some more projects in the pipeline, similar sizes, similar type of locations. But we're now looking to, within the next couple of weeks, to be releasing into Europe. So I think about three weeks time, maybe a month, we'll be launching our first facility in Europe. So we're really excited for the growth that we're seeing. Yeah, on that note, I was gonna ask, I mean, maybe you've answered it, right? But I was gonna ask, you know, what is, what are you most excited about as you think about sort of the second half, we're already, I guess, looking towards the second half of 2022 and beyond, what are you most excited about? Well, what's there not to be excited about in this industry? I mean, it's an amazing industry. I've been involved in it for 20 years. I've never seen anything like I've seen at the moment. The, you know, growing with customers, just the volume that we're seeing. I mean, we're gonna concentrate on, on Americas and Europe this year, this year. And then we'll look at other markets, but that will be based on client growth. So we won't speculate, but we will grow in other markets in the future. Fantastic, we look forward to hearing all about it. And thank you, Michael, for joining us today on this last day of Data Cloud 2022. We appreciate your time. And thank you viewers for tuning in to JSA TV and JSA Podcasts. Happy networking. Thank you.


Tom here from Lauren systems and unified network application version 7.376 was released just a couple weeks ago today Is December 7th of 2022 and because I've been running it a bit I wanted to follow up and do a review on it now What I won't be reviewing is some of the new VPN features because I still don't recommend the unify routing devices and A lot of people seem to be a little upset by this as I can read through the forums and see lots of Upset unify dream machine pro users and that's because a lot of these new features that are mentioned in here Which will go over briefly like the updated VPN support which technically would make my video where I said Unify has a weird way of making VPNs that video is linked down below They only updated the unified dream machine SE to get these new features So if you have a unified dream machine pro, which is really not that old of a product here in 2022 It's only a few years old It sounds like these features may not be coming to you because they're not going to go to the 3.0 unify OS with the older dream machines now if someone can find a link to prove me wrong Please leave it in the comments or let me know how to find it But after some searching I just keep finding posts on reddit and inner forms or people who seem to be quite aggravated that They're dream machines that are not the SE version Don't appear to be able to get any of these updates now They can get the new network application version 7.376 They just don't get any of the new VPN features and some of the things that well are the reasons why I don't really recommend any of the unify routing devices so I wanted to throw that out there in the beginning and mostly what I'm be focusing on is how we use it as a Self-hosted multi-site controller and how we manage our clients with it Which is going to include the APs and switches I have a few other videos where I've kind of discussed this and I also have a tutorial Because the big requirement for 7.3.76 is the Java 11 And that's why I made an install video to show you how to install the self-hosted controller either setting it up fresh Or if you want to restore from backup But basically I recommend Following that video before you do an update or read through the forums There's ways you can remove the old Java version and then install the new Java version and update There's a few files you have to delete Which is why I made a much simpler shorter video of just reinstall restore from backup and all your settings should be good now before We dive into the details video. Let's first are you an individual or company looking for support on a network engineering storage or Virtualization project is your company or internal IT team looking for someone to proactively monitor your system security Or offer strategic guidance to keep your IT systems operating smoothly Not only would we love to help consulting your project We also offer fully managed or co-managed IT service plans for businesses in need of IT administration or IT teams in need of additional support With our expert install team We can also assist you with all of your structure cabling and Wi-Fi planning projects If any of this piques your interest fill out our hire us form at Lawrence systems comm so we can start crafting a solution That works for you if you're not interested in hiring us, but you're looking for other ways you want to support this channel There's affiliate links down below to get your deals and discounts on products and services We talk about on this channel and now back to our content Now let's start here with the release notes for a unified network application 7.3.76 and they do have a note right here about not upgrading the UDM UDM Pro running Unify OS 1.12 and older. This is because of an upcoming migration from Unify OS 1.12 to 2.4. Please note They didn't say to the version 3 as I noted earlier But this is another thing if you're using the older Cloud key the first gen cloud keys those are now a dropped and I think they should have been dropped before you even went to 7 There's people may have a debate about that, but those things are really slow They've been around for a long time So I think they had a good life and a good run, but their time has come and they're just a little bit too slow and not powerful enough to Really host and run this application now if we start scrolling down here the Things we'll talk about in a second will be in the UI changes But this is also where you do require if you're using the SC that Unify OS 3.0 This is that reference I made earlier about the new VPN features that there are a highlight of this for their routing equipment are Exclusive to things that are running the Unify OS 3.0 as in the unified dream machine I see currently if I'm not mistaken it also rules out their USG line as well because it also doesn't run the Unify OS 3.0 Now there's a long list here And I'll leave this list for you to read through but let's actually talk about what it looks like now One of the first things I noticed when we switch to the new version is this I'm gonna blur out my client names in here But they made this what's just a nicer scroll So you when you go up and down for the sites instead of them just kind of Spanning the screen and they do have the search here so we can switch pretty quickly For example right to my house and it's just a little bit faster a little bit snappier after I updated it Maybe that was like that from a previous version for the speed But overall it's it made a nice little bit enhancement to the UI here the next thing we're gonna talk about is going over to settings And they have a restore defaults right here me zoom in Restore defaults now the restore defaults is something we end up doing quite a bit for people Unify giving people a lot of knobs to turn and a lot of options to change frequently means the installation problem They run into is a non-default setting for reasons. I'm not really clear someone in some forum said Hey, if you turn all these knobs it will well fix it or make things faster not everything needs to necessarily be tuned So this is nice when you're not sure what you did you goofed around with settings You can just click the restore defaults and put everything back to a default setting And one of the other changes they made is over here in the client listing So we're gonna search for one of the clients here like Brett desktop We find the results we can click on it And then we can look at the insights and the insights will tell you Brett desktop has connected to default default network Is what it's referring to this will also work for Wi-Fi devices also gives you a pivot point here for Seeing all and this is another change she made so here's a list of actually all the different devices as they've kind of moved Around or connected and disconnected from different networks or different wireless I like the way each one of these let you pivot so we can say this device has roamed from LTS office 6 to the hallway LCR and you can click on any of these and will bring you to that point So they just made a lot of nice little UI changes to make this more convenient So if we go here back to the Brett desktop or like Pi KVM is right here if we look over here to the Pi KVM It brings us right to the device It leaves the last search.  Here's all the connected disconnects from that particular device This is actually really nice in terms of UI elements being all connected to make it easy to go back and forth To find each thing you're trying to trace out or when you only have this Maybe you want to start building a list of what it is and what device this may be I may not know the name of it yet, but this kind of gives you some of the ideas It clearly doesn't want to give up its DNS name or it's not logged in here Now I do use pfSense as my firewall and that is also why some of the DNS information may be missing within the controller itself Because it's not using one of the unifier routing devices, but nonetheless. It's nice that they've Built these issues built these in so I can go through and look at what's connected to each device and kind of get a quick History of any of those devices or clients that were connected to them now going back over here to system logs You can also see critical updates that are in there admin activities that were done and who did them client and access point and the access point logs to tell you what channels were changed because I Have it on an auto scan So it's going to say the system has moved from channel 112 to channel 100 to avoid detected interference I leave these on with the auto and I haven't had a problem But nonetheless, I like the fact that it does offer this insight so you can see what's going on and what was changed in there And then of course correlate that to any other logs You may have for people experiencing problems the next let's go over here to system settings to system advanced And we want to have the debugging tools now the debugging tools are the terminal connections So I want those on and for some reason those somehow got turned off through one of the updates And it was also moved to here I remember where that was before but this is where that option is if you want to name your debug terminals be Re-enabled and they've also don't have the debug term anymore where you can just click the IP address I'm not sure when that went away But that was actually one of the things I used to like when they had that as an option You can just click the IP address that would open up a debug terminal I think when they moved to the new UI that went away But if we go to settings we go down here at the bottom We can now click it here and it opens up a debug terminal This is actually really helpful when you're using the controller to be able to get inside of another network and have instant Access to a command line or look at some of the details on any of the vices You can do this. You can actually go into var log go through and look at messages and Dive deeper into something if I need to now generally I push things to assist log server to make that easier But I like the fact that I have access to the debug terminal right here without having to actually SSH into each device If I don't need to now the next change you made is in The way you handle port management with the devices and the switches So if we go here to this flex mini we can look at the ports We can pull up the port manager for the flex mini and then we can see it's connected to port 8 for this device So then we can go port 8 back rack click on ports go back over to port manager and now we're at these ports What if I need to keep tracing where that was up? Well, this is up linked here to the production rack So then we can go over here port manager and now we're at the port manager for the production rack I actually like the way they allow you to pivot to the different switches So if you're trying to sort this out once again This is that UI element enhancement that I'm seeing and this is me not hating anymore on the new UI interface I actually think they finally got it really polished up Well these cross-linking to make resources easily clickable so I can go between Either another switch if I click here or in this case This is actually going to pull up the LTS UN VR Pro that we have so I can actually see the devices that are attached to there and get those insights as well So it's not just for switches and then I can figure out where this device is connected to and keep pivoting back and forth So whatever this device is this is what it's plugged into and then pivot back and forth now We're back to the USW pro aggregation Overall, I do really like these improvements and I've actually found this to be really stable and work well Now if you're having trouble getting your older version of unified network application updated That's why I made that video that is linked down below that shows you how to do a fresh install and just grab the backup from your old one Throw it into the new one and it restores fine. This is how I did mine I know there's ways you can go through delete some of the Java Libraries remove the old version Java and install the new Java 11 get it working, but I didn't really have a need It's just a basic VM that just hosts my unified network application Now we are using the multi site instance because we use a central server that we host to manage all the clients that well We manage their networks for and it works perfectly fine for that But none of them really have to deal with any of the unify routing. It's just managing switches and access points So it's still a pretty lightweight VM overall to be able to manage that many sites in a single controller Now as far as if you want to host it in the cloud and doing that I am working on some updated videos for that Hopefully depending on how many comments I get for people that want to understand that better I will talk about how to set up your own cloud multi-host controller and set the DNS and everything else Comments asking me to do it often encouraged me and drive for each of your videos on this channel But anyways leave your comments and concerns down below I'll leave links so you can read through and see all the different bug fixes and changes because there's a lot More than I took the time to cover it just in this video If there's something you want me to cover more in depth about unify Let me know or head over to our forums for a more in-depth discussion And thank you for making it all the way to the end of this video If you've enjoyed the content, please give us a thumbs up if you would like to see more content from this channel Hit the subscribe button and the bell icon If you'd like to hire a short project head over to Lawrence systems calm and click the hires button right at the top To help this channel out in other ways There's a join button here for YouTube and a patreon page where your support is greatly appreciated for deals Discounts and offers check out our affiliate links in the description of all of our videos including a link to our shirt store Where we have a wide variety of shirts that we sell and designs come out? Well randomly so check back frequently and finally our forums forums dot Lawrence systems comm is where you can have a more In-depth discussion about this video and other tech topics covered on this channel Thanks again for watching and look forward to hearing from you