Aseem will be speaking on the topic of organ donation among Muslim communities, reading interventions through the lens of applied Islamic bioethics. Good evening. It's a pleasure to be here to round out the near end of a long marathon. I want to try to keep it short today and give you an overview of a few concepts, hoping that we can have an engaged discussion at the end. So thank you Mark and Peter for the introduction. I'd like to talk to you a little bit about Muslim communities and Islamic bioethics.  I'll introduce just two concepts related to Islamic bioethics. The first being that judgments and Islamic law are non-binding. Judgments and Islamic law are called fatawa or fatwa singular. So they're non-binding. That's the first concept. The second concept is that there are different types of Islamic scholars, that they're not just one monolithic body. So two of those different scholars I would call one academic and the other spiritual. And that will be important because at the end of that, at the end of this talk I'm going to talk about organ donation interventions that have been done amongst the Muslim communities in light of these two concepts. So to begin our snapshot view of the Muslim world and organ donation, there was a few studies done in the West. The first one here was done of an internet survey done of Muslims living in the UK, the United States, and Canada. They had an N of 891 and they assessed a lot of different measures. One of them was around organ donation attitude. And in this study they found that only 39% believed organ donation was compatible with Islam. And they had several measures of religiosity. Predominantly it was about intrinsic religiosity. So how important is Islam in your life? And they found that individuals who had a higher level of intrinsic religiosity were less likely to hold positive views for organ donation. Building upon this, I did several studies in Michigan where I was before I went to the University of Chicago. And one of them was a population-based representative survey of Arabs residing in three counties in Michigan. We had about 1,000 people in this survey. We found that Muslims as opposed to Christian Arabs were 1.5 times less likely to believe that deceased organ donation was justified. And we controlled for socioeconomic factors, education factors, language factors, healthcare access issues. This was an independent predictor of negative attitudes. I wanted to see how prevalent this was amongst Muslims who are not of the Arab ethnicity. So we did mosque-based sampling with South Asian Muslims as well as African American Muslims. And in that group we did a very small pilot survey and we found the same finding that 55% believed that deceased organ donation is not justified. So I'm going to just give you one or two data points from Saudi Arabia which may be considered to be a very Muslim country, a very conservative. Interestingly enough, Saudi Arabia has the largest organ transportation program in the Middle East. If you include Iran and Iran, they vibe with each other on how big they are. So survey done in Riyadh. Riyadh is a very cosmopolitan city within Saudi Arabia, with South Asians as well as Indigenous Arabs over there. I made a survey from a health clinic where they found 56% believed that Islam permitted donation. So it was 56%. You would think it would be much higher given that they had a huge transportation program within Riyadh itself. They did a survey of high school students in Riyadh, 830 students. Here the minority, less than half, 42% believed that Islam permitted organ donation. So this is just a snapshot, but in general when you look at the dozens of studies that have been done within Western countries, Western contexts as well as those within Muslim major nations, you find that Muslims are less likely to support organ donation. This is just supporting by lip service. To give you an idea of what happens in the United States, there are some advocacy groups that say 90% of the United States population supports organ donation and 57% would be willing to donate. Now we don't know how that attitude willing to donate translates to will donate, but at least they give lip service to the fact that they support organ donation. And many believe that it's ethically justified. Muslims, on the other hand, have this problem where they don't know if it's compatible with Islam or it's ethically justified, and they are less likely to sign a donor card. So this is the empirical evidence where people suggest there's an independent Muslim factor. In my own study I found this is an independent predictor of negative attitudes towards organ donation. Hence, interventionists think, well, Islam might be the barrier towards organ donation. So this empiric Muslim reality begets a theological intervention. This is the second part of my talk. And before I get there, I would like to point out that these studies have had an impact upon the discourse, the popular discourse around Muslims and organ donation. So this first headline, organ donation describes Wales Muslims. So currently there is a, I think there is a bill in the parliament to have an opt out policy. Where in Wales you will be assumed to have presumed consent for organ donation, but the Muslim community there is adamantly against this. I actually got an email this week about it, asking me to kind of write something to the parliament there. So this is the headline from there. We have this issue in Egypt. This was several years ago where there was the Egyptian, the previous Egyptian government had felt that the poor Muslims in Tanta, which is a small city in Egypt, were being taken advantage of by Christian businessmen. That was the context. So they would come and buy their organs, give them money, and they would do transplants. So they wanted to ban this. But the headlines that came out was that Egypt seeks to ban Christian Muslim organ transplants. Like there was some religious issue here, but we didn't want to have organs go across religious boundaries, as opposed to this socioeconomic issue that was at hand. We have this here in the Netherlands. I'll just look at the last paragraph. So the Dutch health minister says, if you say I refuse to donate an organ because of my religion, but I don't want to receive one either, then I'll respect it. But I won't respect the one-sided attitude of receiving and not giving organs. I find that problematic. So they had found in a small survey in several cities that Muslims were less likely to donate, but they didn't see that they were less likely to receive. And hence they said, well, this is a problem. Why will Muslims receive organs but not donate? And this is a survey that was done in many different countries around different religious groups. And the headline of that survey in the news media was that Muslims are the most opposed to organ donation. I mean, comparing to Christians and Jews, the Muslim population, when they say they are affiliated with Islam, are most likely to oppose organ donation. So there is a social political climate that this data plays into. So the second part of my talk, we'll look at Islamic scholars here who look at organs in the body and they decide whether or not the Muslim community should become repoments where they take organs from one and give to another. Before I get into this idea of Islamic law and Islamic bioethics, I want to put this up there. And the reason you're going to read this from the right to left is because the Arabic script goes from right to left. And I sometimes forget which language I'm speaking in and I want to make figures that come from right to left. But in any case, there you have Islamic law, which is based on a revelation of the Qur'an, which is believed in the holy book, and the sunnah, the sayings of the prophet. So you get normative values that come from these two textual sources. And then you have things that are part of mankind's sort of, we can call them, ethical moral character. So when Islam judges upon something, the law system judges upon something, either comes out of these sources and you can simply be part of law. They have ethical, moral content, positive law. Or you have things that reside within the common humanity and then the revelation confirms them as positive values. So this is how normative values come out from the tradition. In the case of Islamic bioethics, you have other data here in the blue boxes here, blue figures here, from clinical practice, social science, the medical sciences, contemporary discourse around philosophy and bioethics and health policy, which all give data to these scholars of law to come up with judgments around Islamic bioethics. So simply what happens is that you have either a singular scholar who is a textual expert of the law who looks upon the data from the clinical practice or other quality sciences and issues of legal ruling. You can have many of them. Or they sit together in a council and they come together to some sort of consensus statement and again they issue a fatwa, which is the first concept of Maranjijan to know about. So a fatwa is a non-binding legal opinion. You can have many different legal opinions. They all are considered to be the same and equally right. And these fatwa are taken up by three primary audiences. One would be the patient themselves or the health care institutions that take care of most of the patients and the idea that you want to provide culturally sensitive and appropriate care. So what does the religion say about XYZ? The second audience or consumer are Islamic scholars, second level scholars who have researched the opinions and offered their own advice to the Muslim patient or provider population or academic researchers, which is myself, who look at this material as part of the religion and science discourse. And the third primary audience would be physicians themselves or health care practitioners who want to understand the boundaries of their medical practice in light of Islamic ethical and moral discussions. So I'm just going to look at the medical literature here and what they say about organ donation. Now bear in mind, as I presented to you, the Muslim communities are more likely to have negative attitudes. So the question is, what does the law say? Well, the legal system here, the end line here and the results that I snipped out here, I hope you can read it, says that all fatwas, all 70 fatwas that this group looked at allow for organ donation and blood transfusion. They did not find a single one that said that it's not permissible. These include five former grand muftis of Egypt and the Saudi senior alumna council, the Islamic Fiqh Academy of the Organization of Islamic Conference and the European Council for Fatwa and Research. However, there's also a minority view that declares it impermissible. Some of them only restricted to living donation. Others say both living and dead is impermissible.  They decide not to judge around organ donation. So there was no change even 10 years after of any of the organ donation attitudes in the Muslim population nor was there an increase in donor rates from the Muslim community. So the question is why? So I'm going to, for a moment, look at this paradigm of Islamic scholarship per second. So you have a scholar here who's sitting at his desk. He's reading a lot of texts from religious sources and he's thinking about what are the root values or the normative values in Islamic law? How does that apply to organ donation? He's an academic, what we call an almi scholar in Arabic. He's trying to figure out what God wants us to do. What are the textual sources, the Quran and the prophetic statements? What do they say about us in action? On the other hand, you have another scholar who might be a teacher at an Islamic school or a Sunday school who might be the imam at a mosque and gives a sermon on Fridays. He might be a chaplain who takes care or gives counsel to patients in the hospital. He's what I would call an Islahi scholar. Someone who's concerned with the spiritual warfare of the community. His goal in life is to encourage people to care about what God wants you to do. So on one hand you have this can I do something from Islamic law? On the other hand, should I have an inner disposition to want to do what God wants me to do or what God says is permissible? And I think this sort of idea here, if I play it out in the contemporary theories around health behavior change, I will become clearer. So at the end here, you want someone to sign a donor card or donate their organs. What the theory of planned behavior says is that the most proximate predictor of someone doing an action is their intention to have that action. So 50% of individuals have intention to do something will end up doing that thing. So what you want to intervene upon is to have people form an intention to do something. And there are three components to forming an intention. They say the attitude, someone's overall attitude towards donating organs of various different beliefs, but they have some to become an overall attitude towards something. The subjective norm, which is how individuals who are important to you view you're doing the action. So in this case, our organ donation, which is so important to me, be there my mother, my sister, my wife, my religious leader, my whoever, how do they believe, what do they think about my donating organ? And the third component towards forming an intention is perceived behavioral control. So if I want to do something, in this case I want to sign an organ donor card, do I believe I have control over doing that? Am I empowered and have agency to do that? So these are the three components of forming an intention. And the most behavioral intentions work at the subjective norm component. So in the end, I think there are clear implications for Islamic biotics interventions. First, that these Islahi scholars, or the locally MAMS, must be involved. The second is, and I think this is the issue for me when I think about these things, there's a pluralistic theology in Islam. All Fatah are equal. If they're all equal, then should we really be promoting organ donation? I'm going to skip over this for a second. To give you two snapshots from my own interviews of religious leaders in the community. And this is what they said. So about the idea of using religion to promote a health good. I think using religious venues and sharing common values is okay. So going to the mosque and encouraging women to get mammograms and prostate exams to get colonoscopies, that's totally cool.  That's not my understanding of my religion. And then we talked to someone who was involved with healthcare chaplaincy and said, you know, the only time they come to me, meaning the healthcare team, is to encourage the patient to do the procedure if the doctor says to do it. So the only time they involve me is when they want me to have the patient do something that they think is right. And I think this is a challenge for when we bring religion into the healthcare system. I believe that we should have a more responsible ethics. Healthcare response should be in this idea of our organ donation to promote informed choice. Not co-opting religion for medical end. And it might be reasonable to have Muslims who think about their choice and decide not to have organ donation. Thank you.


