It's humbling to be here today, particularly being the context of the two people who have just spoken. I've known Joan Rose and Professor Ogaki for many years, and it's really neat to see what they've done in their lifetime and how much they've changed things. But let's go back to the theme of this presentation and what we're really talking about here. We're talking about a change that is upon us that's really about change. It's not that long ago we can think in our professional lives when we were operating off of single objective optimization for particular purposes with highly fragmented authorities and a rate of change of population, of urbanization, and all the things we've been just talking about that was much slower than it is today and today is much slower than it will be in the future. And in the future, we're dealing with really a multi-objective world. We want to do that because we have expanded our objective function from thinking just about serving people water, for example, or cleaning up a river to thinking about how we manage the earth and the ecosystem holistically. So we've got multiple objectives and that has been an aspirational movement, but now in response to really hard-pressing problems like 155,000 people a day coming onto the planet. That's a million a week, 90% going to urban areas, 90% in developing countries. How do we cope with that kind of change and how do we cope with the underlying effects of climate change on the planet? And I think the answer is we really have to redesign how we think and how we do, how we think and how we do. And with great deference to Mogaki, I would say that technology is a great enabler, OK? But technology does not spell out a pathway for people to make decisions in a very, very uncertain environment, whether you're in a utility or you're in a government agency or you're trying to manage fish populations or you're trying to manage food in a very, very chaotic environment which is to come. So we have a great panel here today and it's my pleasure to ask the panelists to come up on the stage. And I will introduce them as they come. So we have before us essentially Mr. Mohan from, he's a professor at the Department of Civil Engineering at the Institute, Indian Institute of Technology. So he's a guy who's a modeler and is dealing with things that Ogaki was talking about, with climate and being one of a number of factors. Dragon Savage, someone I've known for a long time, comes from Exeter University and has just recently taken over. He's taking over the Netherlands. He's taking over KWR. But he's one of the finest people I know in the world when you think about water systems, drainage systems, wastewater collection systems, and networks, and how you manage in such these are huge investments, 80% of investments. How do you manage when you really don't know what's going to happen next? And if you don't believe what's going to happen next, look at your TV for the last couple of weeks and see what's happening through climate-induced huge hurricanes, which have profoundly influenced three different continents in the world. Third, Marian Savile, who is a health-related microbiologist and a very dear friend, also a good friend of Ogaki Sensei from New Zealand. And she has been involved really with Joan in the microbiology group and is working now with policy in New Zealand related to some of the problems we're talking about. Adrian Sim, please join the panel. Adrian works for an organization called the Water Stewardship Alliance, which is essentially an effort to get industry corralled and some standards set so that we can say that as a world, we're really working towards a common goal of sustainability at the industrial level. Finally, we've got, I think it's finally, Joseph Vessie, who comes from a great company, Xylem, and has worked all aspects of water all the way through the water cycle and for a couple of different companies. So it has been around the block on the issue of, what are we producing? Who are we producing it for? And how do we anticipate what is to come? Now I'm going to get away from this mic and come over and do a little, I think a little pacing, maybe. So guys and gals, how are we today? Yeah, we're OK? OK, so we've got a very limited time and we've talked a little bit about questions which I would post to you. And they come from a combination of sort of two questions. One, how would, I would say, given Ogaki Sensei's speech, his prescription is that we should embrace technology and use technology to adapt to things that are coming. The other side of the coin is, how do I know, how do I know either which technologies to adopt or how do I know what I'm trying to plan for? And when you take a real complex situation, say like salmon recovery in the San Francisco Bay area, we don't understand the problem of the salmon and why their mortality is high. We don't understand the interaction of the Delta rivers and the withdrawal of waters for water supply down into Southern California. We don't understand the broad scale effect of climate change on the ultimate survival of the salmon in that region. It may be that they're going to become extinct anyway. So it's a little bit hard then to say, well, all we have to do is pick out a technology because actually we don't understand the problem and we've got to fly the plane while we're figuring it out. So that gives rise to a couple of ideas and that are being widely used. And those ideas are adaptive management, scenario planning. But if you look at the reality at any university in the world today, they're still teaching students as though we are living in a certain world with constrained objectives and our issue is really to optimize as opposed to be resilient, as opposed to being adaptive, and as opposed to being able to embrace broad scale change. So with that, let's start with one of Sensei's questions, which is we've got structural changes going on, which he would describe as population urbanization and the resource implications of that. And you included flooding and drought and then unpredictable changes, which would be earthquakes and the like. Just focusing on the so-called structural changes, then my question for you, just hanging on a second. Get my names. Mohan, you work at Indian Institute of Technology.  And you are a citizen of a country in India that adds 300 million people every 17 years to its population. And if I ask you the question, are you worried about climate change mostly? Are you worried about population mostly, about urbanization mostly? What would you say if you looked at it from your point of view? Yeah, this is a very difficult question, but I'll try to answer this one. See, actually, our population growth modeling is well-established, so it is not that kind of a problem. At least, uncertainty is not that much. But the more importantly is climate change and its impact in our country. Because recently, we found that two states, which are having the especially urbanized area, the rainfall, which has around 150 years record, that has come again back. So people are now trying to tell that it's more on the climate change. And that too under the monsoon climatic condition. So the more important problem is monsoon prediction, how we can do that, or what will be the change in the climate change, and also urban population. The third problem in our thing is we are making the urban areas worse than the earlier one. Now, because a lot of buildings have come, especially the water is not going down. So that makes a kind of a flash flood rather than the original flood what it is. So that makes almost cities like one week there is no mobility. So we had to live in that particular. So we are now trying to look out on trying to change the stormwater system completely to take care of the future system. That's one way. So what you're saying, if I could sum it up, is that it's hard to say which is more important, but really that you're viewing a host of problems, right? And consequences, and trying to cope with that, right? Now let's shift from a country that has over a billion people to a place in the we call New Zealand, right? Which has, what's the population of New Zealand? Oh, we're 4.6 million. So we are the extreme end. So you could say that in a way, Marion has simple problems compared to Mohan.  So what's your take on this idea that we're in this rapidly changing environment, we're not exactly sure what to do. I know you're working a lot on trying to clean up rivers, you know, in the context of, you know, a changing agricultural settings, right? Urbanization, population growth and pretty significant climate change in certain parts of New Zealand. Well, how do you do it? Oh, that's a good question. We are still trying to figure that out and we're growing. Now one of the first things I want to say is we mustn't, we look at what you guys are doing all around the world and that's what we have to do more. And we've got to be selective because we cannot do every solution available and we don't have the money and the resources. And equally well, we cannot bury ourselves into a dead end so that we can't change that. So we have to look, we have to learn and we have to listen and we have to talk. And that means talk to you guys, talk to the international community but then talk among ourselves. So we mustn't form silos. We've got to get over this and be talking to one another and that is crucial. And then we will incorporate this new technology that Professor Ogaki is talking about because I think technology is important but I think it's going to allow us to grow exponentially but to do that, we've got to talk. Yeah, okay and I just add a thought here. I think, and sensei, when you have your final words, I mean I think technology doesn't necessarily lead. I think technology often follows from trying to work your way through pretty complex problems but sometimes it leads, sometimes it follows. So speaking of technology leading and following for you, Joseph, are you equal by Joe? Oh yeah, Joe. Okay, so you work for one of the big companies in the world, right? And you're making water technology, I know from a lot of experience, you know, in all parts of the world and all parts of the water cycle, right? And you have to make a profit. You know, different from sometimes people that utilities and universities which have big problems but they don't have to make a profit every quarter. So you've got to look out at the changing landscape and figure out what to do either in terms of having the right product available in terms of engineering products that are more flexible and have a longer life and to be a better partner with the utilities ultimately that you're serving. So what's your take on all this? Yeah, thanks. So we serve water utility customers all over the world and we listen most importantly, we listen and we learn from our customers. And I'd say, you know, they're dealing with uncertainty as the professor lined out in the keynote. And there's really, I think two things that we try to do. Number one is how can we build more adaptive products, more adaptive design the products? And I'll give you an example. If you're in the pumping industry, most pump companies or pump people talk about curves, a pump curve, we have a head and flow. And for a duty point, you typically have one pump that achieves that duty point. But in the world of uncertainty, you don't know the flows, you don't know the head you might need. And so we've developed a new product that instead of having pump curves, it's a pump area or a pump grid. So essentially one pump can now do what 10 pumps could do before. So you now need to less predict and understand the environment you're gonna be because you can't do it anyway. And so how can one pump do the work of 10 pumps? That's one area we're working on, that's number one. Number two I'd say is customers under such uncertainty at times, that slows decision making and slows asset renewals and asset replacement. So what if we could deploy sensors, technology, use machine learning to have customers use the assets that are already in place? And we've done this with combined sewer overflows. A traditional yesterday's thought would be to put massive storage, hundreds and hundreds of millions of dollars in for a combined sewer overflow. But what if you could deploy sensors and essentially use the conveyance system that you have today, that's what we're doing with customers in and around the world with saving hundreds of millions of dollars by doing that. And it helps them in this changing environment that they're living in today. Okay so you, and just a follow up question and as a company and you've watched this changing landscape so you've adopted some of your existing products, right? And have you added then new products that would for example on the sensing side that would allow you to create options that didn't exist before from your company? Exactly, so Xylem is a leading digital player in water. The last several transactions and internal innovations that we've driven have all been on the digital sensing, software, machine learning. We are in a whole new world. We're competing with companies we never thought would even enter the water space, right? These are IT companies that are entering the water space. That's who we see as potential competitors and partners for that matter as well. So it's changing dynamic is a changing space. It's an exciting time to be in water. That's fascinating. And you know that if we just carry on from what you're talking about, one of them I think the most difficult task of the whole water space is the fact that we, we don't use water where we sit and we don't dispose of it where we sit. In fact, we've got networks, right? And those networks get built over centuries and they're very difficult to build in the beginning. Most people don't even understand, I'm saying this from experience in my own utility, don't even fully understand the network that was built 50 years ago. And then you've got this idea that you've got, you know, if you think about Europe, you're moving from countries which probably aren't increasing in population whatsoever. However, you know, the whole drainage regime is dramatically changing, right? And then you've got places with no networks that need networks and all that. So Dragon is really one of the experts in the world in this field. What's your take on what is, I think, if you put together the idea that things are really changing, it's part of its population, part of its climate change, and that it's wildly different in different parts of the world, right?   So how do you kind of think about these problems and what do you think are some of the kind of key points that you would say are essential for societies, countries, communities, educational institutions, industries, you know, to be thinking about? Thank you, Paul. You're absolutely right. We're talking about infrastructure that lasted for centuries in some countries now and will have to last for hundreds of years. That's the point. We can't easily replace that or renew it. So we have to plan 100 years ahead. And when you think about it, the only thing I can say about demand prediction 100 years ahead is whatever you predict it will be wrong. So we have to work with those kind of systems. And that's where the flexibility we were talking about happens. That's where this talking to other people happens. I'm talking about federation of scientists, of utilities that are working on the similar problem. An example of this kind of adaptive planning is that we will have to probably invest more at the beginning to build that flexibility so that we can adapt to the future that will happen, which we don't know about. Remember the famous known unknowns and unknown unknowns and we are talking about unknown unknowns. Exactly, yeah. I would just add that within the new organization that I'm working with, I'm really happy because we do two things. One is really well and that's scenario planning. And the other thing is talking to other people, having a network of experts working with us, both utilities and research institution, Professor Ogaki leads one of those institutions working in this federation of research organizations trying to address these problems. Okay, so I wanna come back to you in just a minute but now we're basically thinking how people are responding to uncertainty, right? And so here's the case of essentially that the municipal sector and large scale infrastructure. Now you, Adrian, work with an organization that's trying to work with industries to do the right thing and to set some standards by which you can certify companies as being good guys, right? Or good girls, as you like. And yet what's good and where the bar should be must be just incredible within your association. And when you think about green certification and that kind of thing, certifying to what? And what's good enough and are there times as an example in Seattle, the city of Seattle, experienced a complete meltdown of a giant wastewater treatment plan because they were trying to be so good that essentially the urban area vacuumed up all the stormwater, okay? So and when the stormwater exceedances were too big, it completely blew up the plant, right? So one idea is we could have had a bypass and it goes into the ocean and it's sorted out in about two weeks. But industries have the same problem. How do you cope? So what's your take on this? Well, thanks, Paul. So first of all, the perspective that I'm bringing here is less one of the utility or the infrastructure provided by one of the border user. So our members are, not just from industry, it's important to stress from all sectors, but the approach we're taking is to use a voluntary standard and certification system to drive innovation and best practice. And it's a single standard for whether it's a utility in Seattle, whether it's a noodle factory in India, whether it's a chicken farm in Australia, it's a single standard. So it's not prescriptive, but what it does is it provides a safe place for companies to sit down with others and have those conversations like we're talking about. We're ultimately at slightly different level and perhaps with slightly different audiences all talking about the same thing, which leads me to my perspective is I'm always struck. I'm not a water engineer or a specialist in anything to do with water, but I attend an awful lot of conferences about water. And I'm always struck by how little we actually talk about H2O. What we talk about are relationships, first and foremost, and what flows from them. And so the technologies are great and very important. I can completely concur with Professor Ogaki, but I would add the softer technologies are equally important. Technology isn't just pieces of kit. Technology is also soft stuff that helps to engage, start conversations and build trust. So unlike a regulator, for example, you have the ability then to be a bit of a facilitator for this conversation, right? Which is needed as everybody has said, right? And by its nature, if you watch it over five or 10 years, you'll see how it is adaptive and people shift gears. So one of the things I'd like to sort of add then to what's been said, and I turned principally to you, Dragan, on this. It strikes me having worked in IWA for 12 years and worked with hundreds of universities. You have engineering students, right? Who are being trained in a kind of, a kind of an archaic view of what's ahead. I mean, it's like going fast through, looking at a rear view mirror. You know, the notion of adaptive management, right? And adaptive management systems and scenario planning and dealing with uncertainty is not the centerpiece of engineering curriculum in most universities. Would you agree? Well, I agree with you that we still use some outdated methods in the academia, but we are also moving in that direction because there is quite a lot of departments now that teach systems analysis from a much softer perspective. We include humans in it, which engineers are not well known for. So, you know, there are movements. Okay, so just if there are movements, how do we accelerate that trend in general? Because there's certainly, you know, I work in China and I can tell you, you don't see it and don't see it much in Asia and also in lots of parts of the world. So how would you change the ball game here? Well, if you're talking about water engineering, IWA is a place where you have young water professionals, when you have research kind of area and you also have the industry here. And these are all the ingredients that we need. I was talking about smart systems recently and we can't have smart systems if we don't raise a new generation of water leaders who also understand ICT, softer issues and water above all. Okay, so I'm hoping that all of you here today and all of you sitting in the audience are listening to this because about half of you probably are the next generation and we really need you to take that advice seriously because a number of us will be out of the picture and you've got to sort of take that over and think more courageously, think more audaciously. Yes, Mary. One more comment to say. I think we've got to look beyond our water industry to get the new ideas and we can see this. We need to look at other industries, other disciplines, not just water. And I think this IWA Congress is a great place to start. Okay, so that's the beginning of the wrap up. So just last thoughts here from each of you, okay? Just to... Diversity of workplace ideas and data will help us get there. Mm-hmm. Hey, Jen. Fully agree with... Marion, is it? Marion, yeah. On the broadening of the conversation, it's absolutely critical. I would encourage... If you asked me to be provocative, Paul, I would encourage IWA to stop talking about the water sector because water is everywhere and everything. Okay, and Mohen, you'll be... I just want to add what we require in the current setup and the future here. Some skilled development. So I think the skilled development is really very bad in the developing countries. So unless we train the people, otherwise, you know, it is the same old people, but without much kind of a training. I think the skilled development is one of the area where if I want to manage the system, the water system, whether it's a stormwater training or in the water treatment or wastewater treatment, the skilled development is one of the very important... And when you talk about skills, Bob, and I presume you're talking about universities and... University, as well as... Or continuing education. As far as polytechnic diploma level, we need some training because now nobody goes for that kind of a training. Sure. It is more on the higher education. People are concentrating, but we need people at the mechanic level. Okay, so continuing education. Yeah. Greg, for the panel, you have your last thought. Well, the organization that I work for has a motto of research to practice. And that's one of the things we need to actually kind of do what we preach. And that's both building the educational system but also applying it in practice. And sometimes we are like two words, two worlds, sorry. One is doing the research, the other one is doing it practically. We need to work together into disciplinary. Okay. So, Sensei, you have the last word here. Thank you. You're welcome. It's on. Yeah, just talk. Yeah. I've already discussed about education or capacity building. I didn't touch about it in my talk so much, but I think that this decision making is not done by AI. We should do by ourselves. And for this purpose that we have to grow the young generation who understand the multi-disciplines. For example, that is we have to grow the mechanical engineer who understand the economics or civil engineer who understand the microbiology. Like that one. That is the most important thing to invest to the young generations. And Sensei, just one question because you can speak to a really important country. Do you feel like that is happening in Japan today or it's too yet to happen? Unfortunately, somebody, many, not yet, that is that. I think more. More is required. Emphasize that one in the university or utilities or industries. Okay, so Robert, you're here. So can I adjourn the session? Okay, good. Well, listen, I'd like to, first of all, thank Professor Ogaki. He's in Japan, you use people's name with a son or Sensei. Sensei means someone you greatly admire. World class. So we'd really like to first thank you, Professor Ogaki Sensei, from all of us, okay? Thank you very much. Yeah. Then, Joan, to thank you for introducing this panel. And Joan recently won the Stockholm Prize. So, and she's really been an inspiration for a lot of us. And then finally, can we thank each and every one of you for your time and your thought? I know that you're really busy and each and every one of you, for thinking about this problem, I think it's the most, I actually think it's the most compelling problem that at least our professional area is coping with, right? Because we don't know what we don't know for sure. And even what we don't know that we know is gonna be a whole new ballgame in terms of the lack of really predictability in the future, you know, certain predictability. So thank you, everyone, and just thank the panelists and thank yourselves, okay? Thank you.


