Hi, so I am my name is Lydia, and I just finished my ITTT ITTT course with a Tutor named Carl and he was based in Thailand and so every Every day I set a goal for every day doing a Unix I wanted to finish quickly so that I could get a placement or a posting and the Things that were really wonderful about this program was that I was able to ask any question that I wanted to my My tutor and that was great I also I think that the best thing for me is just that I could do this whenever I wanted I mean it was online. I could I Have a macbook and I was able to I can go You know a lot of different places to work on my lesson plans I ended up being in the kitchen a lot and that was just really comfortable and fine for me The weather hasn't gotten really that amazing here in Vermont it's June 14th and Summer's just beginning so anyway, I think that was the best feature of all that It's a very portable course so you can do a unit there the 20 units total You can do a unit anywhere at any time with the supervision that you need and There were many times when I completed the unit and needed some extra help My tutor Carl sent back the unit and said there are just a few issues and And so then I'd have to look at those again and you know review Whoops, I lost the picture here. So anyway, that's what I would say are the the best Features of this program I just sent off a document stating what I want my certificate to look like what I want my certificate to say So I'm really excited. I have an offer to go to Thailand in October and So I'm I'm hoping to really change things up for me in my life so Good luck


from Seattle, Washington. It's theCUBE, covering KubeCon and CloudNativeCon North America 2018. Brought to you by Red Hat, the CloudNative Computing Foundation and its ecosystem partners. Hello everyone, welcome back to theCUBE's live coverage here in Seattle for KubeCon and CloudNativeCon 2018. I'm John Furrier with Stu Miniman, three days of coverage around the CloudNative growth, around the ecosystem, around open source, and the role of microservice in the cloud. Our next guest is Roland Garcia, who's the IBM Distinguished Engineer for IBM's Hybrid Cloud. Welcome to theCUBE. Thank you, glad to be here. Thanks for joining us. Being a Distinguished Engineer at IBM is a pretty big honor, so congratulations. It means you got technical chops, so we can get down and dirty if we want to, but I want to get your check on this because a lot of companies in IT are transforming. That's right. And that's been called digital transformation. It's happening, and cloud has helped scale, and the wish list, if you had the magic wand, if you can make things do better, is actually happening. Kubernetes is actually creating some goodness that if you had the magic wand, if I asked that question three years ago, if you had a magic wand, what would an environment look like? Seamless operations around the cloud. So it's kind of happening. How are you guys positioned for this? Talk about the IBM cloud, what you're doing here, and how you see this cloud native market exploding. Obviously, there's 8,000 people here up from 4,000 last year. Yeah, that's a great question. I think I work a lot with our enterprise clients. I'm part of what's called the IBM Cloud Garage, so I'm very customer facing. And oftentimes we're seeing that there's different paces of a journey. And so, for example, I worked with a client that started building a cloud native application. They built about 60 microservices, and at the end of that, they were deploying it as one job, which means they defeated the whole purpose of microservice architecture. And so what we really need to think about is an end-to-end journey. I think the developers are probably the more modern role in an enterprise, but we're starting to see modernization of an operations team, for example, and adopting culture and cutting down the walls of IT organizational groups into mixed squads, adopting something like a Spotify model. And I think a lot of the challenges in adopting Kubernetes is really in cultural aspects in an enterprise. That make sense? And because network guys are different than the app guys, and now they have policy knobs on Kubernetes. They could play with network guys love policy. Yeah, and they're fighting over ownership, right? Yeah, Roland, we look at that modernization, the application modernization really is that long-haul intent. And what we hear here is you need to be able to meet customers where they are. Sure, there's some stuff they're building, shiny and new, and have the developers, but enterprises have a lot of applications, and therefore there's a grand spectrum. What do you hear from customers? What's the easy part and where's the parts they're getting stuck? Yeah, so I think the easy part is writing the application. I think where they're getting stuck is really scaling it to the enterprise, doing the operations, doing the DevOps. I always tell people that a modernization journey might be better started by taking a certain class of applications like middleware. We have a web sphere heritage from IBM, and saying, why don't we take a look at containerizing that? We've built tools like Transformation Advisor that'll scan your web sphere applications and tell you what do you need to change in that middleware application to make it behave well in a containerized platform. Then from there, you built your DevOps engine, your DevOps pipeline, and you really start to get your operations teams going in delivering containers, delivering applications as containers, and then getting your policies and your standards in place. Then you could start opening up around innovation and start really driving towards building cloud native new applications in addition to that. Yeah, one of those areas we've been talking about in the industry for decades is automation. Conversation is a little bit different these days. Maybe you can bring us up to speed about what's different today than say the web sphere days. Yeah, I think IT organizations have always done a bit of automation. I think they're right scripts, they automate builds. I think the mantra that I use is automate everything, right? Organizations need to really start to automate in a new way how I deliver containers, but delivering the app is not enough. I need to automate all levels of testing in a modern way. Test-driven development is big. At the IBM Cloud Garage, we have something we call the IBM Cloud Garage method, which really takes a set of practices like test-driven development, pair programming, things out of lean startup, extreme programming, and really start to help enterprises adopt those practices. So I say, why can't we automate end-to-end performance testing in the pipeline and functional testing, and writing them early and in the beginning of projects that way as I'm deploying containers which are very dynamic, along with configuration, along with policy, you're testing it continuously. I think that level of automation is what we need to get to. Talk about security as well, because security is one of those things where it's got to be baked in up front, you got to think about it holistically. It's also now being pulled out of IT, it's being more of a board function because the risk management is one hack you could get crushed. And so you got to have security. And the container is a security boundary issue, so it's important. Last week we met with an insurance company, we did a workshop, and they walked us through all the compliance steps that they need to go through today, how they do it with traditional middleware and virtual machines and hardware. And it was a very, what I'm going to say, governance-driven process. And so a lot of checks and balances stop, don't move forward, which is really the industry for developing and innovating is going the opposite way, self-service and enabling, and there's a lot of risk with that. And so what we're really trying to do with technologies like multi-cloud manager technology we have around multi-cluster management is how do I do things like I want to check which clusters are HIPAA compliant? Which ones are out? How do I enforce that policy? Now that everything is software-driven, software-developed, there's an opportunity to really automate those checks. To your point, automate everything. Yeah, automate everything. Governance is a service. Yeah, that's right. And actually that can help get away from error-prone human checks, where it had all these tons of documents of all different policies they have to go through can now be automated in a seamless way. So compliance and governance could be a stumbling block or it can be part of the software? That's right. That's what you're getting at. That's what I'm getting at. I think the transition is, look at it as an opportunity, now that everything is software-driven, use software disciplines that developers are used to in those security roles, in those CISO roles, et cetera. So I want to ask you a question. So one of the things we're seeing, obviously with cloud is it's great for certain things and then on-premises that does latency issues, we saw Amazon essentially endorse this by saying RDS on VMware, on-premises, they announced Outposts at Reinvent. Oh, latency, things aren't moving into the cloud as fast. So you're going to see this hybrid environment. So hybrids, we get that, it's been around check. No real discussion there other than it's happening. The real trend is multi-cloud, right? That's right. Multi-cloud is just a modern version of the word multi-vendor about the client server days. So in the systems world, multi-vendor meant choice. This is a fundamental thing. So it's not so much about multi-cloud as it is about choice. That's right. How do you guys see that? Obviously you are in an environment where you have a lot of customers who don't have one cloud. That's right. So this is a big upcoming trend in 2019. Most of our clients have at least five different clouds that they deal with, whether it be an IaaS, a PaaS, a SaaS-based solution. What we're seeing as a trend is we talked about on-premise and private and enterprises, I think 80% of workloads are still in a data center. And so they want to build that private cloud environment as a transitionary point to public. But what we're seeing across the multi-cloud space is, I'm going to say a new integration space. If you really think 15 years ago, SOA and enterprise service buses in a very centralized fashion, I think there's a new opportunity for integration across clouds and on-prem in a more decentralized way. So I think integration is kind of the next trend that we're seeing in this multi-cloud space because the new applications that we're seeing with cognitive data AI are mixing data sources from multiple clouds and on-prem. And needing to control that in a hybrid control plane is key. It's funny, the industry always talks about these buzzwords, multi-cloud. If we're talking about multi-cloud, then it's a problem. The idea of infrastructure as code is to not even use the word multi-cloud. I mean, if you think about it, if you're programming the infrastructure and enabling the stuff under the covers, why even talk about cloud? It should be automated. So that's the future state. But in reality, that's kind of what enterprises are trying to think about. They are, and I think it's a tension between innovation and moving fast and control, right? The enterprises want to move fast, but they want to make sure that they don't break security protocol, that they don't break resiliency that they maybe have used to with their existing customers and applications. I do think the challenge is how operations teams and management teams start to act like developers to get to that point. And I think that's part of the journey. Open source is obviously a big part of this show. And that's open source. People contribute upstream. It's great stuff. IBM's a big contributor. And even more when Red Hat gets into the mix. So upstream is great. But as you got 8,000 people here, you're starting to see people talking about business issues and other things. One of the downstream impacts of this conference being so open source centric is the IT equation. And then just the classic developer, right? So you have multiple personas now kind of interacting. You got the developer, you got the IT architect, cloud architect, pro, whatever. And then you got the open source community members. Sure. Melting pot, good challenges, thoughts. So I think it's, so developers love that, right? I think from an enterprise perspective, there are issues. We're seeing a lot of our clients with our private cloud platform ask us to build out what's called an air gap environment, which is, how do I build up an open source style ecosystem within my enterprise? So things like getting an artifactory registry or a Docker registry or whatever type of registry where I get certified open source packages in my enterprise that I've gone and done security vulnerability scans with. Or that I've made sure that I look at every layer from the Linux kernel all the way up to whatever software is included. So we're seeing is how do I open the aperture a bit but do it in a more responsible fashion, I think, is the key. Yeah, and that's for stability, right? Yeah. So Stu, one of the things I've been talking about, I want to get your thoughts on this, Roland, is that you got the cloud as a scalable system. And one of the things that's being discussed in Silicon Valley now for the first time, we've been saying on the queue for years, is the cloud's a system, a system architecture, it's network distributed computing, art, paradigm. All that computer science has been around for a while, right?  But also you got the horizontal specialism of applications that are using machine learning and data and applications, which is unique on top. So you have the collision of those two worlds. This is kind of a modern version of two worlds that we used to call systems and apps, but they're happening in a real dynamic way. What's your thoughts on this? Because you got the benefits of horizontally scalable cloud. And you now have the ability to power that. So we're seeing things like AI, which has been around for a long, long time, have a renaissance because now you got a lot of compute. That's right. I think data is the real big challenge we're seeing with a lot of our clients. They have a lot of it in their enterprise. They don't want to unlock it all right away. We recently did what's called IBM Cloud Private for Data, in which we've brought in a set of technologies around our AI, our Watson Core, to really start leveraging some of those tools in a private manner. And then what we're seeing is a lot of applications that are moving to the cloud have a data drag. It might start as something as simple as caching data in no SQL database, but very quickly they want to learn a lot more about that data. So we're seeing that mix happening all the time. Yeah. We've had someone say in the cube, ML is the new SQL. Yeah. Because you start to see these abstraction layers are a beautiful thing if they're connected. So I want to get your thoughts on this because everyone's kind of in discovery mode right now, learning, there's a lot of education.  You see network guys going, wait a minute, if I don't like get on the new network programmable model, I'm going to be irrelevant. So a lot of persona changes in the enterprise. How are you guys handling that with customer? I know you guys have the expert program. How are you, comment on that dynamic. I think what we're doing is we use the IBM cloud garage to bring in practices like the Spotify method where we start pushing things like What's the Spotify method? Spotify method is a way of doing kind of development where rather than having your disciplines of architects, development, operations, we're now splitting teams, let's say functionally where I have mixed disciplines in a squad and maybe saying, hey, the person building the account team has an SRE, an ops guy, a dev guy, all within their same squad. And then maybe have guilds across disciplines, right? And so what we do at the garage is we bring them into one of the garages. We have 14 locations worldwide. Maybe do your first project. When we build enablement and education around that, bring it back to the enterprise and start making that viral. And that's what we're doing in the IBM cloud garage. So not a monolithic thing, breaking it down, integrating multiple disciplines, kind of like a playlist. Yeah, that's right. And I think the best way to do it is to practice it, right? In action, let's pick a project rather than talking about it. If I had to ask you in 2019, what is the IT investment going to look like with Kubernetes impact? How does Kubernetes change the IT priorities and investments for an enterprise? Yeah, so I think you'll see Kubernetes become a vehicle for enterprises to deliver content. So one, the whole area around Helm and other package managers as a way to bundle software. I think as people build more clusters, multi-cluster management is going to be the big trend of how do I deal now with clusters that I have in public cloud, in private cloud, all different clouds. And I think that integration layer that I talked about where, what does modern integration look like across Kubernetes-based applications? Someone asked me last week at re-invent, hey, can't we just automate Kubernetes? And I was like, well, it's kind of automated now. What's your thoughts on that? So I think when someone asks a question, what does it mean to automate that? I think the Kubernetes stack really sits on top of IaaS infrastructure. And so for example, our IBM cloud private, you can run it on Z-Linux or Power. And we have a lot of IBM folks that run multi-architecture clusters. And therefore they still need a level of automating how I create clusters over IaaS. And there's technologies like Terraform and others that help with that. But then there's also automating, standing up the DevOps stack, automating deployment of the applications over that stack. And I think they mean automating how I use Kubernetes in an environment. So 2019, the year of programmability and automation creating goodness around Kubernetes. Yeah, absolutely. Roland, thanks for coming on theCUBE. Thank you, this is great. Thanks for that smart insight. We've got coverage here, day two winding down. We've got day two three tomorrow. This is theCUBE covering KubeCon and cloud native con 2018. We'll be right back with more day two coverage after this short break. Thanks.


