Okay, thank you for sitting patiently. I hope you've had a good day so far. It's talking about multi-cloud. It's about having options. It's a talk for people who like to have options. And it is not about Cloud Foundry, or about Bosh really, from the technical point of view. What I'm going to focus on is what it means for you to have those things, and why it's more important than ever for you to have that capability. In your organisation. And to do this, I'm going to look back at the last ten years of Cloud Buying Decisions in public cloud, particularly. And then I'm going to have a little look at some of the current trends and some of the things that are happening around us day-to-day, which are changing the way we see things. And then I'm going to look forward to how, if you take all that into account, and you have things like Bosh and Cloud Foundry in your life, how you can make better decisions for your business and better economic choices. But before we do all that, we're going to have a little story. So it's a story about another Dan. So I didn't introduce myself. My name's Dan. I work for Engineer Better. My business associate, my partner, he's also called Dan. And Dan has a moustache. Now, he wasn't born with that moustache. He has it and it remains on his face by virtue of the decisions that he makes in his life. And every day he gets up and he looks in the mirror and he has to contemplate whether he's going to keep it or not. He's holding a razor in his hand and he decides, no, I'm going to keep the moustache. And he goes away and he comes back and then he thinks again, he looks in the mirror and he goes, no, I'm going to keep the moustache. But the longer that cycle goes on, the more everything in his life becomes dependent on it being there. So his identity, the ability of his friends and his co-workers to even recognise him, his identity in a professional sense and a business sense, the marketing of his fledgling business. And even his family are completely dependent on it being there because the first time he got rid of it, his girlfriend burst into tears. So you could say his switching costs away from having the moustache to being clean shaven are very, very high. He's locked into it. Now, we kind of have a similar situation in business and we often feel quite uneasy in the decisions that we make in business. And we have lived through, or many people in this room will have lived through a couple of decades of Microsoft and VMware and Oracle and these buying decisions that we make. And sometimes this begins to feel very familiar when we're looking at cloud as well. That's disappointing that we have to have that feeling. And it translates into a more tangible effect as well in the business. So we have a study here by Wakefield Research that spoke to 400 IT decision makers. 78% of those people believe that the fears of lock-in were preventing their business from really taking advantage of cloud. So it feels bad and it is bad for the business and we aren't really getting the most out of things. So what exactly is it? What is lock-in? So I went and had a look at some research on this and some ideas about how to conceptualise lock-in. And it turned out it's not a binary state. So you're not either locked in or not locked in.  So you come to have to make a decision and you're choosing a vendor and you choose that vendor and then you sample that technology and you go, this is pretty good stuff. And then you begin to use it in your production environment or over else and you begin to be locked into that. Because by the time you come around to your next technology decision the world looks different by the time you've been around this cycle once. And every time you go around the cycle choosing the same vendor again and again you start to have fewer and fewer options available to you when you get back to your next technology choice. So if you take that idea and then you map it onto the last 10 years of cloud decision making, we're going out and we're buying public cloud. We've got a situation where we've had a really sort of pretty much a one horse race, I'd say. It's fair to say, you know, had a decade of AWS. They've created a market. You could say it's almost a captive market rather than a competitive market. It's a situation where you can see that they've been very, very good at persuading you to go around that decision cycle as fast as possible without really thinking about it. And you have very compelling economics so you say, oh, I can't afford not to do this. Everyone else is doing it. I've got to get on the train. Let's go around the cycle again and you think, well, there's no one to switch to anyway so I'll just have to keep buying from them. And it's not that I'm picking on AWS but this is just what I've perceived if I look at this locking cycle and apply it to the last 10 years.  So there's been very few tools available for you to do this. So you just keep going around the cycle. So what? Who cares? AWS works, right? It's a good service. Well, it is often that you look back at infrastructural technologies throughout history and you realise that they sort of evolved to become shared. So you look at roads and railways and electricity services and utility services and it's only through sharing stuff that we get true value out of it as a society. But the more things become shared, the greater the risk when they actually start to fail on us. And there's this quote that I picked out from the CloudWatch 2 consortium and had a chat with the CEO of Strategic Blue who had written a report for the European Commission on how we're kind of getting to the stage now when we're ready to think about just what impact we see from having this global service. Because we're always unprepared. So society is notoriously bad at anticipating unforeseen events, these black swan events. And we're very bad at pricing into our decision-making. So we don't really have a way of understanding the economic cost of random extreme events that will affect us in our lives. And here's a question. So what other utility service can you think of apart from computer utilities where a single massive outage or a critical failure of that business affects the entire world? Can you think of any other utility service you have, like gas or water or electricity? All of those things are regionally bounded. GPS, but that's not... Is that a utility? Could be. That's a question, think about that one. But I would say that if you compare the commodity-like utilities that we deal with every day, you compare that with computer utility, i cloud, then we've got maybe a much bigger problem to deal with there when we think about failure. Because there's no real predictable outcome. So these systems are complex. Global systems are complex. So by definition we have no predictable link between cause and effect. We can think of things like imagine if countries in Europe started to vote to leave the EU. Imagine if that was to happen. Can we foresee that happening and can we imagine what sort of data legislation might spin out of that and how that's going to affect us and how that's going to affect the regions of our cloud providers? Stuff like that. Brexit and Trump and even the banking crisis. These things are complex events and we aren't able to really foresee the outcomes of these things. So that's something to think about. So that's at a macro level, but meanwhile, what's been going on in the last ten years and much more recently in the trends that are happening and why would we need to take this into account as well? Well, while everyone's been going round that decision cycle of the lock-in, so is everyone else. So you come back to a stage where the competitive advantage from choosing AWS, for example, has started to erode because it's become much more ubiquitous and the skills have started to diffuse a bit more throughout the industry and everyone else has got the same capabilities as you, more or less, access to the same skills and the same capabilities. So your competitive advantage that you were so keen to get in the beginning has started to erode. And we just keep on abstracting. This is another trend. Liz Goff here, who was the first American woman to get a PhD in computer science for her work in computer languages. So her work led to the development of object-oriented programming. She said this about abstraction. Modulality through abstraction is the way things get done, which is very, very true. So we just keep on abstracting things. We keep on abstracting away from the complexity behind, and we use those things as building blocks to become more productive. So why would we stop doing that just because we've got different silos of different cloud providers? If we have the means to abstract beyond that even, why would we not do it if it makes our businesses and our lives better? And of course, we keep on re-architecting. So these trends to have stateless 12-factor applications and to implement microservices so that we can scale our teams and we can scale our applications better, these are starting to help us decouple the idea of the application away from the infrastructure. So again, there's a level of abstraction there that is really helpful to us, and we see this in Cloud Foundry, the app as the currency. So all that's going on, and meanwhile we've got this really sort of pent-up unmet demand for portability. So as I said, Amazon are really, really good at playing that game of the locking loop. So everyone's going around and buying Amazon and they've even had the audacity for Andy Jassy to stand up and say, hey, everyone kind of wants choice, but then they try and they give up. So he was quoted as saying that that was the case and I thought that was quite brazen. So there's also survey data that suggests that that is the case. So people are locked in, but they really would like to have those applications available to them and to have that choice of portability. Of course, public-to-public portability is one area, but the private-to-public hybrid world is definitely a thing. So this is the step that all organisations are making from owning things to not owning things, and you could, if you turned it the right way, call that multi-cloud. So this was the study that RightScale did, 82% of that survey resulted in activity you could call multi-cloud. So it is really important to have that portability. That's what the customers think. What do the analysts think about this? I wanted to find some evidence that suggested that things were changing in the marketplace that would support the idea that multi-cloud is a really good idea and it's becoming more important. Well, Gartner, of course, had a magic quadrant. So what I did was I took three consecutive years of the magic quadrant, put them all in one slide so you could see the changes in the marketplace from their perspective. And the bottom left square, as you can see here, is what I would describe as a shrinking island. So the market's becoming completely polarised. The only three players in the public-cloud market that aren't going backwards are Google, Amazon and Microsoft. Microsoft have even closed the gap on Amazon a little bit. So that's quite interesting. You can look at the visualisation there of the data and say, OK, well, things are changing. There's fewer competitors, but there's only three horses really in this race now. But that wasn't the most remarkable thing about the report because if you dig inside it and you find this sentence about Azure, you find that they're describing Azure as good enough so you should consider it good enough for your organisation and base your decisions on things other than the technical characteristics. So that's good enough is something you talk about when you're talking about commodity-like markets. So that's actually quite interesting, the fact that they start to use that sort of language. And then Ripmunk went away and they said, OK, well, let's look at how fast the pricing is changing in the cloud market. And they said that it was slowing down. So the race to the bottom is starting to level out now. The rate at which pricing war is taking place is slowing down and starting to level out a bit, which is sort of consistent with it becoming a commodity market or a commodity-like market. OK, so where are we so far? Perasif, single supplier. So we've got this situation with 10 years of us buying services from one provider. That's a big risk to us. We're very bad at managing our switching costs in that world. Unexpected things do happen and we're awful at predicting those events. We keep on abstracting. We've also got ubiquity in AWS. So we've kind of lost our competitive advantage by using that as a single supplier. We keep on abstracting away. So there's a trend for us as human beings using computers to keep wanting to abstract. And we wish we had options. So there's evidence to suggest that we know it feels wrong to just keep doing the same thing over and over again. We want to have more options in the future. And the market's becoming more like a commodity market. So that's the trend. And this is where open source steps into the picture. So there's an amazing structure in my mind around the way that Cloud Foundry and all of the assets of the Cloud Foundry source code and the governance structure around the Cloud Foundry foundation really helps us. And what it's effectively doing is allowing us to create a competitive market space in cloud. So where we've had a very captive market space in the early days of AWS, it's much more in keeping with Sam Ramsey's idea of this positive sum game to have a competitive marketplace by using things like Cloud Foundry Certified, where everyone's put on a more level playing field, and having things like Bosch and Cloud Foundry together, wrapped in this idea that you have not just one company in control of things, but over 60 different companies. And the governance model around that is that because the Cloud Foundry foundation is a trade organisation, it's a 501C6, I think, it means that it is illegally impossible for the source code assets of Cloud Foundry to be transferred to any single commercial entity. So you are very well protected when you choose this technology. You have a lot of the risks of locking, mitigated for you by choosing this technology. Of course, Dave's can go anywhere when they use it, so it applies not just to operators, but also to Dave's, of course, because that's where it all started. So you can see a push to anywhere, and you've got a certified provider from anywhere, and you know that your app is just going to work in exactly the same way on all these different providers. And the operators have Bosch, and Bosch I describe as this travel adapter for cloud. So it's basically the, it allows, just in the same way that I can take my laptop from here to any other country in the world, and as long as I've got the right travel adapter, the right CPI in Bosch terms, I can take that anywhere, and I just know that I will be able to run exactly the same deployment in the same releases on a different cloud. And I just put some of these CPIs up here that I know that are in common use. There are obviously others. I would assume that most people in this room have probably come into contact with Bosch by now. If you haven't, please go away and read a lot about it. The beauty of it, as I just said, is that modularity. So you can swap out a CPI completely and keep everything else in your deployment in exactly the same, and you have that nice separation, and that separation of concerns between the IS and what comes above it. So who's paying attention to this? Well, we've got governments. We've got the British government, we've got the Australian government, and banks. So these are organisations that have been early adopters of Cloud Foundry, and it's really because the stakes are so high in these organisations. So they do care about switching costs. Governments are not going to want to take on the risks that I've been talking about a few minutes ago. And also working with a very big bank at the moment for whom that ability to deploy into public cloud but then repatriate that into their data centres is a huge issue for them. So Cloud Foundry was the natural choice for that to meet those requirements. The best example I've heard from the community around multi-cloud is NE9s. So they've actually done this twice. They've already moved from VMware to OpenStack, and they did that mainly as a cost-saving exercise. I think they cut their licensing costs or their operating costs in half by doing that. And they did that on a production platform that had 120 apps. They moved between these two CPIs. They did it with just two to three people in a couple of weeks, and it only had a 30-minute downtime for their production-hosted CF platform. And then they did it all again from OpenStack to AWS because they were having stability issues on OpenStack and hardware problems. So this is a real-life example of somebody taking a service which from the customer's point of view remains exactly the same, between the three different clouds, which is remarkable, I think. And the good news is that Bosch just keeps getting better, and it's, you know, with the good work of people at Google and Microsoft here. I'll come back to that in a minute. So we've had the CPIs getting better and better, and Bosch, as a technology, is maturing. So it's much easier to use. All of the complexity and the nastiness of all the yamol manifest is beginning to be sort of moved out into different areas, and there's going to be much better tool sets available. So I think it's a great time to start investing in that, and it's bringing down the marginal cost of us using Bosch in our production world. And I saw a great talk earlier from Colleen and your colleague about how Google has been working on service brokers and the CPI as well, which really helps us when you combine that with the fact that the commodity market is evolving in cloud. It means that those two things coming together make it a great time to start implementing us in multi-cloud. So at the end of the day, I think this is what you begin to see when you look forward. So we've had the last 10 years. This could be the next five to 10 years of us making much better choices in our businesses. And by doing this, what we're doing is we're managing our switching costs. So because we know it's a cycle, it's not a binary state, so it means that we can control things, whereas we haven't had that control before. So I'm working in a team at the moment, and when we have our IPM or when we are evaluating stories throughout the week, every now and again, someone will say, is there a Bosch release for that? And when they say that, I know that we are unconsciously managing our switching costs. And that is the side effect of having that capability and we're equipped with that tool. We have a choice to either use an inherent service or, sorry, a native service in AWS. If that's going to accelerate us, then we have to weigh up that choice against actually having a portable service. And as I said, for one of our customers, that's really important. So the reminder here is that you can manage your switching costs in exactly the same way that you manage your technical debt. I think that's the key issue here. It's not a binary state. You're not born locked in. You're not born locked in by the decisions that you make. So to wrap up, open source is the enable for all this. That's what enables us to have those competitive markets, which is really important. We get portability for devs with CF and we get portability for ops with Bosch. And we've got that lower marginal cost. So it's getting easier and easier to use Bosch. So you should definitely start using it. And the benefit of switching is that you've got viable alternatives to AWS now if you're in public cloud. And of course, you also have the benefit of more easily being able to move between private and public clouds. So that's a wrap. If you've got any questions, now's the time. Okay. Oh, there's one here. So, whenever you're migrating, you're moving things over and it says something like a green blue deployment that you envision for moving over to a different cloud or something like that. Just using Bosch releases, I've just deployed the same setup and then I have to do the switching manually and stuff like that. So there should be something above that layer. I guess in broad sense, DNS is probably something you need to manipulate quite cleverly there. If you're moving between clouds and you would need to factor that in. DNS is something that you should probably have outside of the cloud provider that you're investing in heavily. At some point in the bar in the last few days, I had a conversation with somebody who said okay, on something to deal with going Bosch, two different CPIs and moving volumes across as well. Maybe I'll make enough. I'm sure something. We'll think about it and get back to you. We'll take your details. Anyone else? Any other questions? Oh yes? Do you want to take the mic? How do you see the predominant role of single companies in an environment like Cloud Foundry? So we have this situation. For example, yesterday I counted the number of talks. I think there have been 32 talks and 16 of them, Pivotal was involved in some way or the other. He told us about not a single vendor dominating a project. How does this play together? There's no denying that the contributions to Cloud Foundry are heavily weighted towards Pivotal and they buy more influence in the direction of Cloud Foundry because of that. By the virtue of the fact that the foundation has and they're still working on this openly admits that it's not perfect. The structure's in place to make sure that everyone has a voice in that group of member companies is really important. Also Pivotal themselves don't want that because they know that it doesn't look massively healthy to have an 85% ratio towards them committing. But I think it's going to get better and I think that you can see the rate of growth in that foundation membership. All we can do is open more dojos and encourage more people to become committers and try and change it. That shrinking island of a second tier IaaS providers that you mentioned in the Gartner diagrams. Do you find that any people are starting to look more closely at those via the mechanism of the Bosch abstraction so that you can put them more easily into your sampling part of the cycle? If they do offer the services that you want. Does the Gartner diagram become less important now that you've got that Bosch abstraction? A good question. I think you could do that. It would be a good way of making niche providers much more relevant and giving them a chance to offer things which are consistent with public clouds. Any other questions? Good. Thanks for coming. Enjoy the rest of the day and have a safe journey home.


