Okay, everyone, Nihao and good evening to this session. The penultimate session of Mesoscon 2016 Asia. It's great to see that are now today. And I would start, what would start? Can you just show me the mouse please? Yeah, okay. So the title of the session is how we could use Mesos to drive DevOps. And before I dig into the session, I want to give you small introduction of who I am and where I work from and where I come from presenting this conference. So I am part of GS Shop. And GS Shop is one of the largest TV shopping networks in Asia and now one of the largest e-commerce sites in Korea. So we've been in the business for the last 20 years and we have over 1,000 employees and within a half users every day and 28 million app users on an average. So we are based out of Korea, the headquarter isn't Korea, but we have a lot of presence in Asia, including India, Vietnam, Malaysia and other countries. So I work for the container platform team and my interests are DevOps containers, microservices. You can call it the buzzwords of 2016. And I work for the IT Innovation Center. So a slow point to touch upon is this is a Mezos conference and it's 4pm. It's the last day of the conference. Why we don't have a talk on DevOps yet? So this is all missing, right? So every conference these days you have a talks on the DevOps. So this is that talk. I hope some of you may be missing that talk of this while. So this is a talk that I'm going to cover about DevOps and my pitch is basically to talk about why Mezos is a DevOps enabler. How we are using inside Gearshop Mezos to drive DevOps across our teams for the last one year. So how many of you have read this book from Leo Tolstoy? Anyone? Okay, so there's a nice quote in this book and it's quite popular. And it's about happy families. It's quite applicable in the modern times. And happy families have common characteristics. And unhappy families is very unhappy because of their own reasons. It's very unique to them. If I apply this to teams, especially software teams in our organization, I could just make it productive teams are productive and they're common to cross all productive teams. But unproductive team is basically unhappy because of their own reasons. Something very unique about how they operate, how they do business. So the reason to put this out is basically I'm going to talk about how as an organization we identified where we were doing wrong and how Mezos became the DevOps enabler for our organization and where we are going next. So my definition of productivity is basically happy teams. Happy, fulfilled, satisfied teams. That's what we define inside Jigarshop. So let's start by putting some agenda across you. I have four part agenda today. I'm going to bit start with a little bit of history. Some of you may not like history but actually it's easy to pay interest on history for a bit. And I'm going to start talking about where we move on from there, the starting of the change happening in the organization using these rules. And from there, what we are doing now, how we are adopting this across our teams, across the entire organization. And lastly, where are we going next? How we are making it, how we are driving this internally to take the next leap in the equation. So we start with a little bit of history. So the history begins with how we do build and deployment. Of course, the common things. It's a very familiar artifact that you see all around. We build something. Most of it is the Java shops. A lot of people that are building Java applications. And obviously we have a maintenance team trying to support whatever applications have been moved over to production and across environments. And these are some of the stats that we currently have. So you look at some familiar terms like lead time that is from the origin of that particular requirement until the application or the change going in production. And then you have per developer per week how many changes that we go. So this is an important metric to understand where we are in the current equation and where we started from in this space. Now I want to introduce two important characters of my story today. And you may have heard of these stories. You may have known about these characters. One is a developer, the other is operations. So these two individuals and these two rules have a divide as usually you read it in the books. And it's a divide is based upon their assumption of the goals in our organization. So the DevOps actually is a combination of efforts to unify them as you already know. So the developer and operations are driven by separate goals. Their goals are separate because that's what they're measured on and that's where they are penalized upon. So we, as a developer we look at new features fast moving to production and the operations need stability. They want strict control on how changes move in and out of the environment. So monolithic apps, operations love it because it's a very simple, easy to understand primitive and there are very less moving parts to it. So when we started looking at microservices and multi-apps this kind of creates a conflict with them because there are so many moving parts of the equation. And there are some new primitives to learn. So they obviously don't have a nice time with these services. And we practice something called yawn-driven deployment. As you know, deploying at 3 AM in the morning. So that's what we were doing a long time. Everybody gets together at 3 AM, it's a party. So we deploy and we have a lot of yawns and that goes to code, goes to production. So this was a common tendency inside our organization for a long time. So now we have seen where we were. I'm just quickly going to the next part of where we started looking at the change and how we identified that change. The first rule of making a change is to know the issues that we have. And I start by looking at the issues internally. You may have heard this term already many times and I want to repeat it. We love to have pets, pets are very important but unfortunately we have machines as pets and we like to name them and take care to them.  So the same context applies in here as well. We love our machines so much. We also have a lot of teams inventing their own tooling and processes which means they take whatever works for them and just apply including processes. We also find out that a lot of our developers are taking long time to get feedback when they put something in production. Very common, familiar situation in large organizations. Big bang releases are like events. They're like everybody's prepped up, they're religious events. And that's like been happening for a long time in the organization. And lastly, the empathy part, especially when we're driven by separate goals in the developers and the operations, they are having different ways of dealing with their roles and the roles of the others. And that creates this great divide that I talked about. So we looked at the issues and now we need to find some inspiration. So for inspiration, we start looking into history and anybody can guess who is this gentleman? Okay, no problem. So you may know the name Conway but full name is Melvin Conway. So Melvin Conway created this Conway's Law which you might have heard. But there's a twist to it. So what we look at Conway's Law is around producing designs which are mirror of the communication structure. The way organizations are divided internally. And we want to take a flip to it to take this as an advantage for us. So we want to flip this by creating called the inverse Conway maneuver, a common familiar term for DevOps professionals. So the inverse Conway maneuver talks about creating constraints that helps and drives the organization to change. So it's basically system-based thinking, allowing systems to influence how we do and how we communicate inside our organization. So we looked at inverse Conway maneuver and the other motivation comes from the O-ring theory of economics which last year, a ring caller of Spring Source talked about it in his very familiar blog and he coined the O-ring theory of DevOps. To make it simple to understand, he talked about two key concepts. First, everything in a DevOps process in a workflow, every step has to happen. It has to be successful even if in a small quantity. Otherwise, you don't get the advantage of it. And if any one of this step is not done properly or there is an inefficiency, that kind of destroys the benefits of the entire workflow. So this applies to a lot of internal practices that we have and this is what we observe running our teams for so many years. So based on that, we looked at tenants. How can we create the tenants based on which we could drive this change inside our organization? So there are five tenants. So five tenants, first is to make our applications disposable. Secondly, focus primarily on improving the quality of life for a developer. The developer must have amazing productivity inside the organization. The third, allow applications and services built inside of share as much as possible. Make them run on a multi-tenant environment and allow them to use common tooling. Fourth, management permitives like link service starting up, restarting services relocating across different blocks. These permitives needs to be automated as much as possible. And the fifth and the most interesting point, measure everything. So based upon these five tenants, we want to drive all the changes around DevOps and I will talk about how MISO's kind of plays the most important entity in that deduction. So the master plan is simple. We take the ideas from inverse runway maneuver and the O-ring three of DevOps. We created this five tenants and we apply it as simple. So based on that, we created the platform called the Gravity. It's the service delivery platform which we started last year. And it's to make it very simple. These are, we are just meeting the building blocks for our teams to build software on it. So the end to end workflow in this is quite simple to make it to the audience that we have here. So we have a build process which obviously generates your artifacts. In this case, the talk or image. And then it goes through a preparation phase. So preparation phase generates your deployment manifest which is then sent over to scripts and tooling to allow our applications to move into our MISO's cluster and allow these load balancer reload and DNS to be kept updated. A very common familiar MISO's adoption scenario that you may have seen in your teams, in your organizations. And along with that, there's a standardized tooling for common aspects around APM, around logging, around dashboard and notifications. So this is what developers get out of the box for every service that they build inside our organization with this adoption. So we wanted to have a common manifest to rule all the environments. And I say environments, it could be any permutation and combination of these. So you want to have a single environment with a manifest that we could use for all our deployments everywhere. And for that, we wanted to make our deployment template as common as possible and allow the change parameters in this deployment manifest to be managed by a template engine. So what we did was we externalized some aspects that vary across environments and that used to generate the final template which is then pushed over to each environment. So this template is nothing but the marathon JSON configuration, which is obviously having some templates that are replaced at runtime in our case. We also follow gluten deployments. We use the marathon LB project and the zero downtime script that we got from the project to follow and to allow zero downtime deployment in our teams. And that's been working very well to now. We say zero downtime deployment is basically ideally zero downtime deployment as you would know in your organizations. It's not 100% zero downtime, but we are trying to make it as less downtime as possible. And the primary purpose of the zero downtime is to deploy when we are awake, not the odd hour of getting up and deploying. And that's been very fruitful in allowing our teams to get the confidence to move ahead in this adoption process. We do notify of every step. So use Slack as our audit log of everything that happens in our infrastructure. So in terms of builds that are created, the notifications from the marathon infrastructure. So everything goes into the Slack channel. So it's searchable and it's trackable and you can find out what happened and what time. And based on that, you can filter down to the events that you would like to pass on to your operations or the developers of the SREs in your team. We also have custom dashboard that we built inside our team. But this custom dashboard allows us some new capabilities over marathon, especially around metadata based roadmap. So we would like to go back to a version, not just based upon a build ID or version comment, but also in terms of build. And we wanted to control it end to end. So we introduced metadata based roadmap into our dashboard. We also support multiple site and multiple regions, which means we have multiple visas cluster running across different availability zones. And it allows us to manage them all together in one dashboard. And we use comprehensive head checks. So we leverage the marathon head checks as well as the HEPROXY head check and give a common indicator of the service health for the developers. So that when I deploy an application to an environment, I get a sum of all the head status together, not just the marathon head status. Lastly, everything is available through an API and CLI to our team so that they can take advantage and integrate with their infrastructure, with their other integration points in a pipeline. Puppet Labs, obviously most of you have heard about it and they publish this state of DevOps report every year. And they talk about number of times deployment and difference between organizations which are high impact, high performing versus ones which are laggard. And one of the common aspects is that amount of times the high performing organizations are doing more deployments than the others. And we wanted to take this as we apply these practices internally. So we also take advantage of this by measuring information coming through the marathon events and pushing it down to our metric collector. And that helps us to gather information to provide to our teams. For example, you can see the deployment counts, average time of deployment, end to end for all their environments. We also provide monitoring and this means the oil developers, every team using this platform is able to get this end to end stack so that they can take advantage of it with their systems, with their services that they are building. And this means end to end. So we use a couple of familiar options that you may have seen, we use Prometheus, Monit and use for APM integration with BNPenPoint and Scouter for our APM needs. And we use Elastic Stack heavily inside our organization. This is a screenshot of the Monit service dashboard and our Prometheus dashboard making material. False identification. And this has been one of the impacts for this transition in our teams. When I talk to our developers and we tell them not to worry about where your machine is, where your container is. The most important question is, what happens if something is wrong? Because I want to log into the machine and see what's happening. And that practice took some time to change it. So what we do is ask our teams, follow the inverse Convay maneuver to force them to change their practices around the system. Now they obviously have the business three-sides which they generate in the application but we bind it to the actual application and the container running in the mesos cluster. So for example, you can look at the Kibana dashboard, find out the exact mesostask ID which is generating that log. And obviously you could go to marathon dashboard and take actions on it. You can kill and scale your applications whichever is appropriate. So that's not false identification in our environment. Most importantly, this created an indirect effect on our teams. Our teams started creating more environments. They loved it so much, they would have environments for every new deployment and they were creating too much of it. And obviously we had a mix of public cloud and internal infrastructure that we managed. And creating this, making it easy for our teams to deploy as services means there are too many of these environments lying around. So we created transient environments which means we time out environments at a certain interval which is configured on a cluster. So we have a service which basically goes on deleting the dev and test environments after a pre-configured time. This allows our teams to have a check on how much resources they are using and also creates a discipline. And this creates a lot of good benefits to our infrastructure team as well because now they see good resource utilization and the disposability part is enforced on the teams which makes them more strict in how they use resources. So we practice this currently in our production, not in production environment but in the dev and test environments. When we deploy this track, suppose your teams, we are deploying the stack on a given infrastructure, whether in public cloud or internal IEC environment, we want to standardize how we deploy that. So we have basically zeroed onto two nodes. One is your master node and worker node. So master node, as you may have seen, it's basically the Viso's master and some related services. And the worker node which is the agent and it has some package services. So this allows us to simplify how we deploy our infrastructure. So some of these services in the worker node may change but overall this creates a template for us in deploying our Viso's cluster, the gravity platform for our teams. So which means we can manage an entire feed using package repository and create various worker and master nodes evenly. And some of these worker nodes would basically hold onto the application, the business services that the developers deploy and some of it runs a system management. For example, our continuous integration server or backing services. So some of the familiar tools that you may have already used or seen in your organizations, we also use them. Now coming to the third and important part of this presentation, we're about adopting the change and adoption of change is really hard. So last month an article came in for you about why it's so hard to install DevOps and Agile in Asia. There are many reasons and I believe that all the reasons have a check on it because I've been operating this in space for last 10 years. It's really hard to do DevOps and Agile in the right manner inside Asia. And primarily this has to do around mindset, the culture. So we hope to have inverse Conway maneuver as a way to drive these changes but the first thing to change is the mindset. So we created this simple adoption graph. So when we look at any developments or adoption of DevOps practices, we try to follow this adoption graph which means at the beginning you're in evaluation stage and then you'll start putting something in production so that you get some feedback, teams get some confidence that this thing works. And once you reach and confidence in a production environment, you would likely see a tipping point. That's a point where your team starts majorly using the services in all projects and all services. So currently in our evolution, we are in the experience and production stage which means we are trying to give our teams the benefits and they are actually acknowledging that benefits are coming out through the gravity platform. Once we reach the tipping point, that's the opportunity for us to ensure that this goes to scale, this goes to widespread adoption across our teams. And there are three important components of that playbook, the adoption playbook as I said. The adoption playbook first is obviously getting the confidence and technology like Vizos, like the Vizostat and DCOS. Second, we don't deploy it just for new services, we also do it for existing applications and do it in a manner which shows them the difference between the old style and the new style. So doing a compare and contrast mode for the technology. And lastly, we create teams and we create new roles for people to take up opportunity in this transition. So let me talk about this in a brief in the next few slides. So when we put for things in production and we move systems to this new environment, there will be a stage where the old and the new stays together. In our case when we moved our critical systems on the Vizos cluster, we had a child where the teams were really not confident that this thing really works. It looks great, it works great, but I don't know if it's able to take up the load and especially work with our teams. So that's about the time that we're, the present and the future remains in the same space, which means we use the old system and the new system for brief time. At this time, we follow four ideas to align and help with this transition, which is the old deployment of, specifically around VM-based or physical machine-based deployments and the container-based deployment actually are unified. So in our case, we use a single deployment channel and which deploys both the virtual machines that run our services as well as the Vizos cluster that runs our container. We use common notifications for them so that they don't have to worry about two different systems throwing information to them and centralize the logging and the monitoring aspects of the system, which means I don't want my teams to have to manage two different style of management services just because we are in the transition phase in our organization. So we did this four things and this is kind of through a way because we needed to go through this transition phase. As we go into the future where everything runs on the Vizos cluster, we might not have to use this throwaway bar all the better. So comparing contrast also means putting both the old style and the new style services, containers and VMs in the same environment and allowing our applications to move gracefully to the new services. So in our case, this is a representative diagram of how we run some of our services. So we have some legacy monoliths which are now containerized and run on the Vizos cluster but also run on the VM environment and we move between the launch to confidence which basically means we move traffic between them so that a particular percentage of traffic moves to the old environment and the rest goes to the containerized environment. This has trade-offs but it also provides us the basis for proving the technology. So everything becomes mainstream, everything becomes stable. That's the time where we move everything all the 100% traffic to our new environment which uses Vizos. And regarding roles, so we created new roles and these roles have to work with our existing team structure. So in here you can see there are two teams and we also have a separate platform team that is basically a platform engineering team building this gravity platform. And what we do is we create three parts to it. One is service engineering, platform infrastructure engineering and the developer advocacy and solution architecture. These, the solution architecture and the developer advocacy works with our different teams inside the organization. They do the outreach for our teams which means they go out and help them go and adopt these services. So that's needed for an organization of our scale to make this in production to allow the change happen quickly. And we also have so-called evangelist, DevOps evangelist installing teams. These are point of contacts who can work with our developer advocacy teams so that they can become a way to distribute the ideas and enforce constraints within their teams. And that helps us to move across many teams at one stage and in the smaller footprint of the platform team. What happens now is because of these practices the operations and the developer start mingling their goals. They try to understand better which means the operation specs more time building self-services and developers start using those self-services instead of a manual interaction between them. And because the preventives are automated operations don't waste their time building and doing manual changes and manual activities over that. Lastly, they have shared goals with them, the operations one and the developers have shared goals with the operations. This is important to do that adoption otherwise the change just remains a technology change then a non-culture change. What are these shared goals that I talked about? The shared goals in practical are three and our teams are rolled around these shared goals. We want all the operations and developer to zero into that shared goals. So first is both developer and operations have a goal to reduce the time that takes the code from a check into production. Everybody works to improve this timeline. Second, we want releases to happen any time as when it's needed not at 3 a.m. in the morning. And lastly, reduce unplanned activity especially doing work which is around downtime or issues that can be automatically managed by the services. So every opportunity that we get on unplanned activity goes as an automation task into our JIRA so that everybody can look at that and then start working and improving that activity. So these three goals helps our developers and the operations to unify how they operate inside the organization. And some reality checks. So what happens because of all this is instead of allocating a VM to a service we let the software decide and operate that and which means we don't do upfront capacity meetings basically many, many days of just meetings and going in meetings just to understand what capacity we allocate and we get more work done. Secondly, we also make availability and fault tolerance from manual map practice to more automated let the software decide by itself thanks to MISOs and which means we don't have more opportunities to do manual intervention. Third, time to production and that's extremely important metric inside our organization. Instead of being blocked by manual monotonous work we get minimal work, manual work and this means we get more set of service inside organizations and that led to something remarkable which means the teams especially developers for that the ops world becomes more accessible. They don't have to learn new skills they just have to probably call an API or use a dashboard or CLI to do that for them by themselves. And lastly the important reality checks because of this transition is because of the reusability that we lacked now we are standardizing across all workloads inside our organization which means all our teams use zero in a standard stack and they don't have to re-inquit these processes by themselves. So this is the four reality checks that we currently have inside our organization but DevOps is just not bad it's also about architecture it's also about design and obviously that leads to some new design principles that we work at, we advocate to our developers. So the work that you see from our solution architecture and developer advocacy they work with engineering teams to drive these four in the design phase and architecture phase. This means you need, as a developer you need to make ops-friendly code which means your code is monitorable you can, it's build to log, build to debug and everything generates metrics. Every code that we write has a capability generator metric and can be collected and aggregated and shown to the user at any time. Lastly, very cliched but obviously important failure-driven development which basically means failure is an important component it's thought and surprise but it's an acknowledgement. This means we try to tell the teams that your container can re-debate or could die which means we can even apply Netflix's ideas of Simeon Army and your container's data in environment and this is very easy to implement in one cases where the dev and test environment where you can just remove the environment and they say, hey, I was testing it I said, sorry, just create a new version of it and just call a new copy of it. That creates a tension but I think it's a constructive constrain applying the inverse Conway maneuver and lastly around distribution. Most engineering teams came from an era where everything was running on one box so trying to adapt that now everything is distributed is a drastic shift what Mizo's got to us instead of creating this notion by just education now we have a platform where when they put their code it's just distributed from day one the containers can move across the cluster so everything that they read in books is actually in practice so that it becomes more visible and more easy for them to apply in the day-to-day activity. So what's next where we are in this whole equation? So the road ahead will give you some glimpse of where we are and what ideas were we pursuing to take this further. Number one, we'll obviously need right now we have independent clusters of our environments not because of technical reason but more political reasons as in a large organization but we want to zero into multi-tenant cluster which basically means we run most of our teams not to own machines or not to own servers rather than run on a single cluster and for that we're taking advantage of some of the primitives that Mizo's is building around multi-tenancy and what DCOS is trying to offer especially around isolation primitives and around resource reservation and these are important for us to drive some of the multi-tenancy aspects across our application inside our infrastructure and the other point that we are working is on the global workload allocation which means everything inside GSHOP everything is a container and everything runs on a Mizo's cluster. Now with that assumption we want to have a global workload allocation which means workloads of any type but as you know not all workloads are same basically they have different attributes so I would like to classify them in three parts so there's a cost based, performance based and isolation level so if you're running a dev environment for some low critical application you will not need strong isolation you can just have a limited isolation and still take advantage of it but for example an application that is using customer data and because of some regulation they cannot be used on a single major Mizo's agent or cannot run on the same box on the same VM that also classifies for another type of workload so what we would like to do is allow our data center fabric which is running gravity platform using Mizo's to allow workload to be intelligently scheduled on different type of machines different type of agents based on the type of workload that they have so if you have a workload which is around less cost but more performance and it can go into a particular type of Mizo's agent while a workload which is not very fancy on isolation can remain on very tightly dense systems and this is a very important initiative that we are driving internally in the next year around global workload allocation and that means we take advantage of what's already there example Netflix Fenso library that they have built that allows us to build new primitives inside how we schedule applications over Mizo's cluster and that's the direction that we are doing we are building a recommendation system for workloads that are deploying on the Mizo's cluster this means it's just not the profile of that application but also the cost efficiency comes into the picture for example if I'm deploying a particular unit of an application as a container on Mizo's I would like to also see which is the right place for me to deploy this service in the Mizo's cluster think of this like a trusted advisor of AWS if you have used one so similar concept on the Mizo's cluster which means building system gets integrated into our deployment choice so as a developer I don't have to pick and choose which is the right data center or Mizo's cluster for me and the choice of Mizo's agents that becomes a part of scheduling itself that's a grand vision there where we want to go into the next year with what we are doing in the gravity system and we have some work pending around and also the community looking at how we can leverage that over marathon as well using the fence of support we also run a B2B2C platform on our gravity platform and that basically means we can give out our customers an ability to run their own e-commerce sites and that allows us to also build new capabilities on Mizo's cluster which means if I give a free account to someone I would like to probably schedule that account on a very densely populated Mizo's agent while an enterprise customer with strong isolation and needs could get allocated to less dense more quality of service to that particular customer that means we need to rethink about how scheduling happens it's not just the resource offers but also about how much density that particular node or Mizo's agent is occupied with and that is something that we are trying to approach as we deploy our B2B2C platform on the Mizo's cluster and it allows us to invent over Mizo's to build these primitives and as we build we also would like to take it out and push that community that obviously leads to cost reduction that we can pass on to the customer who are running their stores and e-commerce sites on our platform Lastly, the next steps that we have is around giving ability for our needs to do architecture A and B so we piloted VAMP as one of our services that we're trying to leverage to provide us capabilities over Marathon which means we can do candidate style releases as well as do architecture A and B very easily The other point that it gives us is around automated workflows for testing our systems which means we could provision the applications on the Mizo's cluster over Marathon but it goes through the VAM and the VAM's DSL takes care of it Lastly, we also want to take advantage of self-healing and automated rollbacks capability built inside VAM that leverages Marathon for that which means when you deploy a new version of the application and that version leads to more 500 errors that are obtained in the probably elastic search VAM could automatically rollback that changed the previous version because it knows that it has reached a threshold of issues So this is capabilities that are already out there and you can take advantage of it This is something that we are very keenly putting inside our platform next year So we covered all aspects of what we have done where we started from and it's still day one for a gravity platform We're still making it taking a lot of steps to do this change and change is possible Change is really possible through the efforts of the Mizo's community and the DCOS and the Mizo's sphere guys What change is hard? But if you need to know the proof of change that is change is really possible you may know it this week when Microsoft joined the next foundation So that really proves that change is possible even if it takes long time So we are driven by that ideology that change will happen and that brings me to the end of the presentation So if you have any questions with what we are doing or you need more information please do so and I will also be around and we can catch up after the conference Any questions? Go ahead How do you connect with the parameters? See, the noisy neighbor is more loaded terms For example, it's just not about reservation that we give to a particular tenant but also about how much utilization a particular workload happens in its peak time So for example, when we deploy we have one after applications that is running our order system So when we run this application for some time we understand how this application has been performing for a certain duration of time and how it peaks Now when we deploy some other tenants on the same NISOs agent we want that particular tenant to not just have an isolation of performance but also in terms of the tooling it could reuse For example, we have log aggregation services on it Now log aggregation runs through the same agent through a Docker containerizer Now when I try to reuse the same log beam system for the other tenant that may create issues with respect to how that tenant would want to share their information It may contain customer data It may contain data that they do not want to be mixed up with other tenants So for me noisy neighbors means one of the aspects is just resource isolation The other is your behavior isolation in terms of what you're doing on the application The other is around data isolation and the management service isolation So for example I could even deploy a separate log service a log rotator and a log forwarder for that particular tenant which is completely isolated for the other tenants So think of this like a sidecar container that basically works for a particular tenant and it's sticky to that particular tenant So that there is no issue of mixing traffic and allowing a common aggregation system to pull into data Okay, thank you very much And if you have any questions we can discuss it outside Thank you