Thank you very much for the kind words and for the invitation to really engage with kidney cancer experts. As David said, I have a number of disclosures to make, patents related to the PD-1 field licensed non-exclusively to a number of papers. So immunology has offered hope for curing cancer for the last 100 years, but hasn't delivered until recently. Work stimulation of the immune response can cure cancers and mice, but these haven't before recently translated to standard human therapies. But new strategies are now working. And this change in strategy is to block immuno-inhibitory pathways. And this works in humans. So we know that tumors can express tumor antigens, and that the immune system surveys tumors for tumor antigens and eliminates many early tumors. But tumors develop multiple mechanisms to evade immune responses. And these include PD-1, IDO, TGF, beta. Now I discovered PD-1 and PD-L2, also known as B7H1 by Leiping Chen's group, and B7DC by Drupart Ohl's group, and show that this engages PD-1. When the PD ligands engage PD-1, it results in tyrosine phosphorylation of the cytoplasmic domain of PD-1. This recruits the phosphatase, SHP2, which in turn defosphorylates proximal signaling pathway molecules of the T-cell receptor. This has the effect of reducing T-cell receptor signaling, reducing T-cell cytokine production, reducing T-cell target cell lysis. Now the PD-1 pathway has an important role in the normal immune response. The PD-1 pathway regulates T-cell activation intolerance. It inhibits naive T-cell activation, as Chuck has shown you. It suppresses effector T-cell function. It can also induce T-regs and maintain T-reg function. Now if you block the PD-1 pathway, what you see is that you get increased cytokine production, such as production of interferon gamma, and you also get increased T-cell killing of targets. Now we've recently developed additional new antibodies for immunohistochemistry and have found some energetic pathologists, Sabina, Signoretty, and Scott Rodig, who have really optimized their use. And we've gotten clinical samples from David McDermott and Michael Atkins at the BIDMC. Now this shows that about a third of solid tumors will express PD-1, and they use it to evade immune attack. And here you can see nice PD-1 staining on the surface of the RCC cells. And Sabina has gone on to extend this, and she has shown that RCC metastases can become PD-1 positive. In the top panels, you see that initially the tumor mass doesn't express PD-1, but when it progresses to a metastasis, it does express PD-1. In contrast, there are other tumors which express PD-1 both as a primary and as a metastasis. We've also begun to look at PD-L2 expression, the somewhat underappreciated second ligand for PD-1, and gotten good immunohistochemistry going there. And this shows that PD-L2 can also be expressed in RCC. The top panel shows a tumor expressing both PD-L1 and PD-L2, and the bottom tumor, the bottom panels, a tumor that expresses only PD-L2 and not PD-L1. Now Topalian has published really groundbreaking clinical studies, and indeed the people who've done the RCC component are up on this podium with Chuck Drake and David McDermott. In summary, these studies show a 20 to 50 percent response rate in clinical trials, and effectiveness in multiple tumor types, including melanoma, renal, lung, and others. The responses can be durable, often lasting multiple years, and the drug is well tolerated. There's not the nausea or hair loss associated with chemotherapy. This really has a different mechanism of action, and it has a good safety profile. Undoubtedly, if it makes it to the clinic, there will be a relearning process by physicians to be more aware of the side effects of an immunotherapy drug, which are going to be autoimmunity. And so there's going to be a learning process of learning to clinically translate these drugs. Now we really learned a lot about the PD-1 pathway through studies with Ralphie Ahmed in studies of chronic viral infections. What we found there is that PD-1 was a T-cell activation antigen. In the solid lines, you see the mean fluorescence intensity of PD-1 expression on antigen-specific T-cells. In an acute infection, PD-1 expression goes up, it peaks at about day seven, and then it gradually declines to low levels as an infection is cleared and antigen disappears. In contrast, if it's a chronic immune response, PD-1 expression goes up and activated T-cells, but if the infection isn't cleared and it stays chronic, PD-1 expression on the T-cells goes up a little more and it stays high. Antigen isn't cleared, the T-cells are repetitively stimulated, PD-1 stays high. And these T-cells are exhausted. They don't make cytokines well, they don't kill well. And the importance of this is that tumor infiltrating T-cells or TILs behave like exhausted T-cells. These are studies with Kumar Duruswamy and George Kukos looking at TILs in ovarian cancer. And what you see is that the level of PD-1 expression in the TILs in both CD4 and CD8 is very high. The vast majority of TILs express PD-1. In contrast, cells in the blood express just a low level of PD-1. And these TILs are exhausted. If you, in the middle panel, if you give them antigen, in this case the NYESO tumor antigen, they make just a little cytokine. The cytokines here measured are interferon gamma and TNF alpha. But if you block the PD-1 pathway, you can see in the upper right that you get lots of expression of the cytokines after PD-1 blockade. So TILs are exhausted. Now early on in our studies of the PD-1 pathway, we tighter in the amount of stimulatory CD80 or 86 signals or inhibitory PD-L1 signals. And what we found is that if you put in a PD-L1 signal that you would shift the dose response curve to the right. You would need strong antigens and lots of them to get a good immune response. In contrast, if you gave co-stimulatories signals, you'd shift the dose response curve to the left. You wouldn't need much antigen or a strong antigen to get a response. So basically the immune response sums up or integrates the positive and the negative co-stimulatory signals and decides on the strength of the response. When a normal cell mutates and becomes a tumor cell, it has a number of changes. And it's estimated that 10 to 200 of these are amino acid changes that are potential antigens for T cell recognition. If the tumor cell expresses PD-L1, it can inhibit T cell functions, particularly of exhausted T cells. The other important thing about PD-L1 expression is that a lot of these tumor antigens are weak or mediocre tumor antigens for T cells. And that if you block the PD-1 signal, you may allow the T cell to really recognize and respond to these weak tumor antigens. But T cell exhaustion is more than just PD-1. T cells express, as you've seen, a large number of inhibitory receptors. Including CTLA-4, LAG-3, CD-244, BTLA, CD-160, TIM-3, and others. And these are all potential, druggable targets for tumor immunotherapy. So the future now is to find combination therapies that work even better. Based on a bedrock of PD-1 or CTLA-4 blockade and adding a second target, preferably with a different mechanism of action. So you can envision PD-1 blockade plus CTLA-4 blockade or TIM-3, LAG-3, CD-244, or CD-160. Or PD-1 blockade plus immunostimulators, such as Ox40, CD-137, IL-2, or TLR ligands. PD-1 blockade plus targeted kinase inhibitors like BRAF inhibitors. Or PD-1 blockade plus angiogenesis blockers, radiation, or histone deacetylase inhibitors to target epigenetic changes. Also, if you have PD-1 blockade, you may much more allow tumor vaccines to engage the immune response and lead to a successful outcome. So this gives you some examples of some of these combination blockades here with treatment of CT-26 colon carcinoma in mice. And the treatment agents are basically after you establish the tumor in the mouse are GVACs, which is a GM CSF producing vector. Or antibodies against PD-1, CTLA-4, PD-L1, or PD-L2. And this slide shows the effect of single agents on the growth of the tumor. And basically, PD-1, PD-L1, or CTLA-4 can give you regression of a moderate number of the tumors. In contrast, if you use dual agents, which is PD-1 plus CTLA-4, PD-L1 plus CTLA-4, GVACs plus PD-1, PD-L1, or CTLA-4, you get better responses. You get a higher percentage of tumor regressions. However, to get total cure in this system, you need three agents. You need the GM CSF vaccine and PD-L1 and CTLA-4, or PD-L1, CTLA-4, and GVACs. So the combination immunotherapy is what has the best effect. Now, I wanted to just interject here that for tumor immunotherapy model experiments, we need a mouse with a normal immune response. And there's a real need in the field for a C57 black six mouse RCC tumor model with inactivated VHL to accurately reflect common human tumors. The common RENCA model used has normal VHL. So it really doesn't replicate what you want. So what we've seen is that immunotherapy can give you lasting benefit. IL-2 and CTLA-4, you can see long-term survivors and a moderate percentage. With PD-1, you can see a higher percentage of long-term survivors. In contrast, the targeted therapies give a high percentage of response, but because it's a single target, the tumor can basically evolve, get around the mechanism of action, and then the tumor will develop resistance and the therapy no longer works and the patient has a poor outcome. So what we're looking for is combinations, which will give you a higher percentage of durable long-term responses and longer duration. And I've given you some of the proposed combinations. The field is looking at additional ones. And I think the future of immunotherapy and combination therapies is bright. I'd like to acknowledge all the people on the slide who've contributed to these studies, particularly the pathologists Sabina Signoretti and Scott Rodig, Arlene Sharp, who's really pioneered the in vivo mouse studies of the normal function of the PD-1 pathway, Rafi Ahmed and John Wary for exhausted T-cells, Kumar Duraswamy and George Kukos for some tumor models, David McDermott and Mike Atkins for really pulling me into RCC and getting me interested in applications there. Thank you.