What's up guys and welcome to trendy updates up our SPM birds now onto the trending news today is King Charles and Queen Camilla have been rolled a red carpet for at the Nairobi National Park and this has brought a lot of mixed reactions now we all know that King Charles and Queen Camilla are visiting Kenya and they have been having a series of events and places to visit and interact with Kenyans now as they were visiting the Nairobi National Park today a red carpet was rolled for them and that has made some Kenyans feel some type of way now while some of them are feeling it's quite okay to be treated that way others think that their red carpet in the park is a bit peculiar. If you have any comments regarding this story, Doc Kristine and I say my Kenyan mentality of Yombo Zawageni. We can't use the good things for ourselves and we treat visitors in this case colonizers better than us. Silver, Mr. Rich and I say my I think we need to focus on other issues Germany. See, I'm late a candidate. I don't see any problem. It's the king and queen. People will pay a banana with a fork and knife. What do you expect? I can't believe it's so embarrassing. God released my people from the shackles of white superiority. They are not even dressed for the game driver so I think no problem. Miss Githunguri says why is he wearing a suit in a park? Who is in charge of the wardrobe? Let us know down in the comments section what are your thoughts about the red carpet being rolled for King Charles III and Queen Camilla at the Nairobi National Park. But in the meantime, keep it trendy. Updates, hop on, SPM first.


