problem session, basically our aim in this session would be to see the limitations of the assumptions that we made during the analysis of the oscillators. You recall that our active devices were all very ideal devices, infinite input impedance, no capacitance inside, zero output resistance for some of them for LC oscillators, we could permit a little, a little R0 there. So our problems would be directed towards practical oscillators in which the effects of the transistor capacitances and transistor imperfections can be taken into account. Before we take up a problem there is a small, small circuit that is left to be, to be discussed that was a crystal oscillator. Let us quickly do that then we will go to problem. Crystal oscillator of the Colpitz type, Colpitz type. You know that a crystal oscillator, a crystal is used in when its reactance is inductive, okay, between omega s and omega p, between omega s and omega p. So Colpitz type oscillator uses two capacitors and one inductance and to bring variety into experience let us say we aim at a FET oscillator. Then in an FET you have the R sigma C sigma, the input impedance is no problem, the output impedance you have an R sub D plus VDD. Then what you require is from here to here what you require in Colpitz is a capacitor in shunt then an inductor and then another capacitor. This is the Colpitz circuit, this should go here and this should come here. Now since the crystal is to be used and the crystal is used as an inductor it is this inductor which will be replaced by the crystal. Now where does this inductor appear? Between the drain and the gate and therefore you connect the crystal between these two points. You connect the crystal between these two points, okay. Then obviously you have to use a capacitor, the first capacitor, well you use it to ground, the first capacitor. The second capacitor is to be between this point and ground, okay, between this point and ground. So use another capacitor and to be able to terminate the gate you use a resistance here. Is this resistance essential? Would someone tell me why this resistance is used? Is it necessary for biasing? No, it is not necessary for biasing. It is yes and no. It is necessary because for DC you have to establish this point as zero potential. Now if you leave it open it is anybody's guess what potential it would go to. It might pick up straight charges and go to certain potential. Even if it wants to go, if you provide a resistive part the charge will pass to the ground and therefore this R G is essential in theory no, but in practice yes, okay. So the V G S, V G S is zero minus V S. This is the circuit of a crystal oscillator using the Colpitts type, Colpitts type architecture and this circuit was independently discovered by a gentleman by the name Pierre Sey and therefore this is also known as the Pierre Sey oscillator. Pierre Sey, Pierre Sey oscillator, okay. Pardon me? Oh we can, instead of R D, instead of R D we can use a chip but you know in LC oscillators my source can have an output resistance. It does not matter. It does not affect the operation of the oscillator and therefore a resistance can be used but if you do not want dissipation you can replace this by means of a chip, fine. You can replace this by means of an RF chip. Now these are all very simple circuits that we have discussed in theory. Now let us complicate our life and you will see life is indeed complicated. Even with a single transistor the imperfections cause many problems in the analysis and design. The first problem that we take, question 1, draw the circuit with me. I have not done this circuit in the class because there are hundreds of varieties of circuits. I thought some of them I will use to illustrate, illustrate how a practical oscillator is analyzed and designed and this is the first problem that I take. Draw with me. There is a transformer, 2 coupled coils and the turns ratio is N1 is to N2. This is N1 and this is N2. This, the primary of the transformer is used to form a tuned circuit with a capacitance, let us say C prime. There is a reason why I am using C prime. You will see later. This acts as the load of a transistor and therefore this is plus VCC and this terminal goes to the collector. The transistor is a common base, common base circuit instead of a common emitter. You see the variety of oscillator circuits that exist. The emitter is connected to the secondary and in addition for biasing you have an R sub B and C sub B which goes to infinity. It is very large. It is a bypass capacitor and in addition what else do you require to bias the transistor? Q. I have shown a PNP. This is not necessary. You can use it an NPN. What else is necessary for biasing? Pardon me. I must have a resistance between the base and the power supply. Let us call these resistances R1, some R1. Is that all? That is all but usually a resistance is connected between the emitter and ground also. RE which is usually chosen to be much higher compared to RPI. You see RPI will come in parallel with RE, is not that right? RPI from base to emitter will come in parallel with RE and therefore in order that it does not load unnecessarily we usually make RE much greater than RPI. This circuit does oscillate. It is not very easy to see how this circuit oscillates but obviously feedback is applied through a transformer, through magnetic coupling, through a transformer and the transformer winding, you know the meaning of the dots that the potentials of these 2 points rise and fall simultaneously. In other words if this goes up then this also goes up. So there is positive feedback. There is positive feedback in the circuit and it does oscillate. Let us see how it oscillates. The question is to analyse this circuit for the frequency of oscillation and the condition for oscillation. Now obviously the first thing we do, I have told you that in oscillator analysis you do not have to identify the A circuit and the beta circuit. You can simply draw the equivalent circuit and see what condition is to be satisfied in order that the input voltage is V pi when the output voltage is g m V pi multiplied by the load. So you just draw the equivalent circuit and oscillator analysis is eased out. Let us see what the equivalent circuit is. Now you see let us take the point E, C and B. B is grounded for the transistor. Between E and B there is a resistance R pi and this voltage is V pi. Do not make a mistake about the polarity. This is V pi. Polarity is B side is positive and emitter side is negative. Between C and D we have g m V pi. It is a common base circuit so the g m V pi is drawn horizontally. There is no reason why you could not draw it otherwise. Then you have at the collector between collector and ground you have the capacitance C prime then the inductance L with this polarity and you have another secondary whose dot is here and this couples to the emitter. In addition you have a resistance R E to ground. Now we have ignored several things in this equivalent circuit. R B C B combination is short so we ignored that completely. We have ignored the transistor capacitances. Since this is a high frequency oscillator transistor capacitances usually cannot be ignored. In other words I must include a C mu first, C mu from collector to base and therefore C mu can add to C prime. Is that clear? C mu is from collector to base therefore it comes in parallel to C prime. So C prime plus C mu alright. C mu is taken care of. Then R pi, R pi appears between this point and ground. I am sorry not R pi, C pi, C pi. This also should have been taken into account alright. Now then is then is the question of analysis. You see whatever the connection here whatever the connection at the emitter terminal, the voltage output V0 appears across this parallel combination of C prime and L due to a current g m V pi passing through this and therefore I do not care where g m V pi goes. I do not care. My V0 would be simply the this current multiplied by this impedance which is not not quite correct because the because of the transformer there is a reflected impedance and that is how this termination comes into effect alright. So let us say let us say R E parallel R pi. Let us not neglect completely. Let us call this as R pi prime. We will neglect it later whenever necessary. Since we can take care of it it comes in parallel with R pi why why ignore the poor fellow right at the beginning okay. Let us call this R pi prime. Then you see as far as the collector as far as the collector is concerned, this ratio was N2 is to N1 alright. N2 is to N1. It was N1 is to N2 from the other side. So N2 is to N1. Now what does this the primary sees? What does the primary see by looking into the secondary? There is a reflected impedance and the reflected impedance would be resistance would be multiplied by N2 by N1 squared and the capacitance would be divided by N2 by N1 squared and therefore as far as the collector is concerned, my equivalent circuit is g m V pi. Let it go to ground. I do not care wherever it goes. Then a capacitance. Now what will be the total capacitance? C prime plus C mu plus the reflected capacitance. What is the reflected capacitance? C pi by N2 by N1 whole squared okay. So C pi N1 by N2 whole squared. Is that clear? Let us call this capacitance as C. Then we have the resistance. What is the resistance? R pi into N2 by N1 whole squared. Is that clear? R pi prime. That is right. N2 by N1 whole squared and you have finally the inductance L which is coupled to another inductance with this polarity. Now what should be the condition of this terminal? Once you have taken the reflected impedance, this should be open and this voltage would be V pi with what polarity plus minus. Is that clear? Okay. What I did was I wanted to calculate V0. So I look at I look at this transformer. This transformer reflects a certain impedance into the primary. I have reflected that okay. So the the amplifier circuit, the amplifier circuit consists of g m V pi passing through C prime plus C mu L and the reflected impedance. So I have been able to calculate V0. Then V pi appears across the secondary. V pi appears at the secondary and the secondary should now be such that there is no reflected impedance. Obviously the secondary is to be open because I have taken care of the reflected impedance alright and it is with this polarity. Pardon me? Which one can be short? If it is short then there will be short reflected here which means that V0 will be also be short, agree? It is only infinite impedance reflected as an infinite impedance. Yes. How is g m V pi going to ground? How is it going to ground? As I said I do not care where it is going. It has to come through this impedance. I am calculating as far as my calculation of V0 is concerned this circuit is good enough. I do not care where it goes. I can leave it empty if you so desire. It goes somewhere but it has to come through this combination okay. Now I also know because of the transformer ratio, N2 is to N1, I also know that V pi should be equal to this is V0. V pi should be equal to minus because the polarities do not agree. N1 by N2 times V0, agree? What about the coupling? I have taken care of that. Oh we assume that it is ideal, 100 percent. That is right. Sir but that is well only when the current through this load, ZL? Once I reflect the impedance the current can be put equal to 0 in the second wave. No but that is well only when the current is only because of the secondary current. Here the current is not going only because of the secondary current. It does not matter. There is a current here. There is that through the load. It does not matter. This current goes through the load. Now the load I have reflected into the primary. Therefore the secondary can be left open. No, no current in the secondary because the effect of the secondary current has been reflected already. I am not saying that. I am saying that when we reflect this impedance and multiply by other turns ratio square. Right. That we do only because the current through this load is because only because of secondary load. No only. You see so far as if there is a load R here RL and the turns ratio is N is to 1 then this is equivalent to a simple resistance N square RL in parallel with a transformer whose output is open. As far as this side is concerned this is a perfectly valid circuit. Sir what if there is another DC or say AC connected to RL secondary? Oh, that is a different story. So here that is what is happening because... There is nothing connected. The current g m d pi is also adding to this load. Oh, that does not matter. How does it matter? Between this point and this point whether a current is coming or not the impedance is that of Rbe, Rpi, Cpi. Impedance does not change. Whatever the current I do not care. Okay. Think about it it should be clear. Now therefore my equation my equation for oscillation should be this is Vpi and my V0, V0 should be equal to minus g m Vpi divided by the admittance of the total combination that is j omega C plus 1 over j omega L plus Rpi prime N2 by N1 whole square. Agreed? That is my V0. g m Vpi passes through this. That is my V0 and Vpi, Vpi is minus N1, N2 by V0. So substitute Vpi here then cancel out V0. You get a certain relationship between the coefficients. And obviously that can be satisfied. Let me write this relationship. 1 would be equal to g m N1 by N2 divided by j omega C minus 1 by omega L plus Rpi prime N2 by N1 whole square. Okay. I have made a mistake. Alright. Now obviously this can be satisfied. The right hand side should not have any imaginary part because the left hand side does not have one and therefore the frequency of oscillation is 1 by square root LC. This C you must remember is not simply the external capacitance. It is supplemented by C mu and Cpi N1 by N2 whole square. Okay. External is the external inductance. That is used in the primary of the circuit. Now if this is so then obviously what we require is that g m N1 by N2 multiplied by Rpi prime N2 by N1 whole square. This would be the condition. This goes to 0 and this comes up and therefore this is the condition that I mean. Which means that g m Rpi prime should be equal to how much? N1 by N2. Now g m Rpi prime is RE Rpi divided by RE plus Rpi. This should be equal to N1 by N2 and if RE is much greater than Rpi by design then obviously beta should be equal to N1 by N2. In other words the terms ratio of the transformer should be equal to the beta of the transistor. Yes. Oh analyze the circuit to find the conditions of oscillation. Then I can give some numbers in terms of the circuit parameters. We require to calculate the frequency of oscillation. Okay. Now this problem was not too difficult. Let us next come to a difficult problem. More difficult problem. Although it looks simple. Simply says analyze the Colpitt's oscillator circuit shown below. Taking account of transistor imperfections. The circuit, this is also revealing what kind of circuit one makes in practice. Instead of a resistive load one uses an RF choke, RFC so that there is no DC dissipation. Then you have the transistor RE CE. CE goes to infinity. It is a Colpitt's circuit. So you have let us say a C1 prime, then an L and a C2 prime. You will understand why I am using primes because they are supplemented by things and then this goes to the base. Do you require a capacitor? Yes you do. You require a CC which is very large. You require, otherwise this DC will pass to the base. The circuit is not complete. You require the base biasing and the base biasing is done by 2 resistors, RB1 and if you want to conserve, no, if you want RB1 and RB2 not to load the transistor then you use an RF choke. Otherwise you do not. Usually RB1 and RB2 parallel combination is much greater than R pi and therefore that can be neglected. RB1 and RB2. The question is to take care of all possible imperfections of the transistor and analyse the circuit. In the usual analysis in the class we had ignored all those imperfections. Okay. So the first thing we do is to draw the equivalent circuit and now the real problem starts. RB2 should be grounded. I beg your pardon. This should go off. I beg your pardon. Please do correct the circuit. RB2 should be grounded. It is not connected to CC. Okay. Now let us draw the equivalent circuit. The equivalent circuit starts with RB which is RB1 parallel RB2. Then an R pi in parallel with C pi, C pi then you have this voltage is, I beg your pardon, V pi. This voltage is V pi plus minus, a gm V pi goes to ground. The RFC poses no problem. It is infinite impedance. We ignore that. Then we have the C1 prime L and C2 prime. This goes to this point and one thing that we have not drawn in this circuit is this minis of C mu even though it is a small value. Now C mu complicates the problem of analysis because this is a coupling between, if we call this as V0 between V0 and V pi. We cannot isolate the 2 circuits. There is a connection from here. There is also a connection from here. Now can we use miller effect? Please do consider. Please do listen to me very carefully. Can we use miller effect? You see the load here is not resistive. So that C mu 1 plus gm RL that will not work. Agree? The load here, the load that it sees is not resistive. In the miller effect we always had a C mu, the miller capacitance reflected was C mu 1 plus gm RL. It is not RL. It is no longer RL here. But there is a saving grace. The saving grace is that at the resonant frequency, at the frequency of oscillation, you see this is not a wideband circuit. It has to work only at one frequency. And at the oscillation frequency, at the oscillation frequency these will resonate and what will be left is a parallel combination of RB and R pi. Is that clear? If the circuit oscillates then between this point and ground the gm V pi source shall see a resistance because the condition for oscillation is that the inductor should resonate all the capacitances that are present in the circuit. Otherwise it cannot oscillate, okay. So approximately, approximately you can replace C mu. This is approximate. It will not give you an exact solution. I will come to the exact solution later. But you can you can ignore the effect of C mu by including a capacitance here which is equal to C mu then 1 plus gm R pi prime, agreed? And in addition C mu shall also come in parallel with this. So there is a C mu here. Yes? At the oscillation frequency, what this source sees is an anti-resonant circuit. Anti-resonant circuit C1 this capacitor in parallel with an inductive reactance which cancel each other, okay. And therefore what will be left is what will be left is this resistance R pi parallel R B. This is what it will see. You agree? No. This is not correct because gm V pi does not see the resistance across this. It is not a pure C L R. If it was so it could have. Is the point clear? No sir. I have been arguing wrongly and I am waiting and pausing after every sentence nobody objects, okay. From here to here what this current source sees is not a pure resistance because the resistance is here. It is not a parallel LCR circuit. If the resistance was put between this point and ground, yes I would have agreed. But it is not so. It is after the inductance. You see what I am seeing is the following. What the current source sees is a capacitance, then an inductance, then a capacitance and a resistance, okay. So what it sees here at resonance is not simply this resistance. Agreed? It is not this resistance only. It sees C in parallel with L plus this RC combination. That has to resonate. It does not mean that this input impedance will be this resistance. Nevertheless the input impedance would be resistive and that resistance has to be calculated. It is not simply this resistance, okay. So while in theory the procedure would be correct, the reflected Miller capacitance is not this. It would be something different. C mu 1 plus gm let us say r pi double prime, effective impedance seen by gm r pi, gm v pi. Do you see the problem of analysis? And then C mu has to come here. If I do this, mind you this is approximate. If I do this, then my equivalent circuit becomes simple. What I get is the following. We have to include C mu, C 1 prime, C 2 prime and C pi. All of them, okay. Then my equivalent circuit becomes the following. I get gm v pi. You understand the simplification. Even with the simplification it is an it is an approximate analysis. I will come to the exact analysis a little later. What I get is gm v pi, C 1, then an L, C 2. Now I have removed the primes. C 1 now is C 1 prime plus C mu. C 2 is now C 2 prime plus C pi plus Cm, the Miller capacitance, okay. And that comes across r pi prime and this is my v pi with this polarity plus minus. Now you analyze the circuit. You analyze the circuit and obviously you do not write loop equation or node equation. You make a Thevenin source here. You make the equivalent of a Thevenin source here and then it is a one potential division which gives you a single equation giving the frequency of oscillation and the condition of oscillation. I would skip this algebra. It turns out that omega not squared. Can you tell me what omega not squared would be? 1 by L, C 1 C 2 divided by C 1 plus C 2. It is the series resonance of these 3, okay. And the condition for oscillation is that gm r pi prime is equal to C 1 by C 2. gm r pi prime equal to C 1 by C 2 and if r pi prime is approximately r pi then you see that beta has to be C 1 by C 2, okay. This is approximately equal to beta. I would skip the algebra. If it is not so, if Miller effect is not acceptable, you see these results obviously will be quite away from what the exact results are because it was based on the assumption that the shunting effect or the bridging effect of C mu could be removed by using 2 capacitances, one at the input and one at the output which is not quite true because the gain is not purely resistive. We consider the gain only at omega 0 at that frequency. How does the exact circuit differ from this? Isn't it only in the inclusion of a capacitor here across L which is similar, right? So all this approximation was not really necessary. It does not, it does not give you more complication than what you did in analyzing this circuit. Instead of L, instead of L, it would be g omega L 1 minus omega square L C mu. Is that clear? Yes. Can it be said that I have evaluated minus of C mu in parallel to this?  Where was C mu? C mu is between this point and this point. Now this point is the same as this end of L and this point is the same as the other end of L and therefore all this fuss about C mu and all this care about C mu was not really necessary but it creates complications. Having a C mu here, having a C mu here, obviously my C 2 will now be, can you tell me what is C 2? C 2 prime plus C pi, that is all. Nothing else, okay. And what is C 1? C 1 is simply C 1 prime. I am not including C mu, all right. If I include C mu here, then obviously these are the values. And in the analysis, all that you have to do is, first you apply Thevenin's theorem here, then you write a single potential division equation where you wrote J omega L, now should be replaced by J omega L divided by 1 minus omega squared L C mu. So it is not too difficult. What is difficult is that the condition of oscillation will now be of what order, what would be the condition of oscillation, what order? In the previous case, there were 3 reactances, L C 1 and C 2, so the degree of the denominator would have been 3. Now the degree would be 4.  This is the Thevenin equivalent. It does not matter whether it is resistance or capacitance or inductance. Thevenin equivalent is multiply the current by the impedance and put that impedance in series, okay. So the condition of oscillation now shall be, shall contain in the denominator a polynomial in omega, to be precise polynomial in J omega and in the numerator a polynomial in J omega. And what you have to do to find the condition of oscillation is to make the phase of the numerator equal to the phase of the denominator, okay and then find out the magnitude. After you cross out the phase what remains? That would be equal to 1 and this is a little bit of algebra. It might prove slightly difficult but if numerical values are given you should be able to solve it, okay. I would not go into that discussion. The final circuit, final problem that we discussed in this session is the following. The question is can, I do not know if you know the answer to this question, can an emitter follower be used, a single emitter follower be used to generate sinusoidal oscillations? You know the answer to this? Is the answer yes or no? The answer is yes, okay. Now how? A emitter follower has a gain slightly less than unity, okay. Emitter follower has a gain slightly less than unity. Emitter follower has a gain slightly less than unity. It is beta RE divided by, it is 1 plus beta RE divided by r pi plus 1 plus beta RE and since 1 plus beta RE is much greater than r pi it is approximately unity but it is always less than unity and therefore the beta network, I should not use beta HFA, the beta network that you should use should give a gain slightly greater than unity but a phase shift of 0 degree, okay and that network can be derived very simply. You recall this network, okay, R, R, R, C, C, C. You know that if this is VI and if this is V0 then V0 by V0 by VI is equal to minus 1 over 29 at omega 0 equal to 1 over, yes, what? Route 6, RC. This is the phase shifting network. Instead of CR I have drawn RC, okay. If that is so then you consider this voltage, V0 prime. What is V0 prime by VI at this frequency? You see VI is equal to V0 prime plus V0. Therefore V0 prime by VI is equal to 1 minus V0 by VI which means 1 plus 1 over 29 which is 30 by 29 greater than 1 and the angle is 0 degree, agree? Is this okay? So all that we need now is to use an emitter follower. Now let me draw the circuit. Without any more ado, VCC you have to have a blocking capacitor. No, I beg your pardon. Do you require a blocking capacitor? No, you do not. That is what it is. The voltage is from output is from here to here and this output is 30 by 29 times this output. The gain of the emitter follower is less than 1 and therefore the product can be equal to 1, slightly less. Do I require a blocking capacitor? I do not because there is a capacitor here but I do require a biasing arrangement. Do I require this resistance? No, 3R should take care of it. Yes, I know you are going to ask that question. Which minus sign? Yeah, what is your question? No, this is 180. V0 by VI is 180 but I am taking the output here which gives me 0 phase shift. It is a very novel way of designing and you see in an emitter follower many things, many imperfections are taken care of. R pi C pi and many other things. You can include R pi C pi and see that it does not change substantially. You can always choose your capacitors and resistors in such a manner. Even this resistance is not required because 3R takes care of it. It is a very simple oscillator. You can quickly wind it up in the laboratory and see. By putting the power supply on, you see beautiful oscillations. We will meet in another 10 minutes. We will take a break now, meet around the 10 minutes.