Hello everyone. Hey, welcome to IstioCon, the virtual IstioCon 2023. My name is Keith Maddox. And I'm John Howard. And we're going to be giving you a look at Istio's journey with the Gateway API. And if you don't know what the Gateway API is, you will also learn that during this talk. But before we get there, we need to understand where we're coming from. So I want to give kind of an overview of some of the history of Istio's traffic management APIs. So if you've used Istio for a while, I'm sure you're familiar with some of Istio's kind of what we call the traffic management APIs. This is the Gateway, the virtual service, the destination role, kind of all these things that are configuring how traffic goes from point A to point B and kind of modifying properties in London does. But even before that, and currently in Kubernetes, there was this API called Ingress. And Ingress did a lot of these things, but it was all in one resource. And it was kind of this awkward fit of, it was so simple that everyone could adopt it, right? It was a single API that had multiple implementations like Istio and GenX, Cloud load balancer, like everyone's implementing the Ingress API. But it's so simple that no one can actually use it in a real world environment and meet all of their needs, right? It's really constrained to just have one resource handle everything. Like we have the same single resource that's managing how routes work, like, oh, the food pass, you go to the food service. But that exact same resource is also provisioning a Cloud load balancer, which is like this highly privileged infrastructure admin operation. It's also managing certificates, which is probably somewhere in between the application and infrastructure admin, right? So we had this mix of personas all bundled into this one API. And the API itself still is kind of too simple to meet all these cases, right? There's no, nothing like retries or timeouts or I don't even think header based matching, like all these kind of features that we kind of won out of routing APIs wasn't there in Ingress. So it was a nice starting point, but it's not sufficient for long term. So that's what brought about the Istio APIs. That's why Istio had its own APIs rather than using kind of the vendor neutral Kubernetes standard Ingress one, right? So gateway and virtual service kind of take the roles that were previously all in Ingress and split them apart. We have kind of the infrastructure layer, the gateway, which opens up ports, listeners, things like that. And then we have virtual services that attach to them and configure the routing and also expose a huge array of functionality that Istio provides is not in the core of Ingress. Things like cores, mirrors policy, retries timeouts, like I mentioned. There's a whole assortment of things. And additionally, destination rule, that's kind of completely new to Ingress. It's kind of how we connect to a back end. So we may say, for example, that I want to use TLS when I connect to it, or I need to use a circuit breaking policy or any other, but again, there's a lot of options in these Istio APIs for customizing how traffic is routed, right? So this is all great, right? We have a new API. It's a bit easier to use in Ingress due to the split of concerns. We offer a lot more functionality. Everyone's happy. And to some extent, that's true, right? We have a lot of Istio users, hopefully a lot of happy Istio users, but there's still a lot of issues with the API that I'll go into in a bit. So let me show just an example concrete. If you're not super familiar with the API, here I show a gateway and a virtual service. And this is just doing kind of a simple case of I want to match request on some external host name. Here I've got hbbn.example.com. So in my gateway, I'm opening up this, what we call a server. And then the virtual service will bind to that. We have this matching host here. And then we set up a few routes for different APIs to expose and we route them to our actual hbbn service on some internal port. Istio wasn't alone when it came to how it, you know, experienced the Ingress API. There were various implementations all doing things slightly differently. And the, you know, folks behind SIG network saw this in the community and said, no, I think we can do better. And so around 2018, there was a user survey that was sent out to collect information and feedback about the Ingress API and what people wanted to see from networking APIs in Kubernetes. And from that conversation, the gateway API was born. The gateway API was introduced by Kubernetes in order to attempt to build a unified service networking model. And big pieces of, big areas of focus for the gateway API is to learn from the mistakes of Ingress and to try to be more just a lowest common denominator. So in gateway API, you're going to see lots of things that weren't present in Ingress, such as a standard way to do a header modification, standard ways to do traffic splitting and things of that nature. And it's extensible by default. There is built into the specification a way to, you know, create CRDs that follow a certain, certain fit and have those be policy. So for example, you can configure a timeout policy within gateway API, and there's just a standard way that that should look in things of that nature. And so the gateway API recently graduated to beta and it's got at this, at the time of, you know, recording here, about 24 implementations. So it's this very widespread, widely adopted specification that is in use across multiple different networking platforms on top of Kubernetes. And Istio, similar to the upstream API, Istio has beta support for the gateway API. So, you know, we talked about one of the main benefits around persona development here, but want to go through and talk about them a bit more in detail. So the first thing that you, first big benefit of the gateway API is that now you've got a common ecosystem. Ingress have the same benefit as well, but the issue with Ingress was a lot of the feature, lack of feature parity with custom implementation API, such as, such as Istios. And so what you really saw is that people who wanted to build cloud native integrations had to do bespoke code and bespoke workflows for each Ingress provider. Both gateway API, the features are rich enough and the extension patterns are explicit enough that you can really have a common specification for integrations to plug into. Things like cert manager, Argo, and Flux, and typical GitOps workflows can target the gateway API instead of implementation-specific behavior in order to build their ecosystem. Similarly, you know, when you're out trying to figure out how to accomplish traffic splitting or how to accomplish header modification, if you look out at all the different Ingress implementations from IngenX to Contour to Istio, you're going to find a ton of different APIs with different nuances and all kinds of different proxy implementations and things to keep in mind. But with gateway API, by and large, you're able to share from the knowledge of different implementations, all 24 implementations, when they have support for the core gateway API resources, you're able to benefit from those knowledge and the shape of things are going to look the same and the Helm charts are going to look similar and the documentation is going to look similar and so you're able to benefit from multiple communities all rallying together under the same platform and ecosystem. We alluded to this earlier, John did, about the different personas that are in use when you're deploying a company of applications today and one of the big friction points with Ingress was this overlapping and this coupling between different personas. So the application developer who just wants to expose a route on the application has to touch the same resource as the platform admin who wants to configure TLS or even the cluster admin who the cluster operator needs to expose a new load balancer to expose traffic to the internet. With gateway API, those different responsibilities and personas are broken up across different resources. And so with less coupling, you can have increased cohesion across the organization and have your application developers just focus on the routes to their services. Your cluster operators can focus on provisioning gateways and provisioning infrastructure to expose traffic to the public internet. Each persona can have ownership over just the scope that they need to manage and that creates better efficiency for teams who need to just write business logic and get things done. And then lastly, this is a really big one that John is going to talk to us a little bit more about in a second, but with gateway API and Istio, you get automated gateway management. And what does that mean? Well, right now the situation in Istio is a little bit split. You have to provision the service and the load balancer in a separate step from configuring it and programming it. With gateway API, by deploying the Kubernetes gateway API gateway resource, the Istio control plane is going to take that resource and create all the infrastructure in the background. And you only have one API that you have to deal with instead of two. And so you really get this really nice automation in lifecycle management by adopting the gateway API. And so John can talk a little bit more about that specifically here. Yeah. So in the world, kind of the old world with the old Istio APIs, you would have kind of two parts if you want to deploy gateway. First, you would have the installation, which is on the right side. This is the service deployment. And you probably also have a few other things like roles and maybe a pod disruption budget, whatever. These are usually configured through Helm or maybe Istio Cuddle install. And then in a completely separate operation, you deploy a gateway resource that programs that, right? And these things need to be in sync. So you can see I have these selectors that's matching the Istio Ingress gateway. This is a pod label. So this pod label needs to be matched on the deployment, the service, and the gateway. And they also have some port numbers. These need to be matched as well, right? Now consider I want to add another port maybe to expose my database. The obvious thing to do is go out into the gateway, try to send traffic to it, and it doesn't work, right? And the issue is, of course, it's not actually in my service. So my traffic is not able to go there. We've only configured one half of the story. So the fix is obvious, right? I go add the port to the service. And it seems trivial, and it seems obvious. And to some extent it is. But this is just a simple case. In the real world, I may have hundreds of these gateways that may be managed by different teams than that managed Istio install. I maybe have one shared Ingress gateway used by many different teams, or I may have multiple Ingress gateways for each team, or some combination of the two. Once we started getting into more and more complex things, like target ports, mismatching with the service port, like all these weird edge cases, it ends up getting quite complicated. And it kind of makes management and lifecycle of Istio just a little bit harder. Is it the hardest thing in the world? Of course not. But there's a lot of these little cuts, and over time they add up to a lot of friction, and in some cases could even cause like an outage or something. So with the gateway API, like you've mentioned, we've kind of improved this quite a bit. Absolutely. So with the gateway API, as a user, you only have to interface and focus on a single resource. And here, like in this example, you create the gateway resource, you set the listeners, you say, I'm going to listen on this port, on this protocol. And then what the system will do, the system will do is it will, the service subsystem and the deployment subsystem of the Istio control plane are going to take that single resource and manage it for you and generate the accompanying deployment in service and handle the lifecycle of that infrastructure for you. And so with this gateway API approach, the configuration and the lifecycle of the gateway are handled via a single resource instead of disparate resources spread out across your cluster. And so going to the next slide for me, John. Taking that same example, you still have the listener that's defined, you're still saying that this gateway is going to be listening on port 80 with HTTP protocol. But instead of the user, you, the user happened to go and synchronize the selectors and the ports, et cetera, across multiple resources. Now the system was going to take care of that for you. So if you wanted to change the same, hey, I got a call from the security organization, we can't expose plain text ports anymore. And we have to move this to TLS. And so if you change this listener from port 80 to 443, now the system is going to update that for you, instead of you having to go to both resources and make the change and keep them up to date. And as John mentioned, this sounds simple, but you spread this out across multiple organizations within your company, multiple different timelines, multiple different requirements. And this can cascade really quickly and lead to an outage or a hidden productivity. Yeah, before we move on from some of the benefits, we now have a slide for us, but I wanted to touch point out, like we showed this one example of one nice feature. And it is nice, it is great. But I think in general, the gateway APIs provide just a lot of small improvements over these two APIs. In many ways, I see it as kind of taking the learnings of Istio over the past five years or so, and as well as other projects, and then kind of iterating and learning on all the mistakes that we've made. And so a lot of these are really subtle, like you may look at the two APIs side by side and say, those are basically the same, there's only surface level differences. But in many cases, these subtle differences all add up to make a very large user experience difference. And the gateway management is one example. Like, could we have done this with the Istio API? Maybe, but there's all sorts of edge cases that the Istio API exposed that made that really, really hard to do, but the gateway API doesn't do, which is why we've enabled this only for the Kubernetes gateway API. And the same thing applies for some other features as well, like one common one is cross namespace certificate references. We've tried for quite a while to see how we can adopt that into the Istio API, but some of the namespace boundaries in the Istio API are a bit fuzzy, which makes it hard to do that securely. That's something that the gateway API has improved upon. And so cross namespace references are available in Istio with the gateway API. And there's many of other cases of these minor improvements that add up to big user experience changes. So we can keep going on about the benefits, but we're gonna move on. So here's another end-to-end example. So this is the same gateway resource, just name, tweak a little bit from the previous example on exposed on port 80. And now, as an application developer with my cluster admin provision this for me, I can now expose a route to my HTTP bin application on this host name. And, you know, we've got a couple of HTTP routes to status and delay the same ones from the first example that John walked us through with the Istio APIs and route it back to HTTP bin with a back-end ref. So you see very similar functionality, but with some very subtle user experience improvements that make things that are going to really add up and make things better for organization. So, you know, we've been talking about gateway API for the lens of ingress, right, getting traffic from outside your cluster to inside your cluster. But, you know, around July of last year in 2022, the Istio community, you know, joined the Vanguard and was really part of this effort to use the gateway API as a standard specification for mesh configuration as well. Similar to the ingress space, all the different meshes in the ecosystem have very similar but slightly different ways of doing the exact same things. Routing traffic, setting up MTLS, authentication authorization policy, things of that nature. And so several different folks from several different communities came together in an effort called the GAMA initiative. And this has initially started between SMI and Istio. And for the past year, we've been iterating on seeing how we can make a gateway API specification fit for east-west traffic as well as that north-south outside of cluster and inside of cluster step. And as a gateway API version 080 that just released a couple of months ago, mesh support was officially added to the gateway API spec as experimental. And I'll note that, you know, we were very purposeful about the way we went about doing this and no API changes were had to be made to get the API resources to get this to work. The only changes so far have been semantic. And so you'd be curious to see what this looks like in action. So you've got this example here for you that in HTTP routes, the same HTTP route that you would use to program traffic from your ingress controller to your back end applications, use that same resource, but you're going to change the parent ref of that resource. And instead of it being a gateway, we're going to say the parent ref is a type as a kind service. And so this is the one of the really big, you know, the big shifts is that what this is going to do is it's going to say, hey, for traffic destined to the service, we're going to route it to the following back-end refs. And you can have, you know, various different kinds of rules, but here's a very classic example of traffic splitting between two different versions of the through service. And so anything that's destined for traffic to service through, we're going to send 90% of traffic to that actual service through and then 10% of traffic to through V2 in order to, you know, get that the V2 version of the application up and running. You may notice here that you've got a back end, you've got the service resource kind of doing two jobs. The service, the service resource of the parent ref is kind of healing from the matching logic, but service is also a back-end ref for routing that traffic. John, what does this mean and, you know, how do I make sense of this? Yeah, it's, this exact topic was kind of the root of a lot of contention in kind of designing how gateway API could be used for mesh. If you look, I think last year at East2Con 2022, I had a talk on gateway API and I touched on mesh and I think I probably said something like mesh is experimental or something. And Keith just said mesh is now experimental as of this month. So what happened in that one year? Well, we iterated quite a bit and this is where we arrive, right? And this iteration involved this diagram times a thousand for every possible way we could possibly model how to represent service mesh traffic in the Kubernetes gateway API, right? So it may seem simple in the end, but this is like the result of years of it, well, one year of iteration and this kind of where we arrived. So the issue we have with service and remember East2 is a service mesh, so we generally are concerned with how we interact with services and how we kind of modify the behavior of services, right? That's largely what we're trying to do when we have a HTTP route or a virtual service that's kind of in the mesh mode, right? We're taking a service that was traditionally just a layer four TCP service has no kind of special routing rules and we're kind of upgrading it to an HTTP service that has all sorts of customizations that have added, right? But service is more than just one thing. It's one object, but it kind of has two rules. What we kind of call the service front end and the service back end. So the service front end is like how do I identify it calls the service or how does a client reach the service? So this is like the DNS name, the example.service.cluster.local or the cluster IP. But then it also is a kind of collection of back ends, a collection of pods or kind of the endpoints or endpoint slices. And in classical Kubernetes without a service mesh, those are tightly coupled, right? If you reach the front end, then you reach the back end directly. What gateway API or even virtual service allows us to do is say, I want to match on this front end, but then customize the behavior, right? So here I've attached a route to the service a front end. I'd be using like an attachment like this apparent rough here it's boo and the slide I think it's a. So I attach a route here. And now I'm overriding how I want to handle traffic to that service. So the client still calls service a but now I'm following this route. And this route may, for example, split between service AP one and service AV two. If you want to hear more about this, Tim Hawken gave a lightning talk all about service and kind of problems with it earlier this week. So feel free to check that out. So this is one of the core problems that we wanted to solve in the gateway API. We think we did a reasonable job solving it as long as you're okay with accepting that service is one object with two roles. And as you can see again in the example, we have the front end role here in parent ref and then the back end role here in back end refs a API in the ambient. So if you're if you're not familiar with ambient, you probably haven't been watching the other talks because I'm sure that over half them are about ambient. And same with all the used to blog posts, used to tweets, everything's all about ambient these days. But I'll give a quick summary. So used to ambient is kind of a new data plan mode that instead of using side cars, the traditional deployment model, we've kind of split the service mesh proxy into two layers. On each node, we have what we call the Z tunnel, which is kind of the node encryption layer. And it really doesn't do much. It's just augmenting the cluster networking stack to add encryption and a few other enhancements. So we can maintain the zero trust properties with mutual T loss that we want to use to. But the the core of it is really these waypoint proxies that run external to the application, typically in the cluster, but in theory, they could run anywhere. And these are standalone pods that kind of do the work that the service mesh sidecar proxies used to do. But now they're standalone. And the gateway API plays a key role in this right, the waypoint proxies are actually represented as gateways. You know, oftentimes in our docs, we're deploying them with an Easter cuddle helper command. I think it's used to cuddle waypoint apply or something similar. But under the hood, that's actually just creating a gateway object, just like we did in the past examples. And so it is a gateway, it has a few special properties, it has its own gateway class, which we touched upon, which is, you know, kind of a qualifier for what type of gateway it is. But ultimately, it's very similar and uses the same APIs as the you would for ingress. In fact, you can actually do I have a blog post about like, what would waypoint, what would it that architecture look like if there was an ambient, and how you could kind of do it the hard way. And you can check that out if you're interested. So just like a normal ingress gateway, we have routes that can attach. We have policies that can attach. So for example, we may want to apply an authorization policy. These will attach to the gateway, whether it's a waypoint or an ingress gateway. And yeah, so like, you know, this is kind of the, the two, I think main focuses and projects going on Easter is where the ambient mode and the gateway API and these two are also very tightly linked. I can wrap us up here. So like John was saying, gateway API is the encouraged ingress approach for Istio moving forward. Mesh support is currently experimental, but the Istio community is, you know, currently investing to pushing that spec forward. And we hope for it to one day be the out of the box default for Istio. Now our goal as we go through this process is to try to match the stability of the upstream gateway API. So we try, you know, through our, through our involvement in both communities, Istio and gateway API. Well, whenever gateway API, let's say milestone, we try to match that milestone relatively soon afterwards. And like John just said, ambient mesh utilizes gateway API for its waypoint proxies. And this, you really see the marrying of these two new innovations and these two concepts within Istio that we're putting a lot of focus in right now. This means, you know, this ambient mesh using gateway API means that policies are going to bind to the waypoints, which is a little bit different than, you know, what you might be used to in Istio, where you use workload selected about new workloads, you know, in ambience, policies will be binding to waypoints as in general. And we also see, we talked about two different roles of service, which might be your first time hearing about it. And so service, when you see service as a parent ref in the HTTP route or any kind of route and gateway API, it's going to refer to the front end role, which typically corresponds to the DNS name that is provision inside your cluster as well as the cluster IP. And when you see service being used as a backend ref, that refers to the service, that's a typo there, the service backend role. So the bag of endpoints that are provisioned by the Kubernetes API server, based on usually a selector of some sort. So that's the kind of Istio's journey with the gateway API. Hopefully, this was really informative. And we'd love for you to try out these features in Istio. Gateway API again is in beta support in ambience. Mesh is an alpha. And the gateway API mesh support is experimental. So various difference, you know, there's something for everybody, no matter what level of maturity that your organization is at, we've got something for you to try out and give us feedback. So really appreciate it. Thank you for your time.  And we'll be around to answer any questions or you can reach us on Slack, there's a gateway API channel, we'd love to hear any questions or feedback. If you like it, you don't like it, you have issues, whatever, if you're back super useful. So thanks everyone. Appreciate it.