The Arleigh Burke class-guided missile destroyer USS McFaul, DDG 74, returns to its home port, at Naval Station Norfolk after a eight-month deployment to the US Sixth Fleet Area of Operations, January 4, 2024. McFaul, part of the Gerald R. Ford Carrier Strike Group, GRFCSG, deployed to the US Sixth Fleet Area of Operations, to defend US, Allied and partner interests.


Hi there. My name is John Palfrey, and I'm the chairman of the steering committee of the Digital Public Library of America process, and I wanted just to give a brief update on where things stood with the DPLA through this video from Cambridge, Massachusetts. It's the very end of June, 2011, and there are two things that I wanted to report out on. One is the overall DPLA process, and second, the substance of what the DPLA may emerge into, what it may be. So as to the process, the most recent developments have been the very exciting feedback we've gotten from our beta sprint announcement. In May, we urged anyone who wished to build part of the DPLA to send us a letter of intent that they would be building something for our beta sprint over the course of the summer. As of June 15, due date for this, we had 66 zero applications or notices that people would be submitting to the beta sprint. All these beta sprint proposals and code and so forth are due on September 1, 2011. I'm extremely eager to see what we get from these 60 submissions, and extremely grateful to all those people who have agreed to work on it, and presumably sprinting right now. Many of these are partnerships among public and private libraries, and there are big federal agencies involved and individuals involved and big institutions like Internet Archive. We're fabulous, and we're very grateful to everybody who's working on it right now. What's going to happen thereafter is we'll have an external review board who will take a peek at these submissions, and we'll spend some time pushing them around, and will then help us to make selections of some of these beta sprinters to present at what we plan to be a big tent meeting in Washington, D.C. The date is set nominally for October the 21st for this big tent meeting. It's going to be hosted at the National Archives, which I'm personally very excited about. The Archivist of the United States, David Ferriero, very generously is hosting us there and will be convening this event. It'll be a publicly available event, and we'll webcast it and so forth. The idea will be to present some of these beta sprints to show people what a DPLA could be, and also to plan for the next steps thereafter. Our game plan is that it'll be 18 months roughly after that kickoff in October until we have a prototype. That's the game plan as of now. Something like the spring of 2013, there will be a DPLA, and that's the idea. Obviously much stands between here and there in terms of hard work and building consensus and talking to lots of people and raising money and so forth, but I'm confident that we're on a great track for it. Second, I wanted to give a few words about what the DPLA is and where it might be headed as a substantive matter. This is something that we have very carefully been trying to do as a process as opposed to having a clear sense of what it might be. So I just wanted to give a snapshot. Basically back in October of 2010, a group of about 30 people came together and agreed upon a sentence, a sentence about what a DPLA could be. And by March of last year, we had worked with a slightly broader group and camped with a four-page concept note, which is up on the DPLA wiki. If you're interested in that, just Google DPLA wiki and you'll come up with it. And the concept note on there builds it out a little bit more articulately. And I think we're now at a point where it's coming into focus, at least for me, that there will be five elements of a DPLA. The first element is, of course, there will be content. There will be some information in a DPLA. This could take the form of books. It could be images, moving images, audio files, and so forth. So it's not just books. I'm thinking that the initial Digital Public Library of America will be something on the order of 10 million objects. Think about it at that order of magnitude. Who knows, it may be more or less. But the idea is a very big library. It's not meant to be the biggest ever library. But initially, I think it will have a large-scale critical mass. And 10 million objects is just a goal. You can imagine drawing upon lots of things in the public domain that have already been digitized by the Library of Congress, by many different partners within the DPLA, which are public libraries, academic libraries, and so forth. But there would be a corpus of information. This would be made available on a free-to-all basis. I'm thinking about the words above the Boston Public Library as you walk in, that beautiful inscription that says, free to all. So the notion would be, however we obtain the rights to them, and we'll obviously do this entirely lawfully, from the end user perspective, the content will always be free as it would be at a public library. Second, this will be metadata. So the second element of the DPLA is there will be information about the information. There will be things like catalog records, circulation data, reviews, and so forth that describe and make findable and useful the information in the content part. My sense is this will be as open as we possibly can make it. I believe in open access to metadata. We've been very interested in and working with people who are focused on linked open data, interoperability among data. This may also be a way that we can connect the DPLA with the European effort at this metadata layer. You can imagine a server that hosts all of this metadata and people can use it for various purposes. Third, there'll be code that is part of the DPLA. This will be open source code wherever possible so that people can in fact make their own little DPLA. So let's imagine that we've got the large DPLA.org, which is a place where people can come and get access to this information with a certain kind of interface. But we would imagine the code being such that somebody could make their own version of a DPLA, perhaps for a specific public library or for a particular historical society or for a particular academic library or K to 12 environment so people could take the code, take that content, take that metadata and form it into their own library. So it'll be a resource for all of these different parties. Fourth, it'll be very open and easy to use tools and services. So one thing that we recognize is not every library, certainly not every library of every size, has technical people on staff who could take open source code and do something with it off of, say, source forage. That would be nice if everybody could. But we know that we'll have to make tools and services that are somewhat simpler to use and that allow people very easily to curate a collection or to create a DPLA or a digital public library for a town or for a historic society. You can imagine it also taking the form of mobile scanning operations. So you could imagine a project I like the name of, the Scanabago, which I've heard some people talk about, driving Winabagos across certain areas, going to historical societies, going to local libraries and helping people to scan materials that might be of local interest, have them fold up into the DPLA, but also be curated locally as part of a local collection that otherwise might not get put into a digital collection. So the fourth is open tools and services that make it very easy for people to use and to be a support system for the public libraries and others who are doing cultural heritage work in America. Then fifth, it's a community. I see this very much as something that's emerging in a way like Wikipedia, which I think is a great model in some ways, maybe like the IETF, the Internet Engineering Task Force. These are obviously slightly different communities, but in both cases, these are open processes to the extent possible that allow people to participate broadly. And overall, we have a very large group of volunteers who are coming together to create the DPLA. I foresee a very lightweight structure, something that doesn't grow into a large scale heavyweight organization, but rather something highly distributed where lots of people can see themselves participating and succeeding in it. I like the idea of a Wikimania style event once a year where people interested in the DPLA might come together and hang out and work on projects related to the DPLA and then go back to their relevant libraries or communities and so forth for the rest of the time through a volunteer mode. So there will be a community built around the DPLA. And I think the very active group that's already on the wiki and the listserv and those who have already agreed to submit as part of the beta sprint, those 60 sprinters, I see the beginnings of that community where people share this ideal of creating a free to all, free for all American library of this sort. So that's the basic update on the DPLA. I want to just share the current thoughts as of this last day of June 2011 and very grateful for your interest and attention with respect to this project. If you have anything that you would like to let us know, please contact us. The secretariat of the DPLA is based at the Berkman Center for Internet and Society at Harvard University where I think easily found on the web and please do send us a note or give us a call if you'd like to be involved one way or another. Thanks so much.