What is going on guys welcome back to the channel and I do appreciate you being here today I bring you another Borderlands 3 video and today we're gonna take a little bit of information from the Borderlands website more about the game going forward and so forth the story the family and eight unique weapon Manufacturers, which we're gonna that's good. That's gonna be the main point of today's video We're gonna take a look at how these weapons differ and how they are unique to each manufacturer But before we go any further guys if you do enjoy the video I would like to show you support you can by smashing that like button now this information is thanks to the Borderlands website Which you will find linked within the video description Also so you can see on the screen now discover the Borderlands at the hard edge of the galaxy lies a group of planets ruthlessly Exploited by militarized corporations Breeming with loot and violence. This is your home the Borderlands So you want to hear a story answering the call of the siren champion Lilith Four volt hunters charge headfirst into a spray of bullets blood and bandits to recover a map to ancient volts and Prevent a universe destroying power from falling into the wrong hands The rest is history now if you want to click to the timeline and read through past Borderlands storylines and so forth You can go to the website and do that yourself if you want Meet the family fearless renegade mercenaries on the wildest interplanetary treasure hunt of all time Flack is a wondering real but it trucker whose cold steel heart warms only for their pet beasts a Mara beats bad guys into pancakes with a sidekick of fists Moses best friend is a 10 ton walking killing machine and Zayn the semi-retired Corporate hitman. Well, he's Zayn cool Hunting alone it states score recruit fellow volt hunters regardless of your respective Levels and defeat their calypsoes with guns teamwork more guns and the power of friendship If you click no it states no problem shoot and loot your way through their borderlands discovering the regions untold stories and Piling high your increasingly deadly cache of goodies and weapons now moving on to brand loyalty Corporations vie for control of the borderland through military force their currency weapons their trade death each Manufacturer specializes in a different delivery method First up we have Mali wan Target between two elements charge your weapon and deal guaranteed Elemental damage with your finger glued to the trigger that sounds pretty cool people next we have Jacobs Deliver devastating critical hits to enemies soft and sensitive Then joy puke as your bullets ricochet towards other targets pretty cool Next up we have TDR toss your gun like a grenade to reload then watch it pursue a nearby enemy As a fully loaded version the destructs in your hand Next up we have Torg switch between regular and sticky projectile file molds Stickies do more damage if a bunch of them detonate on the same Target sound epic and you will notice how unique these weapons are to each Manufacturer next up we have Hyperion aim down the sides to take cover behind your weapons mounted shield and keep your finger on the trigger for increased accuracy Wow, they look incredible people next up. We have Atlas step one hit your enemies with tracker tags step two Unleash a hail of smart bullets that track towards your targets step three Again guys look how amazing these weapons are Next up we have Dahl toggle between alternate fire modes depending on your player story or predicament and your pre-delection for damage bonus And last up we have the lead off augment these rapid firing ammo hungry guns with under barrel attachments Including tasers rocket tubes and additional gun barrels and wow they look so so badass. It's unbelievable people But yeah guys those are the eight weapon manufacturers within Borderlands 3 It may be hold more we do not know yet now soon as any more information does drop on the game people Obviously, I will have you covered right here on my channel Another thing that people are speculating about as if you look on the Xbox store for Borderlands 3 if you want to pre-order it It does state cross-platform co-op now a lot of people are speculating whether this means Xbox and PlayStation. I'm not sure it does people I mean we've seen plenty of cross-platform play games before and it's normally Xbox and PC or PlayStation and PC. It's never really PlayStation and Xbox as amazing as that would be I'm just not sure it's going to happen, but we will see people we will see But I don't know guys we have come to the end of the video or just a quick video updating you guys and the latest news Sure and in the game if you guys enjoyed it Even though like really does help out if you are new around here and this is what you want to see more I'll be sure to subscribe and if you never want to miss a video I upload a content notifications on by hitting that Bow button but guys thanks as always for stopping by hopefully you enjoyed the video and hopefully I will see you on that next one