Hey everybody, welcome back to a week in Geekdom, Gio here, and no, I did not get my cooking utensil, I meant this Asadota. Welcome back to the channel everybody, and yeah, I had to beef up my Urusawa collection if you will, and Asadota is a brand new series. Although currently, I just read that it's on a hiatus, which is unfortunate, but still, we got a few volumes coming out. I believe the last one was volume 4 in Japan, and we already have volume 3 solicited stateside, so that is really exciting. I'm very much looking forward to continuing reading this series, but nonetheless, it's not a formal review because it's only just beginning. This is more of a first impressions on what I thought of Asadota volume 1 from Naoki Urusawa. Now, Urusawa, I mean, there is this expectation when it comes to his books. You've read 20th Century Boys, Billy Bat, Monster, there's a quality there that you expect, art-wise and story-wise as well. So, what the heck is Asadota all about? Now, there are some mild spoilers here because they literally happened in the first two pages of the book, so I'm not really spoiling what the big twist of it all is because they give it away right at the beginning. The opening pages is in an alternate version of 2020 in Tokyo. Let me show you right there real-time, hope that looks great because it does look awesome to me. So, there's this monster attack happening, or a kaiju attack, and then we go back in time to the port of Nagoya in 1959 as we follow this rungbunksious, really awesome character, Asa. She is the youngest in a family of many siblings. Her mother is giving birth to the latest member of the family, and she's, Asa is tasked in getting the local doctor to help with the procedure and all that stuff. At the same time, there's a typhoon or massive storm hitting Nagoya in Japan, and that is sort of the basis right out of the gate. And we follow Asa through her point of view as she's going, running through the town, through the port, and trying to locate the doctor. She does, the doctor is on his way to check on her mother. And while she's also leaving, we get a chance to see the world around her and the different characters in this story. Now, one of the tropey complaints I see a lot on the internet when it comes to Naokirusawa is that, oh, yeah, the stories are great, but the art always kind of looks the same with the same character models. I mean, that's not really a complaint, that's his art style, but I can understand where people are coming from when you're used to seeing these books and everybody starts looking alike. You do a massive Urusawa marathon, I guess that could be a problem, but nonetheless, the art is so great and the character models are so fantastic. You're not going to have this issue right here. They're all, all these characters, regardless of the book that you're reading from the author, they all have great character facial features and personalities where you don't mind that they may look alike. I certainly don't. But nonetheless, continuing on with my brief plot description, as Asa is on her way home, she passes by a friend, a childhood friend, who is training to be in the Olympics. The family, his family were athletes and he, unfortunately, they had to participate in World War II and all that stuff, so the kid is sort of the future for that family and representing Japan and all that stuff. You see, the 50s is a very transformative period in Japanese history. We are just coming off of World War II and the country is starting to be reborn, if you will, into the mega house that it is today. His friend is practicing for that and Asa is still faster than him, which is hilarious, and as she's turning the corner, when he turns as well, she's disappeared. Turns out that this guy that you're seeing right here, this bum-looking dude, kidnaps her thinking that she's the daughter of the doctor, so she's got to be worth ransom money, right? And this is the heart and soul at least of the first volume. I can't go into detail about the series itself because I've only read the first eight chapters of this story, but this is the heart and soul of the series because here we have what Asa is really made of and how she reacts to what is happening. The storm is brewing outside, it's nightfall already, and the kidnapper, you think, oh, this is just some bad guy, but there's more to the story, there's more to this character. Asa, on the other hand, you think, oh, she's going to react in a certain way, yes, she's angry, upset at what happened and at him for kidnapping her, but she shows a quality that is so lost in today's time and it's empathy. She's able to sympathize with the kidnapper into, like, why he may have committed what he did. You know what I mean? And in a world like today's time where everybody's obsessed with that first impression and not really talking things out, things just get lost in the shuffle, I appreciated the scenario and Asa is willing to hear this guy out and why he's desperate, because he's not just a face, there is a story there. He was a former World War II pilot and you would think there would be glory in that and there isn't and, you know, society all but abandoned a character like this and he has to resort to what he's doing in order to keep going and surviving and all that.  The storm may be something else, however, I do appreciate the aftermath. You see the storm is so intense, they have to leave that abandoned warehouse that they're sitting in alone in the dark that when the typhoon hits, they go to one of the huge containers, transport containers and when the day breaks and we find out what really happened in this amazing splash page, which I really enjoyed. I mean, it's pretty tragic. Here we have the storm brewing right there with the characters running for their dear lives and some of the sound effects right there to let your imagination go wild. The aftermath, oh, and here is what I'm talking about. Look at how amazing those portraits are for those characters. I mean, Bodhisattva is just a master for a reason, right? So when they find out in this great reveal right here, as you can see, it's all pretty much flooded and this part rang a little bit close to home because if you've ever been in a storm or a tornado or a hurricane or something, a natural disaster like that, there's so much chaos and confusion after the storm because the storm has a pattern. It's going to do its thing and you can't do anything about it. The chaos and confusion is what happens afterwards. Not the eye of the storm, none of that stuff. It's the immediate days, hours and seconds after the storm passes, after this great upheaval of the status quo. How do you react? What do you do? How do you move forward from that? And the book goes into that and the story goes into that with Asa wondering, is my family safe? What's going to happen? I have to look for them and the old man, there's more to the story and how they're going to interact and help each other out and it just keeps going from there. So I'm not going to ruin all the surprises. I think I already talked a little bit too much and I do apologize for that, but I just wanted to geek out a little bit about it and this is a really fun series, man. I really enjoyed this first book and the build of the actual manga is awesome. It's a biz signature size, so it's oversized artwork. So yeah, overall, on a first impressions basis, this is another solid hit in the making. It's unfortunate that we've hit a little hiatus, but I am looking forward to volume two and three when those come out and continuing my adventure with Asadora. What about you guys? Have you read the first volume? Have you read everything released so far? Let me know in the comment section down below. And if you haven't, let me know what are some of your favorite Naokiru Sabo books. Very interested in finding out. As always, guys, thank you so much for tuning in. Thank you for liking, commenting, subscribing, and being a part of A Week in Geekdom. Again, it truly does mean the whole world to me. Be sure to hit the notification bell so you know when new videos pop up and if you're not subscribed, please consider doing so. I do content like this where I talk about anime, comics, manga, all that fun stuff. Alright, that's it for me, guys. Thank you so much. God bless. Stay safe out there. I will catch all of you on our next video.