Aloha and welcome to Stan Energy Man, Stan Osserman here on Think Tech Hawaii and bringing you another great show. This time I'm at least in Zoomland on my lanai in my cabin in Hamakua, so I'm kind of relaxed today. I'm feeling really comfortable. I have a fan going to simulate the cool temperatures in Hamakua rather than sweltering heat in Kailua, but today's show is a little bit different. I have a great guest who's been on before, but to set the stage, one of my previous shows, in fact, I did it over two years ago, and I did a rerun by request a couple of weeks ago, and it's on what the guest I had at the time, Dr. Nate Hagen said, is energy blindness. I think one of the big challenges we have right now overall across all of our communities is that we really don't understand the cost of our energy in real terms.  How much energy do you have to generate every second of the day in Honolulu or in the whole state? Where are you going to get that electricity from? And if it's from solar and wind, the sun isn't out at night, and the wind doesn't always blow, so are you going to store multiple gigawatts of electricity so that Honolulu and the state of Hawaii have power all the time uninterrupted? Because we take for granted that all that oil that's in oil tankers and big storage tanks for Hawaii Electric to use for fuel, that's a lot of energy stored in oil. So just to give you an idea, I did a quick calculation based on some numbers I got and the basic formula was a barrel of oil is about 1750 kilowatt hours of electricity. Now of course you got oil and you got electricity, so it doesn't exactly, you can't just plug your house into a barrel of oil, but to convert that oil into electricity, cost some money, it probably is not perfectly efficient, so I lose a lot of heat and things like that. But if you took the raw cost, say a barrel of oil costs $50 as just an average dollar amount, that barrel of oil using my real average kilowatt hours per day could run my house for 79 days. So theoretically $50 worth of oil could run my house for almost three months. So why does it cost over $500 for me to run my house for almost three months when the barrel of oil only costs 50 bucks? And the answer is because nobody understands everything that goes into storing, moving, converting, generating, transporting, changing the voltage to higher voltage to push it through long lines and then back down through transformers to get it back to where you can use it in your house. All those things add cost to making your electricity. And so we go to try and solve our problems in Hawaii of how we're going to be renewable on the grid or how we're going to go with clean transportation, which is even more of a polluter or greenhouse gas issue than electricity. How are we going to do that if we don't really have a true respect and a true understanding of how much energy we're really talking about? And we're going to have to account for, just like an accountant does for all the numbers in your bank account, every penny to make sure we can do it reliably and people can have reliable energy. So to help me kind of go through some of this discussion today, I have a good friend, Sid Higa, who's got a great background of some F-22s flying over the beautiful skies of Hawaii because we both have an Air Force kinship back in the day, so to speak. And Sid is into sustainability and renewable energy and has been on the show before. So Sid, welcome to the show and why don't you take a couple seconds to tell the viewers a little bit about yourself and how you got into being interested in sustainability. Thank you, Stan, for having me on the show. Yes, so my background is I had 24 years of military service with the active duty Air Force, Hawaii Air National Guard and Air Force preserves. I've been in technology pretty much all that time from crypto tech to a computer systems development officer to running data centers and developing communication systems for the intelligence community, etc. So I've been interested in technology for a very long time and how I'm kind of interested in the sustainability part is because Hawaii is on an island 2500 miles away from the mainland, we are pretty much dependent upon ourselves, hopefully, for energy, clean water, as well as food. And so my efforts here lately have been towards clean water and sustainable energy so that we can support farmers and farming and hopefully become sustainable in our food production here. So looking at those two areas on how we can support farmers has led me to looking into alternative methods of delivering and creating energy to support those methods. So as we, and I promote this too, you know, when you think about the ancient Hawaiians, their population wasn't a whole lot different than what we have in the state today, it's probably within a couple hundred thousand. And yet they could sustain themselves with agriculture, with fishing. And it was because the systems that they had to make sure that they didn't deplete resources, they didn't deplete fish stocks or, or OP or, or, or anything else, and they could always feed themselves and that they took care of their water resources and maximize their agricultural practices. So as we look at what we face today in Hawaii, do we be looking for synergies between the production of electricity and agriculture? And as an example, I know on the big island, I know of it, at least two in-stream hydroelectrics. And I just talked to a gentleman last month who's helping actually put in a hydroelectric in-stream project for the, for KIUC, the utility on Kauai. And that's something that's always intrigued me because we've got water that was originally moved around the islands to support sugarcane and pineapple. And those aqueducts and those, those tunnels and things are still around. They may be fallen into disrepair in some places, but they still basically take rainwater and move it downhill so that we can use it for drinking water and things like that. So while it's running downhill, it could be producing electricity on the way downhill. And that's a synergy we should be taking advantage of. Do you, do you have any kind of, you know, are there things like that that you think about when you look at agriculture and water and the kind of ways we could be doing stuff a little bit more sustainably? Yeah. So from our standpoint, we're looking at it as far as what can we help the support the farmers with in their energy needs because they need to run their tractors. They need to be able to run their, their trucks and plows and be able to get their product to market. So they're going to need a sustainable method to provide that energy. And of course they need the energy to provide the water. So whether it's bringing it up from wells, bringing it and diverting it through the rainwater or in some cases, severe cases that go around to a drought, bring in and doing desalination for water so that we can use it for farming to make sure that we're sustainable in all aspects of creating our own food. And one of the things that you had mentioned there about the barrel of oil being able to produce enough electricity to run your household for nearly three months is power density. And I think what we're kind of missing here in some of this conversation is the power density. So I know that Kale Loa AES is a 180 megawatt electric generating plant. They sit on 28 acres of land and there's some solar developments that are familiar with one called Kapehao, solar on Oahu, and they create or they're mapped out to create 60 megawatts with 240 megawatts of storage. And it sits on 200 acres. So in other words, the power density from AES and Kale Loa compared to the solar project, you're actually almost 10 times, taking up 10 times a space of what Kale Loa is doing. And I know it's cold burning and it is considered a dirty method of producing electricity. However, on that 28 acres, they have the capacity to store roughly two months worth of coal to produce power at 180 megawatts per day. So power density is something that we're really not looking at. Yeah, and that's basically what I was trying to point out with the oil. People don't realize how much energy a barrel of oil can store and how convenient and cheap and cheap being the operative word. And that kind of ties into the theme I had in mind for today's show, which is if we plan to go green and we plan to do it quickly, like if we listen to Alexandria or Ocasio-Cortez, if we're not green in the next nine years, we're all going to die. If we can't do that in nine years, we're hosed, but how much will it cost? How much is it going to cost to replace all that energy density with totally new technology across the entire planet? And can we do it in 10 years? And I think the answer is no. And we have to be realistic and say, okay, but how do we do it as quickly and as efficiently and effectively as we can without causing more collateral problems or more issues? And I think there's ways we can do it. We just have to be smart about it. So you know that one of my favorite things is hydrogen. And the one nice thing about hydrogen is it actually has really good energy density when it comes to storing it. There's a lot of energy in hydrogen. If you don't think so, ask yourself what kind of liquid fuels they put in rockets to get it into orbit. And it's liquid hydrogen and probably hydrogen peroxide mixed together to make rocket fuel and put it, you know, it's a lot of energy. And the formula that I keep in my head is like a lead acid battery is 20, about 20 to 40 amp hours or amps per kilowatt kilogram, amp hours per kilogram. And hydrogen is 26,000 amp hours per kilogram. And your typical lithium ion battery is between four and 600 amp hours per kilogram, depending on exact chemistry. So nothing can come close to hydrogen's energy density. And if you've got to store a lot of energy, hydrogen is one of the best ways to do it. And in the sustainability side, if you're making hydrogen, like by splitting water with electricity, one of your byproducts is pure medical grade oxygen. And medical grade oxygen is actually really good for hydroponic and for raising aquaculture for fish. Because if you farm fish, and you put oxygen into their water, instead of just, you know, how they usually have something paddling the water or something to put air into the water, if you actually put oxygen into the water, the fish grow at a much more rapid rate because they can, they can digest the food and turn it into flesh faster if they're in an oxygen rich environment. So, you know, it's like we need to start looking at energy density and how we can get those synergies between agriculture and energy production and energy storage. Are there any things that you see on the horizon that would help us along those lines? Well, definitely. I think, like you said, there was an article that came out, I think it was yesterday, it was published that the Public Utilities Commission has approved microgrids. And I think hydrogen fuel cells or hydrogen powered within those microgrids would be a great method of distributing power and generation. But also from a sustainable sustainability standpoint, what people don't realize is the CO2 that we're trying to get rid of, we need to capture that because there's a lot of need for CO2. And the farmers, especially if they're doing greenhouse farming, if they're able to capture that CO2, take that captured CO2 and then apply it to the greenhouses, the plants grow a lot faster and they grow bigger. So it's the whole sustainability thing is just the big circle where we can use what we were capturing as well as utilize other methods to create the energy that we need. That's true. That's something we don't normally think about. We think about CO2 as the greenhouse gas that's bad for the planet. But in reality, that's what plants use to make oxygen. The O in CO2 gets released for us to breathe. To go back to the we have 10 years or 12 years or 15 years before we're all dead, I don't think people really think about the discussion in great detail. But if you want to realize how much natural CO2 there is in the air, because air is not a single gas. It's a homogenous gas of nitrogen primarily over 74% nitrogen, about 16 to 20% oxygen roughly. And then the rest are just a mix of gases. And if I ask the average person on the street, how much CO2 is normally found in the air? There's what percentage of if all the air is 100% and nitrogen 75 and oxygen 20, that leaves 95. In the last 5%, how much of that 5% is CO2? I guess a lot of people would say 5%, 4% would be wrong. 3%, 2%, they're still wrong. 1%, they're still wrong. It's 0.3%, not even 1% full. It's not even a half a percent. It's 0.3 is the natural average CO2. And when we talk about the state of where we're at now, it can approach 0.4%. So we're talking about a shift from 0.3 to 0.4 is about where we're at right now in terms of CO2 and in the air for greenhouse gas. But plants need it. And so maybe in agriculture, we need to focus it. We need to take that excess CO2, like you say out of a combustion system, because CO2 comes out of gas engines because it's not completely combusted in the burning process. And so you could take that CO2, you can this is something quite frankly, I just learned a couple of weeks ago. If you have pure CO2, it'll burn. I had no idea. And a guy showed me, you can go on Google it. I saw a picture of a flame of CO2 burning. And it's because unless you have the right mixture and even a pure form, and ignite it and have the right kind of jets and stuff, it's hard to get it to burn.  But if you put it in the gasifier, like a lot of the waste energy systems are, a gasifier will pull a lot of the stuff out of there, including the bad stuff, and drop the carbon out and give you hydrogen, release the oxygen and give you a lot of good stuff that we probably ought to be looking into. So I guess what I'm trying to say here is a lot of people hang a big negative on CO2 and think our objective ought to be to get rid of as much CO2 as humanly possible. But that's not the right answer. The right answer is to look at it for what it's good for and balance it out. Like you say with, maybe we could help our crops grow better. If we had CO2 and had a way to get it to the plants in the right proportions to help them grow better. And I think that's the approach we have to take to solving our big energy problems, is to look through a different lens and see how we can take what we think of as negatives and turn it into positive. Absolutely. And those in the food and beverage industry would really have bits if we got rid of all the CO2, because that's where you get the bubblies in your soft drinks and stuff. Yes. My background wouldn't let you see that was my Wendy's cup. But yeah, I had ginger ale with my lunch today. So you're right. That's all CO2. And I just think we need to start looking at those kind of things. We need to let the real scientists, the real technology people, the real inventors, the real innovators, start to help us to solve these problems. In some ways, I think looking at the electric company to the electric company for all the answers is a mistake. And it's not because they're not good people. And it's not because they're not smart. They're really smart. They're dealing with a really complex grid that they have to keep going. But when you look at the electric world through their lens, they only see certain solutions. Otherwise, it costs them too much money or it's going to require massive changes to their infrastructure and things like that. But sometimes that's what it takes. It takes somebody from the outside who's not from the electric company to help the electric company solve them. So I was really happy when you told me about this PUC decision about the microgrids because that's one of the solutions that I think we really ought to be looking at. If you took a typical housing development like the one I live in here in Kailua that has about maybe 150, 200 houses in it, and if every house had solar on it, and if every house had some batteries, and maybe even some capacitors, and every house had a little tiny electrolyzer that could break down any electricity that was left over and turn it into hydrogen for storage, my whole housing development could be a microgrid. And even if one of my neighbors was running a little short on power, I could loan him power, or they could loan me back power, or somebody's house had solar panels that were going bad or were damaged by weather or wind. We could share electricity and have it all in one community. And what that does for you besides making it cheaper is that we have also the capability of surviving a storm. Because if all of us are contributing to the power for this one microgrid and there's no big power lines stringing all over the mountains where the winds and stuff just tear them apart during a big storm, we can survive the storm because our little community may get some damage, but we'll still be able to function. The one thing that's cool about solar panels is you can damage them and whichever solar panels aren't damaged in the array and still generate electricity. So you're more survivable as a microgrid. And I think it would solve a lot of problems with right now the electric company, no matter whether it's here or the mainland, they have to move the power. And in Honolulu, it's pretty short distances from Kahi power plant to Kailai Loa and that area of Kunia, not too far. The Pearl City power plant stuff, they can move it to Central Oahu over the mountains to the windward side. But on the big island, you get hundreds and hundreds of miles. And maybe at the end of the line, you only have 150, 200 houses. Does it make sense to run a high-voltage power line for 100 miles just to a couple hundred houses? It just doesn't make sense to me. It makes more sense to have a community on a microgrid that Hawaiian Electric runs and helps maintain those solar panels and helps maintain the batteries on the houses. And be the place that takes the old batteries and recycles them. Because batteries have an end-of-life issue that we need to also take into account. So I see Hawaiian Electric as needing to kind of change their vision of how their grid looks and be able to support microgrids and the people that contribute to microgrids as one of their services and take some of their linemen and have the linemen helping people in that community with their solar panels and with their batteries and with their capacitors and with their electrolyzers to work on their hydrogen, to store their hydrogen. And then as we move into fuel cell electric vehicles and plug-in electric vehicles, the folks that have hydrogen fuel cell cars, they could probably even be driving their car off of hydrogen they make off of their solar panel. And now they don't have an electric bill and they don't have a gas bill for their car. And those are the kind of things I hope that we're looking at. Are there any more that you can think of, Sid? Well, you had mentioned, you know, the amount of electricity a barrel of oil could run your household on. But I wonder if anybody's really measured the capacity of the electricity that gets used to charge their vehicle into how many miles it's running and the cost of all that as well. I don't think anybody's really measured that cost. I think the average person certainly has it. I don't know the exact equation, but I can tell you this. We built buses for the Air Force and the same design is going to be used for a helion bus for the hydrogen vehicles that come to the big island. And we had 14 kilowatt hour batteries, two of them in the bus. So each bus had 28 kilowatt hours of just battery storage, plus all the hydrogen that could be turned into electricity. If we didn't have the hydrogen on the bus, the bus could go about 30 miles on that 28 kilowatt hours of battery storage. That's almost a one-to-one ratio in terms of one mile per kilowatt hour. So if your house, like my house is 20, between 20 and 22 kilowatt hours of electricity used every day, if I drove 22 miles or 44 miles every day, I probably use half the energy a bus does. And I could have enough solar panels to provide my house with my 22 kilowatt hours. And my vehicles with 22 kilowatt hours or 22 kilowatt hours to move my small car instead of a bus, that's 44 kilowatt hours of power need to be generated by my solar panel. And we have five hours of what we call rated generation from solar panels here in our latitude and stuff. So that's what each panel is about 300. It's like about 40 panels. Your typical house has 40, 45 panels on it. It could run your house in your car. So that's the kind of thing where I think that's within reason. I mean, it'd be expensive investment right now. It's expensive to put solar on your house. But to double the solar, you could probably also run your car. A lot of us in Hawaii are retirees or self employed or don't drive cars quite as much as the truck driver. So maybe we could even do better than that. But those are the kind of things I think we need to look at. We have about a minute left. I'm going to leave it to you to just kind of wrap us up here. Yeah, well, maybe for another show, we could delve into those people that can't put solar up like those that live in condominiums and stuff. Because what we're talking about here is being able to generate your own electricity and stuff and then powering your own vehicles, whether it be through hydrogen or electricity. But those that live in condominiums, which there are about 3,000, I think condominiums within the islands. We need to help them solve this problem as well. I know the legislature is trying to tackle that one already. And I think it's getting some traction where if you live in a condominium or a townhouse or maybe you're renting. And so when you're renting, you don't own the building or you don't even own your lanai technically speaking. But you can actually invest in utility scale solar and get solar tax credits and maybe get credit for electricity because you've made an investment in a utility scale solar field where you own half a percent of the solar panels that are out there.  And I think that model would work out pretty well. So yeah, let's plan and have another show and we'll dig into some of the legislation and try and see if that's getting any traction. Great. Well, thank you very much for having me on the show today. We really appreciate it. Thank you, Sid. I got a steal of your background there from my Zoom meeting. So I'm jealous right now. That's a cool picture. I'll send you the image. Okay. Okay. Well, that's going to do it for Stan the Energy Man this weekend. We'll see everybody next week here on Think Tech Hawaii. Until then, aloha.