Welcome. Thank you all for coming. We're ready to get started. Good news. We've actually got a two for one today. We're going to walk through delivering an application on a platform. We'll talk about platforms and operators and the like. And we're also going to use this opportunity to introduce you all to tag app delivery and what we do and how you can contribute. Before we start, I just wanted to ask if you could raise your hand. How many people here have read or referenced the GitOps principles? Nice. Nice. And how many people have read the operator's white paper or referenced it or used it? Okay. One last question. Who here is title or is part of a team that's called platform engineers or platform team? Okay. I've got quite a few of those. Well, the reason I'm asking is because actually the GitOps principles, the operator white paper and right now we just released the platform white paper. That's come from this group the past two or three years. So thank you for benefiting from our work. We hope we benefited you. All right. So let us now introduce ourselves. My name is Josh Kovant. I am a solution architect with Red Hat and one of the technical leads for tag app delivery. Yes. Hello. My name is Tom Schütz. I'm Tech Lead of the CNSF Tag App Delivery. Furthermore, I'm a consultant, educator, CNSF CDF ambassador and whatever. And just happy to meet you all here. Hello. I am Jennifer Stradewicz. I work for Canos and I'm a co-chair of the Tag App Delivery. Very happy to be here. Just a quick run through of the agenda already mentioned by Josh, but we are going to just talk a little bit about our tag, the mission and a few updates. Josh is going to go through the platforms, the work with the platforms white paper. I'm going to go through a bit about operators and some of the changes in the landscape in the last couple of years. And we'll end with Thomas talking about what is a cloud-native application and trying to define that. So who are we, right, if you have heard of us? We enable, we help end users and projects by providing some unbiased feedback and also onboarding new contributors and matching, like, trying to help both sides. We provide some advice on projects that want to join the landscape, the CNSF landscape, sandbox or incubation. We also provide some materials like white papers for people who want to get onboard onto the open source world and the cloud-native. We also help facilitate working groups, creation, and by providing some structure and helping form them as well. So one of the working groups that we have is the platforms. We had the operators working group, which was short-lived. Throughout the time we created the operator white paper. We are trying to get a new version now, so it's coming back. A new working group that's coming is Artifact, and we also have the GitOps working group. I'll hand it to Josh. Thank you. All right, so I'm going to start off by talking about platforms and showing an application deployed seamlessly, quickly, flexibly, efficiently on a platform. I put this picture because when I think of platforms, I think of people supporting each other, being able to build on the shoulders of giants. So here you see how high one person could get when they've got a lot of other people helping them. So we're going to talk about what exactly a platform is, or at least the opinion that we've put in the paper. And how they can help with that development, a little bit about why. I'll show you a demo, and then maybe we'll go a little into the capabilities and attributes. So what and why? Yeah, so in the consensus that we reached working on the paper was that a platform consolidates, brings together a collection of capabilities that an application needs in a consistent, coherent, directed way based on the real needs of the user of the platform. So for example, in the cloud-native world, bringing together observability services, database services, event buses, artifact management, all these different things that need to come together for your application to work, the platform provides consistent interfaces and consistent ways to get at them and also to integrate them. Let's not leave that out. Part of the purpose of the paper that we wrote, and I want to talk a little about why, is that we wanted to enable platform engineers or leaders of platform engineers to convince their enterprise, like, look, if you want to move forward with cloud-native development and really maximize the value of it, you should adopt this platform model. And so we put a lot of whys in there, too. Some of them include, I mean, I'm sure you've heard the term cognitive load, make it easier for your app developers to focus on the task at hand, the business logic at hand, and not all the collection of stuff that's underneath. Instead of having many, many teams building that full stack underneath, dedicate a team that becomes a set of experts on this, becomes much more resilient, reliable. We mentioned sharing. If you have a common platform, it becomes much easier to share code, to share knowledge, to share people even. It's much easier to switch teams. It reduces risk. This kind of is reflected in the kind of funnel shape here. There's a choke point here for all the code going into production where you can apply policies, you can apply security checks, you've got a little bit of control. And it also enables, a lot of times, this bottom layer, you might think it's data centers that you maintain or something like that, but could also be cloud providers. But you can't just, I mean, maybe you can. A lot of times, you can't just throw out cloud services and say, oh, use them. You need to provide a consistent way that fits in your enterprise. So it also enables you really to better use all of the software as a service and provider capabilities. So tell your CEO that. Yeah, so here I just wanted to illustrate, here's all that platform stuff that we illustrated before. Here I put, actually I built this app a long time ago, but it's a typical logical diagram of all the components that have to interact in a cloud-native app. And interestingly, and I think I mentioned this in the last slide, it becomes distributed. I mean cloud-native and distributed are pretty closely related. But I like this because it kind of shows you, I didn't want to draw lines because you would never be able to even see this page, but it kind of shows you how all of these pieces get pulled into an app and integrated. So with that, I wanted to show just a quick example of, this is just an API service. Let me see if I can get it to come on over. Come on over. Oops, must be going the wrong way. Sorry folks, there we go. Yeah, I wanted to give an example of a set of capabilities, making up a platform and then an app writing on top of them. So let me just make that a tiny bit bigger. So I'm first to show you the end result, actually, which is just a widgets API. I'm sure that's hard to read up there, but it's just hostname slash widgets and it's just returning a list of widgets that I inserted. That's the end result. But it's using a database. I could actually show you it's got Yeager tracing established on it. It's using a bucket for some stuff. It's got a certificate. It's been deployed by Argo CD by GitOps. Forgive me, I'm using OpenShift here, but it's operator lifecycle manager behind the scenes, which is part of operator framework, which is allowing all these operators to be quickly installed. So I've installed a database provider. I've installed distributed tracing, a couple of different parts, which gives me open telemetry. I've got Minio, which gives me buckets, search manager. So this is kind of my platform in this case, my capabilities. And this gives me, remember, we said that consistent coherent interface, these are all just Kubernetes manifests. So I've got a build. This OpenShift has a built-in build controller, so that wasn't in the list before, but I've got a build. I've got a certificate. I've got my configuration. Images is a way OpenShift stores. So that's my artifact storage for my images, instrumentation gets me open telemetry installed, PGDB. I'll just open one of them for easy. I mean, I don't have to go through all of them, but look, that's the simplest of things. And then, of course, there's a customization, and it all gets deployed out by, and Thomas is going to talk more about this, but here's an application YAML, and that kind of expresses, pick up all that stuff, put it into the cluster. I've already done it. I'm not going to do it right now, but here's that entire application, or actually the core code. I didn't even show you the code of the application. It's in another repo. But here, I've just, with that set of manifest, deployed the application, integrated all that capability from the platform right into it, and there we go. Much easier than having to build that whole thing from scratch. Let's close that out. So the next step that I probably would take with this app, if I was building a platform, would be to templatize that, and say, oh, you're looking to build an API server, and here's a standard framework for all the components you're going to need in your API server. That's also an important part of a platform, is templates. The last significant thing I wanted to go over, in the paper, we have functional attributes, or functional components that you might want to consider for your platform. Here, these are the non-functional ones. We really want to emphasize, and we really want to help you all, and we're working on some stuff for that product mindset. You've got to really emphasize with your app developers and understand what they need, and try to understand if what you're providing meets those needs and iterate with them. That kind of fits in with the next one, developer experience. Your core is to let those platform users have a good experience. Documentation, self-service. Things should be automated. I can click and get it as much as possible. Reduce cognitive load. You want to abstract and encapsulate as much as you can. Optional, there's always going to be people that want to go around. Composable, and of course, secure by default, like we mentioned. The last one of my slides, I don't have a timer here, but I hope I'm not taking all of Jen and Thomas' time. I'm not going to go through all of these. Actually, this is what's listed in the paper as capabilities to consider in a platform, so people have been looking at these. It's got some synergies with landscape, and we're going to be talking about that with them. A lot of people had eyes on this, and we felt this represented the things that you should look at and think about, including in your platform. With that, I'm going to turn it over to Jen, and she's going to tell you about operators. Thank you, Josh. Hi, everyone. I'm going to talk quickly about operators because they aid platforms and applications. As you know, in Kubernetes, the primitives like deployment, pods, and replica sets, they are operators behind the scenes, and the operator pattern and operators came to provide developers and platform engineers with ways to customize that, create custom resources, and controllers to manage those resources in the same way as you do manage like a deployment or something. That abstraction also allowed for platform toil to be reduced with the same kind of automation as you would do for application lifecycle management. Also, these operator patterns over the years have evolved so much that they matured beyond Kubernetes itself. Just quickly going through basic operator reconciliation example here diagram. It's on the operator white paper as well. You have your business language, your business domain knowledge that you apply into custom resource that you create for users to declare based on your needs. You then implement a controller, implement a watch that will be watching this resource and matching it against the current state in the cluster that's going to take actions, apply changes to reconcile those. You also will report to them. My view on this is that the operators make platforms more product-like, as Josh mentioned with the platform capabilities. You think of it as a product because that allows you to develop ways and to provide a foundation for creating portals and the CLIs so people can consume that in a more product way, I'd say. One example of this is, let's say, a user journey that could be is like a developer trying to consume a database, create a database. I will show you an example of cross-plane, for example, which uses leverages, CRDs and controllers in order to provide a couple of personas in this case, for example, a developer has only to concern, has lower cognitive load, like Josh said, on just concerning themselves with their knowledge about the application and on the infrastructure side, all they need to know is what kind of database they need. They just need to worry about designing the database so they decide that they need a NoSQL, they decide about the performance they need and the size, for example. So the cross-plane provides a way using operators for you to declare your ubiquitous business language, I'd say, via customer resources. And then the other persona, the operator here, which would be your platform operator, will then declare their business policies and ways that what means a fast database and, for example, a provider could be a cloud provider, could be on-premises APIs. So it's totally abstracted from the developer these details that the operator would be concerned with. Next. So another thing that is also available on the operator white paper, it's some of interesting operator patterns that have emerged over the years and one of them that I'm going to talk about quickly is this operator of operators, which is basically an operator that's concerned with managing other operators that have other concerns. So for the user that consumes this operator, they are seeing just one, but in fact, in the actual implementation, it's other operators that are being installed by those and being managed by this meta operator, let's say. A few popular operator frameworks you've probably heard of since you answered Josh's question in the beginning. It's CubeBuilder, the operator framework. Interestingly, there is a few, with the landscape changes now, there are some emerging operator frameworks that you couldn't read about as well. It's like Metacontroller, which again is similar to the idea before, but it's just a way to create those Metacontrollers as a service. And also there is Juju, that's a model-driven operator framework that is catered for more enterprise use cases, multi-cloud, and actually transport the operator. It can create operators outside of Kubernetes, not using the same reconciling patterns. So it's just quite interesting, you should check out. And yes, I've been talking about the operator white paper quite a lot now, and we have made some changes since the publication, which was in 2021, the first version, but as you may know, like for example, GitOps was like 1.0 version, and lots of changes have happened, and we added a few more things in there. It's constant changing, but I would like to call you to tell me your story about your usage of operators as well, and either talk to us through in the meetings that we have by monthly and also on the Slack channel, and also you can submit a PR on our GitHub. And yes, so the Slack channel, and take a look at our blog that we made, Tom is going to show a bit more, but we have a new website, very nice. Please, I will hand to you then to talk about applications now. Thank you very much. Thank you, Jennifer. Yes, I can only encourage everyone of you to contribute to such white papers or whatever. For Jennifer and me, this was the way into the tech, and it was very much fun to work on such a white paper. So, yes, as announced previously, I will talk a bit about applications, and as I said before, I'm a teacher. So, who wants to tell me what an application is? Well, has anyone an opinion of it? No. A collection of services that provide business or end-user value. Thank you. Another one. An executable. Okay. Jarek? Yeah, so I would say there's not one definition of application, but from a business perspective, it could be a set of services that serve one business stuff, whatever. Okay, thank you. As you heard now, it was a bit of an easy example. Normally, when you talk to three people about applications, you get five opinions. And I think the same is about applications in the Kubernetes environment. So, at the moment, at least in my opinion, not a really clear definition of what an application is. So, in the first step, I just want to show a bit how cloud-native applications are described normally. So, sorry, there's too much light. So, we have an application. An application could consist of one service or multiple services. So, in fact, the application is more or less a boundary for a thing which fulfills a business purpose. In this application, the services should be able to scale independently. So, when we find out that one service is overloaded or whatever, we should be able to scale it alone and not have to scale all of them. And finally, we could describe that the infrastructure and the configuration can be seen as part of the service. So far, so good. So, that's what I understand as a service. As an application, sorry. And now, so we talked a bit of what is an application and you might ask yourself, what is the problem now? At first, we are living in a cloud-native world and all of us are thinking that services should be always developed and tested individually. That's the thing we read in the books. In fact, it's always different. So, there's a lot of applications out there which are more or less micro-monoliths which are tested, developed, and so on together, which are multiple services, but only work in a certain version combination. Furthermore, when we deploy things in Kubernetes, we know that our workloads are running. We know that they are most probably in the state we defined somewhere, but we never know when the application, the deployment is finished. So, there is no resource at the moment in Kubernetes which tells us in which state the application is. The same is there for workload and application health checks. So, we always know that the workload is running technically. So, we define somewhere in our manifest that we want to have three replicas, we want to have resource limits, resource requests, and so on. We know that we want to have these environment variables and maybe we have some health checks which help us defining if our application is somehow running or if our service is running. But in fact, these are only scoped to the services. We don't know if the application is running.  So, there are application definitions out there. But if we have five application definitions from different vendors, we don't know how to switch between them. So, some weeks ago, I said down a bit and investigated a bit about application definitions and I will show you some results afterwards. But at the moment, there are about three types of application definitions. The first one, our application definitions were the whole application. So, all of the deployments, services, and so on are defined in one resource. This is, for example, in Open Application Model and in QVilla. The second ones are the types of application definitions where a source to the, where a reference to the source is stored in the resource. Many of you, I think, know ArgoCity. This is one of the things where we simply reference to a git repository, but we don't have single resources defined. The second one I found here was cover and cap. The third one is an application definition where the reference to objects is stored in the resource definition. And this is how cap operates at the moment. Okay, so, as I said before, some weeks ago, I said down, I took our demo application, the Potato Head, and tried to deploy it with various application definitions. So, just out of curiosity, Potato Head was a demo application which was created for KubeCon NA, I think, 2021, 2020. And what you're seeing here is an application which consists of six services. So, the body of the Potato Head is one service. The left arm is a service. The right arm is a service and the same for the legs. You can put arms up and down and so on. And this is also a thing which is done in the tag app delivery. So, what we are doing in the tag is not always very, very serious. But I think this is a very, very funny example of funny work you could have in a tag. Okay. So, this was Josh's entry point. Okay, so then let's take a look on the first application definition. This is, what? Where are we? Sorry, I'm not used to working with this. Okay, so this is a typical application definition of AgaCD. We see that this is an application. This is called Potato Head. Yes, and so on. The interesting part of this is we only have a reference to a kit repository which tells us that everything what's there in this kit repository is the application. But we don't know from this definition how many workloads we have, which configuration we have, and so on. In the second example, this is for the open application model which is used by Cubila. And there we see the application is defined in a very different way. In fact, this is also an application only with a different API behind it. But what we see in this definition here, we have all of the components in there, such as front-end service, as in left-arm service, right-arm service, and however they are called, we have all of the environment variables, all of the configuration, and so on and so on manifest. It's also a very valid way. And in the third case, we have the captain way, we always simply have references to such things. So in this case, the deployments and so on are simply annotated with a name and a version, and the application manifest simply puts down all of them together. So as you see, we have three tools and three different opinions. And there is at the moment no way to switch between them. So to get back to the slides. And this is where we are at the moment. So the whole application definition topic is a very new one in the tag at the moment. And this is a question I have to you. Is anyone interested, has anyone such problems that you don't have standardized application definitions and would need one? So it's a good idea to do this. Okay, so if you were afraid of raising your hand, and you are interested in this topic, just feel free to reach out to us. And if you know more than the definitions I've showed you until now. So these were only three examples. I have two, three for another one. You can always provide examples for the potato head. So this was the initial thought of the service to showcase how such application departments could look like, how such scenarios could look like, and to always have them testable. What we want to get out of this application, of this whole application were things. Maybe a proposal for a standard, maybe we could provide some new project out of this and so on. We only also want to create blog posts so we started a few months ago and a white paper and a working group. And as I said before, we want to provide some examples. Yes, this was the application part now to wrap this up a bit. Some weeks ago, a member of the tech was so nice and started creating a website for the tech app delivery. This is there on the tech app delivery since the FIO. And what you can find here are all of the white papers we have created all the blogs and so on. You can also find meeting times. And the nice thing of this, with this white paper section here, we could change our white papers to a more or less rolling reads model. So we can update them in place and when you are looking at the white papers there, you always have the newest version. And some of you might ask or might not ask what you could do for the tech. And the first thing would be if you have use cases, experiences and so on about cloud native application delivery. We are really glad to hear this. So the things we are doing there should not be academics. They should help you. They should help other end users but also our project to involve. So if you are doing cool things just get in touch with us and you can always show this in some of our tech meetings. You can always visit our website and read our white papers. You can always provide examples to the potato head and you can support the tech in its technical domains. But at the moment, we have the, as we said before the platform's working group, there is the work on the operator white paper. We might want to do something on UCI artifacts and applications and so on. So there is enough work for everyone if someone wants to work something. Okay, so I think this was it from our side. Thank you for being here and have a nice rest of the CubeCon. Sorry, are there some questions? Kind of combining both topics with the operator and app delivery. So if you don't have access to the operator life cycle manager, is there any type of push to treat operator or what's the reasoning behind the operator life cycle manager? If you don't have access to one can you just use your typical app delivery means to deliver operators? Yeah, actually I have a repo full of operators and capabilities that I add into my clusters and one of them is a home chart, one of them you download a CLI tool and you run it, one of them you run a special, like in certain clusters you'll run a special add on add. So the advantage of operator life cycle manager, and you can install it in any Kubernetes as part of operator framework is that it gives you a marketplace and gives you a way to, the way it works is you create a subscription and then it will install it for you. So if you discover and install operators the other option would be just find each individual one it says install the home chart do it that way so that's the advantage of, I think it's something to think about like some consistency across clusters and that, but yeah operator life cycle manager is one option. Does that help? Thank you. Any other questions? Alright, well we're here for the next couple of minutes. If you want to talk and thank you so much. Thank you.