So, yeah, welcome everybody, and wait, I tried this. Ni hao shanghai, thank you that everybody joined my talk. The talk, if you may not know about this or the tutorials about from cat to lion, building a practical guide to build a large secure CICD platform with Tecton. This is the slide I took from the CNCF. They send it out and said, hey, please use this. But actually, I like this much more because that's the thing I like so much about Tecton. And you will see, if you're like, what is Tecton with a lion or a cat to do, you will see later if you did not already notice. Shortly to my person, my name is Engindiri. I'm from Germany. You may hear it from my weird accent. I'm working at Pulumi as a customer experience architect. Do everything, cloud transformation, cloud enablement, so whatever the customers come up with questions, I'm here to help. So that's me shortly. If you want, you can follow me on some of the social medias. I'm even have a GitHub handle. Let's switch to the agenda for today. Okay, give you a short introduction. And then I will also make a very short introduction. I'm not going to bore you with some extensive details about Pulumi, Tecton, backstage and so on, but give you as much information that you know, okay, how to follow and what we're going to build here. Then we come to the tutorial part where we see all the pieces brought together and moving to say, hey, this is actually working. This is the story behind this. And then we just make a wrap up and Q and A. The idea of the talk is, I mean, we all saw during the day at work, we saw different CNCF projects. And sometimes it's interesting to see them working together and to say, okay, how can you use one tool to enable the second tool? And what is the second tool doing to deliver more user experience or to speed up my deployment process? And this is all about. There are some pieces missing. I led it for you folks to check out to say, okay, how can I add, for example, a missing piece? But from the idea, it gives you a very good user journey from beginning to the end. So let's start with the first tool. I chose Pulumi for the infrastructure as code tool. You can also use probably Terraform. You can use your preference tool of choice. It doesn't change the idea. The idea here with Pulumi is, or with our infrastructure tool is to say, okay, I have different providers I can use. I have different possibilities to connect to cloud providers to create Kubernetes deployments, for example. So this is the idea here. If you use a different tool of your choice, yes, the language will be maybe different, but the idea is the same. I write my deployment of my infrastructure as code and can save it for collaboration with my colleagues together. Here in this case with Pulumi, as you can see, Pulumi offers languages in Go, Python. So you can choose your programming language of your choice to write infrastructure as code. This is useful, for example, where you say, okay, we are heavily using Python for our application. Let's use Python also to create our deployment. So this is the part here. Of course, Pulumi is an open source tool. It has many, many integrations in an existing system. You have web hooks, you have secret management, so everything comes out of the box. This is about Pulumi, but now let's dive into the idea of what we're going to use with Pulumi, because when we see the code later, you will recognize and say, ah, okay, that's what Engine meant with the high-level overview. So this is the Pulumi architecture. As you can see, we have a language host. So if I choose, for example, Java, as my programming language to create infrastructure as code, the Pulumi CLI detects that you are using Java and starts a GRPC service in the background with your language host, translating Java to GRPC calls. Everything goes into the CLI and Engine. CLI and Engine, inside, is the main core. And then depending on what provider you're using, for example, you say, I want to provision on Ali Cloud, I want to provision infrastructure.  It's automatically downloading the Ali Cloud provider from GitHub and starts also as a GRPC service. Then they start to communicate, yeah, create a resource, update, delete, and the result of every action gets stored in a local state, in a state file. And then you can decide what I'm going to do with the state file. I save it locally, maybe not do it because you could maybe delete it and you end up with orphan. You can upload it to an bucket and object storage. Everything is supported and you could even use the Pulumi SAS offering for free and say, hey, Pulumi, here's my state file. Please take care of it. But again, we talked with somebody during lunch and he said they have a heavily regulated environment. They cannot go out for a SAS service. Then they use, for example, an object storage. Just save the file here. Okay, that's the high level architecture of the Pulumi engine. How does a Pulumi program looks like? So everything starts here with this, on the right side with the diagram. So a Pulumi project is the wrapper around everything. The moment you put in your folder a Pulumi.yaml file, Pulumi detects it as a Pulumi project. You will see later in the code what I mean with the Pulumi.yaml file. Inside the Pulumi.yaml file, I can put some default values in. For example, you say, my Kubernetes cluster per default should always have six worker nodes. You can put it there. The config in the Pulumi.yaml file is always the default config. And then we head over to the stacks on the right side. Now you can say, okay, I use this Pulumi program to deploy different environments. Dev, QA, prod, you name it. You can use it for ephemeral deployments. And inside a stack, you can overwrite the value. So imagine you have a dev stack and you want that your developer or your team is not using the expensive worker nodes they could use in productive. So you could overwrite this. You could say per default, everybody gets the AWS T3 large, for example. But development doesn't need this. It's a very small Kubernetes cluster. So you can overwrite this stuff. This is what stacks are for. Next point is resources. This are our building blocks. This is our Lego pieces. We can say, take the Kubernetes resource, take the S3 bucket resource and stitch them together. And the glue between the different resources are the input and output. So every resource creating an output and every resource has an input. So I can then say, when the Kubernetes cluster is up and running, and this is what I have in our tutorial, the Kubernetes cluster gives me the cube config. So I can take now the cube config and feed it into my deployment or helm deployment. I can say, here's the cube config, use it. And that's the story we're going to do here, making the turnaround and say, build the resource, get the output, put it into the next resource. And then you can build a graph. So in the back, Pulumi is creating a duck and say, okay, Engin wants to create this infrastructure. I can provision this independently. For this one, I have to wait for the output that the resource is finished. So Pulumi takes care that everything is in order and gets executed. And the interesting part, we will also see in the tutorial, you can use the output from a project as an input for a project. So now comes the interesting part. We can now model separation of concerns. We can say, okay, the database team is owning the code for creating database. Me as a user, I can maybe use a ticket system, gyro, service now, whatever, to tell them, please create me a database. They create it and then I can just reference the Pulumi program and get the values out like database, URL, password, and so on. So that's all about Pulumi for now. And this is all we see during the tutorial. Now we come to the next one. And now you see why I say the lion, because the tecton icon is a nice cat. So when we use tecton very cleverly in our projects, it can become a lion because it has superpowers. Shortly for tecton, yeah, tecton is an open source framework. Also main contributors are Red Hat, IBM, Google is also contributing to this. And it belongs to a foundation. We know the last weeks, we all heard about licensing and all the stuff. So here, for example, with tecton, we know it's already here in the CD foundation. It will be governed there. So from this side, it's very, very cool to use it. What does tecton offers us? Tecton offers us here composable, composability, let me say like this. So I can create tasks and bundle them together. That makes it very powerful. So I can build really my own steps and then distribute them again inside my project, inside my company. Nobody needs to create the 10 time the doggie built for my Go application. I create this and I distribute this. The newer version of tecton also supports OCI bundles. So I can create OCI bundles, upload them to my container repository and people can then just reuse this. I'm going to use in the demo also the OCI approach. Declarative, I don't need to tell anything about this. Anybody who worked with Kubernetes know the power here and declarative is also working for tecton. Everything is visible. Everything is changeable. And what you see in your Git repository is probably what you also deployed on your Kubernetes cluster. Reproducible, it runs in containers. This is very, very helpful. Some CICD systems don't run on computers. They have specific worker nodes. Here we know every task can be run in a container and it will be always the same container, same task. That's very good. We ensure here the immutability. And of course cloud native. I mean, yeah, it runs in Kubernetes so it's cloud native for me. And just again, for the benefits of using this, we just, I mentioned some of the points. It's customizable. Yes, we can adapt it to our needs. It's reusable. That's what I love so much. You can create tasks and share them. I just mentioned this. It's expandable. Tecton offers a tecton catalog, a tecton hub. So you can create now your own components as I mentioned before and share them inside your company through the tecton catalog. People can browse and can just reuse them in their own pipeline. Very, very powerful. It's standardized. Yes, it used the Kubernetes resource model. So we have here a standardization going on out of the box without thinking about this. And it's scalable because it grows with your cluster. It's really seamlessly growing. What are some other benefits? Because yeah, we have tecton pipelines. There's a whole ecosystem waiting for us to use. So I put some of them with the icons. So we have tecton pipelines. That's the main one. We have tecton triggers. We can create now our own triggers on basic stuff like Git changes. Somebody pushes new stuff in a GitHub repository or in your Git T or in your Azure DevOps. We can configure and say, hey, please execute this. Please build the tecton pipeline. You can connect it to your gyro. You can connect it to service now. It doesn't matter. As long you get informations out, you can send it to tecton. You can do some interceptor work, transforming the body of the workload and then execute whatever you think. Very powerful. Tecton CLI. If you need the CLI, you can execute all the CLI commands also. Tecton dashboard, what you will see, I deployed tecton dashboard because I like to see dashboards from a developer perspective. It's also there. Tecton catalog, I just mentioned. Tecton Hub. If you ever use, for example, OpenShift, you will see the tecton hub is connected to OpenShift. You can use then out of the box the tasks other persons in the community wrote. The tecton operator I use also in the tutorial makes easier to deploy all the pieces of tecton. So I just need to deploy the operator, define my CR, what I want, and it automatically deploys it for me. And the latest one I like very much and it's really important for our security needs, for our security posture. It now has also support for tecton chains. So I can sign my images. I can check. I can check for artifact provenance. Yeah, I can even sign tecton tasks and say, okay, this task is signed and I can tell tecton just use tasks which are signed. So you really exclude the situation that you maybe execute tecton pipelines you don't want. You can generically disable this and say only signed one and the signing procedure is up to you how you define this. Okay, how does a pipeline looks like from a high level perspective? We have the pipeline. Every pipeline consists of different tasks and every task has steps. And now you can see, you can run them independently, task A. And then you can even say, hey, task B has a dependency to task A. I say to him, please run after task A is finished. So you can really create a nice structure depending on your needs. So if you, for example, need to update a ticket or close an issue, you can do this before you proceed to your next step. So have a really, really powerful way to create a dependency here. And then the high level which is executing my pipelines is so-called task runs where I can execute a single task or I can execute it via pipeline runs. I can execute a whole pipeline. And again, pipeline runs offers also possibilities to define schedules. I can define a service account. For example, I can say this pipeline doesn't need cluster admin rights. It just needs rights to write on a storage, for example, to execute, to create a deployment in Kubernetes. So you can configure this on the pipeline run. You can say the pipeline runs with the service account. We have it in the demo. Or you can say the specific task runs with a certain service account because it needs to access a secret, maybe. And then high level for the tecton triggers, as we said, event listener, event comes in. We can then look into the trigger bindings. What did we configure here? And then you can then execute depending on your interceptors and your binding. You can then say, please execute following pipeline. And then the pipeline starts to run. So the tecton trigger is really, really a powerful functionality. Okay, so far to tecton. Now I choose, for this tutorial, I choose an engine for policies. I wanted to be sure that we can define policies. And I wanted a policy engine which works also very well with tecton, for example. We come later to the idea why I choose, in this case, Kiverno. So Kiverno, for everybody who doesn't know it, it's a very Kubernetes centric policy engine which derives from the Greek word govern. Just look this up, so please. And what are the key capabilities here? What I like very much about Kiverno, in this case here, it treats policies as a Kubernetes resource. So I can just define it in my Kubernetes resource.  It has different capabilities for validating, mutating, or even clean up resources. So I can come up with a deployment and I see somebody puts in five CPUs. I can say, hey, wait a minute. That's not something I would like. So you could say, I reject this deployment. You can mutate the deployment. So somebody forgot the resource and you're like, wait a minute. If you forgot to set your resource, I'm going to set it for you. So you mutating the request. Or some other interesting thing we just saw in talks before, Sidecar. You could now use Kiverno to mutate a deployment to automatically inject a Sidecar into your container. Or you could use it to update a Sidecar. Imagine you own the Sidecar and the development team doesn't even know that it exists. But you can take care to deliver the people all the time the latest Sidecar version. Just some ideas. Powerful, we just had it with Tecton Chains. It's also the container image verification. So that's a big plus for me when choosing a policy engine. And yeah, everything is, you can set it up everything in tools like Git, for example. The policy rules I just mentioned, we have generate, mutate, validate, image verification, policy exceptions, exceptions also very interesting. If you, depending on the certain conditions, you can just also exclude policies and clean up is also very nice. This is how Kiverno works. I jump over this, okay? It's in a nutshell is you get our API request via CubeCuttle, for example. And then it's before it gets applied the admission hook listens for this one and executes the rule. So there's much going on in the Kiverno engine, but for us as a user, there comes a request into the API, Kubernetes interjects this, looks it up, run all the engine stuff and says yeah or nay and then things get either deployed or not. And this is everything around this. And now comes the part why I love Kiverno in conjunction with Tecton because it offers us already out of the box policies for Tecton. So that's really, really cool though. I maybe don't need to think about at the beginning to write rules. Maybe I don't even know or in my old company we had this situation. Compliance is owned by a team who doesn't know how to program. For them, even Yamal is like rocket science. They look at you like can I not click on a button and so on. So we could argue then with the people inside a larger company and say hey, let's use Kiverno, let's use some of the default policies already listed here and then if we see the benefits we can start to write our own policies. And here we see with Tecton already some out of the place. I will use one in the tutorial and that's very cool. Okay, so you could argue say okay, why Kiverno and not somebody else? What are some of the features which makes Kiverno also additionally better for admission webhook? Background reporting, I have event creation that's some nice functionality on top of it. I like the functionality with offline usage of the Kiverno CLI. So I can use now in my Tecton pipeline, I can run now my Kiverno CLI to just validate stuff without even connected. So I don't need to wait that somebody says hey, your deployment failed, I can do it shift left, I can do it while creating the stuff or at least when the pipeline runs. We have visualization of real-time visualization of our violation, difficult word combination with the policy reporters or there is something inbuilt. And now again, I just mentioned this, it has a huge policy catalog. And this helps you to grow the adoption very quickly inside the company. Nothing is more annoying than having a nice cool tool for your use case, but then it misses some stuff and you need to build everything, it kills your stories. So when you have something to show management out of the box, look, hey, you forgot the resource, Kiverno blocks it, that's very nice. So you can start, you don't start completely empty, get some of the, one of the catalog and then replace them later with your stuff. Okay, next one, I hurry up, Kubevilla. And this is, I think, this is a Chinese project, I think from Alibaba, Alibaba Cloud, somebody correct me. So I'm very happy that I'm here talking about my tutorial and I have a piece which is here maintained in China, so very cool. Kubevilla is heavily connected with the open application model. So I cannot talk about Kubevilla without talking about the open application model. So just shortly, again, I don't want to bore you too much with details and there are many, many talks, I think also in this area. What is the open application model? The open application model is a way to manage our cloud native applications, a specification, you can look it up. And it provides a very flexible way to define and deploy our applications and it's vendor agnostic. So that's also very cool. So I create with Kubevilla a layer, whoops. And people may don't even know what is underneath this because the platform team taking care of the integration, I can just say, hey, please expose my application of type web service on port 1990 and it will take care as a load pencil will create the ingress. So I even don't need to think about what is the ingress, it will take everything and makes it very easy for potability. And the idea of Kubevilla is that developers think in application architecture and not of infrastructure. I work at Pulumi, we do infrastructure as code every day. And yeah, it's true. Most of the time, most of the developers really don't care about this. They're like, hey, here's my code. I don't care if it's the VPC, you did very perfect and so on they say, just run it. It gets a problem when the application is not running. You have to think about nobody in the company comes to you when the infrastructure is working perfectly fine. But the moment the application what generates money, what makes the money for your business is not working, then you get a problem. So that's the thing to say care and say, okay, being application-centric and this is what the OIM is, it's an app-centric approach can help. So what is Kubevilla done in this term? Kubevilla is the runtime of open application model. They are different runtimes too, but I think Kubevilla is the reference implementation of the open application model. Kubevilla leveraged Kubernetes as our delivery, delivery control plane. It's a CNCF project and it offers you multi-tenant, multi-cluster approach. So you can really define your application as a developer, you know, okay, cluster A, B, C, they're available, you can just define them in your application and Kubevilla takes care to deploy it to your multi-cluster environment. And it's extensible, that was also good. So if you're not happy with the current add-ons, maybe they don't fit your need, you have now the option to say, I can create my own add-ons using Q, for example, or I can also create custom definitions. We will see this in action. Here, an overview map, how Kubevilla fits into the system. As we can see, yeah, we have our CI part, we use the Tecton one, where is it? No, it's not working. Okay, it's not working. Ah, yeah, okay. So, well, okay, that's the Tecton part, that's, okay. It looked in Amazon better than it is in real life. The add-on catalog we just talked, and then of course we have our day two operations on the right side. And Kubevilla is continuously working on new functionalities, so I don't know when you had the last time you worked with it, or maybe you did not had a chance at all to look at it. It offers a very cool UI. I have it in the tutorial. It has a GitOps approach with Flux, so now it automatically adds Flux as a GitOps engine, and then you can just deploy also via the GitOps approach, everything using Kubevilla, and of course observability, you need observability. Okay, how does an application in Kubevilla looks like? Application is the top level entity, and then we can start with the component. Component is mostly associated with a microservice, so I can choose from different types. I can say, hey, this is of type web service, for example. I can add then to this application, top level application, I can add traits. I mean, components, they are not one. You can do end components. You can define your whole structure. You can say, my application, shopping UI, consists of the shopping cart, consists of the catalog, everything is a component, and then you have the traits, which enhances your components with additional functionality. You can say, the web service has also an ingress. This is a trait, for example. You can also add policies to this one, and I did not do this now for this tutorial, but it also offers some kind of workflow engine, but then again, there are so many workflow engines out. I was not sure how this is going to work. Maybe it makes sense, have a look into this if you like this. Okay, last but not least, this one is going to be very quick because everybody knows Argo. If you don't know Argo, please look it up. It's the GitOps engine next to Flux, and it fulfills all the GitOps practices so we can declaratively create our deployment. It's versioned, immutable. It will be automatically pulled when there is a change in your system, and it's also continuously reconciling it, so Argo CD completely fulfills the requirements from the GitOps working group. This four stuff completely fulfilled. This are the architectural overview of Argo CD. So we have Argo CD UI, everybody needs a CLI, and then Argo CD itself consists of different pieces. The server, the repository server, oh, I have two times repository server. We have the Redis, we have DAX, we have Argo notification inside, and this lives on the cluster. I can even set up Argo to do multi-cluster deployments, so what I create in Argo is then a hub and spoke. I can say I have a central control plane Argo, and then I attach different clusters to Argo, and then I can use the system of application set to then deploy my application, depending on requirements to different clusters. Very, very powerful, and you should see this. We're going to use this for our tutorial too. And last but not least to make the round finished, backstage. Backstage is a relatively new project in the CNCF. It was initially created by Spotify, and you have to think about backstage is an internal developer or developer portal. So you have now the situation. You have a way to talk to your customers, a guided way. So there are two parts of backstage. First of all, you see the catalog of all your applications. You can configure backstage to scan your Git repository, to scan your wherever you use, you save all the artifacts of your workplace, and it will create automatically a catalog, and then you can see who's working on what, what products do we have, who's the owner of it. So you get a whole structure. You will see this in the demo that makes more sense. And we have also the situation that we can offer with backstage so-called software catalog templates. So your development team or your infrastructure team can self-serve them infrastructure or projects. They say, I need a go application. They go to backstage, they register themself, they answer some questions you can define, it's completely free, and backstage is provisioning everything for you. So with backstage, we have our different requirements. We want speed, scale, we want to reduce any cause control. So we don't want the fragmentation that everybody does what they want. Hey, I created a Git repository here for whatever, and I use make files and so on. No, we have a central way now, and this is backstage in the middle, so the best of speed, scale, and cause control. And on top of it, you can say, okay, Argo CD and Pulumi is heavily supporting this approach because you can define your infrastructure, you can deploy application, everything is possible. So I just mentioned this backstage for developers, it's very cool. And backstage again, because it's an open source tool, it's heavily customizable, you can extend it with plug-ins. It uses underneath, it uses material type script and React was it, yes, the React framework is underneath.  I created a backstage plugin, and it's not that difficult. So the moment you got it, you can now start for your company to create plugins so people can see everything without leaving backstage. Okay, tutorial time. So enough of the theory, everybody talks about theory. Let me talk about the architecture, okay? So how is the architecture look like? So I created here the so-called GitOps platform. We have on top of the GitOps platform, we have the platform team. I created the EKS, I use Amazon, I use the EKS is created with Pulumi using type script. So everything, the VPC, the gateways, everything I need is all defined in Pulumi. And then it creates for us the Kubernetes cluster with some of the deployments already in. The middle column is the deployed workload. So what I deployed, maybe you don't see this, backstage, Argo, Tecton, and Kubella already deployed. And backstage is built to listen to a specific GitHub organization. Everything what happens in this GitHub organization will automatically picked up from backstage. So now comes the development team and say, hey, I want to create a new project. They go to, this is the green arrows. They go to backstage, they order their project. And what backstage is doing in the background, it will create a pull request in the platform team repository for Argo CD. And it will also create the blueprint of the go application in their own repository. So that's the green arrow going up here. So this one is the code where the go application is. The development team can work with this. This is the pull request to the platform team git repository where it belongs to them. They decide.  They can review it and say, oh, that's nice. We do this. They accept the pull request. Argo CD is like, hey, there's new workload I need to deploy. And this new workload is our Tecton pipelines. And when the Tecton pipeline runs, it will automatically deploy this application via Kubella into our Kubernetes cluster. So much going on here. Okay, and that's the initial bootstrapping all the day one stuff. And now you can think every time when the development team works on new code pieces, we talked about Tecton triggers. Tecton trigger will see the changes. Will trigger the Tecton pipeline again to either rebuild the image because there were changes in the logic or just execute because they changed something in the Kubella definition because we just talked about you can add traits or you can add components. So every change gets detected and gets executed. Okay, I will show this now and I hope it works. So, but so far any questions feel free to interrupt me the session is for you folks. So if any questions so far before I switch to the code ask, otherwise we can do this also afterwards if you feel more happy. Hello, and then as you know, that's when we do, when we use the token pipeline to do the stuff to the deploy that's sometimes we meet that's our task is a large, large, large task. We have the scenario that we needed to separate the task into pieces. Just for example, we separate the task to task A and the task B. And yes, we know that in the publisher and the subscriber system there's a, when the task A is passed and it will be promoted each status will be promoted to a channel and task B subscribes the channel to be triggered after the task A is successful. But yeah, as I know this, I just know that the task B only can subscribe, subscribe the status of the task A, but in some scenarios, we may need some materials. Yes, some result from the task A. Yeah, let's use the example. In the task A, for us that we provision our cluster, we create a cluster and wait for the cluster to be ready. And the task B, we need to use to do some actions on the cluster. So we need to, in the task B, we need to know which the cluster is. So my question is that, is there any way or any global variables so that we can translate to the task A's result? Yeah, it can post a cluster ID from the task A to the task B. So just take it be understanding. So you talk about the cluster creation and then one cluster is still reconciling or not fully ready. And you want to know how is it possible to get feedback about this or? No, sorry. Task A, a private cluster, private cluster, private or set for a ready cluster, but the task B needs to do something on the cluster. So task B needs to get a flag, such like a class ID or class name from class A. So that's why we can do something on the cluster B. Maybe we discuss this later words because maybe that's a little bit bigger. So sorry for this. Then I will come after the talk to you again and we can talk a little bit. Is this okay? Okay, no problem. Then I just continue this because it's a bigger question and more for thing. Okay, so let me show you everything in action. What I created here now is the demo code. You will see the QR code. You can look it on. I created now two folders, one zero zero infrastructure and one zero one Kubernetes. We talked about Pulumi. We said we can create two different kinds of stacks. We see the Pulumi YAML file is here inside and defines everything in the folder. It's a Pulumi program. So I create one Pulumi program in the infrastructure folder defining. So here I can define now everything related to the creation of the infrastructure. So the gateway and everything it's here. I created a stack called def. This is here. I said you can define in your stacks specific config which is different from the normal stack. So my development stack will be deployed in EU central one. If I create a second stack, the prod stack, I could then say, hey, this is in US West for example, doesn't change anything. Here inside is the code and here we create our Kubernetes provider. Where are you? Here, here we create our EKS cluster and we see the EKS cluster gets also out. Where are you? Here, this is the cube config. What I said, every resource has an output and gives for example, here the cube config. So I can say now, create a Kubernetes cluster, create a Kubernetes cluster in AWS and then create a Kubernetes provider using this cube config. So this is this definition. Let's have a look how we deployed the single applications. So here again, it's a JavaScript project, a TypeScript. And we have here, where are you? So this is very important for the whole idea with the stack reference, I can now reference the values inside the 00 infrastructure program and can say, hey, please give me the cube config from this stack because I'm not the owner of the Kubernetes cluster. Maybe that's the infrastructure team doing so. I separated this, somebody run the infrastructure deployment, me as maybe a platform engineering team or a platform developer, I can just reference this and start now to deploy all my applications. So we see here, for example, I deployed engine X as a Helm chart and then we go, I deployed external DNS because I wanted to show with the DNS everything. Here I deployed Tecton and so on Argo CD. The thing what we created here now, which is also very cool, as you can see, I created a Qiverno, but this is not coming from Pulumi. Pulumi doesn't know about Qiverno. What I did in the background, I create a Puyah was here in this talk, a Pocable abstraction. So I created a component resource called Qiverno, which has the real deployment inside. So now I hide the implementation of Qiverno and somebody else can use Qiverno as a component in my Pulumi code and he doesn't need to know the implementation. So if one day the thing change, the person who's including Qiverno doesn't know about this. He says, hey, I included the version of Qiverno, version 1.0 as NPM module. I then say as platform team, I say, hey, I created a new Qiverno version. He then just can include this. So the trick we do here, creating transparent abstractions using component resources to hide the implementation, to reduce the blast radius of anything and people can just use it because sometimes maybe the person doesn't know what's the best setup for Qiverno. So what he's doing, he just includes Qiverno in classical type script using the new Qiverno, changes some properties, can send some dependencies, that's it. So and in this way I deployed Argo, backstage, everything is deployed. So let's, I will share the code as a QR code. You can have a look into it. How does it look like in action? So now we come to the last part to see everything moving together. Where are you? Sorry for this one. Okay, so this is backstage deployed. This is Argo CD deployed. This is my GitHub repository where I connected backstage to it. This is Kubevilla deployed. Oops, let me go to the start page. Okay, and this is Tecton dashboards deployed. Okay, so let's do, we are on development team. We go back to backstage. Where is my mouse? So here's the mouse. So I go in, I log in here. In this case, I choose GitHub as an off provider.  Come on, come on, don't do this now. Just a second, sign in. Okay, now I'm signed in. We created our catalog. As you can see, I created also a test application. This one is our test app and I can see now the relationship between them. I see, okay, this app belongs to who? It belongs to the development team. It's owned by this person, very, very good. If it has an API, I could also publish the API of it. But the interesting part is now, I see all the components available. I can also browse through domains, location, and all the users. But what happens if I want to create a new one? We go to create and then we see the different templates, I said. This template is completely written by myself. You can write every template to your needs. So in this case, we have a brief instruction. It's creating a new go up with following features. It creates a GitHub repo, Tecto and CI, Kubella application and Argo CD application. So let me choose this one. It asks for some stuff. I can ask if I don't want then it's up to my, to me. So I say a KubeCon, CN and I can add some demo text to it. And as you see, owner is mandatory. I have to say who owns this component. I can say it's the whole development department who owns it. Now we go in the next step. It asked me, where should I create a new GitHub repository? I say in my silly organization and the name of the repositories should be KubeCon CN. Then we go next step. It shows me the information. You can create unlimited steps as you want. It really depends on your process. I can then click on create and now the magic happens in the background. So I mentioned before, it creates a pull request in the Argo CD repository. It will create the application, GitHub repository and I get all my links here now. I can go to the PR and I can see my application code. So let's see how does it look like. If I, now I'm the platform owner, I will get an email, a notification, slack, whatever. And it's written, hey, somebody created a new application, the new KubeCon application. I can now review the code and say, yeah, okay, that looks fine. I can run a pipeline for conflict checks and so on. Yeah, that looks fine. And I could then accept the pull requests. So before we accept this, we also check our Argo CD. Okay, we see Argo CD currently has only deployed the test app from before inside. Okay, that's fine. So now we check also the application code. How does the application code look like? So backstage created this folder called KubeCon CN. It also templated some of the readme. So everything is free. The cookie cutting of the project work perfectly fine. I have here my tecton pipeline. I have my KubeVela application definition perfectly fine. So me as a developer, I can start to work. So the only thing which is missing now that the platform team says, yeah, that's fine. So we say squash and merge, we say confirm. And now we go to our Argo CD, let me refresh this. And we see it detected automatically that there's a new application with new tecton pipelines. It's automatically deployed the new pipelines and it already started the build of the image. So when I go now into my tecton dashboard, here you can see now under pipeline runs. Here, it started the KubeVela deployment and it also started the KubeVela pipeline to build everything. So when we look into this, this was a pipeline we mentioned we saw in the picture and these are the different tasks. And every task has a step. You see, I created a task for cloning the repository. I create a canico to build the image and most importantly, also write the hashtag back into the repository. And then we see also the KubeVela will be also executed. So KubeVela push to apply the application. So this takes some seconds, it should not be that long. Okay, a canico if you don't notice you can create a doggie image without a doggie agent that's very powerful. So the build of the doggie image happens in my EKS cluster. I don't have a dedicated worker node running somewhere. So now he's pushing the image to GitHub. So I want that it's pushing to the GitHub container registry. And now I tell KubeVela, hey KubeVela, please deploy the image with this digest. And yeah, that's it. And then just telling KubeVela the tecton also and now push the changes to the repository. So let's look how does it look like? So this is my application code. And if we have now a look, we see, hey, there is a package. There is the tecton package just created. And we see, yeah, this is the image I created here with the latest, fine. And when we go into KubeVela, you see there was a change just now. And there should be in the customization YAML. Yeah, there is the Shah. So everything should be fine working now. Then we go back to our KubeVela UI. You see KubeCon CN app is deployed and we see all the information here now. These are the components. I can now add additional traits to it. And yeah, the application is so far deployed. And if I need any changes, I can then just update the git repository. Okay, let's head back to our slideshow. Okay, wrap up. What did we saw? We created a platform all in code using infrastructure as code tool. Again, in this case, it was Pulumi. We created Backstage as a front-facing portal to interact with the platform. So we have now a UI where people can interact with our platform with the golden paths I provided them. We see that Tecton and Argo CD plays very well together. I can, because everything is Kubernetes, it just works, that's brilliant. What of course is missing now, we have to implement now triggers. We should create some kind of authentication for the users, a DEX for example. We should think about security observability. Yes, there are some missing pieces, but I think the idea to create a full story using Tecton with other parts of the ecosystem work perfectly fine. And yeah, that's it so far. So now thanks for everybody who stayed to the end. Shinshin, any questions? Thank you. I have a question about the Kubevilla in the graph. I mean, I see that the Argo CD is the last thing that trigger to deploy the new version, right? And the Tecton is the runner that makes the chain on the Kubevilla configuration so that the Argo CD can trigger the deployment. So my question is, so basically I can replace the Kubevilla with something like the Terraform or something, right? I mean, yes, of course, I mean. Yeah, so when will be the run of the Kubevilla on your example, I mean, so I did not follow. Yes, of course, sorry, maybe it was too quick. So I have here in my Tecton, I have two tasks. So two pipeline runs. So when the image gets built, it makes automatically a Kubevilla up because then the image changed. And I want that the application definition has the latest image inside. Every time when I change something in my Kubevilla file without changing the logic, maybe I want to add a trade or a component, it will execute this deploy only one. And here there's just one step into it just to do the Kubevilla up, you see? I use customize to change the image tag because the image gets built from Tecton and the SHA number has to be brought back into the customization YAML because we want to do everything GitOps. So what the one pipeline is doing, the moment the image is built, it gets the SHA number of the new image, push them into the Git repository into the customization YAML. And when I do a Vella app, I'm not doing a Vella app vanilla, I do customize apply, customize change the SHA number with the latest one inside my application YAML file of the Kubevilla and then deploys it with the latest SHA. Okay, okay, thank you. So that's the thing that the chain on this. And yes, of course, you can change Kubevilla with vanilla helm charts. So I just need to update the template as the first plate to use the other, right? Sorry? I just need to update the back state templates to use the other thing like Terraform replace for the Kubevilla, right? Yeah, if you want to say, I want to offer a new backstage template where people can choose between Kubevilla and Terraform, you can either, I would then say, okay, you can create here a checkbox. You can say Kubevilla or Terraform or helm. So you can do as an application platform owner, you can give people the choice because as I mentioned, this is everything what you wrote. So if you say either Kubevilla for everyone or they can choose between Kubevilla and whatever, so it's up to you. I see, I see, I see, thank you, thank you. Okay, I will be here around to you. Hello, thank you. I just want to confirm that the configuration of the application and also the application code is in the same repository. It belongs to the idea was, let me show this here, that because why do I use Kubevilla? Because Kubevilla is easy for developers to change. So everything is inside like a Monorepo. So I have the Tecton files. They're not somewhere else. The application team can still change the Tecton file. Argo will deploy it. So I just gave them here, hey, this is the good thing. If they want to change it, they can change it. And now comes the thing, with Kiverno, you can check it now. You can say, hey, if they do some stuff I don't want, I can block it. But the application team is completely independent now because they own now the Kubevilla definition. They own the Tecton pipelines. If they want, they can change it. If not, they leave it like this. So that's the idea behind this. So making them independent while applying to confirm and to rules, you know? Because if you don't deliver this and this, then a new project has to keep copy, paste the stuff from somewhere else and so on. And now you say, hey, I create the Git repository. I put everything. This is also created by Backstage. So everything is created to my rules but you have to free them to change it. And with QKiverno, I will check it. If you do some not good stuff, I will block the deployment because, yeah. So scalable, the people have speed, what we say. Speed, chaos, control, everything inside. I hope it makes. Thank you very much. Okay. Then thanks again. And I will be here around if you want to talk, then feel free.