So, can you hear us? Perfect. So, good morning. Thank you for attending our session. Today we are going to be talking about the implementation of Router Networks. This is work that part of this implementation took part in the Newton cycle. And there's some piece that is going to take place in Nocada. And so, most of what we are going to show today, it's already implemented, but there are some pieces that, even though we are going to show them, it's still in implementation, okay? So, my co-presenter is Carl Baldwin. Let's, yeah, do introductions. This is me, Gulloval. I'm Carl Baldwin. We both work for IBM. It was a recent change for me. Not so recent change for me. I've been with IBM for one year. And for today, we have a pretty simple agenda. We are going to talk about the motivation for Router Networks. Why is that important? Why we took the time and the effort to implement this in Newton? We are going to go into very good detail as to how Router Networks is implemented in Newton, the changes that we did in Newton, and the interaction that needs to take place between Newton and Nova for this to be useful. We are going to provide some guidelines as far as configuration. And then we are going to try to do a demo and show you some of the functionalities that we implemented. So, with that... Yeah, so, most of us are probably familiar with the complexity that Newton provides in terms of allowing you to create complex network topologies as a tenant or a project with an open stack. Routers, tenant networks, floating IPs and such. But there's a class of deployers out there that just want to provide like a provider, a shared provider network that all the tenants boot to a shared medium. They're all on the same network. They just want access to the internet and from the internet. So, Neutron also allows you to do this with a Layer 2 provider network. So, you can set this up. It's pretty simple for users to use. They go in, they boot their VM, they select a network, and as soon as it boots up, it's on the network. It's visible. The problem is, what if we wanted to create a deployment with a very large provider network, one that's scaled up to possibly many, you know, hundreds or thousands of hypervisors and thousands and thousands of VMs all sharing this one shared network. Then we start to run into scale issues that are kind of inherent with the way L2 networks work. In L2 network addressing, you think about it, it's a big flat 48-bit address space. And I won't go into the scaling problems, but you go read about it, you'll find, or if many of you have probably had some experience with scaling L2 networks, there are all kinds of problems that happen when you try to make these networks bigger and bigger. So, what do we do with Neutron? If we want the provider network model, the simplicity that that provides, just boot to it and your VM is accessible, and what if we wanted to scale up to very large? This is the problem that we aim to solve with routed provider networks. So, there were two ways you could scale this up in Neutron. We talked about scaling up the L2 network to very large. The other way you could do it before is to create multiple provider networks. You know, just segment your network into multiple networks. The problem with this from a user standpoint is that if you make your users come in and choose between a set of different networks without any real differentiation between the networks for them to choose which one to boot to, that just creates a confusing environment for users.  I just, you know, I want a public IP address. Now I've got 12 choices. I've got public network one, public network two through public network 12. That's not ideal for users. From a user standpoint, you just want one. You just, I just want to boot to the public network, right? So, this is what routed provider networks gives us. We can create one network from the user's point of view. So they choose just the one public network. But behind the scenes, we can segment this network into multiple L2 domains that are easier to scale. And then we provide the routing between them to make it one contiguous L3 domain. So that was the motivation. I'll go into how we implemented this in Neutron. So we started with segments. Now, segments are not new in Neutron. In fact, segments have been around in the ML2 plugin for quite a while. And you could even have multiple segments within a network. Now, the problem was the assumption with multi-segmented networks in ML2 was that there was an underlying assumption that all of the segments were bridged together into a large L2 domain. And that was what we didn't want. So we had to have some way to distinguish between legacy multi-segment networks in ML2 and a segmented network that's going to become a routing network. And in fact, if you're using the ML2 plugin, your network has a segment associated to it, at least one, even if you haven't used the multi-segment extension to ML2. So if you're unfamiliar with ML2 segments, a segment is defined by three pieces of information. The first one is the physical network. That's really just a name that you give to the physical network that hosts the L2 domain. And then there's a segmentation type or network type, and the segmentation ID. So for example, you might call your physical network, my network, and you're using network type VLAN and segmentation ID 2016. That's an example. So what we did was we decided to take this segment idea from ML2, and we actually kind of promoted segments into neutron core. So they're no longer part of the ML2 plugin, they're no longer only part of the ML2 plugin, but they're part of neutron core. So the neutron core model now has a segment, and we provided an API for segments. So now you can, a segment is now a first-class thing. It's not just a piece, an implementation dutel under the network. It's now a first-class thing, and you can do CRUD operations on it. And whereas before, you could only create segments along with creating a network, now we can create a network with segments, and later on we can add segments to the network, and we can delete segments from the network. So the network can grow and shrink along with the segments that we need to have with the network. And there's a lot of detail here, I'm not sure we need to go over, but it's important to know that there is now the REST API to interact with segments. Now this is actually a pretty important slide. This is the thing that distinguishes a routed provider network from a legacy multi-segmented network. And it's that we can now associate subnets to individual segments. Before this, subnets were just a part of the network, and it was assumed that anywhere since the network was one contiguous L2 domain, it was assumed that any subnet that was on the network was available anywhere on the network. Well, we're breaking that assumption now. And what we did that by adding a new field to the subnet that is the, it's kind of squeaky, we added a new field to the subnet that is the segmentation ID that that subnet is associated with. So once you take a subnet and you lock it onto one of many segments within a network, that's the way you distinguish the routed provider network from a traditional network. And this, you know, the diagram just shows that we've got different subnets in different areas. So this first one, the way you imagine it is the subnet is now confined to a small part of the network instead of available everywhere in the network. And we added another attribute that's kind of important here. We added an attribute to the network called L2 adjacency. Now what this does, forever in neutron since the beginning, networks were L2 things. And there's been a lot of discussion, I bet there's been discussion at every single summit since neutron began, is network just an L2 thing or is it, can it be something else? Well this, adding this attribute L2 adjacency, this is formally saying now a network doesn't necessarily have to be just an L2 thing. And we're going to give you this attribute on the network so that you can tell if it is an L2 network or if it isn't. So if you read a network and you get L2 adjacency, if you get a false back in that field, that means that your ports may not be able to send L2 traffic to each other because on a routed provider network it might be that your ports landed in different segments and L2 traffic isn't going to be carried across them. If you have for example a Calico network, a Calico network will always show L2 adjacency false when this flag is implemented in that plug-in because it sets the expectation that L2 traffic is not going to be carried from port to port which is actually breaking an assumption that's been in neutron for a long time. And the other consequence of breaking L2 into parts is that now we need to think about providing DHCP in each of the segments because DHCP is a protocol that requires L2 adjacency, right? And we just broke that. And so given the way that neutron provides DHCP with a DHCP agent that connects to the network, now we have to have at least one DHCP agent in each segment. So that's kind of a consequence of deploying provider networks is now you have to think about providing the DHCP server for each of your segments. Now, the next thing we had to deal with in order to implement routed provider networks is how does a port behave? What happens when you create a port on a routed provider network? So if I go and I say I still have the neutron command line in my head, I don't have the open stack command line in my head, but if I say neutron port create and then, you know, routed provider network what happens, what do you get back? Well, you can't get back an IP address on that port because it doesn't know which segment you want to be on. The port just exists on the network, but the subnets exist on segments, right? So what we did was we give you back a port and we set a new attribute. The attribute is called IP allocation. We set that IP allocation. Think of it as kind of a policy when and how IPs are allocated. We set that to deferred, and then the fixed IPs is empty. Now, doing this allows you to take that port and hand it to Nova without Nova complaining that, hey, you gave me a port without an IP. What's up? This communicates to Nova that, hey, I know I gave you a port without an IP address, but go ahead and try and boot a VM on it and bind it to a host, and when you bind it to the host, then you'll get an IP and everything will be okay. So there's this concept, new concept of a deferred IP port that allows us to do this. And we had to go in and we had to change a bunch of stuff in Neutron IPAM so that we triggered IP allocation at the right time, which is basically when you hand the port to Nova and it tries to bind that to a particular host where it's going to boot a VM. And in order to do this, we added another model to Neutron which maps hosts to the segments they're on. Now, we tried to do this in a way that is kind of operator-friendly by reusing some configuration that you already have in your deployment. So if you've got agents running on your compute hosts for ML2, say either an OBS or a Linux bridge agent, then you've already got mappings in your configuration that allow us to create this host to segment mapping. And those are, in OBS, those are called bridge mappings. In Linux bridge, I believe they're called interface mappings. And those you configure the agent with, the bridge mappings and the agent actually sends those to the Neutron server.  But what is new is on the Neutron server side, we actually open up that mapping and we say, hey, there's a mapping. There's an agent, there's... My mind just went blank. The mapping has the agent's hosts and... And the bridge mapping. And the bridge mapping, right? And we actually take that and we resolve that to which segment that host is connected to. So we keep that mapping. And when you go to bind a port that has no IP address because it's deferred, we take that mapping and we say, okay, now I can find a subnet to get that IP address from. So this is jumping a little bit off topic. This is actually something we have not yet completed. Everything in the slides before this is done and merged in Newton. The issue here is that we can't yet use a routed provider network as a router external network. Now, if you're familiar with the router external, setting router external on a Neutron router, what that means basically is that this router can host floating IPs. So imagine if you took a router and you set that router's gateway to a routed provider network. That's saying that this routed provider network can get my floating IP to this router interface. Well, the problem is now we have a routed network out there and we have floating IPs that aren't really... You don't want your floating IPs to be stuck on one segment. You want them floating. And that's a problem we haven't quite solved yet for Newton. And we hope to get it solved for Okada. So the other point I wanted to make on this slide was that with a routed provider network, we actually could take the Neutron router out of the picture for floating IPs. And in fact, there's one operator, Godaddy, that I've talked to a lot about this. They actually have an implementation of this in their data center where they boot VMs to a routed provider network-like thing that's very similar to what we have here. And then they have the ability to create floating IPs and associate them directly to those VMs. And they do that... I don't remember exactly the motivation, but one example is you could boot your VM with a non-public, non-routable IP address, and then your floating IPs could be routable public IP addresses that you could selectively associate with VMs on that provider network. Which I think would be pretty cool. And I'm going to pass on to Miguel to talk about what we had to do with NOVA and scheduling. So the other side that we need to address in this implementation is that now when NOVA creates a port for an instance, it has to make sure that the compute node where that instance is scheduled is connected to a segment where there's still IP address availability. Segments might run out of IP addresses, so we need to make sure that NOVA has the information necessary to schedule that instance in a host, in a compute node, where we are going to find IPv4 addresses available. So that's pretty much what we want to say here. And essentially in this graphic what we are saying is that segment 3 has no IPv4 addresses anymore, so therefore next instance needs to be scheduled to any of the other racks. So on the NOVA side we are moving right now, up until now in NOVA, all the wiring of the instance sports has taken place in the compute manager. In other words, NOVA schedules the instance to a specific compute host and code the compute manager running in that compute host takes care of wiring the neutron ports for that instance. What we are doing now is moving that out of the compute manager, we are moving all that functionality to the conductor, and it's going to take place in the NOVA server. And once we do that, we have the possibility of having four use cases when we provide ports to an instance. The user might create a port manually, and the boot provides that port ID to the boot command. And let's say that port has no IP address. In that scenario, what NOVA can do is schedule the instance to any segment, to any rack where available IP addresses. Where IP addresses are available. Now let's second use cases, one in which the user creates a port and assigns an IP address to that port. So when we give that port ID to the NOVA boot, NOVA now has to find where that IP address is located in the segments of the routing network and schedule the instance to a compute host connected to that segment. Third use case is one in which we boot the typical case where we boot the instance just providing the network ID. And in that scenario again, NOVA is going to be able to schedule the instance to any segment where IP addresses are available. And finally we have the instance move case where the instance already has IP addresses. So when we are going to move the instance from one host to another host, that host needs to be in the same segment. Otherwise the IP addresses are not going to work. So for all this to happen on the NOVA side, we need to provide NOVA with information of the topology of segments on the neutron side. The NOVA scheduler now needs to know how the segments are mapped, how the compute host are mapped to segments, and using that information then the NOVA scheduler can do the proper placement of the instance. So to accomplish that, we are using a new API on the NOVA side and that's the generic resource pools API. That's work that has been done already on the NOVA side and essentially what we do is we create a resource pool and a resource pool is anything that can provide resources to an instance. Those resources can be storage blocks, can be IPv4 addresses, and another type of resources. So we create a resource pool and with those resource pools we associate inventories. Inventories of those resources available for the instance. And we also associate with a resource pool aggregates. In other words, collection of compute hosts that are associated with that resource pool. Specifically in neutron what we are doing is we are creating a resource pool for each segment in each router network. Every time we create a segment in a router network, we create a resource pool and every time we associate a subnet with a segment, with that segment, we are going to update the inventory of IPv4 addresses available in that segment. So let's say I have segment A and I associate subnet number one. At that point in time what we are doing is we are sending information to NOVA saying from this point on this segment ID, this segment in this router network has this many IPv4 addresses. And then let's say I associate a second subnet to that segment. So what we are going to do is we are going to increase the inventory of IPv4 addresses available in that segment. And also with each segment we associate an aggregate where in that aggregate we update the hosts that are connected to that segment. And that's where the segment host mapping that we are keeping in neutron that Carl mentioned a few minutes ago becomes very, very important. Because on the neutron side we know which segments are connected with which hosts. And that information we communicate to NOVA so NOVA can do the proper placement decision. So as far as configuration essentially there's some physical preparation that needs to take place. First of all we need a unique physical net per segment. We are going to assign a VLAN number per physical net and those VLAN numbers can be reused across physical net. As Carl already mentioned we are going to need a DHCP agent with each physical net and the routing architecture that is used for the router network is really up to you. It's really up to the employer. From a neutron configuration point of view you need to configure the service plugin which is not configured by default. You need to set up your bridge mappings and in the case of OVN another mechanism is being implemented. Then you create your network and then you start creating your subnets associating your subnets to segments. And that's the operation that makes this network a routing network. So let's see how that works. So we are going to show you a little demo that we put together. Essentially in this demo we have four nodes. We have an all-in-one node where we have all the services running. We have three computes. In Compute 2 we also have another DHCP server and we have two segments that makes this router network, segment one and segment two. All-in-one and Compute 1 are connected to segment one, Compute 2 and Compute 3 are connected to segment two. And we have an IP router which in our case is just a VM doing IP routing between the different segments. What we are going to try to do is to show you how this works. So this is the network that we are using and as you can see we have the two segments on physicalnet one and physicalnet two and we are using segment ID 2016 for the router network. And now what we are going to do we are going to create a couple of subnets and as you can see in the subnet create command I associate a segment ID to the subnet. That's the last part of the command. And that's reflected in the subnet that was created close to the bottom. You can see that now we have a segment ID attribute and that segment is connected to associated with my segment number one. Same thing with the second subnet and now I'm going to show you that we created two aggregates on the nova side. We have one aggregate associated with my first segment and another with the second segment and within those segments as you can see I have in the first segment I have host all in one and compute one associated to it and compute two and compute three to the other one. Another little piece of information that I wanted to show you is that we have two new resource providers on the nova side. This is something that is happening on the nova side. We don't have a CLI client yet so I'm using PDV to play with the Python client to show you the information. And as you can see we have a resource provider for both segments and I'm going to show you let's speak that with each one of those segments there is an inventory of IPv4 addresses. In this case this inventory has 2253 IP addresses available for instances. So now let's create a port and in this case let's create an onbound port and there are two important things to note here. Number one in the fixed IPs attribute we don't have any IP addresses. And in the IP allocation attribute this port is marked as deferred because this port is going to get its IP addresses once we bound we bind the port to a host. Now let's do a port create but let's create a bound port and in this case indeed we get IP addresses and the IP allocation is immediate. Why? Because we are telling we are telling when we created the port in the port command I'm specifying the host ID where I want that port to be bound. So now let's create a couple of instances so our instances are ready and good to go so I'm going to use the HCP name and space to log into one of those and we are going to see that we have traffic between them. Oops. I'll show you some tricks later. What? I'll show you some tricks later. What line is this? You might just remove the file. So we should have traffic to the other instance that's going to be... Yes, we have traffic to that. So what's happening here is that we have one instance on one segment the other instance is in the other segment and we have traffic here. So that's pretty much the presentation we prepared for you guys. I think we're at time. Do we have time for questions? We're at time, 12.30. So if you have questions we'll be up here for a few minutes. And this demo is in my GitHub account so feel free to download it and play with it and it completely configures the whole router networks for you so you can play with the functionality. All right, thanks everyone.