Kobe Bryant. He was such an inspiration for my generation and I'm sure all of us in this room, I'd like to share a lesson I learned from him. It was 2008, the redeemed team was formed and we were in Vegas for the start of training camp and we're getting ready for the Olympics in Beijing. We're going ahead to Beijing and I wanted to establish myself as a young leader on the team by waking up bright and early. Day one. So the goal was to be the first one at breakfast. So I set my alarm, I make sure I'm up by sunrise, I get out of bed, I put on my gear and I head downstairs. But when I get there, Kobe's already there with ice packs on his knees, drenched in sweat. Now it took me a minute to figure it out but this guy wasn't only awake before me. He had already worked out. He had just played in the finals days earlier.  What he had done that morning was incomprehensible to me. That dedication he had only days after falling short of an NBA championship. That taught me some I've never forgotten. Legends aren't defined by their successes. They're defined by how they bounce back from their failures. I can't believe it's been over a decade but back in 2007, Nike flew me out to Los Angeles to work the first ever Kobe Bryant Skills Academy. Nike brought in the top high school and college players from around the country for an intense three-day mini-camp with the best player in the world and I know some of you follow hoops but I don't know if everyone does. So let me paint the picture. In 2007, Kobe was the best player in the game. Michael Jordan, who everybody's heard of, had already retired. In fact, twice at that point. And LeBron James is great as he was. He was still climbing that mountain. In 2007, Kobe was that dude. Well, an important fact about me, I've spent my entire life in a basketball bubble. Basketball was my first identifiable passion and I fell in love with the game at five or six years old. So I had always heard the urban legend of how insanely intense Kobe's individual workouts were. Well, now that I was on his camp staff, I figured this was my chance and this was my shot. So at my earliest opportunity, I walked up to him and asked if I could watch one of his private workouts. He was incredibly gracious and flashed a smile and said, sure man, no problem. I'm going tomorrow at four. And I got a little bit confused because I had just got done looking through the camp schedule and the camp schedule said the first workout with the kids was the following day at 3.30. And Kobe recognized the confused look on my face and he quickly clarified that with a wink and said, yeah, that's four AM. Well, as a room of high performers and high achievers, you guys realize there's not really a legitimate excuse in the world on why you can't be somewhere at four in the morning. At least not one that a guy like Kobe's going to accept. So I basically committed myself to being there. And I figured if I was going to be there anyway, I may as well try and leave my mark. I may as well try and impress Kobe and show him how serious of a trainer I was. So I came up with the plan to beat him to the gym.  Now, when I step out of the cab, it's 3.30 in the morning. It's pitch black outside. And yet from the parking lot, I can see that the gym light is already on. From the parking lot, I can even faintly hear a ball bouncing and sneakers squeaking. I walk in the side door. Kobe's already in a full sweat. He was going through an intense warm-up before his scheduled workout with his trainer started at four. Not of professional courtesy.  I just sat down to watch. And for the first 45 minutes, I was actually shocked. For the first 45 minutes, I watched the best player on the planet do the most basic footwork in offensive moves. Kobe was doing stuff that I had routinely taught to middle school age players. Now, don't get it twisted. This is Kobe Bryant. So everything he was doing was at an unparalleled level of intensity. And everything he was doing was with surgical precision. But the actual stuff he was doing was incredibly basic. Now, the whole workout lasted a couple hours and when it was over again, I didn't say anything to him. Didn't say anything to his trainer. I just quietly left. But my curiosity got the best of me. I had to know. So later that day at camp, I went up to him and said, Kobe, I don't get it. You're the best player in the world. Why are you doing such basic drills? And again, he was very gracious and smiled. But he said with all seriousness, why do you think I'm the best player in the world? Because I never get bored with the basics. I never get bored with the basics. Kobe Bryant, the best player in the game of basketball, said, I never get bored with the basics. And as a young coach for me, that was a life-changing lesson. And that's just because something is basic. That doesn't mean that it's easy. If it was easy, everyone else would be doing it. But as you all know, we live in a world that tells us it's okay to skip steps. That tells us it's okay to circumvent the process.  But as you all know, the basics work. They always have and they always will. And the very first step to improving your performance in any area of your life, personally or professionally, individually or organizationally, is admitting that the basics work. But it's also having the humility to acknowledge that implementing them with consistency is never easy.