Welcome to class 23 on topics in power electronics and distributed generation. We have been talking about economic evaluation of DG systems and we looked at a few measures for doing that. The simplest is the initial cost which is a short term immediate decision. Payback period is something which is more on a commercial time frame maybe of the order of a year and to make a decision on whether meaningful investment is being made in terms of investing in DG technology. The cost of energy we saw is much longer term time frame which is useful for policy considerations and we looked at examples in these methods and we have we will start looking at looking at effective initial cost and one of the advantage we will see with effective initial cost is that as a power electronic designer we may not know the entire system which is being assembled together. We might know only the power electronic part of the subsystem and we would like to actually make a decision on whether to how to go about doing the design based on a portion of the system which may not we may not be 100 percent clear at the point at which the DG overall DG system is being built. So if you look at the effective initial cost it is a way of summing together different costs with some of which might be upfront and some of which might occur later in time. Some of the upfront costs would be things like material, labor, markup, etcetera for example if you need to build a power converter you need IGBTs you might need capacitors. So these are upfront material costs you might need controllers you might need human input in terms of actual manufacturing process you might also need people to do controller development etcetera and you also have any company would need some percentage as a profit or a markup on whatever system that they are building. Once you manufacture say for example a power converter you may want to ship it to the end location where the power converter is going to be located for example you might be building a power converter may be in Goa may be the wind turbine in which the power converter is going to be sitting might be in Tamil Nadu and you need to actually ship this thing across the country and depending on whether it is a bulky device whether it is a compact this device you have shipping cost you in terms of systems which are used in transportation systems like aircraft space size and weight is a very important requirement. Also once the equipment reaches the end location you need to commission it you need to make sure that the civil work mechanical structures are in place if you are sending it to a location where it is a urban area the cost of area might be different from a rural situation. So depending on many of these things now reflect as initial cost upfront which is fairly well understood. There can also be other cost which can occur when you run this particular power electronic system on an ongoing basis for example you might have operation and maintenance you might have circuit breakers which might need periodic maintenance the springs the contacts might need cleaning. You might have capacitors whose ESR might change as a function of time you might think about replacing the capacitors after so many years of operation. So those are future cost which actually have to be encountered when you operate your system you might also have cost on a running basis for example ideally we might think of power converter as being lossless whereas in a real power converter we know that there are finite loss and in a DG system you might one might consider as something that is being lost in the power converter as something that is not available for you at the load or not available for you as a unit of power which can be sold. So you can think about losses in your converter also as a ongoing expense over the life of the system. At the end of the life of such a system you are talking about power related equipment so you are talking about longer time frames of you are talking of maybe 20 years 30 years etcetera for a large power system. So you might also have cost associated with decommissioning if you have electronic things you might have to look at how to dispose of electronic waste if you are having machines, windings etcetera you might have value in the copper or the iron so depending on what the decommissioning cost are you will have to make a decision. And you will see how all these cost can be effectively rolled up to a up front number to see whether it makes effective design which particular design might be more appropriate depending on your application. So one way of looking at a cost which is going to happen in the future is that if you have some amount C if you have some amount C at the end of a year and if your interest rate is R you will have 1 plus R into C at the end of 2 years you would have C into 1 plus R square at the end of P years you might have 1 plus R to the power of n. So if you have a cost that is incurred at year P and you want to see what is a cost today you are facing because of that you will have the present value of the cost that you are going to incur in the future to be C in the year P divided by 1 plus R to the power of P. So if you have some expense that is going to happen over here you can actually reflect back to the present value. See you might have annualized cost C, A and N occurring over n years. So depending on what this annualized equal cost are you can actually then take this particular number and take over the entire duration over which you are doing your particular calculation and sum it up to get the present value of say for example an annualized cost. So in this example annualized cost may be the losses that you incur in a power converter you might know how much kilowatt hours of loss is there and you know what is the cost per kilowatt hour of for electricity. So in a way you can then reflect back the losses to a upfront number to the initial point to look at what is a effective cost. So many times what can be encountered in the future can be reflected back to the present to see overall what would be the benefit of making one decision or the other way. So we look at an example where say for example you have a 1 megawatt per converter and say the cost of the converter is 50 into the 10 power of 5 rupees and it is used in a machinery with 20 years of expected operational life. And we will assume that in this particular power converter you might have capacitors that might need replacement every 5 years and the cost of the capacitors are given. You might have IGBTs which need replacement every 10 years and your cost of the IGBT is known. So for example of the 5, 10 and 15 year you might replace capacitors, 10th year you might replace your IGBT you are given some interest rate which you find reasonable for your particular application. So the question is when you decide on purchasing this 1 megawatt per converter it is not just the initial upfront cost you will have to also look at what is the cost associated with the operation and maintenance associated with an equipment. So you could then look at what the cost could be. So if you look at your net present value of ONM operation and maintenance so you might have capacitors 10th power of 6 divided by 1.15 to the power of 5 years plus 1 plus 2 into 10th power of 6 divided by 1.15 to the power of 10. So this is IGBTs and capacitors at year 10 plus capacitors at year 15. So if you look at the net present cost of your operation and maintenance in this case it works out to rupees 13.6 into 10 to the power of 5 and then if you look at now your overall cost including your upfront cost which was 15 to 10 to the power of 5 you will need to add this to actually reflect that you need you are making a commitment to operate this particular equipment for 20 years which reflects in the additional operation and maintenance cost. So your effective initial cost including ONM in this particular case is rupees 63.6 into 10 to the power of 5. So we can next ask say suppose you have this 1 megawatt power converter you have say 3 options in technology whether you might have something which is the latest technology having very high efficiency you might have something which is slightly older or something which is now commercially available. So depending on the type of inverter which is being used you might have say a 1 inverter which is 94 percent and its cost might be 45 into 10 to the power of 5. You might have another inverter which is 95 percent, 1 percent more efficient which is 15 to the power of 5 so cost slightly more and then you might have another inverter which is very efficient 96 its cost is slightly more. So then the question is if we know the way in which your particular power converter is going to operate we will assume it is 8 hours per day 365 days a year and for 20 years you are expecting to operate this particular unit and we will assume that the operation and maintenance cost is same as what we calculated in our previous example. We will assume 15 percent interest rate we will also assume the cost of energy is rupees 4 per kilowatt hour. So we could then look at what is now the cost of the losses that you are incurring in this particular equipment and clearly the choice over here is you trade off between paying more for a more efficient converter or paying less for a less efficient and the question is what would be reasonably appropriate decision. So if you look at the example of the 94 percent efficient power converter you can calculate the power loss. So this is P n minus P out so it is 1 megawatt divided by 0.94 P out is 1 megawatt. So this is about 63.8 kilowatts of power is getting dissipated. So if you look at your energy loss per year so this would be 63.8 into 8 hours per day 365 days a year. So this turns out to be 186 into 10 power of 3 units or kilowatt hours per year and assuming at 4 rupees 4 per kilowatt hour this turns out to be rupees 7.45 into 10 power of 5 rupees per year. So then you could then calculate what the net present value of your cost is based on the expression that we just had. So using the expression for the annualized cost you know what is the cost per year you know the rate you know it is operating over 20 years of life. You can then calculate what the net present value of losses so you have the capital cost being 45 50 or 60 into 10 power of 5. We assume the operation and maintenance cost to be 13.6 the respect for all the 3 units. If you calculate the present value of losses for the 94 percent it is 46.7 into 10 power of 5 for the most efficient it is 30 into 10 power of 5 because the losses are a lot lower. So if you then look at what is the overall effective initial cost you find that the what leads to the lowest cost of ownership or the initial cost is actually something which is intermediate not the cheapest or the most efficient you will have to look at what is appropriate depending on whether it is operating 8 hours a day or 12 hours a day. So you can actually go back and calculate according to your particular design and see what would be an appropriate design. In this particular case all the components in this particular system is related to the power electronic converter so you could actually make such a design decision without knowing much about the balance of plant. So you can see that some of these numbers are good as comparison physically the present value of losses is not something that you actually spent out of your pocket it is something that happens. So these numbers are more for comparison rather than absolute numbers which reflect expense that you will be incurring but it can give you a guidance in the direction of what is appropriate or what may not be the most appropriate in terms of making a technology decision. So if you look at the different applications depending on whether you are designing a solar inverter or a wind turbine or maybe a automotive power converter used in electric vehicle depending on the time frame you can adjust your interest what is suitable for your particular application. What might be available as an interest rate for a small business may not be the same as what is available as interest rate for a larger business more established business. You can actually again keep in mind that these numbers are not absolute you are making comparisons and when you are making comparisons you can make comparisons at equal level rather than use one rate for one particular comparison and another rate for another comparison. So you can actually make a decision on whether the technology that you have selecting is the appropriate technology. Suppose you have we discussed in the last class that many times because of the addition of a power converter you can have benefits to the balance of the plant. So a balance of plant where you get benefit can be reflected as a negative cost in depending on your particular power converter technology. Also people can refine it further here we are just considered a simple interest rate. You could also include factors like depreciation inflation tax numbers things like that to refine it but those are essentially details. The basic framework is essentially taking cost that can occur on the in the future or on an ongoing basis and reflect it back to the present and people look at this type of design as and people call it creditor to creditor design end to end point design where all aspects of not just your initial cost but also your operational cost are included in making a design decision. And often as a engineer you may not just make one particular design for your customer your payback period might be important for your actual design engineer may be effective initial cost might be important as a company management who might be trying to see whether the technology is going to be broadly useful to society you may want to actually calculate the cost of energy. So you often it is important to calculate all the methods and actually see which particular method gives you justification in making a particular design decision and help you guide through whether the power converter or power electronic technology is appropriate for the particular application. So with this background in essentially making design metric or making a decision on how to actually go about with making a decision on your power conversion equipment we also saw that the role of power electronics is actually increasing quite rapidly in distributed generation applications and your power electronic converter is actually intermediary ideally it is 100 percent efficient at no cost it is compact lightweight very reliable etc. So we will look at what it takes to transfer power so this is an intermediary transferring power from one particular source to another source and what does it take to actually transfer power. So if you look at a typical power transfer system which is based on power electronics what you would want to do is transfer power between sources say here what what is shown is two voltage source one is V in and the voltage source is V out and you want to transfer power between say the two sources and if you use components such as resistors you always end up with dissipation so or if you use switches in active or in the linear range again you will end up with participation. So to get the best possible efficiency in power transfer the method that people use in power electronics is to operate the switch the the the component as a switch which is either on or either off a switch which is on ideal switch does not have any voltage drop across it so there is no participation a switch which is fully off does not carry current through it so again there is no participation so ideal switch does not cause dissipation okay and the question is what possible combinations are feasible for a network of switches between say input and output what is shown over here is that shown is two voltage sources and one thing that we can immediately say is that say in this particular system your switch S1 and S2 cannot be turned on because immediately they would short the voltage sources. Similarly you could actually look at what are the other possible combinations of the switches S3 and S4 cannot be on because the two voltage sources would get shorted through the switch S3 and S4 similarly you can see whether S3, S5 if you turn it on it is again equivalent to shorting V in so you will find that in a switch network between two ports input port and the output port you cannot really operate any of the switch without causing short circuits or we will not be able to transfer power between your input and output in a efficient manner. Similarly we can think about what are the possible ways of exchanging power between different types of sources we just saw that voltage source and a voltage source you can have problems we will see that with even with the current source on both sides you can have problems if you have two current sources such as this you cannot open a switch a current source because it would cause a large interruption in the current and that would cause a large voltage spike so current sources cannot be opened voltage sources cannot be shorted and even if say the current source are connected in series one source will dominate the other and will cause the large stress to be applied from one source to the other. So both voltage source to voltage source and current source to current source would not work well in a efficient manner and it would be quite it would cause a lot of stress on the components in the circuit however we will see that once you have a voltage source on one side and a current source on the other side then it is actually possible to have a fairly efficient good efficient power conversion and in this particular case the voltage source might be battery it might be rectified AC voltage a current source is typically obtained in a power electronic application as a inductor a inductor does not like to change the value of its current rapidly so depending on the design of the inductor you will end up you can end up treating it as a equivalent current source. So if you have a combination such as this the number of switches that you need can be reduced to just two S1 and S2 and to prevent the voltage source V in from getting shorted it means that S1 and S2 cannot be simultaneously on so either S1 is on or S2 is on but cannot be simultaneously on similarly you need to provide a path for the current I out to flow it means that S1 or S2 has to be on you cannot actually prevent the current from flowing through the I out which means that S1 or S2 has to be on. So if you look at this particular model of two switches S1 and S2 this corresponds to a single pole double throw switch you can think of it as we will look at the next slide you can think of it as a switch where you either connect to the bottom or the top so your throw is either connected to your one end of your source or to the other end depending on how you want to transfer power and this can be used in a variety of configurations. You can actually see that the basic buck converter boost converter etc are actually variants of this particular configuration of having a voltage source on one side and a current source on the other. So if you look at an example the realization of this particular circuit you in a DC to DC converter form you have V in so your pole is connected to 3 and because you are either in location 1 or location 2 you always have a path for the current I out and because 1 and 2 are not simultaneously connected anytime you will never create a short circuit in V in okay. So it satisfies both the conditions for the voltage source and the current source. If you then look at what could be a realization of this particular circuit if you think about it in terms of a practical switch along with diodes or to form a power converter one realization would be your buck converter. So a buck converter is a simple realization of this particular circuit where you have a voltage source on one side and your filter inductor along with whatever load is connected acts like a single pole double throw switch. Your boost converter is also equivalent to this particular configuration. So if you have a boost converter so the boost converter also can be thought of as a realization of this single pole double throw configuration and you it is possible to have efficient transfer of power between your input and your output whether it is a buck or a boost as we are familiar from our Paul electronics courses. You could also have bidirectional power flow if you have with a buck boost type of configuration. So depending on your control you can actually send power in either direction and depending on how you send your power you can have a buck or a boost effect. So then so the next thing that we would be interested in is what how to actually make use of this rather than on a DC to DC basis how to actually generate a AC voltage how to put together a elementary single phase power converter using the same configuration. So building a simple DC to AC converter is straight forward again assuming the SPDT configuration for your power converter. So what is shown over here is essentially your DC input to be consisting of two voltages V DC by 2 and V DC by 2 and the midpoint N which you might one might consider to be the neutral and you have again the SPDT which can either be into positions. If the SPDT is on the top position so if throw is at P so your V ON is now plus V DC by 2 whereas if your throw is at N at the negative DC bus your V ON is minus V DC by 2. So depending on whether it is connected to the top or the bottom it is possible to get an AC voltage and value V DC by 2 or minus V DC by 2 depending on the position of your throw. So the next question is how can we then generate a sine wave from a configuration such as this because many times you are interested in interconnecting to the AC grid and the AC grid voltage is a sinusoidal quantity. So again similar to what we saw in the buck converter boost converter example converting this single leg single phase single leg inverter using transistors and diodes is possible and we could make use of pulse width modulation of the switch by appropriately controlling your switching action of your switches in the positive half cycle and for short durations. So when you are talking about generating a fundamental output your fundamental voltage is of the order of time duration you are talking about 50 hertz or 20 millisecond the switching times that you are typically talking about this of the order of 10s of kilohertz. So you are talking about 10 kilohertz you are talking about 100 microseconds. So if you look at in this particular case your fundamental frequency is 50 hertz so your T naught your fundamental period is 20 milliseconds whereas your switching frequency depending on your particular application you might have switching frequency which might be a few kilohertz to maybe 100s of kilohertz. So if we take a example of 10 kilohertz switching frequency so you are talking about TSW switching period of 100 microseconds. So you are talking about maybe 200 durations of switching period per fundamental in a 20 millisecond fundamental time frame. So when you operate such a power converter as a simple inverter on the one side you have the voltage source which is shown over here as Vdc by 2 and Vdc by 2 with the midpoint being considered the neutral. The output is essentially again a filtering action provided by a inductor we are considered over here as simple RL type of load and the inductor provides the filtering. So the question is how quick how fast you need to switch when you are looking at a PWM action and essentially what you are looking at in terms of the switching period is in terms of your switching frequency has to be much higher than the frequency of the poles of your system. So from your filter perspective or from your equivalent physical system perspective what is seen by the filter is essentially an average value rather than the instantaneous value. So larger the value of the filter you have more integrating effect so the ripple will be reduced. So the natural averaging effect of physical systems comes into picture and you get an averaging effect by the PWM operation of the power converter. So if you look at essentially a filtering effect because of a inductor if you look at the input to be a step waveform going through integrator which might represent a inductor or a capacitor or some electromechanical time constants in a motor type of system the output is essentially going to be a ramp when you are having a step input if you are having say a pulsed input essentially you will have something which steps up and stays flat as you proceed through the filtering circuit if you have something which is having a pulsed input with an average of 0 essentially what you would have is in this particular case the output of such a waveform would be the integral of that would be a ripple the ripple would be riding on top of whatever is the fundamental that you are trying to apply to the load and the magnitude of the ripple is can be reduced by selecting a larger inductor or a larger capacitor for improved filtering. So many physical processes naturally have integrators in it and they lend itself to PWM action and the constraint is that your switching frequency is assumed to be a lot larger than your maximum pole frequency of your plant. So in such a situation what you get at the output of your power converter is essentially the average effect rather than the instantaneous effect so the averaging can be considered.  So S plus takes a value of 0 or 1 and S minus is actually the complementary of that. So you can then calculate what is the average voltage V o with respect to n. So whenever the when you are doing say a sine triangle comparison will assume that say you are having a triangular waveform we try and you are comparing that with say a duty cycle D and whenever the duty cycle is larger than the triangle then you switch S plus is considered to be turned on and when the D is below the triangle then we will assume the switch to be off. In this particular case we will assume that the triangle is between 0 and 1 the duty cycle D is a continuous signal which belongs to the range say 0 to 1 and it is a continuous signal where S plus is 1 if D is greater than V triangle and 0 otherwise. We will assume that the bottom switch S minus is essentially the complementary of S plus. So whatever is when S plus has a value of 1 then S minus is 0. So depending on whether your S plus is on or S minus is on you can actually calculate the average value of the voltage between O and N averaged over a duration of TSW where TSW is your switching period. So when when switch S plus is on you have plus V DC by 2 for duration of T on when your duty cycle is below your triangle you have minus V DC by 2 for a duration of T off. Also T on plus T off is your switching period. Also T on can be related to your switching duration TSW through your duty cycle D and T off is 1 minus D times TSW. So if you look at then what is the this average voltage that you are applying over the period your V ON is V DC by 2 into D minus 1 minus D substituting for T on and T off. So you can see that this is equal to V DC into D minus half. So you can think about your single phase inverter as a amplifier where essentially you are having a gain of V DC on an average basis that is getting multiplied by the duty cycle with some offset depending on the value of your duty cycle being in the range 0 to 1. So that half correspond to the mid value of that particular range. So you can see that essentially in this particular situation your V ON the D is generated internally by your controller it can be PI controller or some other type of controller or it can be some open loops type of structure which is giving a waveform which belongs to the duration 0 and 1. So this is actually a signal that can be thought of as generated by the controller and if you look at then the waveform your S plus S plus has a value of either 0 or 1. If you look at the average value of your S plus over at switching period the signal S plus is also referred to as a switching function the average. So over a duration S plus to TSW S plus is ON for T ON it has a value of 1 during T ON by TSW. So you can see that the switching function and the and the duty cycle give information back and forth. So knowing the duty cycle you know what the switching function is and knowing what the switching function is you know what the duty cycle is. So you can go back and forth between your switching function and your duty cycle. Also if you look at the average voltage expression V ON average and you look at your duty cycle between say D belongs to the range 0 to 1. So when your duty cycle equal to 0 you have output voltage which might be minus V DC by 2 when your duty cycle is close to plus 1 you are having a value of plus V DC by 2. So depending on your duty cycle you can actually think about an average voltage which is being applied and essentially your single phase leg of the converter acting essentially as an amplifier from your voltage perspective. Now once we have a feeling for what the voltage can be generated in a single phase basis in such a power converter we could then ask the question what would be the voltage level that would be considered appropriate for a given application often we are interested in connecting to the AC grid. So we will see that important factors is factors are what is a nominal voltage and what is the range around the nominal voltage that one has to consider. What is the filter voltage drops that one has to consider and also effects such as dead band plays a important role in determining how much margin you need to have over and above your typical voltage when you are selecting a given DC bus value in your inverter application. Thank you.