Now, Roma Wines, present. Suspense. Tonight, tale of two sisters starring Claire Trevor and Nancy Kelly. Suspense is presented for your enjoyment by Roma Wines. That's R-O-M-A, Roma Wines. Those excellent California wines that can add so much pleasantness to the way you live, to your happiness and entertaining guests, to your enjoyment of everyday meals. Yes, right now a glassful would be very pleasant, as Roma Wines bring you... Suspense! This is the man in black here for the Roma Wine Company of Fresno, California, who tonight from Hollywood bring you as co-stars Miss Nancy Kelly and Miss Claire Trevor. Both are currently being seen in RKO Productions, Miss Trevor in Murder My Sweet, and Miss Kelly in Betrayal from the East. There is a phrase of Walt Whitman's, the sisters' death and night incessantly softly wash again and ever again this soiled world. And so the tale of these two sisters, and with the performance of Claire Trevor as Clara and of Nancy Kelly as Adele, we again hope to keep you in suspense. Everyone is so good to me. I like being here, but some of the others don't, I guess. Do you hear? They scream sometimes like that in the night. Maybe they scream because they remember things, but I remember things too. Especially when people come out from town to see me, to bring me things. But there is nothing that I want.  Today was Thursday and they came, and now they've gone. But when they came, they brought back memories of Adele. When we were children, the night that mother died, the night we made the promise. Don't cry anymore, Adele. I'm afraid, Clara. We're alone. We're not alone. But if something happened to you, nothing's going to happen to me. I'm going to take care of you. But that's what mother said, and now she's left us too. But Adele, mother didn't know that she wouldn't have left us if she could have helped us.  And that whatever I do, you'll do. And that you'll never leave me. I promise. And we'll be together, always and forever. Always and forever. I promise. Years I kept that promise. Adele and I were as close as anyone could be. We had few friends, and I didn't mind as long as she was happy. But sometimes I was frightened at the way she clung to me after we were grown. I was afraid of what would become of her in case anything ever happened to me. And then something did happen. I met Douglas Foley. Adele liked him until she realized that I'd fallen in love with him. Then she hated him in a childish, vicious way. He tried to win her over, but it was no good. And then he asked me to marry him, and I... I said yes. That night, after he'd gone, Adele was waiting for me in my room. Adele! Adele, you're so white, darling. You're ill. Would you promise me? Oh, but Adele, I'm not leaving you. You're going to live with us. We're children, Adele. You promised we'd be together, always. I'll never speak to you again. But we were married, and we believed that Adele would forgive us in time, but... but she didn't. She refused to see us. Then when we learned that my husband's new job was to take us to Europe, our first thought was of Adele. If she would only go with us. But when we drove to her house, she refused to come to the door, and we were forced to sail without her. My son, Doug, was born in Europe. And I wrote to Adele a long letter telling her about him, but the letter was returned. I'm opened. When Doug was just 10, we returned to America. I went directly from the station to Adele's home. She was working in the garden when we drove up. I was shocked at her appearance. Her hair had turned almost white, and there was a strange look about her. I sent Doug to the gate to introduce himself. She looked at him in a puzzled manner. Then she saw us sitting in the car, and she turned and walked into the house. The next thing I remember was that day, one month after my return home, when I was put on trial for murder. For my husband's murder. Mrs. Foley, will you please tell us again what happened the night of your husband's murder? My husband was working in the garden all day when it began to grow dark. Will you please speak up? Yes. My husband had been working all day in the garden, and when it began to grow dark, I called, but he insisted that he had something to finish. I called him several times after that, and then I became irritated. I came up, I had my dinner alone, and I went up to my bedroom. Then you admit that you quarreled with him the night of the murder? No, we didn't quarrel. I was irritated, but I said nothing to my husband. Your husband's death was caused by a deep, narrow wound in the vicinity of the heart. It's the opinion of this court that the instrument used might have been a nice pick. Mrs. Foley, have you any other ideas as to what might have inflicted this wound? No. Had your husband any enemies, Mrs. Foley? No. And so I was acquitted that day because of insufficient evidence. I thought Adele would come to me during those awful days, but she didn't. I saw her in the courtroom, but she never looked my way. I believe it was about two months after the trial that my son Doug and his friend Roy went on an all-day hiking trip to the beach. They were late getting back. It was almost dark when I saw Roy coming up the street. He was alone. He was running. Mrs. Foley, Mrs. Foley! Roy, where's Doug? He's down at the beach with her. With who? Your sister. My sister? For heaven's sakes, Roy, will you tell me what this is all about? You see, Mrs. Foley, Doug and I... It seemed that Roy and Doug had forgotten to take along their drinking water and they hadn't missed it until they'd come to a very deserted strip of the beach. Oh, come on, Doug. Maybe we can get water at that little house over there. It's the only place for a house, isn't it? Yeah. Well, come on. Looks like nobody lives here. Well, all the better. We can just drink out of that faucet in the yard. You won't have to ask nobody. Come on. Come on down, isn't it? Maybe the faucet isn't working. The garden's all dead. Oh, sure it's working. See? Someone's just plain lazy. Maybe no one lives here. Oh, sure they do. There's a mailbox. Maybe there's a name on it. Mrs. Adele Norris. That's Mom's sister. Yeah? Well, let's drop in and see her. Ah, she wouldn't even know who I was. Oh, you could tell her, couldn't you? Say, maybe she'd give us some cake or something. No, she's mad at me and Mom.  Say, Doug, look at all the dead leaves on the porch. Let's have a look around. No, she might come out. Oh, she can't hurt you, can she? Let's peek in the window. No. Oh, look, Doug, the place is all upset. It's all dirty and everything. Let's look in the rest of the windows. There's no one around. Here's the kitchen.  Hey, maybe my aunt is sick. Hey, look, somebody's coming to the... to the window. Oh, gosh. What do you want? We wanted to see if you were all right. Go away. Don't you recognize me? No. Are you sick? No. I'm your nephew, Douglas Foley.  I'd like to help you. Go away, I said. Mother wouldn't want me to leave you here like this. Who's your mother?  She's your sister. I have no sister. My sister died when I was 18.  My aunt is sick. I'll climb through this window and see if there's anything I can do. No, no, you stay out of this house. Well, Douglas, let's both go. She doesn't want you here. She's sick. You go for my mother and hurry. If you dare come in this house, you'll be sorry. If you dare... You say your name is Douglas Foley? Yeah, that's right. You see, I... Oh, no. Douglas Foley is dead forever and ever. No, no, don't you see? The one who died was my father. Douglas Foley came between two sisters. And then he died. Yeah, but I'm trying to tell you.   That's it. Yes, he'll have to die again. He'll have to die again. Look, you're sick. You need help. I'm sick? Yeah. Don't you want me to come in? Yes. Oh, yes. Come in, Douglas Foley. Tonight for Suspense, Roma Wines are bringing you Nancy Kelly and Claire Trevor in Meldinelli's radio play, Tale of Two Sisters. Tonight's study in Suspense. This is Truman Bradley for Roma Wines. We have an interesting idea for you tonight from the keen and sensible mind of America's famed expert on parties and smart entertaining, Miss Elsa Maxwell. And we quote... Serving a nice table wine when friends come into dinner or with everyday meals is one of the smartest, most sensible and fruly moderate pleasures of which I know and one which any family can regularly enjoy since the cost of delicious Roma Burgundy is very little. Just serve your Roma Burgundy well-cooled. Enjoy it with any food and don't worry about special glasses. Any glasses available are perfectly correct. The goodness of the wine, the added enjoyment of your food, these are the things that count. Well, Miss Maxwell expresses perfectly what we of Roma believe. In Roma, California Burgundy, in all Roma wines, you enjoy the glorious color, aroma and flavor of superb, sun-ripe grapes. Our noted wineries, located in California's choicest vineyard areas, assure you of flavor and quality which are always good, never varying, always delightful. And so, Roma quality is preferred everywhere and you are able to enjoy these fine Roma wines at modest prices. Only pennies are glassful. Remember, more Americans enjoy Roma than any other wines. R-O-M-A, Roma wines. And now it is with pleasure that we bring back to our sound stage Nancy Kelly Azadell and Claire Trevor who resumes the recital of this tale of two sisters. A narrative well calculated to keep you in suspense. You see how clearly I remember things? I remember so well the horror of that moment when Doug's little friend finished telling me how he had left Doug there alone with my sister Azadell. And I even remember what Roy said at the end.  But now I wish I hadn't left him there with her. I know she's your sister and all, but I saw her face when she came to the window. She looked awful, Mrs. Foley. She looked awful crazy. I followed Roy's directions and I went my foot north along the ocean. I must have walked a good mile before I came to the house. I ran quickly up the pathway. Front door standing open. The lamp burning on the table. Azadell! I couldn't see her very clearly by the candlelight, but I could see that she was fully dressed. Her hair was undone and it spilled down over the pillow. For a moment I thought she was dead. What do you want? Azadell. What do you want? It's me, Clara. Where's Douglas? He's dead.  I don't mean my husband. I mean my son. Where is he? He was murdered with a long sharp... Be still. You don't know what you're seeing. Where is my son? I haven't seen him. You have. He was here. I know that. I haven't seen him. Yes, yes, you have. Try and remember. Where is he? I... I don't know. Yes, yes, you do know. What have you done to him? Was he your son? Yes, Azadell. Please. I hated him. I know. Where is he, Azadell? He went away. Where? Where did he go? He... He went to the village. For a doctor. Are you telling me the truth? Oh, yes. How long ago did he leave? I... I don't remember. I... Will you stop questioning me? Tell you he went for a doctor. Come here, Clara. After ten years? I've come to help you. Oh, I don't need your help. Azadell, did Doug really go for the doctor? You think I'm lying? I don't know, but if he isn't back soon, I... I'm going for the police. The police? Take a thing off, Azadell. You'll be more comfortable. Then when the doctor comes for you to seek Azadell, let me take your thing. No! Yes, of course he will. Douglas Foley came between two sisters. Azadell. He... He worked in the garden, bending down low. Hired Clara. There he is. Try and rest, Azadell.  But he was working in the garden, and I was on my way home from the sewing club. I saw him there, Clara. He looked the same after ten years, because he had your strength to draw from. I was alone. I had grown old. And he had stayed young. And then she seemed to doze off. Her breathing was so labored. And I thought, perhaps she'll rest more easily if I undress her. And I went over to the bed. She was wearing a corset. I reached over and began to unhook it. She started mumbling something in her sleep. You... You broke your promise. Always and forever, you'd say. But she didn't wake up.  But as I went to place it on a chair, I noticed something protruding from the material. At first I thought it was a broken stay, but it was round. And one end was sharp. I looked closer. It was a steel knitting needle. A long, steel one. And there was rust on it. Or was that brown stain rust? A dell had concealed a knitting needle. And there was proof of what I guess I'd known all along. A dell had murdered my husband. With a shutter, I dropped it to the floor. And then something caught my eye. There was a hand sticking out from beneath the bed. It was white. Still, it was a child's hand. I fell swiftly to my knees. Just as I reached out for him, I felt a sharp blow on the back of my head. And I fell to the floor. But she was laughing. And that we were playing an old game of ours where we tied each other up with our bathrobe cords. And then we waited for a knight in armor to rescue us. It was the odor of kerosene that brought me to. The room was filled with it. I was pounding, and I couldn't seem to focus my eyes. I tried to raise myself to my feet. I couldn't seem to move my arms and legs. Suddenly I realized why. But I was tied with a bathrobe cord. I was a child again. A dell and I were playing our games again. My husband, everything that had happened between a dell and me had been nothing but a bad dream. A feeling of relief swept over me. Then I heard footsteps. And the door creaked slowly open. And suddenly I knew that what had happened had not been a dream. For a dell stood in the doorway. Not a dell the child who would rescue me. But a dell with gray hair who hadn't spoken for all those years. She wore a long dressing gown. She was barefoot, her long hair streaming about her shoulders.   And the odor of kerosene filled the room. She didn't seem to notice me as she went past me. And she threw the liquid from the bucket onto the bed. Oh, there! A dell! No, a dell! She paid no attention to me as she left the room again. I struggled wildly, but it was no use. I was tied securely. And then I saw a still figure on the bed. His face was white. He was unconscious. And there was a deep gash at the side of his head. And then a dell came into the room. She had filled her bucket to the brim. And she walked towards the bed again. A dell! A dell, listen to me. This is your son, Clara. Oh, yes, a dell. Untie me. Looking for him. He's untie me, a dell. I've unknew your son. For years I never knew him. What is he, Clara? He's only ten. A dell. A dell, you're sick. Sick. Untie me and we'll go for a doctor. You want me to be well, Clara? Yes, untie me. Are we friends again, Clara? Yes, yes, we're friends. I can't forget the years, Clara. I must wash those years away before we can really be friends again. A dell, forget those years. Let me help you. Untie me. No. No, we can't forget them, Clara. We must wash them away. That's what I was doing. I was washing away the years. Your husband's gone. Your son is all that remains of them. And then we can be sisters again. You don't know what you're doing. Untie me. But this isn't water that I have in this bucket. No, no, you see, you see your sick, a dell. It's what I put into the lamps to make them burn. No. Perhaps I could burn away the years. Oh, yes, that would be better. Much better. No, no. A dell for the love of heaven. Untie me. If I could burn away these years that remain on the bed. No. No, a dell. If I could do that with this candle, well, then you and I could really be friends again like when mother was alive. We could be sisters again. Always and forever. We're sisters now, Adele. No. Now you're lying. We're not sisters. Adele, Adele, listen to me. We're children, you see, and you've tied me with this cord and now you must undie me like you used to do when you left me too long and I cried. Oh, no. You're lying. We're not sisters. And we haven't been for years.  Then she started walking unsteadily towards me, a lighted candle in one hand, the bucket in the other, the liquid slapping over her dressing gown as she walked.  Well, that's what I'm going to do to you now. Or perhaps it would be better if I burned it out. No, no! Now, Clara, don't scream. You awaken your precious son and we mustn't awaken him now. Adele, untie me. I promise you that I'll take her away. We'll go away. You'll never have to see us again. Oh, no, Clara. And she kept moving towards me, holding the lighted candle close to her breast.  Adele, you're ill. You don't know what you're doing. Wash away the ears. Burn away the ears. Suddenly I saw a tiny flicker of flame on her breast. The frilly dressing gown. She'd held the candle too close. Her entire dressing gown was a mass of flames. It spread swiftly to her hair. In a moment she was a blazing torch and the odor of burning filled the room. I could see her face, surprise, and contorted with pain. She turned and talked to that a second. The bucket flaming in her... It was my sister Adele to think about it, Mrs. Foley. You knew my sister burned to death, didn't you, Mrs. Willard? She was very beautiful. Yes, I know. Try and rest. Is there anything I can get you before I go to bed? No, thank you.  Well, you go to sleep then. I will. Good night. That's right. Go to sleep. Was that my sister, Mrs. Willard? No, no, Mrs. Foley. It was one of the others. They scream because they remember things. Yes, I suppose they do. Good night. Good night. Remember things too. I remember. I remember. Promise me you'll never leave me, Clara. And whatever I do, you'll do. I promise. Always and forever. Always and forever. I promise. And so closes Tale of Two Sisters, starring Claire Trevor and Nancy Kelly. Tonight's study in... Suspense. Suspense is produced, edited and directed by William Spear. The other day, Elsa Maxwell told us about a friend who had lived many years in wine-loving countries around the world. I gave him some of our delicious Roma California Burgundy at dinner, and he confessed to me that he thought it every bit as enjoyable as any he had ever had. So I say, you people who do not regularly serve Roma wine are missing one of the most delightful treats daily living can offer. It's so good, so smart, and yet so very simple. Take Miss Maxwell's advice. Enjoy Roma wine regularly. It's always good, unburyingly fine in flavor and quality, and only pennies a glass. Remember, more Americans enjoy Roma than any other wines. Roma, R-O-M-A, Roma wine. Next Thursday, same time, you will hear Mr. Lee Bowman as star of... Suspense. Presented by Roma wines, R-O-M-A, made in California for enjoyment throughout the world. This is CBS, the Columbia Broadcasting System.