Hello, hello. Testing. All right. Should we start this? Okay. Well, good afternoon, everyone.  My name is Mike Metrol, and my talk is, what should I know about insert container project here? Over the next 40 minutes, I plan on covering several of the key projects in the container space, how it relates to OpenStack, and what each project entails. Because there's such a wide breadth of projects out there, and I have a very small amount of time, my idea is to try to cover as many of them as possible in kind of rapid fashion so you guys kind of get an insight into the death of the projects. So I figured I want to do something a little bit different in terms of the format to go about this, so let's play a little game. How many of you are familiar with speed networking or speed dating? Kind of show of hands. Okay, most of you. To make sure things don't get lost in translation, speed networking is when you have a group of people that are interested in meeting one another but a very small amount of time, and the idea is you get paired one-on-one, you have about one minute to tell them who you are, what you do, kind of the highlights of who you are, etc., and you move on to the next person and run robin fashion until you meet everybody.  So I figured this is a great format to expose you to the various projects out there. So let's start with an example. When you meet somebody, you kind of know what their name is, a couple facts about them, they tell you some things you may not know and some endorsements. So an example, my name is Mike, I'm a product architect at Rackspace, and then for the last three and a half years, last year and a half I've been very heads down into the container space doing R&D work as well as market surveillance, some things you may not know about me, joy coding and go, love to play golf, my favorite editor is Vim, and according to my LinkedIn profile, I've gotten endorsements for Python, clock impeding bash, and yes, even Reddit. The things you can get endorsed on there never cease to amaze me. So you guys get the gist, let's get into containers. All of you are pretty smart individuals. We all know what containers are, but to make sure we're all on the same page, containers really bring about four to six times more utilization and efficiency per application compared to traditional VMs and hypervisors. The way they've been adopted really has aided and faster development and duration, and they operate pretty much close to bare metal speeds. Some things you may not know, and people ask me this a lot. Containers are not just to enable PAS layer. They can certainly do that, but sure enough, there's much more to them. They can modernize your stack, they can be integrated into your CI CD pipeline, and the footprint of them is much, much smaller. A trend I've been noticing over the last couple of years, or last couple of months, that I find interesting is that many legacy and enterprise-focused organizations are looking to jump their apps from their current implementation straight to containers, skipping over VMs. Now that may be because they never really made the jump into the cloudy way, but nevertheless, they're seriously considering containers to do so, which is a trend that I find very, very interesting. Some things you may not know, if I've also got containers, is that they all share the same underlying kernel. So containers running Ubuntu and Debian can definitely work on the same host, but Windows containers running next to Debian containers, for example, aren't the case. So it's very different from virtual machines. They're very lightweight, they make app isolation easier, and they can play well across all sorts of platforms. All right, we pretty much got that. So containers are great and all, but let's talk about the runtimes that really bring out the full features of containers. Docker is the most popular one that's abstracted LXC, and they did so in a way that it made it into a pluggable architecture, if you will, as well as they established a model to package and distribute applications far better than what we had before. I constantly get asked this, but the Docker engine is really the only abstraction layer you need to enable cross-platform portability. So if you've ever tried to take a virtual machine from, say, AWS to OpenStack to Rackspace or have you, you've noticed that the pain points in that are very obvious. The boot and init process varies from platform to platform. Also, the sizes of these VMs can be a couple sizes of gigabytes. Transferring VMs from one platform to the other can take numerous amounts of time, and containers are very lightweight in that respect, so they allow for more usefulness and elasticity in terms of not just the resources, but how you use them. The Docker Hub is a collection of over 100,000 applications for a sake of an example. It's like the app store, but for servers, and it's really neat in terms of what you can find on there. So I can take an OpenStack container, I'm sorry, an OpenVPN container, or MySQL, or a Postgres, and I can have it running within seconds, not knowing a single thing about how that tool or technology works, which is very different from, say, trying to build whatever binary it is you're trying to install as well as maintain it. So it's really interesting to see how we evolve how we look at SAC applications in traditional servers. Docker runs in all modern Linux distros that are 64-bit, and there's recently been added support for Windows 7.1 and up. They're very fast, and they're actually being embraced by the entire industry as we speak. With new competition, naturally, sorry, with new technology, it naturally reads competition, and this is exactly what CoreOS' Rocket is really aimed at doing. It competes with Docker, and it's doing this in a different way. Rocket is really an implementation of this new App-C spec that's being developed as an open-source spec in the community. They're defining different ways of how you actually describe and run and manage, and how you enable discovery protocols for containers that are very different from the Docker way. So much so that the Docker manifest in the spec that really defines what a container is in the Docker world was done so after the fact that Docker was created, whereas CoreOS said, for Rocket, let's actually build up the spec, let's throw it out in the community, let's make sure that everyone agrees on this, and then we'll implement it. So it's definitely a more kind of thoughtful approach to it. And Rocket's really aimed at tackling the enterprise primitives around containers, particularly around security and image auditing. It also brings its own new image format, known as Aki, which is, again, different from the way that Docker is defining images. It's still under heavy development, and not production-ready, but it's definitely getting there. And one key thing that the CoreOS folks were harping on when it comes to Docker is that Docker established what we know as a container, and it made it popular. But they started dabbling into other things that didn't really necessarily relate back to two containers, such as launching cloud servers, creating systems around clustering, enabling wide functionality with regards to building and running images, networking, etc., etc., and they were packing this into this one large one binary. So Rocket said, well, we really need to just focus on the true building blocks of what a container is and what we as an industry want it to be, and that's what it's trying to do. A couple of endorsements around Rocket. Intel's clear containers effort is partnering, they partnered with CoreOS to enable the security joint effort to ingrain security as a core concept of Rocket. Kubernetes, which I'll get to later, recently added support for Rocket. And there's been many implementations of the Apsi spec out in the open. So much so, I think there's like four or five implementations of the Apsi spec, which is four or five more than Docker. So that says a lot about what the community thinks about Docker and where they think it should be going. So containers are great enough, but how do they relate to OpenStack? Well, for one, if you're not familiar already, the OpenStack Docker driver is really about being able to instantiate containers through Nova instead of virtual machines. It uses Glance as a back end image registry for Docker as opposed to running your image registry in a container. It's a StackForge project. And essentially, for all practical purposes, the Nova Docker driver is an HTTP client that talks to and controls Docker v of the API. And it works well with DevStack. So pretty simple. That's great and all, but we need something more. And that's what Magnum has really aimed at accomplishing. I'm sorry, Adrian, if you're watching, couldn't help myself to embed a Tom Selleck PNG. So you kind of have to do that. Anyways, containers are great and all, but you really need to think about the fact that they're very different in terms of the lifecycle of how you develop them, how you use them. And those are very different from virtual machines. And so Magnum is aimed at being this container service that makes containers a first-class citizen in OpenStack. It uses heat to deploy swarm Kubernetes and mesos, just a couple of container orchestration engines. And it really is about providing abstraction in the two-fold manner. The first abstraction layer is what's known as the Bay type. And what this does is it allows multiple tenants to instantiate the container orchestration engine, or COE for short, of their choosing. And it allows it to run side by side with other tenants, very similar to how the virtual machines are done. It also provides an abstraction layer from the API perspective and how you deploy it. So Magnum's job is really about saying, hey, I want to deploy the COE. Once it's done, drop me down to the native API. I have the respective tool. And let me do my thing. So it doesn't try to get into the middle or kind of boggle the actual use case or the utilization of the actual COE that you're deploying. Google's recent involvement in OpenStack obviously lends Magnum to be a sweet spot for collaboration because Magnum supports Kubernetes. So definitely keep an eye out as to where that's going in the future. The next project is CoreCube. This is a project I personally started and maintained. And if you think of Magnum as the full-on suite slash toolbox to deploy this multi-tenant, multi-COE deployment, CoreCube is the complete opposite. CoreCube is really just about a simple, easy way to deploy a proof-of-concept project of Kubernetes running on OpenStack in CoreOS VMs. And it does this across not only all Rackspace environments, but also pure native OpenStack. I started it really to understand CoreOS' projects, just the OS itself, but at CD, fleet, flannel, etc., and how this all ties into Kubernetes. I also added support for SkyDNS in Kubernetes if you're familiar with that, which allows native registration discovery for pods to run it and go. And the constant endorsement I say about CoreCube before I finish up here is that it really doesn't require any additional services or installation to use. If you have an OpenStack available and it has heat enabled, that's really all you need. So this is, again, not production ready by no means users that. This is just a way to allow you to play with Kubernetes on OpenStack without dealing with the mess of setting it up. So let's get to the meat of what everyone's really here for, the COEs. First up we have, oh, Apple, it's finest. Let's try this again. Sure we can enter this out. All right, and we're back. DockerSwarm.  On top of that, it's really aimed at providing a common slash standard interface for any COE you're choosing, whether it be Kubernetes or Mesa or what have you. If you've used Docker hosts, this is great for one host, but when you start to kind of branch out and think about multiple hosts, that's what DockerSwarm's sweet spot is, right? It's really wanting to be able to allow you to control Docker across many different hosts. So if you've used Docker, using swarm is pretty much identical, and there's not really a learning curve if at all. But it's not really battle hardened yet. There's no container failover, there's no HA for the swarm processes themselves, and the plug-in support for other COEs is still incomplete. A perfect example of this is, again with the Kubernetes example, if you're familiar with a pod, which is one or more containers, key part being or more, swarm thinks a pod is just one container. So if you expand that beyond one container, swarm just doesn't really know what to do. So it kind of starts to set the tone for what's lacking in swarm. And if they plan to be the standard interface going forward, being able to adapt to the various COEs, right container orchestration engines that they want to be the interface for is definitely going to be an uphill battle. At the same time, there's no real foundation for enabling microservices and the requirements that those things have. And this is really what we're all after here when it comes to container rights microservices. Because when you see the power that containers can harness, it's really about being able to deconstruct your monolithic architectures, piecemeal things into its own separate logical division, and then giving it the resources to do that. And swarm just doesn't really have that. Again, I have this kind of bias towards Kubernetes because I feel like they just started to get things right from the gecko. They have the concept of the pod and everything around it, which, again, I'll get two slides, but it really starts to define at least a talking point of how you should be architecting and restructuring your applications. And swarm is just not aimed at doing that, especially if you want to speed this kind of multiplex way to control many COEs. However, it's still perfect for smaller dev environments of about less than 50 hosts. This is by no means a hard limit of swarm. This is just my personal recommendation. And it's the next logical step of controlling and playing with Docker outside of just one physical host. Next up, we have mesos slash mesosphere's DCOS and marathon. So let's start with mesos. For all practical purposes, mesos is a distributed systems kernel and cluster manager. And mesosphere's DCOS is an OS that encompasses that. So perfect example. You have a Linux kernel and you have an OS like Ubuntu or Debian that consumes that. The same analogy can be applied to mesos as well as mesosphere's DCOS. Mesos is a distributed kernel and mesosphere DCOS is the encompassing of that kernel as well as providing more enterprise-y type of functionality from a UI to monitoring, etc. On top of that you can run marathon which is really about controlling C group services as well as Docker containers. And Kubernetes is actually similar to marathon in the sense that it can run alongside of it or in lieu of. And the reason being is because the mesos here folks thought or at least they have a hard stand saying that the Kubernetes scheduler is not as sophisticated as it should be when it comes to controlling containers. So they created a shim that allows you to map Kubernetes resources to mesos resources. So you can definitely have some sort of intermingling of the two. Another key point you may not know about this set of tools is that mesos and open stack get constantly compared and they even say there's some overlap. But to compare them head-on is kind of doing both at the service. It's definitely comparing apples to oranges. Traditionally mesos is about giving services the resources it needs and open stack is about giving you VMs or the resources it needs. At the end of the day they both about the goal do about giving the resources in some way but mesos is definitely more catered to services. Open stack traditionally VMs. Obviously open stack has moved along in terms of projects like Ironic to instantiate on bare metal and then Nova Docker ever instantiates VMs or traditionally it's VMs. Set of containers is VMs. But the cool thing is that you can actually intermingle these as well. You can run mesos on top of open stack or you can run open stack on top of mesos. A nice little anecdote is about a year ago eBay who's been a prominent player in the open stack space they have an internal open stack cluster and essentially what they would do is every time a new developer got hired on they would get their own VM instance with Jenkins for their builds and this Jenkins instance would live in the VM on the open stack cluster. Well as they got more developers and they each got their own instance it basically turned to the fact that they were creating technical raw because these resources where they're idling or they were not being used their full capacity. So they wanted a way to kind of restructure that and regain some resources back. So they ran mesos on top of open stack phenomenon mistaken they put marathon on top and long story short they were able to minimize their footprint. So there's definitely interplay and interchangeability between the two and interoperability but it's definitely done at some expense right it's a little wonky but it can be done. Some resounding endorsements around this whole space is that Twitter, Airbnb, and Apple use mesos famously Apple is using mesos to power Siri. Verizon deploys all their DC services internally with mesosphere and Airbnb, eBay, PayPal and Yelp all use marathon. Mesos has been around for a couple of years now it's definitely reached a mature level and it's really ideal for a large environments from hundreds to not thousands of physical nodes. Next up is Kubernetes. If you haven't heard about Kubernetes by now kind of living under a rock. Kubernetes is really aimed at being this fully featured large scale container management system modeled after Borg. And Borg is an internal cluster manager at Google that powers hundreds if not thousands of simultaneous jobs behind the famous Google apps we all come to know and love. So just Gmail and Google Maps. It's based on decades of running production workloads and the experience around that. So who better suited in terms of the authoritative stance to do that than Google? Besides we all have confidence in Google so why not? At least some of us do. Kubernetes is supported across various different platforms including OpusDoc, Rackspace, AWS, GCE, Azure, Red Hat, etc. And some things you may not know and I think this is really key here is that Kubernetes takes a stance in defining again what the microservices architecture should be and it's really based around the concept of the pod. And the pod is I believe the truly perfect way of encompassing the atomic unit for what an app should be. It's again one or more containers that share the same volumes that share same C groups resources that share the same networking namespace and these pods these containers living in the same pod communicate with each other via local host. When you couple that with other concepts from Kubernetes such as the replication controllers such as services, labeling, etc. It starts to kind of fill out the story of how you actually think about designing your applications to fit into this new microservices model.  Couple that with services which is essentially a load balancing service aka a single choke point from multiple pods and you start to kind of see that Kubernetes has really given you a language to describe your applications. Kubernetes has no idea what an application it is from the hello world to this you know your standard three tier web apps. It just knows and gives you the concepts to allow you to define your business policies as well as the requirements for the quality of service and it goes about making sure that those are actually enforced. There's a specifically there's add-ons around Kubernetes that come built into it if you want to enable them around monitoring for containers elastic search UI and DNS and DNS is very important here because when you think about restructuring your applications for the container world a perfect example is say I have a Dejango app and a MySQL backend you can put each of those in their own dependent container if you're thinking about one physical Docker host the way they can communicate is through Docker links for all practical purposes the Docker link is a private network tunnel between the two and the MySQL is given basically the socket of how to access MySQL so this is great and all on one host but when you start to think about multiple hosts that doesn't really apply links aren't natively meant to work like that so a pattern has emerged known as the ambassador pattern which essentially is a proxy between the containers that resides on both hosts and these proxies are these ambassador proxies rather they serve nothing more than to allow the communication between different hosts in your cluster but there is also flawed because they too depend on Docker links and the biggest flaw about Docker links is that if the Django depends on MySQL the second MySQL container goes up or down or the sockets change or something happens to it there's no way of notifying the Django of those changes so Docker links are pretty much useless if you have no way of dynamically finding out the information so the DNS is very important because through SkyDNS for example it ties in well with the concept of Kubernetes services again which is a load balancer so DNS lends itself natively to just allow you to communicate with the current information stored for the container and this again is not only integral into the overall concept of containers but it comes natively built into Kubernetes something that does not exist in Swarm naturally nor in Mesos and that's very important because containers are very ephemeral they come up and down much more often than VMs other COEs and ecosystem tools in the container space are looking to integrate with Kubernetes if they haven't already so that speaks volumes about their front runner status it's really ideal for about 100 nodes right now the platform.net recently had a publication how they basically tested this to support 100 physical nodes 3000 pods but Google found out the issues that they were having and they plan on being able to support up to 1000 nodes by the end of this calendar year the force behind Kubernetes is just standing from a community standpoint since their first in it in June 2014 Kubernetes has seen almost 20,000 commits from almost 600 contributors and they're averaging about 250 to 300 commits per week but to put that into perspective ours technically got recently stated that I think the kernel version 3.17 if I'm not mistaken saw around 1,300 commits per week so Kubernetes is about a fifth of the commits compared to the Linux kernel which is pretty impressive it's being used in production today by Box, eBay, Red Hat and many others Next up we have a specialized system that relies on like the color like or one-offs that definitely still fit into the container space but aren't necessarily a COE themselves First up is Engine Yards DEAZ DEAZ is really aimed at being this PAS layer to facilitate app deployment and management it's built on Docker as well as Core West products from etcd, fleets and the OS itself and it's really about structurally abiding the Heroku 12 factor methodology so for all practical purposes it's a private Heroku clone however it lacks persistent storage and state-aware support for applications and that's very important when you talk about the container world because in Docker the philosophy is everything should be in a container including your more stateful information such as databases, message cues, etc and I'll get to this more on the next topic but that is a big key point about containers so if you don't have a way to support stateful stuff I mean you're kind of kind of doing your application of the service DEAZ however also leverages Heroku build packs kind of speaking to the Heroku story it can deploy to anywhere on-prem or in the cloud and v2 that they're about to release soon is set to be running on top of Kubernetes also again going back to the story that Kubernetes is kind of the showstop the showrunner here DEAZ also is being used by some small and medium businesses there's not a whole lot of fortune 1,000 companies I noticed but nevertheless it is getting used next up we have Prime Direct as Flynn which for all practical purposes is a direct competitor to DEAZ also has a layer aimed at solving stateful problems as well as the more stateless stuff around Heroku it's less prescriptive in the technology it uses than DEAZ but again it is a private Heroku but it's not limited to the 12-factor methodology it does provide an appliance for auto provisioning HA and fall over abilities for Postgres as a backend and it's looking to expand that to other databases as well some endorsements around Flynn Coinbase Shopify CenturyLink all utilize it next up this is very different from DEAZ and Flynn is Flocker Flocker is a data volume and multi-host container manager so before I kind of go into details about what Flocker does again the whole point of this is that everything should be in a container at least if you bought into the container story that's what you're trying to do so when you start thinking about how do I put your databases your message cues into a container given the fact that containers are so ephemeral and they come up and down you don't want your stateful stuff to just drop you're going to be able to persist that data in some capacity and that's what Flocker's really aimed at doing it's about being able to allow you to use containers for your more stateful stuff and does it in two different ways it uses a backend to enable a shared or local storage fabric and uses a front end proxy to allow you to do the proper routing for the containers you're interested in doing are utilizing depending on where they are at so you don't have to actually maintain or worry about your containers residing in the same physical host if they are that's great but if they're not you still want to be able to communicate with them and the back end storage actually has support today for AWS as elastic block storage and there's even support for open stack cinder EMC is enhancing Flocker to work with their extreme I only skill a old drivers VM are also partnered up with them to enable their drivers and it's now available as an official Docker plugin as of I believe Docker 1.7 Flocker just hit version 1.0 and they're definitely picking up a lot of steam so keep an eye out for them if you're worried or interested about how to maintain your stateful data next up are micro OS is we all know core OS it's essentially a minimal Linux OS and that being like the distro for massive server deployments and it really does OS it really described an OS in a different way that embraces containers it provides a subset of tools or a toolbox in terms of your basic binaries and then it says everything else and user land needs to live in a container and so that that really kind of moves the conversation of maintaining upgrading updating your servers because long gone are the days where if I update say open SSL it breaks some package that depends on that so if everything is self-contained in the container and user land then everything underlying can be updated obviously without like say the kernel for example but everything else can be updated and the application itself will not be bothered core OS is a fork of Chrome OS and it's flagship projects at CDN fleet or born out of necessity specifically core OS again is aimed at being a way to manage and update your OSs in today by today's standards and they really wanted to have a way to not only update the machines accordingly but make sure that the reboots happened in a in a phasing approach and so they needed a way to track a semaphore to make sure a subset of the machines rebooted at a time instead of the whole cluster so at CD is really was a way to store that semaphore and fleet was a way to coordinate the rollouts of the reboots obviously they've expanded past that and they are being used by multiple different companies today for various different uses but that's certainly originally they started core OS recently acquired KIO for both public and enterprise container registry and it's available across all platforms including Opus stack next up we have a project atomic out of red hat kind of similar to core OS again it's minimal OS aimed at managing containers they took a different stance in terms of of how they're approaching it it's really a security first focus more enterprise driven and it's baked in with SC Linux by default something that core OS didn't do until their most recent release of 808 so definitely they have a leg up on core OS from that stance from my fedora and red hat friends they tell me that using atomic is very similar to for door 20 and it started about six months after core OS so they had some catching up to do for sure but definitely atomic is best suited for your red hat stack especially if you start considering things like open shift there's native support for Kubernetes atomic itself is available as open source today and an EA of an enterprise platform is in the works and obviously atomic becomes an integral part to the open shift story especially if you've bought into the red hat ecosystem lastly in the micro OS topic is rancher labs rancher OS kind of same constant right and OS based around containers but it's doing something differently it's saying that you not only encompass all of the OS binaries in terms of the substance that you're providing in a docker container but as well as you use the land and it's doing that in a twofold way it provides a docker daemon for the OS itself kernel side and a docker daemon for the use line apps so updating the OS concepts is as simple as rolling out a new container which is very very easy and efficient it's still very early in the rancher labs story but they are offering a beta platform and even though they're smaller compared to core west and atomic it's definitely worth keeping an eye on them for the sake of giving you guys a visual of what all these different tools kind of do on the left is a Venn diagram I drew that kind of encompasses the major players and the the buckets they fit in you have traditional paths layers your coes and your specialized offerings and you can kind of see where some of them blur the lines such as flint and flocker on the right is a mind map of the open the open container ecosystem like a 30,000 foot view and this came out of red hat and I definitely encourage you to visit that URL because it really does kind of encompass all the different aspects that are using containers and how they're being really kind of expanded in terms of the OS itself database configuration management as well as the OSes so definitely how check that out to kind of understand how things fall into perspective to kind of reel things in back into OpenStack from and not just harp on containers so much what should we as a community do for containers well for one we have to be very aware of the shift in application development and we have to be able to accommodate that for containers so much so that some people are worried that there's not really an necessity for OpenStack anymore if containers are going to be so predominant that's not really the way to look at it there's still a need for infrastructure management and CoreOS is best suited I mean OpenStack is best suited for that if we know where and when to draw the lines and deculper responsibilities I strongly firmly believe that OpenStack should not be the end all be all tool for everybody the magnum approach for example where it's saying deploy COE and then kind of take a step back and drop you down to the native APIs is definitely a true weight of saying where OpenStack really fits well into this space so knowing that and being able to draw the lines and leave the responsibilities of the management aspects to say the Kubernetes and Swarms and Mace those are the world and not have OpenStack bleed into that will definitely make things easier in terms of adapting containers to your stack when it comes to OpenStack and if there's one thing I'll leave you with today it's this there's a lot of noise out there please pick the right tool for the job and make sure those tools fit and integrate well with your stack and just because you can mix and match these tools does not mean you should perfect example eBay ran Mesos and OpenStack and they got it to work and they were able to able to marathon with it cool it worked but do you really want a convoluted complex stack like that that just makes for like further headaches down the road with that said I point you to this GitHub link of a couple of white papers I wrote several months ago that are still very relevant today and this presentation was a condensed version of that they're easy reads perfect for the playing right back home if you have nothing to do for 12 hours and if you're on Twitter follow me on Twitter and I'll take any questions if you have any sure so where do I start so yeah I'll repeat the question so the question was can I compare the app see spec and how that falls online with the open container foundation so you have to understand right again Docker just kind of created the Docker the company created Docker and they defined the manifest and the specs after the fact so some people kind of thinking obviously that's a wonky way of doing it because we should define what we want out of these tools before we actually implement it there is if you guys have been following there was kind of some debate or some like some bad blood between the core West folks and the Docker folks because chorus just came out of nowhere with the app see spec and with rocket and because they're so firmly of course so firmly believes that Docker didn't get it right the first time the app see spec is a communal way of saying what do we want containers to be and what those containers should actually be encompassing and so the foundation was kind of a way of saying hey you know we're friends again but also we should you're right we should probably take a community first approach and so Docker said we're going to donate the run C runtime which essentially is a wrapper for look container and yeah we'll embrace the core West folks and their necessities around app see spec but that was a couple months ago right that was in July and not really much has changed so the community is kind of like divided right now in terms of the Docker camps and the and the app see spec camps as I said earlier there's a lot of it there's four or five implementations of the app see spec so there's definitely some meat behind that time will tell how Docker kind of goes forward with this a lot of people don't really necessarily believe that Docker is you know they're they're trying to play nice for the sake of playing nice but I don't think they well people don't believe they have real intentions of adopting the app see spec or at least they want to be the most influential voice at the table so does that answer your question cool any other questions going once twice sold all right cool thanks guys