somewhere else. You had a lot of choices. You could have mingled around or been waiting for lunch now after this or could have attended one of these sessions. You also had a choice to go to either track 1, track 2 or track 3 but you decided to come here. So you made a choice. All our life we are making choices. So the session is about why do we make certain choices over others, what drives it and why do we need to even try to improve and can we improve at the last comment or do we need to prepare. So it is all tied up. This is a wow framework which I have been building for last year or so. First I practice it myself. Then I work with impetus. So we have a large number of project teams and our product teams. So try that with them. It seems to be working. So I thought this may be a good forum to come and share whatever I have found and our teams have found useful. Give me a minute. Thank you. Does it make sense? 4 hours out of 6 hours just sharpening the axe. But it matters because once we are sharpened the axe then the cuts will be very smooth. We will be able to do it faster and get more output. So quality, agility and productivity everything goes up with good preparation. Now prepare for what? Lot of things we need to prepare for. Life is uncertain. Things go as expected. They also go quite often not expected. So today's session is not about how to prepare for what is expected. Let me take an example. You come to office from home, driving on the way. You found starting at a particular time is good enough for you to reach office in time. On a particular day it might happen that there is some traffic on the road more than expected and time is running out. You have to reach in time. You find it important to be there on time and it is slipping up. So it was something we had not expected. Now is not the time to start preparing for it. Lot of things we could have done earlier. So what are those kind of things? And there can be variety of ways things can go wrong. All of you must have heard about Marcy's law. If things can go wrong they will go wrong and at the worst possible time. So there are hundreds of ways things can go wrong. If there is one way it will go right. So we will focus on things, more generic things, what we can do to prepare ourselves much better to handle any kind of such uncertainties. Now, how is the framework which I have been building as I said and rest of the session I will be going over those details. How is really for a short form for way of working. So what does it involve? It has front end and back end. Front end is what we can observe. Like for example what are the actions we are taking. We start at a particular time to leave for office. Now today suppose the meeting was very important and we have got to be there. If you are late by even a minute it will be noticed. We will feel awkward walking into a room where meeting has already started. So lot of things can happen. In spite of that as a habit we left the home at the same time as earlier. Things prior to that whatever time what we got up, had breakfast or prepare children for school or whatever we kept on doing the same thing. So we get so habituated to doing things because they normally work. But on a particular day it is important to reach in office. We could have probably started thinking of other things. Actions are what we take ourselves. Interactions are how we interact with each other. So all the visible part of it is mostly made up out of actions and interactions. Emotions are also very important. They are visible definitely to us. If I feel bad I will know about it. If you feel bad probably it will show up on your face. I can see it. So all actions, interactions and emotions are the three visible building blocks of the VAUK framework. But why do we act or why do we interact in a particular way? Because at some point in the past we made a decision that that seems to be a good way of working based upon the situation we are in. And it kept on working. So it was like a master decision which kept on printing out copies of our actions and interactions. And we get habituated to it. It becomes our second nature. It is not so easy to change. And more than the decisions, what is driving the decisions is really the opinions. That is the crux of VAUK framework. That our opinions are values are beliefs and our assumptions are at the back of everything else. So let us see how these five pieces fit together. We start with understanding our actions and interactions. What is driving them are our decisions. I have already said that either explicitly or implicitly we have taken some decisions in the past. And those are resulting into the actions or interactions that we take today in a similar situation. Now behind that are as I said the opinions which consist of the assumptions, beliefs and values. Let me take the earlier example of driving from home to office. Suppose if I have a value that I always respect reaching on time absolutely on the dot. So that value will drive lot of other things. There may be other person. I have seen people who walk into a meeting five minutes late. They think that others are waiting. That is okay for them. It does not matter to them. They are important unless they come their meeting will not start. So for them they do not value as much reaching on time. So values are driving rest of it. I may believe that I will reach there on time because I have always reached on time. But that belief may not come out to be true. Now what could be the assumption? The traffic on the road would be as normal. It may not be. Now I need to check that assumption if it is an important for me to reach in office. So what kind of things I could have done? I could have probably looked at the newspaper or looked at on my mobile app. How is the traffic on that road or heard on the FM radio? There are a variety of ways I could have known if it is so important for me to reach in time. So far we have seen the other four parts but these opinions, assumptions, beliefs and values also lead to emotions. If I want to reach there on time but not able to reach on time. So anxiety will start. Probably the frustration will be there. I may call up somebody in the office has the meeting started. So I am getting worried. So all those emotions are starting because of the opinions I have. And those in turn affect my decisions. If I am in a bad mood, if I have negative emotions I will be kind of stuck in those and will not take good decisions, mature decisions. Whereas if I am in a positive frame of mind or emotions I will be able to do that. So all these five are correlated and what I will be taking couple of examples from, I have plenty of such examples where I can do walkthrough. But I have chosen two examples because of a short time today. But before that let us look at it whose way of working are we interested in. Is it just our way of working? No. Because we are all connected with each other. We have to understand about other persons way of working. All of us, most of us are from software industry using agile. Have some clients or have some customers to deal with. So unless we understand their way of working, in the same way we understand our way of working, it will be incomplete. It will be only inward focus. We need to understand others way of working. And more importantly we also need to understand the systems way of working because we and they are again part of a system. So it is very nice saying is there that we are prisoner of a system we do not understand. It is very true because what happens is unless we understand the system we do not know what options we have. And unless we know the options our choices are very limited. It is like a prisoner. It does not have any freedom except for probably the VIP prisoners they have a lot of freedom. But most of the others have hardly any freedom. That characterizes the prisoners. So we become the prisoners of the system. So we need to understand how systems work also. So as I said if you notice right from morning to night lot of things are going through our life. But we tend to get used to a certain way of working. Maybe work in a half days way. Not really look at what is happening. And if we then we are in problem then start thinking about it. So as I said I will take two examples. One from life at home and one from office and walk through these steps before applying VAO and after applying VAO does it change anything. And before we close I will provide you with couple of tips of how we can practice these things and get better and better. Can I have a bottle of water please? Thank you. Any questions so far? Are you with me? The first situation is I will not read out. We can have a look. And it is more of a pattern. It is a pattern of competitive comparison. We see that often even in office. Two team members, team leaders seems to be preferring one over the other because his performance is better. How does the other person feel? So it is not limited to only this context which I am talking but wherever there is a competitive comparison, same kind of pattern comes up. We could start anywhere out of these high building talks. Let us start with the emotions. Look at it from the person who is being always criticized or compared against his superior brother or sister. So he may start feeling hatred or he may get depressed or both. Now what was the decision that it results to? Do whatever it takes to just get out of this uncomfortable situation. Right? So the actions and interactions will be driven by this decision. So who is causing this? Their and relatives will keep on comparing, keep on criticizing you. Why are you not better? He is so good and so on. So avoid them. Get out of this situation. Or I have seen cases where a person has gone to the extent of causing physical harm to a sibling. It is not a good situation. And what is leading to all this? Our opinions. Bad luck? Can't do anything? Past life I might have done something bad. Therefore now I am getting all this. So I should do something now so that next life will be better. What about here today? Or it could be everybody wants to look good to others. But now it is become so overpowering that you can't think of anything else. So you need to now get out of this. So start applying way of working approach. So emotions was the main challenging part. So we start from there. What kind of emotions we want to have? We desire to be loved. We want to feel worthy. We mean the person who is feeling inferior. Now if we start from there, then what needs to be done? Nature has created diversity. It is not that everybody has all, I mean one person has all these strengths and other person has nothing. Everybody has his own strengths. So rather than worrying about what the person doesn't have or has not been able to develop, why not start looking at these strengths and focus on them. Once that decision is taken, it is good to understand any opinions need to change. So it means that I must first understand what are my real needs. Is looking good to others is my real need or feeling happy, feeling worthy, feeling loved is my real need. So if that is my real need, then I need to act differently. So maybe I focus on my strengths. Naturally there will be better results. I start showcasing them. I will feel more confident and then in my interactions I also become more open to others. Be open to parents, try and understand their needs. Even the person who is considered superior has his own challenges. He has certain inhibitions. So I must take care of those also. If I can do that, I will develop a good relationship with them. If I am able to understand parents need, maybe they want to see their children grow up better, all of them. So they are after that. But once we understand that, we can do something about it. What we can do may change from situation to situation. Now come to office. This is a second situation. Have you come across these cases earlier anytime? I have actually seen it in couple of all projects. So I thought I will include this here. So we do not have to necessarily start from the same point. Now we can start from this here. So what was the decision probably that was there which resulted in our behavior? So given that there was a protective person, we are comfortable. Even if our performance was not that good or we made some mistakes, he was there to protect us from others. He was taking care of us. So we continue to be comfortable. As a result, we totally depended on that person. We did not cultivate others channels. Because after he has run, we have to deal with others. But we did not do that. We did not anticipate the risk. That was action on our part, lack of action. And what was at the back of all that? Our assumption that the person will be always there. It cannot be. And other possible belief is that others are responsible to take care of us. So he is there. He will take care of us. We do not have to worry. So we need to change. So where do we change? Start asking us is what if? Because there are two kinds of reasons why we are successful today. It is because of our capabilities or it is because of external factors. In this case, it is clearly an external factor. He could change. So once we understand or once we decide that hereafter, we will start asking questions. Even if today seems to be going well, is it because of us or is it because of things which we are not under control? So we will look at the impact. We will start building alternate channels. And the driving force, driving change which has happened is we accept that we are responsible to take care of us. And once that happens, we will be more confident and feel in control. So if you look at both these situations, they are just patterns. So we need to start looking at finding certain patterns of things. And it could happen same kind of situation could happen at home, at office, in our social circles anywhere. But once we do this, then there is a possibility of change. Changing our way of working. But that again is not easy just by saying it does not happen because our existing way of working has become a habit. So first we need to break that habit and form a new habit. So for which we have to start acting in new way. And once that becomes successful, automatically our way of working will change. So as I mentioned couple of things I have found very useful, our teams have found useful are, before that what should we be prepared with? Because we need some frame of reference. So we need to be prepared with information, know-how, skills, resources and lot of stamina, physical and mental stamina to be prepared. So why I am mentioning this is the next two tips are very generic. But if we find that there is a need to change, what do we need to change? What do we need to get prepared? We can look back here and refer to this as a frame of reference. So for any success because small as I said, why we are successful? Normally what is our tendency? We feel good, we pat ourselves on the back or pat our colleagues on the back, celebrate and move on. But is it because of our capabilities or external factors? And if it is because of external, what needs to change within us? Even for failures, why did we fail? If there is a bug we always do an RCA. But it is always focused outside. Was there a problem with the server? Something wrong with our test or our practice is bad, processes are bad or what? But are we lacking somewhere internally? Are our assumptions creating some of the problems? Are our beliefs creating problems? Is it resulting in wrong kind of decisions? So that is where we can start thinking. And one very useful practice I have found is call out whether we know something or we assume something. Because a very large number of times we tend to mix up facts and assumptions. So the moment you start saying I know this to yourself as well as to others and encourage others to do the same. Automatically followed by what is the basis on which we know this. So it turns out that what we thought as a fact is actually an assumption. And the moment it is an assumption we need to verify. Other two I will just skip right now because I can see we are already behind time. So I just wanted to share with you that the VAU framework which I am building has the VAU core what we talked today. There is lot of guidance material. There are 7 universal principles and number of useful patterns are there. So I have put up a site called wayofworking.org. You can go there and see there is a good FAQ. So if you are more interested in this you could send me a mail. I am actually working for impetus a software company. I have been there for last 16 years, last one year as a external consultant now focusing on Agile and VAU. So I do all the trainings as well as course the teams to do their assessment, find where are the gaps and I have started now using the VAU also within that. Thank you.