Welcome to lecture 40 on measure and integration. In the past two lectures, we had been looking at the various modes of convergence for measurable functions. We will continue this study in today's lecture also. We will recall some of the properties of convergence in measure that we had proved last time and then we will go on to what is called convergence in the pth mean. Let us just recall what we have been doing. f and f n are measurable functions on a measure space. Then we said that f n converges to f in measure f for every epsilon bigger than 0. The measure of the set all x, where f n x minus f x is bigger than or equal to epsilon, that measure of that set goes to 0 as n goes to infinity for every f. In some sense, the measure of the set, where f n is away from f by a distance epsilon, that goes to 0 for every epsilon bigger than 0. This was called convergence in measure. We denoted this by saying that f n with a arrow and the symbol m above it f. f n converges to f in measure. It is noted by this symbol. In the previous lecture, we showed that the convergence in measure neither implies nor is implied by convergence point almost everywhere. That means, if f n converges to f in measure, then it need not imply that f n converges point wise or almost everywhere. Conversely, if a sequence converges point wise or almost everywhere, then need not imply that it converges in measure. However, we proved that if the underlying measure space is finite and f n converges to f almost everywhere, then it also converges in measure. That means, convergence in measure is implied by convergence almost everywhere if the underlying measure space is finite. After that, we looked at what is called almost uniform convergence for functions. We said a sequence f n converges almost uniformly to f on a set E, if we can find for every epsilon a subset E epsilon such that the measure of the set E intersection E epsilon complement is finite and f n converges uniformly to f on E.  This is called almost uniform convergence. Note, this is different from saying that the convergence is almost, convergence is uniform almost everywhere. Saying that f n converges to f uniformly almost everywhere will mean that except for an L set f n converges to f. And almost uniform convergence is saying that outside a set of measure 0 for every epsilon, there is a set E epsilon of such that outside that set, the convergence is uniform. In general, we showed that convergence in measure does not imply convergence almost everywhere, because if convergence almost everywhere, almost uniform implies convergence almost everywhere. We want to conclude that convergence in measure does not imply convergence almost uniform, because almost uniform convergence implies almost everywhere convergence. So, if convergence in measure implies almost uniform convergence, then it will also imply a convergence almost everywhere, which is not true in general. So, convergence in measure does not imply convergence almost uniform. However, if f n converges almost uniformly to f, then it also converges in measure. So, the convergence is always true. Namely, if f n converges almost uniformly to f, then f n converges to f in measure. So, that the proof of this is quite simple. So, because f n converges to f almost uniformly, so that means for every delta bigger than 0, we can select a set E delta such that outside the measure of the set outside E delta is small, f n converges uniformly to f on E delta. So, that is why the property that f n converges almost uniformly to f. So, for every delta, we can find a subset. So, let us say we are analyzing this on the set E, then measure of the set outside E delta is small and f n converges uniformly to E delta. But, what does that mean? That means, because it is converging uniformly to f on E delta, so that means for every n, integer n bigger than 0, f n must come close to f for every x in E delta. So, that means for every epsilon bigger than 0, if you look at, there exists a set n, this is a natural number n, say that the distance f n minus f x is less than epsilon for all n bigger than n and for every x belonging to E delta complement. But, then that means, if we look at the set of points where this is bigger than or equal to epsilon, that will be contained in E delta and measure of E delta is less than epsilon. So, that will prove that for every delta, we have got a stage n bigger than n naught, say that x, say that f n x minus f x bigger than epsilon is less than delta. That means, f n converges to f in measure. So, we have shown that almost uniform convergence implies convergence in measure. So, these are the basic properties of relations between convergence in measure with almost uniform convergence, convergence point wise and so on. Now, we just now said that convergence in measure need not imply convergence almost everywhere in general. However, one can prove a partial result in this direction namely, if f n converges to f in measure, then there is a subsequence which converges almost everywhere. And this result is quite useful sometimes when you are analyzing sequences of measurable functions which converge in measure. So, this theorem is called Rie's theorem. So, let us prove Rie's theorem. So, it says that f n be a sequence of measurable functions converging in measure to a measurable function f. Then there exists a subsequence f n k, such that f n k converges to f everywhere or almost to almost everywhere actually, we should be saying to f n almost. So, every sequence which converges in measure has a subsequence which converges almost everywhere. So, let us see a proof of this. So, to prove this, we have whatever looking at, we are looking at how to construct a subsequence f n k which converges almost everywhere to f. So, that means we have to find f n k such that, so we reformulate the problem as follows that look at the set of points. So, f n k we want with the property that whenever f n k x minus f of x is bigger than 1 over k, the set of these points for k equal to union of such sets for k equal to j to infinity, intersection over j equal to 1 into infinity, that must be equal to 0. So, we want a sequence f n k such that this measure of this set is equal to 0. Why is that enough? So, let us just look at it. So, we are saying that f n k will converge to f almost everywhere. If we look at the set intersection j equal to 1 to infinity, union over k equal to j to infinity, the set of points x belonging to x such that mod of f n k x minus f of x bigger than 1 over k, this set has got measure 0. Why is that? Because if we take an element x belonging to this, what will that imply? So, that is if and only if x belongs to, this is belonging to intersection, so x belongs to union k over j to infinity, x belonging to x such that f n k x minus f of x is bigger than or equal to 1 over k for every j. That must happen for every j, because it belongs to intersection. But what does that mean? That is if and only if this belongs to j, that means for every j, there exists k equal to j, k equal to j to infinity. So, that means for every j, there exists k bigger than or equal to j such that saying that x belongs to this union means x will belong to at least one of them. That means x belongs to for this set for some k bigger than or equal to j. So, there is a k bigger than or equal to j such that x belongs to this such that means f n k x minus f of x is bigger than or equal to k. For such an x, this must hold is bigger than or equal to k. So, that means it does not converge. So, if we show that this set has got measure 0, that means if x does not belong, then it must converge. So, what is the meaning of saying? So, if we want to say that x does not, if x does not belong to this set, that will mean what? It does not belong to the intersection. That means it does not, that means there exists. So, x belongs to this, does not belong to intersection. That means at least it does not belong to one of them. So, there exists some j not such that x does not belong to this. And if x does not belong to this for some j not, it does not belong to union. So, there exists. So, that means there exists a j not such that from j not onwards x does not belong to this. That means x cannot belong to any one of them. That means for every k bigger than or equal to j, there is a j not such that for every k bigger than or equal to j, bigger than or equal to does not hold equal to j. That means this must happen for less than 1 over k. So, saying x does not belong to this set will mean there is a j not. So, that for every k bigger than or equal to j not, the distance is less than k. That will imply that f and k x converges to f of x. So, what we are saying is essentially that this is the set of points where f and k does not converge to f and we want that set to have measure 0. So, once again let me revise saying that f and k does not converge to f x is same as saying x does not belong to this set. So, because if x does not belong, so for every does not belong to intersection over j of some sets. That means there is a set, there is a j not such that x does not belong to j not. So, it belongs to this for some it should be union of k. So, that is a union here. So, that means for every k bigger than j not this is less than k. So, we have to only find a subsequence. So, we have to complete the proof. We have to construct a subsequence. So, that measure of this set is equal to 0. So, let us write this set as A. So, A is the set of points where intersection over j equal to 1 to infinity union over k equal to j to infinity of where f n k x minus f x is bigger than or equal to 1 over k. And let the inner portion which is a union let us call that set as A j. So, what we want to prove is that mu of intersection A j is equal to mu of. So, we want to prove that mu of A is 0, but this set A is contained in A j because this is the intersection is smaller. So, A is subset of A j. So, showing that the mu of the set A is 0, A is contained in A j that means mu of A is less than or equal to mu of A j. So, we will be through if we can prove that mu of A j is converged to 0 as j goes to infinity. So, we have to construct a subsequence f n k with this property that mu of A j is of these sets must go to 0 as j goes to infinity. So, this will be true. So, we want a subsequence that mu of A j is go to 0. So, that will be true If we could find say for example, a sequence f n k says that the measure of the set where f n k minus f x is bigger than or equal to k, say it is less than 1 over 2 to the power of k plus 1. Suppose, we can choose our subsequence in that way then what will happen? Then mu of A j which is nothing but union of from k equal to j to infinity of these sets. So, that is by countable sub additive property mu of A j will be less than or equal to summation k equal to j to infinity mu of these sets and each mu of this set is less than 1 over 2 to the power k plus 1. So, that is summation j equal to infinity. So, that will be this is a geometric series with common ratio less than half. So, that will give you 1 over 2 to the power j. So, we will get mu of A j less than 1 over 2 to the power j. So, as j goes to infinity we will get mu of A j equal to 0 and hence we will be through. So, we have to only find a subsequence f n k with this property and that is done by using the fact that f n converges to f in measure. So, because it converges in measure, so by the property of convergence in measure, let us start with epsilon equal to 1 then convergence in measure says that mu of the set of those points where f n minus f x is bigger than 1 will be less than say half for every that goes to 0. So, that means after some stage the difference of the measure. So, measure of the set where f n minus f x is bigger than or equal to 1 will be small after some stage. So, let us that stage be called as n 1. So, using the fact the convergence in measure we can choose n 1 such that measure of the set where f n 1 minus f x bigger than 1 is less than half. Now, we proceed inductively supposing we have selected n 1 less than n 2 up to n k minus 1 have been selected with those required property.  So, by induction this existence is a sequence f n k with this property is complete and hence we will have that this up sequence converges almost everywhere to f. So, this is an important result which is used sometimes to analyze sequences which converge in measure. So, this is called Rie's theorem. So, we have looked at various properties of. So, till now we looked at various properties of convergence, convergence almost everywhere, convergence point wise, convergence almost uniform, convergence uniform and convergence in measure and relations between such modes of convergence. There is another mode of convergence which arises when the functions f n are in LP spaces. Recall we have defined LP spaces the p th power integrable functions. So, one would like to know that when sequences converge in LP, does this convergence have any relation with convergence in measure, point wise convergence or convergence almost uniformly. So, we will analyze these things next. So, let us recall what is the meaning of saying that have a sequence converges in the p th mean or LP. So, saying that a sequence f n where p is bigger than 1 less than infinity and f belongs to LP. So, let us take functions f n and f in LP. So, saying that f n converges to f in LP or sometimes one also writes this as f n converges in the p th mean to f if the p th norm of f n minus f goes to 0 as n goes to infinity. So, this is called convergence in the p th mean. So, we would like to find out the relations between the p th means and other modes of convergence. So, the first property is that in general, convergence in the p th mean does not imply uniform convergence and it need not imply almost uniform convergence or convergence almost everywhere. So, convergence in p th mean need not imply any one of uniform convergence almost uniform convergence or convergence almost everywhere. So, to give an example of measure space and a sequence of functions in LP say that f n converges to f in LP, but f n does not converge in uniformly or almost uniformly or almost everywhere. So, we will give an example of a sequence which does not which converges in LP, but does not converge almost everywhere. So, that example itself will imply that p th mean cannot imply uniform convergence because uniform implies convergence almost everywhere. And similarly, same example will be sufficient to say that p th mean does not imply almost uniform convergence because uniform convergence implies almost uniform convergence. So, we want to construct a sequence of functions in LP such that the sequence converges in LP, but does not converge almost everywhere. So, for that, let us look at the measure space, the interval 0 1, Lebesgue measurable sets in 0 1 and lambda the length function. And let us write, if you recall, we had constructed a sequence of measurable functions on this measure space by looking at dividing the interval into equal parts by using the binary points. And that example showed that, that was the example which showed that convergence in measure does not imply convergence almost everywhere. So, that is the sequence we are looking at again. So, let us recall that sequence. So, f n for every n bigger than or equal to 1, let n be represented as k plus 2 to the power m, where this k is between 1 and 2 to the power m and m is. So, this we showed that for every n can be written uniquely in the form k plus 2 to the power m, where m is a positive integer and k is between 1 and 2 to the power m. So, for whenever m n is represented this way, we define f n to be the indicator function of the interval k by 2 to the power m and k plus 1 to k plus 1 by 2 to the power m. So, look at the k th interval of length 1 over 2 to the power m and define f n to be the indicator function of this interval. So, we showed earlier that this sequence of measurable functions does not converge almost everywhere and this converges in measure to the function identically equal to 0. So, this sequence of measurable functions converges in measure to f identically 0, but it does not converge to f at any point in 0, 1. So, this does not converge almost everywhere or at any point actually. Let us just prove that this sequence of measurable functions is in L p because this is the indicator function of an interval. So, the function takes the value 1 on this interval and interval is finite. So, obviously it implies this is a L p integrable function. So, indicator function of a sub-interval, so f n belongs to L p. So, we have got a sequence of functions in L p such that and let us look at what is the L p norm of f n because it is the indicator function of a interval of length 1 over 2 to the power m. So, it is precisely equal to 1 over 2 to the power m. The function takes the value 1 on that interval of length 1 over 2 to the power m. So, its L p norm is 1 over 2 to the power m raise to power 1 over p. So, this implies that the norm of f n minus f which is identically 0 goes to 0 as n goes to infinity because as n goes to infinity m also goes to infinity. So, this is a sequence of functions in L p which converges to the function identically 0, but the sequence does not converge almost everywhere. So, that proves our claim namely convergence in p, convergence in the pth norm does not imply convergence uniform or convergence almost uniform or convergence point wise. So, convergence in the pth mean does not imply this and so as we indicated this cannot imply uniform or almost uniform because both of them imply convergence almost everywhere. Next, let us look at fact that convergence in the pth mean always implies convergence in a measure. So, let us take a sequence f n which converges to f in L p and let epsilon greater than 0 be arbitrary. So, what we have to show? Let us just look at what we have to show. So, f n converges to f in L p. So, we are given that f n converges to f in pth mean to show f n converges to f in measure. That means, so what does it mean? That is for every epsilon bigger than 0, we have to look at the measure of the set x belonging to x such that f n x minus f of x bigger than or equal to epsilon limit n going to infinity must be equal to 0. So, this is what we have to show. So, let us call e to be the set x belonging to x where f n x minus f of x is bigger than or equal to epsilon. Now, we know that f n goes to f in L p.  Let us take the power p also. So, what will that mean is the following.  So, that is what and this goes to 0. But this is equal to integral over e of the same thing f n minus f to the power p d mu plus integral over e complement of the same thing.  Now, on the set e, on the set e, on the set e f n is bigger than or equal to epsilon. So, on the set e, this difference is bigger than epsilon. So, it is bigger than or equal to epsilon to the power p into mu of the set e plus integral over e complement. But this is a non-negative function. So, even if I drop this term, it will still remain bigger than or equal to mu of e. So, that implies that mu of e is less than or equal to mod mu of e is norm of f n minus f to p divided by epsilon to the power p. So, this is the inequality that we get for, this is actually an important inequality in the theory of probability and this is called Chebyshev's inequality, a very simple inequality, but you see it gives a powerful outcome. So, that is following, because f n converges to f in L p. So, this goes to 0. So, that means that mu of e equal to 0. So, the set where f n is bigger than f by distance epsilon, mu of that depends on epsilon and so that goes to 0 for every epsilon. So, that will prove that if f n, so that proves that if f n converges to f in the p th mean, then it converges in measure. So, as we looked at just now, the proof is simple.  So, and one part where the function f n minus f is bigger than epsilon is this and the remaining part will drop. So, inequality still stays, so mu of e is less than or equal to this, which goes to 0. So, that proves that convergence in the p th mean implies convergence in measure. However, in general, the convergence almost everywhere does not imply convergence in the p th mean. So, for that let us look at a simple example. Look at the Lebesgue measure space or Lebesgue measurable sets lambda. So, that is the Lebesgue measure space and look at the function f n which is defined as n raise to the power minus 1 by p into the indicator function of the interval 0 to n. So, this function first of all let us observe that this function belongs to L p because integral of f n raise to the power p is just n to the power minus 1 to the power p. So, that is 1 over n and into the measure of the interval 0 n that is n. So, all the each f n is a L p function, its integral norm is equal to L p norm is 1 and this converges uniformly to f. That is obvious because the values of the function that is taking on a larger and larger interval is 1 over n. So, becoming smaller and smaller. So, we can always find for every x, we can find a stage such that after which the distance will be less than 0. So, that means f n converge. So, it is easy to check. Let us verify. This is easy to verify that f n converges to f uniformly. However, we have now said that the L p norm of each f p is 1. So, that does not converge to f in the p th norm. So, what we are saying is convergence almost everywhere does not imply convergence in the p th mean. This is convergence almost everywhere. Here is another observation that none of uniform convergence or almost uniform convergence or convergence in measure imply convergence in the p th mean. So, that means the none of this each one. So, that means in general uniform convergence does not imply convergence in the p th mean or convergence almost uniform does not imply and similarly convergence in measure need not imply convergence in the p th mean. Because obviously, because both uniform convergence and almost uniform convergence apply convergence almost everywhere. So, if this were true, then we will have a contradiction. So, this is true. Next we want to say that convergence in the measure need not imply convergence in the p th mean. So, for that let us look at the example of the measure space 0, 1, Lebesgue measure space and let define g n of x equal to n to the power 1 over p. It is something similar to the previous one. Instead of minus 1 over p, it is n to the power 1 over p and into the indicator function of 0 to 1 over n. So, here the interval where function is non-zero is shrinking, but the value is increasing. In the previous one in the previous one, the value was decreasing, the length was increasing. So, it is the other way round of this. So, look at this function g n. All of these functions g n are in L p because integral mod g n will be equal to the power p will be n into indicator function. So, integral is equal to 1. So, each one of them has got is in L p with integral equal to 1. And it is obvious that the sequence g n converges in measure. It converges in measure that is obvious because the set where it is going to be together or equal to epsilon is going to be shrinking, it is 0 to 1 over n. So, that will go to 0. So, converges in measure and to identically equal to 0 and its integrals L p norms are equal to 1. So, hence g n does not converge to f identically 0 in the pth mean. So, that means we have produced a sequence of functions which is convergence in measure, but does not imply convergence in L p spaces. However, if the underlying measure space is finite, then the uniform convergence does imply convergence in the pth mean. So, that is quite obvious to verify. Let us just look at mu of a measure space so that mu of x is finite and let f n be a sequence of functions in L p converging uniformly to a measurable function f. We want to show that f n converges to f in L p also, but what is uniform convergence? Uniform convergence means for every epsilon bigger than 0, there is a stage such that after which, given every epsilon bigger than 0, you can find a stage n naught such that the distance between f n and f is less than epsilon for every n bigger than or equal to n 0 and for every x. So, uniform means for every x, the same stage satisfies the required property. So, for every x, there is a single stage n naught such that f n x minus f of x is less than epsilon. .. Now, let us look at the absolute value of the function mod f to the power p. See, we have just given that f is converging uniformly and each f n is in L p, but we do not know whether f is in L p or not. So, we have to first prove that this is in L p, but look at the absolute value of f to the power p. So, by triangle inequality, I can write it as mod of f n minus f plus. So, this should be also less than or equal to by triangle inequality add and subtract f n to the power p. Now, absolute value of a plus b is always less than or equal to 2 times the maximum of the two values. So, this is less than or equal to 2 times the maximum value of f n minus f and absolute value of f n. Of course, everything is to power p, but that is same as less than or equal to 2 to the power p into the maximum of this to the power p. Now, 2 to the power p and the maximum will always be less than or equal to the sum. So, you can write this is less than or equal to 2 to the power p mod of f n minus f to the power p plus mod of f n to the power p. So, what does that imply? So, we can integrate both sides with respect to mu.  So, this will be less than 2 to the power p epsilon to the power p mu of x plus 2 to the power p norm of f n to the power p and each of them being finite that says that the function f is in L p. So, what we have shown is if the underlying space is having finite measure and f n belongs to L p and converges uniformly to f, then the limit function is also in L p. So, that is what we have shown and now look at the difference. So, the difference of f n minus f to the p th norm is by definition integral of mod f n minus f to the power p raise to the power 1 over p, but for n bigger than n naught this difference is less than epsilon to the epsilon to the power p raise to the power 1 over p. So, that is epsilon into mu x raise to the power 1 over p. So, as epsilon goes to 0, this will go to 0. So, that proves that f n converges to f in the p th mean. Let us also analyze what happens the relations between L p spaces and other modes of convergence when the underlying space is of finite measure. So, the result says even if the underlying measure space is finite, then none of uniform convergence or convergence almost everywhere need imply convergence in the p th mean. So, this condition is not good enough to ensure that almost uniform convergence that will imply. That we have just now looked at the function g n x is equal to n to the power 1 over p. So, these are all L p functions and they with norm equal to L p norm equal to 1. So, they cannot converge in L p, but we know that this converges in measure and hence almost uniform. So, also the convergence in the p th mean need not imply almost uniform convergence or convergence almost everywhere. The other way around inequality, even when this is finite the convergence in p th mean need not imply almost uniform or convergence. So, that earlier example of the measure space 0 1 0 1, Lebesgue measurable sets and f n to be the indicator function of the interval i k m, where i k m is the interval of length to the power m. Just now we consider this example. So, this is the example of functions that converges to f uniformly. So, it converges to f in the p th, f identically 0 in the p th mean, but we know that it does not converge almost everywhere and hence it cannot also converge almost uniformly, because almost uniform convergence implies convergence almost everywhere. So, these are the various ways of looking at modes of convergence and analyzing them. Let me just look at this. All the implications put together in the form of a diagram. So, here is the diagram going to look at this. So, here we have got the notion of uniform convergence, uniform almost everywhere in the p th mean. Here is point wise, point wise almost everywhere in measure and almost uniform. As we all know that uniform convergence is the strongest one. So, uniform we have already seen earlier that uniform implies point wise and of course, point wise implies point wise almost everywhere and this other way around implications need not hold. Simple examples. In uniform, we will imply uniform almost everywhere. Actually, uniform is uniform almost everywhere with the set to be empty set. So, uniform implies uniform almost everywhere and just now we proved when mu of x is finite. So, this green arrow indicates that implication under the condition that mu of the whole space is finite. So, uniform convergence almost everywhere and underlying space finite implies convergence in the p th mean that we saw just now. And this way, we have already seen uniform implies point wise, apply point wise almost everywhere. And we also saw that point wise convergence, point wise almost everywhere. In general, linear implies convergence in measure, but when underlying measure space is finite, point wise will imply convergence in measure. Of course, point wise almost everywhere need not imply almost uniform, but we just showed today that if the underlying space is finite measure, then the point wise implies almost uniform. And obviously, almost uniform we have shown implies point wise almost everywhere. And finally, we also showed today that almost uniform implies in measure and when the underlying space is finite, in measure implies convergence in the p th mean, we use Chebyshev's inequality. And just now we said that convergence always in the p th mean always implies convergence in measure. So, this is the overall picture of various modes of convergence. So, with this we come to the end of the basic concepts of measure theory. Whatever we have not done is essentially looking at, one can also look at various ways of necessary and sufficient conditions under which a sequence f n converges to f in L p. That is one thing we have not done, but in the limited scope of lectures, we wanted to cover almost in 40 lectures the basic concepts of measure theory and that we have covered. Another thing that we have not proved is looking at the change of variables formula for R n. That again requires a bit of work and technical things. So, we have not covered that in our discussions. So, with that we come to an end of this course video lectures on measure theory. In the next one lecture, I will just try to give an overall view of the things that we have done in our course. Thank you.