What's up? Salamite, man. First vlog I think I'm filming in 2022. There's footage up, but that was kind of the holiday week. Now we're in it, we're jamming. And a lot's been going on behind the scenes. A lot I gotta tell you. A lot I gotta tell you. But first thing, give this thing a like. Subscribe, new training content every single week. We got a pull day today. I'm a deadlift, little conventional, quick squat, added squats back in. So we're gonna head up to a decent single, probably just 405, naked, no belt, no knees, pulls, triples, some rows, some chinnies, some biceps, and a little cardio circuit at the end. I like to do my harder cardio days on my leg days. So if I'm gonna be sore, it'll carry over. Rather than if I do lower body today, hard cardio tomorrow, my soreness might just linger enough. Not that it'll affect my workout, but it'll affect me mentally. And I just kinda like to bang it all out. So my upper body days, I do more of a low intensity cardio, lower body days I can do a more high intensity. We'll get into that. Announcements, probably most excited about the next two. I got three things, man, but we can't tell them all. All right, list, one, two, three. One, really big clothing collaboration in the works.  I know we're new to the apparel game, although I've been in clothes my whole life. I love sneakers, I love fashion. I've been a hype beast since like 2005. And now everyone's catching on.  Shout out to Divergeal, RIP, Jerry Lorenzo's. All these guys, Bobby Hunter's been in the game forever. All these guys have made it so it's not just skaters, it's not just rappers, it's not just high fashion. All of the streetwear, all of fashion's kind of intermingling now, which is sick. And so it leaves the door open to be really creative and not just niche out.   I love wearing baggy, comfy clothes. So I'm really excited about this to share with you guys who, what brands we're gonna be working with, but I can't announce that. Second thing, our next launch I'm really stoked on. We're taking like an American traditional approach to our bear and our branding. And that's gonna be coming out hopefully in the next month or so. So keep your eyes peeled, 3SB.co. There's a little bit of stuff on sale on there, but our distinct collections, nothing new. But soon I'll keep you updated. And then last piece before we get into the workout, I got a podcast dropping, a brand new podcast.  But I got a top secret one on the way dropping in Feb and I'll hint at it as we're going. I can't quite announce who, what, where, when, but stay tuned, new podcast on the way I think you guys will dig it and check out Discord. That's where everything's happening. So we've got good company Discord live right now. I'm gonna leave, link in the description. We got a small community there from my Twitch streams itself, but I'm opening it up to our clothing, fitness. I'm opening up to the whole world so we can really get like-minded individuals to hang out, talk shit, have a good time. So check that out. It's good company Discord. I'll be hanging out there almost all day. I game a little bit, not as much as I want to anymore, but schedule switching.  And I hope to see you guys there. Twats. Hips are feeling tight. Often when I'm chasing down, I squat and trying to get stronger at it. I hope the frequency, because my hips and my low back just tighten up so much. I sit a lot less than I used to, but still they just lock up on me. So the frequency really helps me feel good. The 405 beltless, naked squats, before tugs. It's pretty good. You guys gonna why the frequency is low?  I'm kind of just focusing on squats for strength and to warm up for the poles. I don't have direct goals with my strength. Just want to tug, do what feels good, and squats have always felt good to warm up, get my legs going. And the volume on squats, my quads grow pretty quick. I'm just trying to fit in some clothes, you know? I'm just trying to fit in some jeans here and there. So quads are still big despite low volume, but we'll keep the volume low. RPE is kind of high, although that didn't probably look very slow. It felt heavy because it's third squat session in six months under the poles.