Hello, everyone. Welcome back again. I think I have the honor of doing the same talk twice in the same day, so that's something new for me. Again, let me, if you missed it earlier, essentially what happened was we started a little early, so I'm doing a rerun again. I'm going to introduce and start from the beginning. My name is Sohan Maheshwar. I work in a startup called Fermion, and we are in the WebAssembly space. And I've been working in the cloud and tech for a while now. I used to be with AWS before. And essentially, I'm super happy to be here, because A, even though I live in the Netherlands, I'm originally from Bangalore, so it's always nice to come back to Bangalore. And also, I'm glad we're talking about sustainability in tech. Because tech is at the heart of everything that we do. Latest estimates say that the software industry has the same amount or similar amounts of carbon emissions as that of the airline industry, which really is alarming. And all of us as decision makers in tech, it's time we can do something about sustainability. So I have to start off with this formula, which is defined by the Green Software Foundation. They define software carbon intensity of a workload in the cloud as C per R, which is the carbon per rate. Again, this is a rate. So it means per user or per API or per machine learning run or whatever. And the C can be expanded to O plus M, which where O is operational emissions, which is what is the carbon emission of your software that is running on a piece of hardware in the cloud. And M is the embodied emissions, which means for that hardware to exist and to run multiple pieces of software over a long period of time, there are carbon emissions. And your software is a fraction of that. Those two things combined per rate is the software carbon intensity. And essentially, I want us today to take a look at everything in terms of how serverless web assembly can make your software more energy efficient, where you use less electricity to perform the same function or make it more hardware efficient, where you're using fewer physical resources to perform the same function. So these are the two lenses that I want us to think about today. So let's dive into it. And actually, let's talk about WebAssembly itself. Anyone here uses WebAssembly or has tried WebAssembly? Few of y'all. Awesome. So just to tell you what it is, essentially, it's another bytecode format. That's the boring answer. WebAssembly is just another bytecode format. It was designed as a portable compilation target, which means you can write your code once in any language, like Python, Go, Rust, JavaScript, whatever. Compile it to a WebAssembly format and run that code anywhere, as long as that anywhere has a WebAssembly runtime. Now, this compile once, run anywhere, is possible because of runtimes, which are meant to be very portable. Similarly, if I say the word wasm, it's basically just short for WebAssembly. They're one and the same thing. This was invented and came about for the browser, and hence the name WebAssembly. But sometime in around 2018, 19, people thought, hey, WebAssembly is fast. It's portable. It's secure. All of these things might make it good to run in a server side as well. So originally, it was only for the browser, but now you can also run it on the server side. And it was made possible by something called WASI, which was invented in 2019, which is WebAssembly Systems Interface. Now, for anything to run on a server, you need things like system clocks. You need access to files. You need random number generators. You need all of this for anything to be a server. And WebAssembly didn't have that until WASI was invented. So this is a very new piece of technology that's actually available server side. And the good thing is it works independent of a browser. So all of the security sandboxing model of WebAssembly in the browser is available for us now on the server side as well. And it also includes this sandboxing for things like input and output. And just to visualize how it works, you have your code. Write it in any language, TypeScript, JavaScript, Python, Go, Rust, whatever. You compile it to a WASM format. And this can run in any place that has a WASM runtime. So it's independent of architecture, so Intel, Mac, ARM, it's independent of operating systems, so Linux, Windows, Mac, whatever. You can run it on Kubernetes, on your Raspberry Pi, in the cloud. You can run it in any place as long as there is a WASM runtime. Now, the good thing about WebAssembly is that all of these things that I mentioned to you, and we are going to look at it through the lens of this open source framework called SPIN. It's completely open source. Check it out on GitHub. About 4,500 stars right now supports 15-plus languages. It's a framework to compose serverless WebAssembly apps. And some of the benchmarks that we have done today in comparing WebAssembly, serverless, versus other things that exist in the market right now are done using SPIN. So there are four things that make WebAssembly pretty cool to run on the server side. And again, take a look at things in terms of being energy efficient and hardware efficient. When you're looking at scale, a metric like binary size actually makes a big difference. Think of all the deploys that we do on a day-to-day basis. Think of the number of deployments and builds that we run just for our testing on a day-to-day basis. Just to give you an example, a simple Rust Hello World compiled natively is about 2MB. And if you do an ahead-of-time compilation, where you are optimizing it for the architecture and the OS, you can bring that down to about 300 kb. Similarly, a SPIN app, a HTTP API, which I will show a live demo of, you can do a just-in-time compilation of where the size is about 2.3MB. And you can optimize it ahead of time for about 1.1MB. And again, these are really small binary sizes. If you take a look at any comparison with apps that we run right now.  So this is the CLI. If I can bring it, there we go. So I've installed SPIN, of course. I'm just going to do a simple SPIN new. Maybe I'll link it. I'm going to choose Rust, because Rust is low level. And I'm going to call it Qubeday India. This is a simple Hello World application. Nothing extremely fancy. So I will do Qubeday. And I will open this in my Visual Studio Code right here. All right. So anyone here familiar with the concept of serverless in general, or has used either Lambda or Azure Functions? Few of you all, I'm sure. Yes, perfect. I'd be surprised if people weren't. Or did I open a Swift? Oh, I'm so sorry. I'm just going to do this again. I want to show it to you in Rust. My bad, folks. I'm just going to do a SPIN new again. It's hard to look at the screen there while writing code. OK. There we go. That's Rust, finally. OK. I'm going to call it Qubeday this time. All right. And I'll say, and I'm going to open it in my browser. Sorry, in my VS Code. Yeah. So you don't have to be familiar with Rust and things like that. It's fairly simple. This code is straightforward. If you're familiar with the concept of serverless, it's a simple request in, request out. So there's a request that's coming in. You can see it here. And there's a request that's going out. I'll just change this to Qubeday for now. I don't know if that spelling's correct. Yeah, it is correct. I think my eyesight's going bad and I might need glasses. OK. I'm just going to do a build where it actually just builds this code. And I can run it locally. And we'll actually see the binary size of it just so that you know I'm not just putting a metric out there. There we go. It's just building the entire app. And so this is using SPIN, the framework that I was speaking to you about. And the build is done now. And I'm just going to do something called SPIN up, which basically runs this app on a local host. And I can just do a simple curl to the local host over again. There we go. Yeah, you can see hello Qubeday. So it's actually running right now. And if I go deeper into the directory, if I do an ls-l, you can actually see the wasm file. This is in byte, so it's about 2.3 MB. That's what I was speaking to you about. The binary size of HTTP serverless app is only 2.3 MB when it's written in WebAssembly using SPIN. So I'm going to go back to this right here. Now, typically when you're taking calls about metrics like sustainability, there are trade-offs you have to do. And the trade-off in this case is the startup time itself. Because when you're actually building something natively, it's a little faster than when you're building it on when the startup time in SPIN and WebAssembly. So it's about 2.3x slower than compiling it natively. The other advantage is the portability where you can build this once and run the same piece of code anywhere. The same 2.3 MB file that I showed you will be able to run across platforms, across OSes, and so much more. And the fourth thing is security. Because WebAssembly is security sandboxed by default. So nothing can access that file that I just showed you. So as a WebAssembly module, it's completely security sandboxed. Even if it needs access to a file, you have to explicitly give it access to a file. If you have to make an outbound HTTP call, you have to give it access saying make this call. Similarly, for an inbound HTTP call as well, again, this provides a greater deal of security too. Just to compare it with Docker, because I'm guessing that's a piece of software most of us are familiar with, on the left, you see, again, SPIN WebAssembly app in Python, a simple app. On the right, you see a Docker file with Flask. If this is the file size in Docker, the same thing in SPIN looks kind of like this. And again, in our benchmarks, we actually saw a difference of 23 MB to 550 kb. Again, look at it in the terms of being more energy efficient. Imagine making builds and running production workloads at the scale using WebAssembly, where the size of your binary itself is reduced so much, thereby reducing your carbon emissions. So we spoke about WebAssembly. Let's talk a little bit about the serverless aspect. I'm assuming most people here are familiar with the concept of serverless. I'm old enough to remember using data centers back in the day. You had this machine, a physical machine in your office that people guarded very secretly. And you had to keep an AC running so that it's cool. But we have gone from that to things like EC2 and virtual machines, to containers, Kubernetes Docker, to the concept of serverless. And we really see the next evolution of serverless being in the WebAssembly space because of these regions. The reason that I just spoke about. To understand the concept of serverless means you have to understand some of these concepts behind how the system is actually being used. When I talk about serverless, I could either say it's a type of application which is short-lived. It's completely event-driven. When an event happens, a piece of code runs in the cloud, gives you a response back, and that's it. You can also think about it like a development model where you, as a developer, you don't have to write any server code. You don't have to write server demons or maintain that server. All you have to do is focus on your business logic. And a lot of people refer to this as fast or functions as a service. It's become popular off late because you're focusing only on your business logic, the scaling is faster, and you're utilizing your hardware better. That's the key. And because of this, you're more green, and you save money. So how do you utilize hardware better? To understand this, you need to understand the concept of multi-tenancy. And this, I think, is the key to understanding why serverless is actually great. Because with multi-tenancy, you're saying you have a piece of hardware in the cloud. You want to run as many applications on that as possible to extract value of that piece of hardware. Imagine you had this huge server running somewhere, but just one small piece of code that ran there all day.  And you're not being hardware efficient. With the concept of multi-tenancy, you're running many tenants in that same piece of hardware. Each of those tenants are independent of each other. So they're workloads, they're usage patterns. They're all independent of each other. And the more independent they are of each other, the better you're utilizing that hardware. And overall, over a long period of time, the value of that piece of hardware has actually your extracted value. In fact, we ran some benchmarks. So on your left, so your left on my right, on that side, you will see there were two functions, two serverless functions, running in the cloud. And the idea is the gap between your peak and the gap between the average should be as low as possible. Because fundamentally, as people designing for the cloud, you don't want to design for your peaks. And because that's when you get more expensive and your carbon emissions are probably higher because you have idling machines. So on the left, you can see there's function A and function B running. Your average is about 10, and your peak is at about 17. So that's a difference of seven. But the minute we added on the right, the minute we added two more functions, so more tenants to the same piece of hardware, the peak and the average, of course, increases, but the gap between the two reduces. And that's really where the sweet spot is, reducing the peak to average gap to extract value of a multi-tenant system. And this multi-tenancy is actually increasing with each wave of cloud computing. In the early days of your data center, you had just the one tenant on one piece of hardware.  Now, with things like Wasm Runtimes, you can actually make very, very dense workloads, where you have multiple tenants running at the same time, only because of how lightweight these programs are. You saw the binary size of only a couple of MB. So you can actually pack these runtimes and pack these applications in the same piece of hardware using WebAssembly, right? So the idea of serverless WebAssembly suddenly becomes so much more powerful because you're saving money and you're becoming more green. Now, I used to work in AWS, and there's a very interesting paper that you should read if you're interested in serverless. I've linked it at the bottom. AWS Lambda is based on the Firecracker VM. It's a micro-VM. And that team wrote a paper where they decided the six ideal characteristics of one serverless unit. So if we were to have the ideal serverless unit, what are the characteristics? The first one they said was isolation. Like I said, running many tenants on one piece where they don't interfere with each other because we wouldn't want that. The second is to have density, right? Where you can run thousands of apps or thousands of functions on the same tenant with minimal waste, right? Extract value from that hardware. The third, of course, is performance when you can bring near-native performance on the cloud in a multi-tenant system. Nothing like it. The fourth they said was the ability to fast switch, right? When an event triggers that application, it has to start, do the thing it's supposed to, and then shut down, yeah? So the idea of a cold start time. And lastly, soft allocation, which means you can overcome it resources like CPU, memory, disk usage, and so on. And of course, compatibility, where at the end of the day, we all want to use our libraries and some other pieces of code which are compatible with what you're running in the cloud. So we actually did a benchmark between a micro-VM like Firecracker and WebAssembly using the same thing. So in terms of isolation, both provide good isolation because micro-VMs like Firecracker are sandboxed completely, and WebAssembly, by default, and by design, as a technology, is sandboxed already. There are a couple of places where WebAssembly really shines, right? In terms of overhead, you run thousands per node. With the micro-VM, you had to run 48 cores at 382 GB and 3,360 GB of RAM on a disk. But the same thing on WebAssembly, because it's so lightweight, you were able to run on 8 cores with 32 GB RAM and 100 GB disk. And if you're wondering why, what makes it so lightweight, it's the technology itself, right? If you look at the innards of how WebAssembly is designed, the reduced instruction set, so it's smaller already, and it also uses a stack-based VM. So again, it's a little more efficient in how it's built and eventually compiled. So that's a different talk, but that's what makes it so lightweight. In terms of performance, again, micro-VMs are near-native, same with WebAssembly, so very similar performance. In terms of the ability to fast switch or to cold start, again, WebAssembly really shines, because things like Lambda and Azure functions do have cold start times. And how companies actually change that is by keeping the instances kind of warm, which is not really serverless, because you're not scaling down to zero. So your cold start times are typically about 125 ms, whereas with WebAssembly, we were able to see less than 1 millisecond cold start times. So the ability to fast switch is very good. The thing is, WebAssembly is untested in large production, so over the next couple of years, we will see what performance will be at scale, whereas, of course, micro-VMs are running in production with over-subscription ratios as high as 10x. Also, we'll probably get better. And in terms of compatibility, in micro-VMs, you have Linux plus KVM only, whereas with WebAssembly, it's platform agnostic, OS agnostic, architecture agnostic, supports a bunch of languages, as long as they are compatible with Wozzy, which is what I mentioned earlier as well. As you can see, there is very good performance, and it really seems like the next evolution of serverless computing, which, again, becomes more energy efficient and hardware efficient when you use it. We have a very quick demo, and this is a prerecorded demo of how we were able to run 10k apps or make 10k calls to about 500 apps in 10 seconds using WebAssembly. So this was actually run locally, so I've prerecorded the demo. This is the architecture of what you're going to see. We're using Nomad, basically, as our orchestrator here. And there are 500 spin apps and about 10k calls to these spin apps. And essentially, the same app that I showed you earlier, the Hello World app, those are the apps that are running here. This is our Nomad dashboard. You can actually check if it's playing now. As you can see, we have traffic. We have Bindle Journal. We have our own multi-tenant version of spin called Spin Multi-tenant, and we have our own garbage collection as well. So what you're going to see in this demo is there's a text file with 500 URLs of these apps. And we're going to do a load test of 10k calls. And we'll see the memory and disk usage at the same time. So we're going to start with the deployment of 500 apps right now. The key thing to actually check is the memory usage that you will see right here. This is running on my colleague Kate's MacBook Pro. And these are all the apps. We have about 500 simple Hello World Rust apps that are running. So as you can see, there's CPU on the left and memory on the right. Right now, it's just about 20% CPU and about 50% memory, standard computer that's running on a local MacBook. And we have a text file here with the 500 app URLs listed. So you can take a look. These are the top five. We're just showing you what's in the text file, essentially. And yeah, if you do a curl to any of these files, you get the simple Hello World. And that's it. Now, we built our own load testing tool because engineers like to engineer. And you can actually see in this load testing tool, it's very similar to Siege or any other load testing tools that you may have used. That we have said there are going to be 25 concurrent users. And the number of requests per user will be about 400. So that's 10,000 in total. And we'll also add some jitter to these calls to mimic the real life. So we'll add a delay of about 0.01. And keep a look at the CPU and the memory usage on the left when this starts. So we're going to start this right now. So it started. And you can see the CPU and memory usage slowly increase. It goes up to about 90% CPU. Memory goes up to 52. And this is done. So in a latency of about 9 milliseconds, the average length of test was 5.8, which I think is quite good. And if you look on the left, you can actually see the CPU and memory already come back down to normal amounts that it was before the test. And again, this is because of the performance of WebAssembly. It's able to bring up all of these apps, make calls to them, and then scale down to zero in no time. We're taking very less memory. And again, being more hardware efficient and energy efficient. If I had to do a two-slide review of where we are at in terms of hardware utilization today, this would be it. There are so many reports of how, with things like Kubernetes clusters and cloud deployments, there's so much unused CPU and completely underutilized CPU out there in the cloud. There was a test, or there was an article by sysdig recently. And they said 69% of CPU is unused in containerized cloud deployments. There's a very interesting thing which is mentioned in the second bullet point there, which is an idling computer actually spends about 30% to 60% power. And there is a non-proportionality to how this works. Because the more you use it, doesn't mean it increases proportionally. You're supposed to use a system that's actually running. So the way to get maximum value from a system is by using it, not by keeping it idle in the cloud, because that is not being hardware efficient. That is actually increasing your carbon footprint. So think about getting maximum utilization of that hardware. The way to think about it is the right serverless is the solution. In another report, they said that about 81% of Azure functions are invoked once per minute or less. So there is a significant cost of keeping these serverless applications warm, only to provide that speed and that lack of cold start times. And usually, you as a customer take up that cost. So again, maybe with WebAssembly, some of these things will slowly start changing. And we know that this is a priority for tech these days, because just, I think, a month and a half ago, Meta launched their own serverless service as well called XFAS, where they're claiming about 60% utilization of their hardware, which is very good. Of course, by using that, you do have vendor lock-in, because you're locked into Meta solution. But I think it's worth checking out. The thing I'm really excited about is this thing that was just launched by the bytecode alliance. This is the CNCF equivalent, but with WebAssembly, called the component model. Now, there's a very interesting thing called the 2,400-hour problem, which is if you take any random thing like, say, parsing URLs, fairly simple to do. You get a host, a protocol, some data. Every language has multiple URL parsers of its own. Rust has one. Python has one. Whatever. What if we could use just one that was created and across languages? And this thing called the component model will actually give you that promise very soon. So say you're building a JavaScript app, and you need a YAML parser, and you need a date formatter. You don't have to write one from scratch. Nor is there a necessity that you have to use a JavaScript YAML parser or a JavaScript date formatter. With this component model, you can get a Rust, YAML parser, and a Python date formatter. And that's it. And again, you can be more hardware and energy efficient. This was just launched. How it works, essentially, is you have these components, or core modules. And any module can export some data, and any module can import data. These modules don't even have to be written in the same language. One can be written in Rust. The other can be written in Go. For example, both can be combined to create a new module which now does something. And this opens up so many different possibilities of how we can write software compared to how we have been writing software. Check it out. It's very new. It's still, of course, there's a lot more work to be done by the bytecode alliance and all of that. But this opens up possibilities because how we build CI CD now looks like this. On the left, you have a YAML file. It's something written in Go. It's something called OTH. And you can see there are multiple Go versions in the same YAML file. There are multiple builds. This is how we write our YAML files for CI CD. On the right, you see Docker. This is straight form the Docker documentation. So for each build, for testing, for packaging, you're throwing in your OS, different language versions, different architectures. This is a huge binary. This has so much footprint. In the component model, you wouldn't need any of that. All you have to do is put one build. You have a runtime which already works across architectures, across operating systems, across whatever. And you don't even need to package anything because as components, they are already packaged. I don't even need to do any bandwidth testing here. You can tell that this is already more energy and hardware efficient just by looking at it. So this is really what the component model unlocks. So keep your eye out on it because I really think it's going to change how we start building serverless and event-driven and microservice architectures very soon. Anyway, for next steps, you can check out. If you want to build your first WebAssembly app, check out. It's on GitHub. The 2,400-hour problem, there's a blog post written there. You can check that out as well. And also check out this blog post about carbon-neutral AI inferencing. We had friends from Civo speak here as well. Civo, basically, also, we work with them. And we use their hardware to do AI inferencing. And Civo works with Deep Green. And Deep Green does something cool, where they take the heat generated in data centers to actually reheat swimming pools in the UK. So your AI inferencing can actually be carbon-neutral, which I think is a very cool thing. So different ways to actually look at sustainability in tech. Anyway, I hope that opened your mind to the idea of sustainability in tech. Do check out WebAssembly and serverless. I'll be around if you have any questions. It was lovely talking to you. Feel free to connect with me on LinkedIn or wherever, and enjoy the rest of the conference.