The GitLab Kubernetes agent allows a secure bi-directional connection between GitLab and any Kubernetes cluster. In this video, I'll show you how to set up this connection using the newly introduced GitLab Kubernetes agent user interface, which streamlines the setup of your GitOps workflows. Hi, my name is Cesar Saavedra, Technical Marketing Manager at GitLab. Let's get started. We already have a Kubernetes cluster running. Since it's running at the group level, the app group level, let's go ahead and create a project inside this group. Within this directory, we'll create next a file called config.yaml, but it needs to be located under specific directory. The directory needs to be .gitlab. Agent Cesar Saavedra agent K. It is under agents where the configuration of all your agents will reside. In this case, I only have one agent. That directory will create a file called config.yaml. This is basically the configuration of the agent. This is saying that the project that will be observed for changes and updates is this one here, Tech Marketing City Workshop GitOps Apps pull-based GitOps, and the path under that project will be manifest and any file under that sub-directory that has the suffix yaml, yml, or json. Next, we need to go to the Kubernetes cluster. And on this screen, you see the Kubernetes cluster there, SNEKS cluster, and we click on GitLab Agent Managed Clusters. We say integrate with GitLab, and here we select the agent that we just created. Now to install the agent that runs within the Kubernetes cluster, here's the command we need to run. So let's copy the command. Here I have set up my command line to be able to connect to the EKS cluster, and I've done that by creating a file called config, Cesar Saavedra GitOps EKS under my .cubed directory, and this is basically the information that I need to provide to the cube config so that it can successfully log in or connect to the cluster. And that's the HTTP address for it. One more thing I did was I defined a variable called cube config that points to that specific file. That way, when I run this command, it should be connecting to it. Very good. So the GitLab agent has been installed on the Kubernetes cluster. Let's check the pods that are up and running, and there it is. The agent is deployed and running in the EKS cluster. So let's head to the pool-based directory. And in here, let's go ahead and create a folder called manifest. And in manifest, let's create a file that we'll call nginx.yaml. Let's paste the configuration for an nginx deployment. There are now two nginx pods up and running. And as you can see here, there were two replicas, so that's consistent. So let's add one more. So let's edit. Let's put a three here. And before we do that, let me see if we can do the following. Let's do a watch here. Very good. So let's commit changes and see if there's a third nginx deployment that is spawned. And there it is. The Kubernetes agent is actually taking care of bringing up a third nginx instance. As soon as the yaml file was updated. So that's one and two. And it's creating one right there. And there it is. The three nginx pods up and running. So we have shown how you can streamline the integration of your Kubernetes clusters for use in your GitOps workflows by using the new GitLab Kubernetes agent user interface. I hope you enjoyed the video and until next time.