Hey guys welcome to SSUnitech, so see this side and this is continuation of Power BI tutorial. So today we are going to see about the Cardinality inside the data modeling in the Power BI. So this is very important while we are going to clean up our data after that build the relationship between the tables. So go to on the Power BI desktop and we will see in the practical. So here as you can see this is the project by which we are currently working on. So the first table which is our center table that country sales final table and we have three dimension tables that is address, customer and product. Now double click on the relationship between address and country sales final table. So here you can see the left bottom we have option for cardinality. So here we can see it is by default mini to one and we have other options as well like one to one, one to many and many to many. So what it means? It means if our first table that is our country sales final table is having multiple data against a single entry and in the second table that would have distinct values. In our case we can see the address we are having the distinct address IDs and in the country sales final table we are having multiple address IDs. So in this case the joint that will be mini to one because we are having the multiple values in the country sales final table and single value inside the dim address table. So this is mini to one. Let's move to next one. If we are having the distinct values in the country sales final table and in the address table then that relationship will be called as one to one relationship. So there will not have any duplicate values either country sales final table or address table. In the next one to many relationship if we will switch the tables first table will be the address table and second table will be the country sales final table then that relationship will be called as one to many relationship. It means our first table will have distinct values and our second table will have multiple values against a single value. So that will be the one to many. In case of many to many relationship it will have multiple values in the table two and in the table one. So in this case if we will join between the country sales final table with the country sales final table on the basis of address ID. So address IDs are repeated in the country sales final table. So that will be the many to many relationship. It means we will have the multiple values in the table one and we will have the multiple values in the table two as well. So that relationship will be called as many to many relationship. So I hope you have understood about the cardinality. So this is basically how our tables are going to join. So thank you so much guys for watching this video. If you like this video please subscribe our channel to get many more videos. Don't forget to press the bell icon to get the notification of our newly uploaded videos. See you in the next video. Thank you so much.