Today on the show. We're taking a look at Superman the man of steel number 20 from February of 1993 This is funeral for a friend number three. So stay tuned Hey guys, welcome back to comedy and TV. We're all geek culture collides. If you're new to the channel Don't forget to hit that subscribe button so you don't miss out on future videos All right guys as I said, this is Superman the man of steel number 20 from February of 1993 funeral for a friend number three I just finished reading this issue. I Never actually read it before And I have to say the end of this issue is very emotional. It actually brought a tear to my eye I'm not ashamed to say it was written by Louis Simonson With art by John Bogdanov. I guess you pronounce it. I'm not sure The first page or two of this issue kind of had me a little bit worried because the art was slightly different Is more exaggerated Kind of like how the early issues of steel were Just very over pronounced. I guess you could say in that more Partoonie style, I guess. I don't know. It's very hard to describe. I don't care for that style But luckily late as the issue progresses It gets back to the normal death of Superman Style and as you can see here this in this issue, this is where they bury Superman in the crypt On the front cover here, you've got Batman and Robin lurking off in the distance watching over everything You got Mr. Miracle Guardian Bibbo Green Lantern flash Supergirl Wonder Woman shazam or at this point in time Captain Marvel Aquaman Nightwing and I believe that's fire right there And as you can see this was at a time when the comics code authority was still in use I don't believe they're really in use anymore. I I never see comics anymore with the comic code authority on it See this is what I mean by over exaggerated Very Cartoonish like style here Don't really care for that Lex Luthor is making the arrangements for Superman's funeral But as you can see they start to get back to normal This you know Lex says try as I might I couldn't kill Superman But sure as hell. I'm gonna bury him So that sets the tone for why Lex is doing everything he's doing For Superman I guess you could say then we've got we joined Jonathan Martha Kent who aren't able to be at their son own son's funeral They kept a secret identity even in death. That's how they that's how he was able to come back and You know Be Clark Kent again Then Jimmy Olson has taken everything pretty bad One of the reporters his name Dan, I'm not sure but he's kind of He's more of a he wants Jimmy to take the glory of such an iconic picture and He's not understanding why Lois is so upset even though Clark is missing Missing sorry Perry's been invited to the funeral Lois wasn't But he offers to let her go in his place, but she doesn't know Lois goes up to the roof out of habit in Morning, I guess that's where Superman often met with her and it shows here that they've placed a plaque at the site where he fell and Jimmy comes and takes her to the funeral procession right there Try to get through and as you can see the entire Justice League is marching with the casket we've got Booster gold right here Who's Not really in his uniform since it got shredded, but he's still in the mask and like what looks like a jacket or whatever We got ice and blood wind I'm not sure who that is in the crease, but we've got a long-gated man guardian Wildcat power girl green arrow Green Lantern fire black canary Wonder Woman Flash Aquaman Captain Marvel Alan Scott's guy gardener Jake Garrick Obsidian back here. I think that other that one next to kill a log is one of the black Hawks But as I said kill a log Right there we've got Nightwing I Can't remember who that is Maxima Dr. Light the female dr. Light dr. Fates I think that's Orion Can't remember his name for the life of me And then you know so on and so forth we don't see Batman and Robin here They've kept to the shadows At this point, you know for those of you Who've looked to see who's all in the funeral procession? Which I see the metal men there Big Barda mr. Miracle So on you don't see Batman and Robin in there, but you see Nightwing You have to remember that Superman gave Nightwing his name Dick Grayson knew Superman since he was a little kid Always working alongside Batman. He knew Superman as well as Batman did We see all the people in metropolis grieving over Superman's loss and Here's a family he saved from a fire One lady says they say Superman was an alien Funny isn't it since he was also Earth's greatest hero A guy who got pulled out of a wreck Lois Lane and Jimmy Here's all the issues that Funeral for a friend takes place in Justice League America number 70 adventures of Superman 498 action comic 685 Superman the man of steel number 20 Superman 76 Adventures of Superman 499 action comics 686 Man of steel 21 and Superman number 77 And that's not including the official tie-ins as well like Justice League. Oh, actually, yeah It is there. I'm sorry, and I think Superman number 77 was the epilogue But we'll go over that in the future.  This is our first first sighting of Batman in this issue He's not down with the rest of the Justice League. He's watching over everything Doing things Superman's way. He noticed the bomb in the guy's jacket And the guy says No, don't drop me I'll turn myself in anything just don't drop me Batman Don't tempt me, but Metropolis is Superman's town and for today I'll play his way He just leaves him hanging there with a sign that says please arrest me Then we come to dr. Emile Hamilton the underworlders Bibbo and some guy who Superman saved from a burning building at one time selling a Death of Superman t-shirts and a a Bag that includes the newspaper and the armband all together and he's telling them because You know Superman Did save him and his family from the fire, but now they're homeless and he's still got to feed his family Bibbo's about ready to just pound this guy until he finds out and he says all right Superman was my pal. So we'll do things his way all by all of the merchandise $300 worth of merchandise and Come see me later. I'll give you a job And there we see the pallbearers of the Justice League those who fought alongside Superman during doomsday's Arrival ice blood wind Booster gold there in street clothes, but still wearing his you know visor and stuff Guy Gardner Maxima and Supergirl all Carrying his casket and then we got some thugs who are trying to Get Jimmy to sell them the rights the licensing rights to his photo and they're they're about ready to Do some bad stuff until Robin comes in and Then the crowd just starts getting crazy and the Justice League have to take action and Jonathan and Martha are just overwhelmed They're not able to be there at his at their son's funeral and they're just devastated by What the people are doing at that time? It's turned into a mob scene and all the while Lois keeps wanting to call them, but she's afraid that they'll blame her And then we've got president president at the time Bill Clinton and Hillary Clinton Making the speech Lois she she finally tries to call Jonathan and Martha, but they decide to more grieve for him in their own way by bearing a box of his stuff Through the years in the crater where they found him originally scrapbook his teddy bear is blanky his Baseball glove or his baseball mitten baseball Wonder Woman and Green Lantern seal the tomb Everyone's looking on Here's the emotional part. Lois finally manages to get through to Monpoch hint And this is where I kind of started tear up a little bit. If you have a chance to read it Louis Simonson really has a way of making you feel this moment with the dialogue Mom Paul Kent don't blame Lois at all She's just heartbroken. I Was there all the time? Clark fought doomsday and all I could do was report on the fight and watch him die I couldn't do anything but watch him die Listen to me. Lois.  Hold on a little while will be right there So that Even now it kind of makes me choke up a little bit Very very heartwarming very very sad Final page It really Shit just re-reading that panel with it kind of brought a tear to my eyes but I Really suggest picking up Superman the man of steel number 20 funeral for a friend number three if you have a chance At the time of this filming comex ology has the entire funeral for a friend Graphic novel in their digital copies for 599 I picked mine up last night Along with the death of Superman along with the reign of the Superman and return of the Superman or return of Superman I'm sorry And as I said previously I will be doing a retelling with images from the story In my off-season probably around December sometime We'll start with the death of Superman. We'll go into funeral for a friend reign of the Superman and The return of Superman I'm hoping to make it a four-part video series But we'll see If you guys enjoyed this video make sure you hit that subscribe button I'm Shannon for come again TV the only place on YouTube where all geek culture collides Take care my friends