Establishing the identification of non-recurssive SCM models can be a challenging task. Non-recurssive models are the models that have either correlated disturbances or feedback loops between two or more variables. They can be contrasted to recursive models that don't have either of these features. Recurssive models are simple to identify because they're always identified. So when are non-recurssive models identified? You can of course try to establish identification by proving the parameter values from the population covariance matrix, but that's very challenging to do, particularly if you have these feedback loops here. So fortunately there are a couple of rules that we can use to rule out non-identificate, to establish identification or establish that the model is for sure not identified. The two simplest ones are the null B rule and this rule states that all models with no paths between endogenous variables are identified. And these can be estimated consistently with OLS regression 2. The rule is named null B because in SCM software these models are estimated using covariance or parameter matrices and the B matrix or beta matrix contains all these paths between endogenous variables and then there are no paths so it's null matrix, null beta comes from that. Then we have T rule. The T rule is a counting rule where you count the number of unique variances and covariances in the data and then you subtract the number of parameters that you want to estimate. If the result is negative then your model is not identified. This is the same as checking the decrease of freedom which you can do after estimation. If it's negative then we know that the model is not identified. So if decrease of freedom is negative you don't need to do any other considerations. You know that that model needs to be fixed somehow or you need to add more information to allow estimation. So how about more complex scenarios? For example if we have this kind of feedback loop with four variables and then one parcel mediation in between. Is this identified or not? The rules on the previous slide don't really help and well this is identified. We know that but why do we know that? That's what we are going to talk about next. So let's start talking about these feedback loops that make it difficult to establish identification. In the simplest case we have a feedback loop between two variables. We have Y1 influencing Y2 and Y2 influencing Y1. So how do we know whether this is identified or not? We can apply the T rule. We know that we have one covariance here and we are estimating our two parameters relating these variables to one another. The decrease of freedom is minus one. This is under identified and we don't need to consider it any further. If you have studied instrumental variables then you know that in econometrics this kind of a scenario is called Simultaneity and it can be estimated by using instrumental variables. So we need an instrumental variable for Y1 or Y2 and that will identify the model. The X1 here is serviced as an instrument because it affects Y1 and doesn't not affect Y2 and is uncorrelated with the error term. And that identifies the model, decrease of freedom is zero and it's just identified. What if these disturbances are correlated? So we add a correlation, decrease of freedom is minus one, this is under identified. We can again identify the model by adding a second instrument but before we do that we need to note that these paths from X1 to Y1 and Y2 are actually identified even if the full model is not. So this is called local identification. Even if your model is not fully identified which means that all the parameters are identified it may be possible to meaningfully estimate some parameters. So here these two parameters are identified and this path from Y2 to Y1 and this correlation between the error terms is not identified. So we can estimate some parameters but not all from the model. We can fully identify the model by adding second instrument. We have a decrease of freedom zero and this is a just identified model. Important thing in identification and many of these identification rules is that we need to have sufficient number of instrumental variables to allow estimates. So there is a link between the social ecosystem model in literature and the econometrics literature in instrumental variables. If you understand one then you will understand the other better. Let's take a look at larger models. So we really have models with just two endogenous variables. Sometimes we have more and this is an example of four endogenous variables. So here Y1, Y2, Y3 and Y4. And this is what we call a block recursive model. So block is a group of equations. It's the smallest possible group of equations that feels that does not have correlations between equations from other blocks and also all the effects from one block to another go unidirectionally. So there are no feedback loops. So we have one block here. So Y1 and Y2 form a block. They must be in the same block because there is a feedback loop and then there is this correlation between these two disturbances. These exogenous variables don't belong to any block so we just block the endogenous variables. These two endogenous variables, Y3 and Y4, can be assigned as their separate block. They need to be in a block because there is a feedback loop and then there is also this correlated disturbance. Why we can split this model into two blocks is because there are no correlations between these disturbances here and also all the effects from the first block go to the second block and there are no effects the other way. So this is a block recursive model and we can split it into blocks. Now the identification rule for these models is that block recursive models are identified if every block is identified. So we can break the big identification problem here involving four equations for four endogenous variables into two smaller problems involving two equations each. Rigdon points out that most models that people estimate actually are block recursive and can be broken into these blocks that contain one or two equations. So how do we establish the identification for this one? We have Y1 and Y2, we have bidirectional path and we have also correlated disturbance here so we need two instruments. X1 qualifies as an instrument for Y1, X2 as an instrument for Y2 and then we move on to the second block because that identifies that block. In here we have Y3 as instrument Y1 and Y4 as instrument Y3 and that is sufficient to identify that block because both blocks are identified, this model is identified. The block rule is clearly a very useful rule for identification. So how about more complicated models? So this model here, we can break it into blocks because we have a feedback loop between all three variables and also the T rule can be applied because this has a decrease of freedom of zero. We have three covariances between Y1, Y2 and Y3 and we are estimating three paths between these variables. So we estimate three things from three covariances that in principle can be done. This can be proven to be identified but doing so is quite difficult. You can think of this intuitively as a two variable loop so you have Y1 affecting Y3 and Y3 affecting Y1 but the effect of Y1 on Y3 is fully mediated with Y2. So based on the relationship between Y1 and Y2, Y2 and Y3 we can say how strong this effect goes through Y3 is in comparison to this direct effect from Y3 to Y1. So that's one way to understand why this is identified. This paper here provides a proof but it's fairly difficult to read under so you have done lots of identification problems before. So what if we make this a bit more complicated? Let's say that we have a correlated error term, correlated disturbance between Y1 and Y2. We can identify this model by adding X1 as an instrument. So when these two error terms are correlated then Y1 is endogenous with respect to Y2 and having an instrument variable here helps to identify the model. What if we have all correlations to be free? Well, we can add three instruments that is sufficient to identify the model. This is actually identified according to the rules that you can find in any good book on structural acres and modeling. The rules are called rank and order conditions. So both are satisfied in this model. And this is how Klein explains this problem. He has the same exact model that we had. It's just drawn sideways instead of like horizontally like we did and we have Y1, Y3, Y2. This is a loop that goes this way like we had before. So why is that identified? We can apply the order condition. So the order condition is a condition for checking for non-identification. If order condition fails, then a model is not identified for sure. If order condition holds, that does not necessarily mean that the model is identified. So this is a necessary but not sufficient condition. The order rule states its accounting rule that we need to first start by counting all the endogenous variables in the model. We have Y1, Y2 and Y3. So we have three endogenous variables. Then we subtract one. So we get two and that's our benchmark. Then for each endogenous variable, we need to exclude at least two of the other variables in the model and to identify that equation. So Y1 excludes three variables. It excludes Y2, so there's no effect from Y2 to Y1. It excludes X2, there's no effect from X2 to Y1 and it excludes X3, so there's no effect from X3 to Y1. So we have three variables excluded. For Y2 we have excluded X3, X1 and Y3, X1 and X3 and for Y3 we have excluded Y1, X1 and X2. So in all cases the number of excluded variables is equal or greater to a two, which means that this model is possibly identified. This is a model that is a rule that is necessary but not sufficient. The model is identified also according to another condition. But let's take a look at what it would require for the order condition to fail. So for example if we have path from X1 to Y1 and then X3 to Y1 then we would have only one excluded variable, which is Y2 for Y1. And that would be a problem because we can no longer use X3 as an instrument for Y2 to identify this relationship here from this disturbance correlation. So you can think of these through instrumental variables. If we include all possible paths from all the Xs to Y1 then these other X variables can no longer serve as instruments for Y3 because then they are not excluded. Then we have another rule called the rank condition and the rank condition is necessary and sufficient for identification. And the rank condition is defined using matrices and I will not go into those matrices in this video but the idea of rank condition is basically that each Y variable must have a unique pattern of Xs relating to it. It holds here because XY has a unique pattern in that it is affected by X1 and no other variable is affected by X1 only. Y2 has a unique pattern because X1 is affected by it no other variables are affected by X1 and so on for Y3 and X3. So that condition holds. So summary of identification. Identification can always be proven using algebra but doing so can be difficult particularly if your model is very large. I would think that most researchers don't try to identify their models by trying to prove that each individual parameter can be solved from the population covariance matrix. Fortunately we have a couple of easy to use rules the null beta rule, the t rule, the order condition and the block recursive rule that can be applied to check whether model is unidentified or to establish that it is identified. These actually cover most of the scenarios that applied researchers face. Unfortunately no simple and general rule exists. So there are always models that are not covered by these simple rules so if you have models with feedback loops of four variables and then you have just one instrument no correlated disturbances then for these rules would not cover that case. Then you will need to use algebra to identify the model or you need to just test for identification empirically. Some advice, practical advice for checking identification. Consider identification prior to data collection. If you want to estimate a model that contains feedback loops then collecting data and after that realizing that you don't have enough variables to identify the model you can't do much about it. So you need to have the sufficient number of instrumental variables to identify the model and you need to know how many you need prior to data collection. Then check for obvious sources of non-identification. Do each endogenous predictor have an instrument? If not then you are probably in trouble. Order condition is another easy to check rule and of course checking whether the decrease of freedom is non-negative is yet another one. If you can't using these rules if you can't establish that the model is non-identified you can either go for the rank condition which is more difficult to apply or you can just do identification empirically. Or if you have a block recursive model evaluate one block at a time using the rules for the model for just two variables. If identification cannot be established using these rules then you need to do it empirically for example by analyzing simulated data sets to see if you can get correct results analyzing simulated data sets comparing results from different starting values to see if you get unique estimates and so on. That requires some work but it's not that difficult to do.