You know, to be a great man, to be a self-creator, a self-master, whatever I referred to in my last book as a noble beast, you need to stop thinking about recreation and start thinking about recreation. You know, great man's recreational preferences are the least interesting thing about him. What kind of wine did Caesar drink? Nobody cares.  The master creates, he is known by his works, not his pastimes, not his likes. His life is not suffering. The noble beast is glad to be alive. He's glad to be able to exert his strength and his will and intellect. He is pleased to be able to continue to create again and again. The noble beast doesn't want to relax. He just wants to keep becoming, to keep making himself anew. And I started thinking about this, you know, talking to a young guy who has mentoring, and you know, we were always working on projects and he was always like waiting for the end. I'm like, when are you going to stop waiting for the end and realize that there's always more to do? You know, I think that people who are really driving businesses and so forth in this world are like, they're always looking for the next thing. They're not like, ah, finally we get to be done. And you know, I think that's a difference between kind of winners and slaves really. When a man is forced to work, he looks forward to the slackening of bonds and a break from the whip. When a man forces himself to work, he works to realize a vision. But during the process, more visions reveal themselves to him. So he finds himself not working toward an end of work, but toward the next beginning to get to what's next. I can't wait to get to the projects, get done with this conference, and get to this party I have to host in a couple weeks, and then I get to plan the next thing that I'm working on in my life. That's what I'm really excited about. So don't struggle to get to the end so that you can relax. That's for slaves. Struggle to get to the next struggle. Because as a self-creator, you're a great work.