Just opened 70 new units of affordable housing here in Kelowna part of our strategy across the province We need to make sure that homes home ownership Places to live remain within the reach of British Columbians who've worked so hard to build this province


Welcome to the Endless Knot. Today is no ordinary episode. Today is an average episode. Actually, I have so much to say that it won't fit into one video, so I'm averaging it out over a three-episode series. People often seem to want to predict the future. I mean, after all, horoscopes are still regularly published in newspapers and magazines. Businesses are always trying to predict what consumers will want and what the economy is going to be like next year. And in Norse mythology, the god Odin was always after wisdom and knowledge, particularly about the impending Ragnarok, the Norse version of Doomsday. So much so that he even gives up one of his eyes for wisdom. And speaking of astrology, it's thanks to that that humans started studying the universe around us. It's why we invented constellations and star charts. But soon enough people started to use those constellations and star charts for navigation. One of the most influential star charts was produced by the Greek Ptolemy. The work was originally titled Mathematicae Syntaxis, meaning mathematical treatise, and in fact was a work on Greek mathematics with a special focus on the mass of the apparent motion of the celestial bodies as the Greeks saw it. No mean feat, as the Greek conception of the cosmos had the earth in the center with everything else revolving around it, like giant glass spheres. A notion first introduced by the philosopher Aristotle. This geocentric conception came to be known as the Ptolemaic model. The catalogue of 1,022 stars within their constellations was only part of this great work, but it would become important to celestial navigation in later eras, especially when European sailors gained the necessary naval technology to sail away from side of land into the deep ocean. But it was due to the Islamic world that the medieval west had access to this treatise, as it had been translated into Arabic and from there into Latin in the 12th century, making it available to Europeans. Its name had shifted to Hei Megalei Syntaxis, the Great Treatise, to simply Megiste, Greatest, which was rendered into Arabic as Al-Majisti, leading to the European name Al-Majest. This is an example of the enormously important contribution of the Islamic world, who transmitted and built upon the knowledge of ancient Greece to European learning. Christian Europeans generally had no access to or ability to read ancient Greek texts in their original forms. As we'll see, the Islamic world is above average in importance to our story in a number of ways. And this brings us to the word average. The earliest senses of the word have to do with maritime shipping. In English context, it originally referred to a customs duty or expense over and above the freight incurred in the shipment of goods and payable by their owner. The word seems to come from old French avai, which meant damage to shipping and by extension any expense, with the A-G-E ending coming by way of parallel to the semantically related damage. And since the usual practice was to share out these expenses between all the owners of freight on the ship, as well as the ship owners, kind of like an early form of insurance, the term gained the mathematical sense of the arithmetic mean, from the idea of distributing a sum between a number of people and the sense of typical or usual developed from there. Now, the deeper etymology of this word is a matter of some speculation and disagreement. As the Oxford English Dictionary puts it, few words have received more etymological investigation. But the explanation that seems to carry the most weight, and the one we're going to go with here, is that it comes from Arabic awariah, damaged goods from awar, blemish or flaw, from awira to lose an eye, from a protosemitic root that means to be or become blind. Kind of recalls Odin giving up his eye. And in a way, this is fitting since average in its maritime shipping sense, which is the beginning of insurance, is all about making plans for future contingencies. The practice now referred to as general average was to share out the losses in freight, if for instance some had to be jettisoned overboard in the event of a storm at sea in order to save the ship. The sailors therefore weren't faced with the decision of what to jettison on the basis of who owned it, since all the freight owners would share the expense of the loss. This practice goes back a long way and can be found in the Lex Rodea, a maritime code from Rhodes around 800 BCE. The law disappeared after the fall of Rome, but the principal was revived in the roles of Olaron, promulgated by Eleanor of Aquitaine, after returning from the second crusade around 1160 CE. There were of course other ancient forerunners of insurance by distributing or transferring risk, such as the 3rd century BCE Chinese practice of distributing goods among several vessels, in case one capsized in river rapids. And in the Code of Hammurabi, from around 1750 BCE, a merchant taking a loan to fund a shipment could pay an additional fee granting the loan would be cancelled in the event of theft or loss. By the way, the Code of Hammurabi also records the first evidence of interest bearing loans. But in any case, the first example of actual contract insurance for maritime shipping dates to 1347 CE in Genoa. Actual insurance laws became codified in 15th century Barcelona with the first statute in England in 1601. Insurance brokers kind of grew up organically from there, and funnily enough, we have coffee to thank for it, which is appropriate since coffee is another of those things that Europe got from the Islamic world. The word coffee came into English through Dutch and Italian from Turkish Kave, which in turn came from Arabic Kawa. The ultimate origin of the word is debated. Some trace it back to the Kaffa region of Ethiopia, where coffee was originally grown. But a more likely etymology is that it comes from a protosemitic root, which means to be or become dull or dark. Thus meaning dark stuff, appropriately enough. Interestingly, the word seems to have originally referred to a kind of wine, also dark in colour, until the Islamic prohibition against drinking alcohol made the word obsolete, whereupon it shifted over to refer to coffee, a non-alcoholic drink, which nonetheless had a pleasant effect on the drinker. The drink itself made it to Europe in the 16th century by way of Turkey. It arrived in England before the end of that century through trading by the Dutch and British East India companies, and soon coffeehouses sprang up in Europe, and they soon became centres of social life and business. For instance, the Café Parcope in Paris was where Denis Diderot and Jean Laurent D'Alembert brewed up the idea of creating the first modern encyclopedia. But more important to our story is the coffeehouse opened in London in 1686 by a man named Edward Lloyd. You see, shortly after it opened, it was relocated in 1691 to an area called Exchange Alley, which was conveniently located near the Royal Exchange, where the exchange of goods was carried out. As a result, people involved in trade and commerce began to congregate at the nearby coffeehouses, such as Lloyd's Coffeehouse. Lloyd installed a pulpit from which shipping news could be announced, and for the benefit of his patrons, engaged in their wheelings and dealings, began to compile a list of ships engaged in trade, which included information about the condition and seaworthiness of the ships, both in terms of the state of their hulls and the quality of their equipment. That way, you'd know what trade venture to underwrite. He used an alpha-numerical rating system. A1 was top-notch, both in terms of hull and equipment. That's where we get the expression A1 for something that is first-rate. At the time, a ship's hull was vulnerable to shipworms, actually a species of saltwater clam which bored into the hull. The solution for shipworm was to coat the hull with a mixture of tar and pitch. No problem for England, as their American colonies produced the necessary stuff. But after American independence, England was in a bit of a pickle. Eventually, a solution was found in sheathing the hull in copper, and that's where we get the expression copper-bottomed, as in a copper-bottomed investment, a really safe bet. The practice began with the Navy, but was soon adopted by commercial ships, and in 1777, the first such ship was listed in Lloyd's Register, and by 1786, there were 275 copper-bottomed vessels. And in case you hadn't guessed by now, Lloyd's Coffee House eventually became the great insurance market, Lloyd's of London. So thanks to Islamic prohibition and maritime shipping with its distributed averages, we have insurance brokers. Thanks for watching, and I'll be back very soon with part two of our look at the word average, in which we'll investigate the history of probability mathematics and property insurance. If you've enjoyed these etymological explorations and cultural connections, please subscribe to this channel or share it. And check out our Patreon, where you can make a contribution to help me make more videos. I'm at alliterative on Twitter, and you can read more of my thoughts on my blog at alliterative.net.