In last week's Nervous event, we learned how interoperability can shape the future of blockchain evolution. So, I think as we grow in the industry and as we serve more and more people, we're going to start to stretch the limits of the boundaries of existing platforms. Nervous is an open-source public blockchain ecosystem dedicated to solving one of the biggest challenges currently facing blockchain technology. Today, the co-founder at Nervous, Kevin Wang, is here to present their groundbreaking interoperability technology, the Universal Passport. Thank you, Giovanni. I'm happy to explain a little bit more about Unificial Passport, which is Nervous Network's interoperability solution. Let's first look into the concept of interoperability. We believe that the future of the decentralized economy is going to be built on multiple blockchains, including both highly specialized blockchains such as Bitcoin to start value and rate of currency, and other specialized blockchains for specific applications, as well as general platforms like Ethereum and Nervous. And this will even include open permission or even private blockchains. All blockchains will come together and form an internet-like public network. Therefore, we need every blockchain to be able to interop with one another. For example, we want to move assets from one blockchain to another one. We want to be able to swap assets between blockchains or have applications that we'll call smart contracts on multiple blockchains. So interoperability as a research topic, it has been around for a few years, but it mostly has focused on cross-chain, which is more about moving assets across different blockchains. It takes a very chain-focused point of view and then talk about the specific protocols, how you would ensure security between typically assets moving between different blockchains. When we look at some of the most well-known interoperability solutions, Polkadot and Cosmos, for example, are both cross-chain projects that could connect all blockchains that are compatible with their own standards. But who will win in the end? We don't know. And they both have great visions and then they both promise that as long as new blockchains are built with their own frameworks or toolkit, then they can be connected to their own universe of blockchains. However, what we are seeing is that blockchains are connecting together directly. For example, we're seeing Bitcoin is bridged to Ethereum directly without going through, for example, either Cosmos or Polkadot. And the same idea that Zcash and Ethereum will be connecting together. So I think we will start to see more and more of these ad hoc connections between pure blockchains instead of a new protocol that will eventually be adopted by all the blockchains as the hub or the relay for all blockchains to connect. Other than the standards problem, today we do have many standards that are incompatible. Another problem that we're seeing today is this user experience problem. And just imagine a user when they use an application that access multiple blockchains. They need to have wallets that can talk to these multiple blockchains.  And just imagine now you have more than just two blockchains connecting together. For the end user, the hurdle to be able to work through the two interfaces will be very, very difficult. Creating new standards trying to unite existing standard never worked out too well in the past. Instead, we need to think about how to be compatible and support existing standards. This is the promise of interoperability 2.0. And this is the result of us at Nervos trying to think about solutions from the first principle approach. We try to think about, you know, once the perfect solution will be built, what we want to accomplish right in the ideal situation. And this is what we come up with, right? So we want to be able to have users operate on any assets from anywhere. And this actually solves both of the problems that we highlighted. The first one is this incompatible standards problem, right? So we don't want to create new standards. So there shouldn't be new standards, but instead we should be compatible with all the existing standards. And similarly, we shouldn't ask users to have multiple interfaces and multiple identities. Instead, we want the user to use any interface and then have a unified identity. In other words, we want to meet users where they are instead of asking them to get used to the interfaces that fit into the underlying plumbing or infrastructure. So now let's look at universal passport. And this is specifically how we at Nervos implement this, what we call interoperability to implement the interoperability 2.0. For the universal passport solution to work, there are several layers of technologies that we put together. At the bottom is our public blockchain, which is Nervos CKB. And then CKB stands for common knowledge base. And the two features that enable this universal passport on the public blockchain level are flexible crypto primitives and also abstract cell model. And we'll talk a little bit about what they exactly mean and how they enable this. But on top of the public blockchain infrastructure, we have a layer what we call interoperability 2.0 components. So these are PWCore, Forcebridge and Polyjuice. And again, we'll get into these one at a time later. And then on top of it, developers can build applications that are naturally multi-chain or naturally cross-chain applications or multi-chain applications. So let's look at these components one at a time. Forcebridge. So Forcebridge is a general crossing protocol between Nervos and any other blockchains. The reason that this can be generic and then connect to every blockchain is because when you think about the ability to verify transactions across blockchains, you have to be able to essentially write in smart contract the other blockchains cryptographic proofs. You have to be able to interpret it and then be able to verify those. And to do that, the blockchain itself needs to support whatever the crypto primitives that the other chains are built with so they can interpret transactions. So Nervos comes with flexible crypto primitives, which means developers don't have to wait for the builders of the infrastructure, the core devs, or hard forks to include pre-compiled for these primitives. But at any time, they can sort of roll out their sleeves and then include these libraries as they wish as they will. So with that, Nervos can much more easily interpret the proofs from any other blockchains and then be able to have crossing protocols in a very decentralized manner. And the next component is PwCore. And this is built by a community team called Lay2. And this solution allows you to build applications that's accessible to all users on other different blockchains. For example, an application built on Nervos through PwCore, you can reach users on Tron or Eos or Ethereum. All they have to do is using their existing wallets and they will be able to interact with the application. Finally, there is Polyjuice, which is right now, it's an Ethereum compatibility layer, but it is really a general computation platform. So right now, we're making an EVM compatible and so what this solves is developers can move their existing returns from our contracts on Ethereum and then seamlessly through this compatibility layer and run them on Nervos. So it preserves the investment they have already made with their application and also just, you know, if they have already done so on Ethereum, this is much faster to market. So let's look at the user stories, right? So from Ethereum users point of view, they are currently today, they're using ETH wallets such as MetaMask and Token to interact with Ethereum. And then when we talk about Ethereum ecosystem, it could be the ETH blockchain itself. It could be layer 2 applications and now they can also, through the same interfaces, they can also work with Nervos, with applications on Nervos. But when they need to work with other blockchains, however, it can be so easy because you see the connection between their interface and other blockchain, there's no direct connection between the two, so they have to be operating on the ETH blockchain and then use another different access point to operate these other blockchains. So that's, you know, they have to go through this route and then to go through other blockchain wallets to operate other blockchains, which is a big hurdle for them. Similarly, if you look at from Bitcoin users point of view, right, so today they're operating Bitcoin with their Bitcoin wallets such as Bitcoin, Electron, and then, so for them, they're operating the Bitcoin blockchain. And then if they want to also be using Ethereum, then they have this another access point, you know, MetaMask or token to operate Ethereum. Now, for any other blockchains, again, they have to install other blockchain wallets. Now, what's special about Nervos is from Bitcoin users point of view, they can be operating Nervos as part of their Bitcoin ecosystem, right? So they can transfer BTCs from their Bitcoin wallets, but they can also operating applications on Nervos directly with their Bitcoin wallets, right? So their universe of Bitcoin includes both BTC blockchain as well as Nervos. So that's for the Bitcoin users point of view. So now, what's even more interesting is it's the user journey for the Internet users, right? And this is, there are much more, obviously, Internet users than Bitcoin or Ethereum users today. So for them, using Nervos as the back end for the economy is really the same as the way they're operating their Internet today, right? So either through their mobile devices or through their browser, they can access Internet, and then through the same infrastructure, through the same interfaces, they can also operate in applications on Nervos, right? So for them, Nervos just complements their existing Internet and brings this decentralized world to Internet. Whereas if they need to operate any other blockchain, they have to go and install a blockchain wallet and then, again, remember, see phrases and acquire some tokens and know how to send transactions and understand the concepts behind it. So let's do a quick review, right? So for Bitcoin users, they come from Bitcoin wallets, and then for Ethereum users, they come from the Ethereum wallets, right? And then these are the blockchain users that they already have their current preferred interface to access the blockchain world. And then Nervos network, Nervos will fit anywhere regardless how they choose to access, right? Either from the point of view of Bitcoin or point of view of Ethereum or any other blockchains. So Nervos will be there and Nervos also connects with all these networks. But that's not really the whole story, right? So there is this much larger base of Internet users, and for them, what we believe the natural onboarding to the blockchain world is through Nervos because Nervos is able to plug directly into their current tools and even future tools, right? So whether it's laptop computers with secure enclaves or mobile devices with cryptographic solutions like these secure chips that they can preserve. It's almost like a hardware wallet within a mobile device, right? So they can directly use their current devices to access the decentralized world through Nervos. So this is what we call the universal password. And then it doesn't matter where you come from and we're able to meet where you are and bring you all these assets from different networks and present them in front of users. So it's for a solution for a fully decentralized world but provide an almost centralized like user experience. So at the last point, even Nervos Network is in the middle but because of Nervos Network's crypto economics, right? So the more users that we serve and the more applications that we have and that will drive the demand for Nervos cryptocurrency and which will make Nervos Network more secure and then make it more attractive as this gateway or passport to the digital economy for all different types of users. So that's the presentation and then for Nervos Network, please come to our website. For a developer, you're very welcome to look at our GitHub and we have included links for all these solutions and we will also have developer focus events in 2021.