Hello and welcome to the session. In this session, first we will discuss about Bernoulli Trials. Each time we toss a coin or roll a dice or perform any other experiment, we call it a trial. The outcome of any trial is independent of the outcome of any other trial. So, trial, the following conditions. The first condition is there should be a finite number of trials This condition is the trials should be to say each trial has exactly a failure. The probability of success at which contains 7 red and 9 black balls. From this bag, we draw 6 balls. Draw the ball drawn is replaced in this case. Now let's see if the trials of drawing the balls are Bernoulli trials or not. As you can see, the number of trials in this case, say drawing a red ball in 7 upon 16, since we have 7 red balls and total number of balls are 16, the of success same for all 6 trials, the distribution. Consider and in this case given ys, so there will be n-x failures of number of successes. The trials may be obtained by the binomial expansion of q plus p whole to the power n which is given as nc0 q to the power n plus nc1 q to the power n minus 1 into p to the power 1 plus nc2 q to the power n minus 2 into p to the power 2 plus and so on up to ncn p to the power n. Thus we have probability distribution of number of successes x is written as given by px values for probabilities for 0 q to the power n. When x equal to 1, then its corresponding probability is nc1 q to the power n minus 1 into p to the power 1, then q to the power n minus 2 into p to the power 2, then when x equal to x, we have probability of x as n minus x into p to the power x, then when x is equal to n, its corresponding probability would be ncn p to the power n. Probability distribution is known as binomial distribution with parameters e we can find the complete probability distribution. The probability of x successes given as into p to the power x where we have x goes from and q is equal to 1 minus p. This function px is called the probability function binomial distribution. So we have a binomial distribution with n Bernoulli trials and probability of success each trial is denoted by b of np. Let us consider an example where we tossed simultaneously. Now in a single throw of a coin, the sample space s would be given by ht if we consider p as the probability of that in this case it would be equal to 1 upon 2 since we get just one head, then q equal to probability would be equal to 1 minus p or equal to 1 minus 1 upon 2 that is 1 upon 2. So we have q equal to 1 upon 2. If we consider the random variable x, then we are supposed to find the probability of getting not more than this would be equal to probability of getting one head or one head or that is equal to probability when x is equal to 0 plus probability when x is equal to 1 plus probability when x is equal to 2 plus probability when x is equal to 3. Now in this formula for the probability function we will substitute the values for nc, q and p to find the probabilities n would be equal to 6 since we have tossed 6 coins. Now to find probability when x is equal to 0 we substitute x equal to 0 in this n equal to 6, q equal to 1 upon 2 and p equal to 1 upon 2 in this formula for probability function. So we get this is equal to 6 c0 1 upon 2 whole to the power 6 plus probability when x is equal to 1 for this we substitute x as 1 this gives us 6 c1 1 upon 2 whole to the power 6 plus probability when x is equal to 2 for this we substitute x equal to 2 which gives us 6 c2 1 upon 2 whole to the power 6 plus probability when x is equal to 3 is given by 6 c3 1 upon 2 whole to the power 6 and this gives us 21 upon 32 a tossed simultaneously probability of getting not more than 3 heads comes out to be equal to 21 upon 32. This completes this session. Hope you have understood the Bernoulli trials and binomial distribution.