Analysts are calling it a landmark anti-trust case. Opening arguments have begun in the United States Department of Justice's suit against tech giant Google for monopolizing internet search for what it says is over a decade. What can we expect from the biggest anti-trust trial against a big tech company ever? Kim Jong-un, the leader of North Korea, is in Russia for a meeting with Russian President Vladimir Putin in the Far East of the country. Why is the Western press paying so much heed to a meeting that is not unprecedented by any means? And what to Russia and North Korea hope to gain from it? That's the lineup on today's episode of The Daily Deepest. These are the questions we'll be asking our guests and reporters on the show coming to you as always from the People's Dispatch studios here in New Delhi. I'm Siddharth Ani and if you haven't already before we get into it I'll ask you to like and subscribe to the People's Dispatch YouTube channel. First up Google and its parent company Alphabet make upwards of $160 billion in advertising revenue a year. A new anti-trust case mounted by the United States Department of Justice as well as 38 states and territories argues that the company in fact used unfair as well as restrictive practices to create a monopoly in the Internet search space by signing contracts with original equipment manufacturers on both the Apple as well as Android platforms spending billions of dollars to ensure Google was the default search engine on their smartphones and other devices. Some sources indicate that as much as 90% of all searches on the Internet at least in the United States are done through Google which allows the company to profile users, target ads as well as set ad rates themselves. It makes therefore billions of dollars while also building a fortress that keeps competitors out. It's the heavyweight trial of the century and a reminder of another landmark trial against Microsoft a quarter of a century ago which set the legal precedence for many of the arguments the government will make over the course of the next few weeks. Bapasina is back on the show and he's of course following this trial with great interest. Let's go over to him for details. Bapasina your headlining a show where we have some really solid lineup of stories today. So you know you have to sort of live up to the hype that is being made off the United States' litigation now against Google anti-trust litigation that begins today. It's likely to be a long affair but outline for us to begin with what the arguments are on both sides and which way sort of things are pointed. Right so this is the really I mean probably hopefully this is the starting shot of a series of litigations which may come against big tech in general right so for the last I don't know for the last 5-10 years people have been saying that we are living in this different people have called it different things. Surveillance capitalism is one of the names which come up and the tech monopolies and then so the basic issue is that these there are a handful of companies the US multinational which have grown to occupy monopoly positions in their spaces and this is when I'm saying their spaces their spaces are not limited to tech. For example Google even though we think of it as a tech company Google really makes this money from advertising and so you should think of Google as an advertising company and it has established a monopoly position in the advertising market worldwide right and so there are other companies like Apple and Microsoft and Facebook right so these companies have Amazon is the other company which have occupied these monopoly positions in large like industries right and so there has been a talk for a long time of controlling them because they kind of hurt the marketplace they hurt innovation they hurt competition but they have become too powerful to be like some people till they have become too powerful to be controlled right and so this this kind of suit which has come to the district court of the District of Columbia is the first such attempt to try to counter this this increasing monopoly power of the tech company and the first cases have been brought by the Department of Justice along with 38 states and territories of the US so that's like US at 50 states so 38 is like a big chunk of those states and they are alleging that Google has been using its monopoly powers to kind of to restrict competition in the search market right so as we know that Google search is kind of the default search right so when people say go to search on the internet they say why don't you Google it right that is the monopoly position it has and what the the contention of the of the Department of Justice of the US government is that Google has unfairly respected access to the competition and how Google does it that Google has tied up deals with phone manufacturers right people like like let's say Apple or tons right this is a big phone player and they have made Google search as a default search in the in these phones right see so the two the two biggest chunks of the phone market one is Apple the other are the Android-based phones now you take Android like if you are a phone manufacturer and you are using Android which is kind of pretty much everybody other than Apple then it comes with these Google services and search is like the main of these services the other services are like Gmail and map other things you use in your Android phone but search is the key thing for Google right and so how Google makes its money is you go to Google to to search whatever you are looking for and to that Google has a profile of you because of the various tools you use on Google right and then Google gives you these search results some of these results are what about paid search right so these are what advertisers are advertising for whatever you are searching for right and that's how Google makes its money and like the bulk of Google's huge revenues come from search and so then Google is kind of using that monopoly position to to basically force the major platform on which people search which is now pretty much mobile which is like ubiquitous like smartphone and so they've gone to Apple and and and Samsung and all them Android phone all the Android phone makers by default take Android which comes bundled with the Google services and then Apple so the the the convention is that they're paid more than 10 billion dollars per year to Apple and these other companies to be the default search engine the default search engine so that's the government content what Google is contending is that it is relatively easy to replace Google as a search engine with some other search engine right let's say Bing is an alternate search engine it's relatively easy to do that me personally I don't think that most regular users if you are a techie you may figure it out but if you are a regular user it's not easy to figure out how to replace search on your phone with with some other search engine so so that's the the the issue which has been brought and it's going to be argued for the next like a few months I think it's going to be a long process right many witnesses many documents are going to be produced on both sides yeah yeah so just just opening arguments I guess taking place at this point but but does it look like a strong case that the government is making we've of course talked before about similar antitrust cases against Google and other big tech companies in Europe of course United States it's biggest sort of go-at-tech in 20 years since Microsoft what do you make of the environment in which all of it's happening and and how do you see sort of that the discourse around this trial proceeding over the next few months Bapa it you're right like this is the first big case in a long long time right I think more than 25 years the last case was against Microsoft in 1998 for Microsoft using it in those operating systems to have similar monopoly monopoly powers over Microsoft apps like office and browsing yeah at that time Microsoft lost that case and was asked to split up right but then on on appeal they kind of reached the settlement and they kind of got away without too much damage to the company so and if you look look at it the the last case where a company was actually broken up like a large company was broken up with AT&T and that was in the mid-80s so it's been a generation since we have seen any action against this massive monopoly what has changed I think is in the last 10 years people have increasingly got concerned about their lack of privacy right and the invasion of privacy by these large tech companies and I think with Cambridge Analytica that kind of concern became mainstream before that tech guys were saying look like bad things are happening right but with Cambridge Analytica with the like series of elections where these these tools were used to in fact influence elections right like the Brexit in UK the first Trump campaign and we have seen such campaigns all around the world right where where writing governments have come into power using effectively social media campaigns right not social media campaigns exclusively but social media played a very big role in it and targeted campaigns so that has made this concern now mainstream right and in at least in the US I think there is a bipartisan kind of consensus right between the Republicans and Democrats that something needs to be done like clearly something I think does need to be done but given the power of the tech companies so I mean if you look at the 10 biggest companies by a market cap worldwide each of them are tech companies right so the 10 amongst the 10 biggest companies eight companies are tech companies they wield enormous political influence so whether anything will finally be done or not remains to be seen but I think these are important steps in at least in the right direction I think the case is strong right I mean like I said off the bat if I ask you how do you replace search on your on your phone it's not something you can I mean maybe you can google it and figure it out figure yeah exactly yeah but it's not something you can just know how to do readily right so so I actually think that Google's assertion that it's something you can change easily I don't think that's right but we'll see what happens in the case now the other thing is that this is only the first of such cases which is brought against Google there is an expectation that by early next year maybe as early as Jan 2024 another case is going to be brought by the Department of Justice and it's going to attack Google's address right now that is the core of Google's money-making machine right and to search is kind of the page right you come to Google to search and then the ad platform is how Google make monetizes that page right yeah and so Google has a double monopoly on the search platform right so on from both it kind of squeezes both the uh the content creator right on you are putting the ad and the advertisers yeah completely like because Google controls both the people who are placing the ad and people who are getting the content and as well as the as the the product the product is you and me right we have been told and so Google controls and all all these various entities right and it's opaque right like the advertisers don't know who who is getting paid out like how the ad budget is actually getting paid the the content creators don't know how much of the how much of the ad revenue is coming to them for their content and you and me are completely unaware that we have been profiled right so so that's a strong case again now so that's the second such case against Google now there is there are these news that is coming in that the US department department of justice is going to bring up a similar case against Facebook for for privacy violation right you have already gone after Google for monopoly practices in the in the new region and and they have put a large fine on Google Google is appealing that let's see how that goes even countries like in countries like India even though the the scale of the fine is relatively smaller but in the the competition commission in India has fined Google for a very similar charge right that using monopoly it's monopoly position to restrict competitors in the android phone market yeah so we are seeing like this concerted effort by different government and different jurisdictions to somehow try to grapple the big beast of big day I personally am rooting for some control over big day right at least like you don't have these wild west days where where they do whatever they want but but again like we said given their political power let's see how far the government succeeds in controlling them yeah it should be interesting either ways to see how things develop Baba thanks very much for that update and also explaining what is actually it goes back also a while and it's a kind of complex and nice little web that they've managed to create so thanks for putting that very clearly and we'll catch you again for an update very soon in what is a vital visit for both his leadership and the future of his country the North Korean leader Kim Jong-un is in Russia to strengthen ties with the Eurasian giant via meeting of course with President Vladimir Putin ties between Russia and Pyongyang are old and despite ups and downs over the course of history they are also strong Putin in particular has backed the most sanctioned economy in the world by providing aid and writing off billions of dollars in debt this time too Kim is coming with a wish list including of course vital food supplies but with the shadow of the Ukraine war over so much of the western media's coverage of everything to do with Russia the meeting is being built as more of a political statement and to increase military cooperation let's find out if that's what Dr. Abdul Rehman who covers the region for People's Dispatch has to say about all that Abdul good to have you with us on Daily DB as always where we're closing the show today with maybe more perspective than anything else on on this much talked about in the western media meeting between the leaders of Russia and North Korea which is not so unsurprising or unusual actually of course if you see the amount of attention which North Korea's visit Kim's visit to Russia has grabbed in the western media which usually considers it as one of those irrelevant pariah states in the global politics that basically shows the panic or whatever you call call it in the western in the western particular the US had to basically even before the meeting was it seems that was finalized the US had incline kind of inkling about it and kind of issued a threat that if Kim visits and kind of sells weapons to Russia that's what their primary fear that Russia is seeking weapons from North Korea just like Russia was seeking weapons from Iran from what not any country in South Africa the countries which were which are not considered to be a military large military producers in any way major players yeah major players in global military trade arms trade even the US has been basically making such allegations and most of these allegations have been found false alive so here also that the speculation is Russia is basically meeting Kim primarily to seek weapons but also they're also confused and they're also saying that it is primarily Russia's attempt to sell technology to North Korea there they need Russian technology to put on code improve their missile technology and so on and so forth so there is a complete confusion in the western media but they also it seems that they are quite rattled you can see with this particular visit which basically means nothing more than kind of an attempt by both the countries to develop the bilateral relationship given the fact that the both of them are by the way before we come to that the US threat the emptiness or horrors of that threat is quite obvious North Korea is already one of the most sanctioned countries in the world and what more US can do to kind of so that the North Korea can pay price and that one should try to it is difficult to understand so this this visit is nothing more than an attempt by both the countries given the given the fact that there is a geopolitical shift in the global politics and the West has basically both of them are victims of the global sanctions sanctions in particular and they basically see an opportunity here to develop a greater relationship and they share a border they share a history this is nothing new their relationship is not new it is a 75th five year since they have diplomatic relations so instead of looking at two countries trying to resolve their bilateral issues and kind of have a greater relationship this is made out to be a geopolitical event by the West and that basically it seems that Kim and Putin have basically they're also enjoying this attention and that they're basically using it as a forum to kind of give a message and that's what the significance of this particular event for the global politics is right you rightly mentioned the shared I mean came arrived on a train and the far east of Russia is a region anyway that the Russians seek to promote investment in this is all happening in in the backdrop of the eastern economic forum meetings as well so so there is a context for the meeting as well and and given what you're saying Abdul the impact of those sanctions and increasingly a western isolationist kind of attitude towards Russia as well so so isn't it natural in that circumstance that the two would seek to seek cooperation and food aid and exchange particularly with the grain deal has fallen through and the black sea as well all of these factors coming together exactly you see if you see a Russian foreign minister Lavrov in fact has basically stated which which is going to be a very big development if it is confirmed that Russia no longer supports the international sanctions against North Korea which were imposed first in 2006 and extended in 2017 it means and he also claimed by the way that China agrees with Russian stand on it it means two of the Security Council permanent members no longer support the extension of sanctions against North Korea that would mean a big achievement for North Korea it will also basically be a big blow diplomatically to the US and its allies and that is one part and if you see you rightly pointed out that these sanctions have been responsible for a large scale humanitarian crisis in North Korea the reports of course there is a very less report in the global media about the impact of the these sanctions inside North Korea but that is a well-known fact and North Korea is seeking and I think this has been on record that this meeting is primarily to see increased humanitarian help from Russia so unlike the western propaganda which basically is talking about weapons deal and so and so forth it may be the case that there is some kind of discussions on that also and Russians did not deny it but more than that it is also an attempt by North Korea to see much more food aid which basically will address some kind of economic concerns within North Korea so apart from it being a visit to basically deal with the technologies related to military and all it is also basically an attempt to kind of deepen the relationship and that's what Russia is emphasizing no matter what the west says it is Russia's right to develop relationship with this neighbor and in the benefit of Russia of course and also in the benefit of the its neighbors that also means that the larger region which includes China which includes Korea which includes other countries in the region so this is not only a military visit which basically has a military connotation it is a visit basically which has a larger implication for both bilateral and regional politics all right thanks very much Abdul just in time and thanks for putting it in very clear context for us this that's all we have on this episode of daily debrief as always we take this opportunity to invite you to head to our website peoplesdispatch.org don't also forget once again to follow us on the social media platform of your choice whether that's Facebook Instagram or Twitter and of course don't forget to like and share this video as well thank you for watching we'll be back same time same place tomorrow until then


Hello, everybody, and welcome to another OpenShift Commons briefing. I'm Diane Mueller, and I'm really thrilled to have with me today Tal Learon from the Telco Solutions and Enablement Group at Red Hat, part of the Office of the CTO, coming to talk to us about Kubernetes Operators for Telco Workloads, which basically covers every buzzword bingo of every conversation I've had, probably for the past week, with the Telco teams and the operators team, and everybody does love a bit of Kubernetes. So I'm really thrilled, Tal has really thought a lot about the pattern of Kubernetes operators and wrote an incredible internal white paper, which he's turned into an external one that will give you a link to at the end of this. And I think he really kind of expressed the role of operators and really explained the greatness of using this pattern. So I'm going to be quiet and let Tal walk through his thinking around this topic. And you can ask questions in the chat. We'll leave some time at the end, wherever you are, whether you're watching on YouTube or BlueJeans or in Twitch. You can ask questions and we'll relay them back to Tal at the end. If we don't get to all of your questions, we will post it in the blog and try and answer them in a blog after this. So with that intro, Tal, thank you very much for today and taking the time. Tal, tell us about yourself and take it away. Well, thank you very much for the kind introduction. So I think you covered everything. I'm an engineer in the Telco solutions and enablement team at Rehat for part of ecosystem engineering. I've been working with Telco workloads on Kubernetes for a very long time and operators is always the topic that comes up. So correct. There's a lot of buzzwords here, but hopefully after this presentation, you'll you'll realize that there's some substance behind it. So I will dive right in because I have quite a lot to cover. This presentation will be divided into four parts where the first part will be kind of a history and context to get people on board to understand what we're even talking about here, why why is this important? Why are Telcos using Kubernetes operators and why are they even interested in that? Then we're going to move to talking about what operators really are. Then we're going to go back to Telco and look at actual use cases where Kubernetes operators can can really help. And finally, I'm going to discuss some practical considerations. So much of this presentation could be interesting for people who are not working in Telco and are just generally interested in what operators can do. So we'll move in and out. So here we go. Part one, how did we get here? Why are we talking about Telco workloads and Kubernetes operators? I'll give you some prehistory in this graph in this slide. So the issue is network equipment. And from the very start, Telcos have been decoupling things. So this is a history of decoupling to an extent where you had big networks run by a big telecommunications company. Think about a transatlantic telegraph right in the 19th century. You have all kinds of equipment along the way, but it's always been decoupled. That is, we had network equipment providers that made and sold the equipment and also serviced it. And then you had the operator. And here, operator in the telecommunications sense, we have a little bit of confusion here. But in this case, when I say operator, I do not mean a Kubernetes operator. So the network operator, the telecommunications company, would be working with these other companies that would actually provide the hardware. And it was from the start also a very multi-vendor situation where you might have equipment coming from different providers, different vendors. And they would need to work together, right? You have telegraph on both sides of the Atlantic. They might be bought by two different companies, but they have to work with each other. So standards to be on the left at all of these steps in the history are still with us. And we're still using a lot of equipment that is basically a specialized computer. And those are becoming interesting too, because when you look inside those specialized computers, sometimes they can look a lot like clouds. But I'm jumping ahead here. This is part of a general evolution from analog to digital. But keep in mind that we still have a lot of analog, right? If you think of something simple as a digital analog converter of voice to digital, right? Antennas with radio waves for cellular networks, right? We're still dealing with a lot of analog stuff, and computers are still doing analog work here. But there's definitely, we can see a trend of evolution to make more and more of our information digital. The second big phase that, again, we're still part of this history is virtualization. And a colleague recently corrected me.  So we have virtualization technologies built into our computers these days, and operating systems that we definitely use. But virtualization here is meant in a different way. The idea here is that virtual is as opposed to physical or actual. The idea being that we're decoupling the hardware from the software.  And this decoupling basically introduced new kinds of players to the game. If it was before we talked about these network equipment providers in the prehistory slide, now we can talk about hardware vendors versus software vendors. And we're also changing our terminology a bit. So we can still talk about equipment, but now we're talking about network functions. And I'm going to dive into that a bit more in a bit. And so we can see here that we really have two different kinds of network functions, the physical ones and the virtual network functions, BNFs. And again, I'll emphasize, a virtual here does not mean it's a virtual machine necessarily. It could be, but anything that's decoupled from hardware would be a virtual network function, even if it's running in a container, because that's the idea here of virtual. The important parts of this story are that we started to evolve to use off-the-shelf products, off-the-shelf hardware and off-the-shelf software. And this story is kind of hard, this evolution, because again, some of this equipment can be very specialized and require very specialized hardware. But in some cases, especially in software, that's easier to move around. So the first phase is the one that we're really involved in right now. I'm calling it cloudification. Here, we're complicating the picture even more because in terms of software, we're talking about cloud-native network functions, that is network functions designed to run on clouds, on cloud platforms. But then we're also introducing the platform vendors who actually create these cloud platforms. So more and more players, more and more decoupling. And again, there are some trends in the evolution here, so we're still using a lot of virtual machines for sure. But the trend is also to move to containers in many cases and possibly the most interesting trend for us here in this presentation is the move from what I call management orchestration, moving from something like OpenStack to something like Kubernetes. And here it's important, the move from OpenStack to Kubernetes is not just a move from virtual machines to containers. That's actually the least interesting part of it. The real interesting part is that we are no longer providing infrastructure, but rather orchestrating our workloads. That's what Kubernetes really brings to the table. And I'm oversimplifying this quite a lot here. There's a lot going on, but my point here is just to give you context. And I'm mentioning here we're also using public clouds in some cases. And that might sound strange to you. Why would a telecommunication network function run on a public cloud? Well, so much of it ends up looking a lot like enterprise software, or IT software even. Think of a cellular network where you're connecting your cell phone with a SIM and somewhere there is a record of that SIM and who would belong to what account. There's a database where all of this is stored with security keys, et cetera. That's kind of a normal IT workload that could potentially run on just truly generic hardware and truly generic clouds. And they could even be public clouds. So that's the overall context of where we are. And it was important for me to present all this because all of these steps, these three steps are still with us. And that's part of the story of where Kubernetes operators become interesting and useful. OK, now let's switch gears and move to really discuss something more abstract. What are these operators that we're talking about? There's something called the operator pattern, which has been with us for a quarter of a century right now. I'll open the link here. This is the oldest version that I at least found on the internet, but I'm sure they're older. From 1997, the operator design pattern for parallel computation. And my point here is that it's really used in a computational sense. And we're not talking about functions, even when we talked about network functions before, we're talking about something that does continuous work. So don't think of it in terms of arithmetic and also don't think of it in terms of a computer program calling a function. That function is triggered by one thing and then it ends. The function is called, eventually it returns. And operators are kind of the same in that way. But here we're talking about things that do continuous work. The network function is constantly functioning and the operator is also continuously doing its work. Our context here is really when we apply this to a declarative intent-oriented orchestration context just like Kubernetes, the operator has a special meaning. It consumes intent as its input and emits intent as its output. And the next slide, if that's not very clear, the next slide we'll talk about it a bit more. But again, I'm emphasizing the fact that this is continuous. The operator is continuously monitoring that input, the set input changes, and continuously managing the output to make sure that it matches our intent. We can see here that we can divide really operators into two kinds. There would be pure operators that have no side effects and that all they do is consume intent and emit intent. But a lot of times we're interested in impure operators that do additional work in addition to emitting intent. And let's take a look at some applications of the pure operator pattern in Kubernetes and hopefully that will clarify what we mean here. So there are many examples of this, but this is probably the most accessible to everybody. Think of creating deployment in Kubernetes. The deployment descriptor will be managed by the deployment controller, which in this case is an operator. So the deployment controller will take that deployment and create a replica set. So the intent consumed by this operator would be the deployment and the intent emitted and managed by the operator would be the replica set. And this is a pure operator, right? The deployment can, if we delete the deployment, the replica set will be deleted as well and they're tied together. The second operator in the chain is also pure operator and that's the replica set. So now we have the replica set controller and the replica set controller takes that replica set descriptor and emits pods, one or more or zero or more pods and with their descriptors. And again, it's a pure operator. That's all it does. It doesn't have any side effects. That's its entire job. Finally, we reach the pod controller and in this case we are not applying the operator pattern or at least not in a strict sense because we are actually terminating the operational graph and moving to the real world. Here we're only interested in the side effects, the actual containers that are going to match work with the pods. And the pod controller makes sure to work with the container runtime to connect those to each other. So we have a graph, right? We have a graph of two operators reaching and they're terminated at one side. So one way to look at this graph is that we move from the left side the more abstract to the right side being more concrete. I encourage everybody to open their imagination a little bit regarding the operator pattern because it's not just abstraction to concreteness. You can think of it as a kind of translation as well. We're translating intent between different kinds of domain and this again would become very important in telco workloads where we were constantly doing work of translation between domains and standards, et cetera. So it's not just about getting more concrete. It's about a different kind of intent almost or even translating between paradigms, really. Okay, this next slide.  I wish I didn't have to include this slide but unfortunately the Kubernetes official terminology is very confusing. If we look at the actual links that I provided here. So when we talk about controllers in Kubernetes these are the built-in controllers and there's really discussion about the controller pattern and this is all okay. What's not so okay is the discussion of the operator pattern which is simply wrong. For 25 years we've been using the operator pattern terminology but Kubernetes has decided to use that in a different way. So in the Kubernetes terminology when we talk about controllers we're talking about the built-in operators. So everything you saw here in the previous slide all of these are controllers even though they implement the operator pattern. But when we say operator and according to the official terminology we're talking about a custom controller. So any custom controller that you create and add to Kubernetes would be called an operator. Even if it doesn't implement the operator pattern. So it's confusing and we're just stuck with phrases like we can talk about a Kubernetes controller that implements the operator pattern or a Kubernetes operator that does not implement the operator pattern unfortunately. But that terminological soup is just there but it doesn't change what we're actually interested in here. And that's the important thought. We care about Kubernetes operators even if they don't apply the operator pattern whether they're pure operators or impure operators could be important to the architecture we're creating but in the end they're useful even if they're not applying the operator pattern. So if you want to think of it as a custom controller that's one way to think about it. And the question of whether you need the operator pattern has to do with your entire architecture and your entire strategy. Are you trying to create a kind of Unix philosophy tool that could be reused? For example, if you go back here to replica set controller replica sets are usable even without deployment controllers, right? They can be used directly and they could be connected maybe to other operators that would sit before them and generate intent. So yeah, don't worry too much that you have to apply the operator pattern everywhere in order to make good use of Kubernetes operators. But it's important to know what you're doing which I hope this presentation is clarifying. And also another thing you should not do is reinvent wheels. There's a whole bunch of operators out there already of diverse quality and diverse abilities but look at them first. And of course something off the shelf might not do exactly what you need and then you need to generate your own. So sometimes you do need to retrofit a certain wheel maybe. But this is almost all of these are open source and that's possible to do if you need to do it. Okay, we'll switch, we'll switch. Sorry, shift gears back to talking about telco and look at how everything we discussed until now could be used for telco workloads. The first use case is stateful components and this is the vast majority of operators that are out there in the wild are really a dealing with state. And there's a good reason for this. Life cycle management is built into Kubernetes in a very specific way, right? You're familiar, you create a resource for example, a pod and it will create the containers around it. If you delete the pod, those will be deleted. If you update the pod, maybe some change to the containers will happen too. So there is life cycle management in Kubernetes but it's a very, very specific. Unfortunately, many stateful components are not, they don't work that way. If you have a say a database cluster, let's say it's a database cluster with 10 instances running. They might work together in ways that you do not want to simply remove delete one, right? You want to maybe, or add one, maybe it needs to be synchronized when it is added in. There are all these issues with state that are more complicated than just adding and deleting. And that's when your operator come in, an impure operator to handle all that specialized work that you would need to do. And again, remember the operator is continuous. So it would be constantly monitoring, say your database cluster making sure that if a node falls off that we can create another node and maybe add it in the correct way, et cetera. There is a lot of state and network functions too. So here I'm emphasizing that you might think that networks are very stateless things, right? A component along the way is like a router, a gateway. Where's the state there? Well, there's configuration states but beyond that there is state that has to do with the actual network. There are a lot of issues with maintaining connections, sessions, load balancing them. There are aspects that are cross components. You might have multiple network functions that are actually part of the same overall session. So again, same thing with databases. Think of it that way. You can't just add a node or delete a node whenever it works for you. You have to ensure that you can scale out or scale down without packet loss and while maintaining these sessions because yeah, I think that's pretty obvious. So again, stateful components are a great reason or a great use case for creating operators. Configuration management is another very big one. Network functions I think more than any kind of workload you might be familiar with involve very heavy configuration. So much so that a whole set of standards and stacks of software have been created just to configure network devices and network functions. And they're complex enough that you can really imagine a complete workflow of configuration. So think of it, think of configuring a router. Well, first of all, you need to find out well, maybe how many interfaces the router has. So you need to query the router and according to if it's this kind of router or that kind of router, you might have a different branching workflow here and do other kind of work. So there's a lot of work with configuration and again, this is a great use for an operator and operator can encode a lot of that configuration and because it's running on the cluster, it can do that locally. So for a long time in configuration management for networks, we had some sort of orchestrator that sits maybe far away from the site that manages the configuration from afar. But by moving it to locally to and operate on Kubernetes we are delegating some of that work. I'm gonna talk about that a bit more in other sites but it makes sense to keep the code close to the data in this case. And here I'm linking to an operator that I've been working on that's been doing exactly that. It lets you write these workflows using Python and have them run in your cluster. Third use, desegregation and modularity. And this might seem obvious but again, it has a very specific bent I think in Telco.  And when I talk about sites, I'm talking about hundreds of thousands of sites in some cases. Think about a network operator that, and here I'm using the term operator as a not a Kubernetes operator but a Telco telecommunications company that covers a continent. Think how many cellular antennas are out there? How many big clusters in cities? We're talking about many, many, many sites. So the scalability challenge is mind boggling almost. So here again, breaking up that big orchestrator to Kubernetes operators that can work locally at the sites means that first of all, they'll operate faster because they're close to the things that they're operating. And they're able to make autonomous decisions. And here there's an entry for using machine learning and artificial intelligence to allow them to make these decisions better. So even if they lose connection to the central big orchestrator, they can still operate autonomously. So huge advantage for reliability too. And huge advantage I think to design. You can create an operator that does one thing well rather than work on a very big orchestrator which could be an enormous project and yeah, you can separate it off. So it fits again with our history of decoupling. So let's have more decoupling. We can think of these then as these operators as part of a large orchestration narrative. And so they fit in with other things. And again, they accept intent and they could emit intent. And you can think of it as part of a big graph that really describes your entire orchestration strategy. The fourth use, it sounds like the opposite of the first use that the previous use. So yes, you can disaggregate, but you can also use operators to actually integrate. And we see a lot of operators like this actually, operators that are installers. So think of creating a custom resource that describes your whole product. We see that a lot with databases for example. So you'd like to install say MariaDB cluster. Well, the MariaDB operator will install all of those for you. Installer is not the best word for those because we're also talking about day two changes. That is after it's installed, you might be updating it and you'll want to see those changes happen as well. At least if it's a good operator. There's some history to this that predates Kubernetes and really predates classification. The terminology here, I'll just go over it briefly. For a long time, we've been talking about specialized virtualized network function managers versus generic virtual network function managers. The idea being that an equipment provider can provide the equipment but also the virtual equipment and also provides a management suite designed for that equipment. So if we want to manage the equipment, we would work with that management suite. But a lot of us has been hoping that there will be generic versions of that. So we wouldn't have to reinvent the wheel every time we're using different kinds of equipment and have something that might be specialized in QWERTY. So that kind of manager would be able to be configured or changed or programmed in some way to handle other kinds of CNF. So that's again, something that I'm working on specifically. There's a project called Turandot which is a Kubernetes operator that uses Tosca to configure what kind of network functions you're working with or general workloads. So yeah, there are two trends here, right? There's one trend here to disaggregate and modularize and use the unit's philosophy. But there's another trend where we can encapsulate all the work inside an operator. And the question is, should we use one approach or the other? And I say both. I think both of them make sense and it depends on what you're looking at. The rule of thumb that I always apply is keep the code close to the data. So if that means that you want to integrate it into an operator, then okay, you're integrating. And if that means the opposite, then you're disaggregating and using the operator to modularize. And I think this is, yeah, this is the final use case and then I'll jump into the next topic. Why not do all our work in Kubernetes? So if you remember, we still, the three phases of history that I started with are still with us today. We still have a physical network functions and they're not running on the cloud, on any cloud platform. They're running on some sort of specialized hardware. Why not manage them from Kubernetes too? So I've come to call these representational operators because they're operators that do work on representations that exist in Kubernetes rather than the resources themselves, right? They're not running in the cluster. Now, why would you do that? Well, you're basically putting all your work in one place. If you're already committed to using Kubernetes for orchestrating your telco workloads, why not use Kubernetes to also orchestrate your PNFs? And it makes sense too because the technologies end up being very similar too. If you think of configuration using, say, the NetConf protocol, well, the physical network functions are using it but the cloud-native network functions might be using that as well. And there are examples of the industry of exactly doing that and a Kubernetes operator or you can call it a controller if it doesn't, it's not applying the operator pattern that manages a box that sits outside of the Kubernetes cluster. And we can update the cluster resource for it, et cetera and it would seem to work as if it's within the cluster. So we stay within the same paradigm. Okay, I'll shift gears again now and talk about, well, how do we do all this and what should we be worried about and what are the pain points? And this is from doing a lot of work with operators and reporting from the trenches over some of the problems you might encounter. One problem is the custom resource definition implementation in Kubernetes. Sad trombone again here because custom resources are names-based in Kubernetes but custom resource definitions are not. They are defined cluster-wide. It might sound like, okay, that's not a problem. You can just, well, you'll just install them in the cluster but in a lot of management scenarios, not everybody has those privileges. The question then becomes, is the operator part of your workload or part of the platform itself? And there's no easy way around this. I hope that Kubernetes ends up fixing this. It would require a major change to how it's designed and how custom resource definitions are designed but I think that would go a very long way to make operators more portable that you can include them as part of workloads and not think that you have to install them separately. But, and another problem with custom resources that I'm mentioning here is that there's a side limit of about one megabyte but depending on what you're doing you might hit that side limit. The thing is, don't worry. There are very good alternatives actually to using custom resources. Custom resources are a nice tool that comes with Kubernetes but you don't have to use it if it doesn't work well for you. And putting out as one alternative you can use config maps. They're also general purpose resources in Kubernetes and you can use them any way you want. Why not use them to store your custom resources? Use them as descriptors and you can add annotations and your own validation and schema, et cetera. You can build that yourself on config maps. Another approach is to use annotations and here we can talk about fine-grained operators that is operators that don't work on complete intent but work on aspects of intent. That's still an application of the operator pattern and a great example of this is Multis. Multis would look for annotations on existing resources and those become part of the intent. They're not part of the custom resource but they're actually in additions to existing resources. That's a great strategy too. You don't have to start with CRDs. So again, I'm going back to that page, the operator design pattern from the official Kubernetes documentation and yeah, again, it talks a lot about custom resources but no, you don't have to use custom resources if they're hard to use or if they don't do what you need to do. Or another alternative is you can actually store your intent elsewhere and sometimes it's already stored elsewhere if you have some sort of orchestration system that you're working with or a database, you could use the custom resource or config map or an annotation to just point to that. So work with IDs instead of actually storing everything there and that of course solves the problem of the one megabyte limit to each of these. So if you store it in your own database, do what you need and yeah, get ups, right? Why not store it in a Git repository too? That's another approach that you can take. So your custom resources will be the live pointers to intent stored in a Git repository and your operator again, remember it's continuous, so it would have to monitor and look at changes to Git and you can do that through triggers for commits and react accordingly. Another practical consideration and it a little bit relates to the previous one. Should the operator be installed in the namespace in which it's going to work or should it be general and work with all namespaces and for different kinds of operators, it could make sense to have one versus the other and many operators actually support both configurations. So if you want, you can install it within a specific namespace or separately and again, this goes back to the issue of, well, if I'm packaging a network function with its dependencies, its operators or do I say, well, are these dependencies something that the platform has to provide for the workload to run? So this is a question that needs to be solved as part of the overall deployment strategy, but technically it's rather simple. It's usually not hard to create an operator that can support both of these. The Kubernetes API server always requires a namespace anyway when it works, so my advice is why not do both if you can make it a flag when the operator runs to say whether it's running in namespace or a clustered mode. The difference, of course, if it needs to be working cluster wide mode, you do need cluster wide permissions to install it. And of course, if it uses a custom resource definition, it does require those cluster wide privileges. Another practical consideration is garbage collection. Kubernetes has a garbage collection. That's nice. It's very useful for the operator pattern because the idea is that you can make the emitted intent owned by the consumed intent. So if you delete the input, the output will be deleted too. And that works if you delete a deployment in Kubernetes, the replica set will be deleted. When the replica set gets deleted, the pods get deleted and eventually the containers would be destroyed. So this kind of built-in garbage collection could be great. It could really add robustness. Even if your operator crashes, Kubernetes can make sure to delete the output intent. It's not good for stateful components though, for all the reasons we stated before, where there's a specialized lifecycle management. So we don't just want, say, the database to be deleted. The node, maybe it needs to, we need to update a connection URL. Maybe we need to make sure that the data in the node has been synchronized before we delete it. So again, an operator can come in here and implement its own garbage collection. So just something to be aware of. Decide for yourself whether you want to use the built-in garbage collection or not. And finally, the big practical consideration really is developing these in the first place. It's not trivial. Kubernetes is a very asynchronous environment. Kubernetes is a written in Go, but I do want to emphasize that you do not have to write your operator in Go too, even though it's the native language of Kubernetes. But whatever you do, it's not going to be trivial. Jumping into developing operators requires a learning curve and a commitment to working within this complex ecosystem. I listed here a whole bunch of links that people can take a look at to see, either get inspiration or get a head start. Some of these can be used maybe for prototyping an operator before you're actually going to maybe develop it fully. And there's no easy way out of this. I'm hoping that making operators will become easier and easier. Ansible operators, for example, are very easy. If you know how to write an Ansible Playbook, you can package it inside an app operator. That's a great way to start. But of course, if you have to work with network devices and things that don't have the Ansible support, then you have to do it anyway. And then if you have to encode the lifecycle management logic too, well, there you go. So it's a good idea to look first at what's available off the shelf that could help you before you jump into developing a full-blown operator on your own. And with that, I'm glad that I managed to fit it in because I did want to leave room for questions. I will notice here, as Diane said, this presentation is based on a much longer document that I've created in the context of the CNCF working group. So we have a working group there that we are trying to develop best practices for developing cloud-native network functions. And from the discussions we had there, I created this very long document, which this presentation was a boiled-down version of. And it is a public document, so anybody can comment on and just make sure that you remember that when you comment on it, that this is public and could be seen by anybody. And with that, I am done with my main presentation and happy to have questions, comments, and discussions. Well, as always, Tal, it is a tour de force on the topic and it stretches the definitions that we're used to and may be comfortable with around operators. And really, thank you for this because I think I'll post the link in a minute into the chat with the full document link. But I really appreciate the distinction between pure and impure operators at the very beginning of this. I think before I read your paper and listened to this, I wasn't really thinking of them in those terms and how the prehistory of all the operator pattern that we take into Kubernetes and we co-opt for our own purposes and how important naming things is and what the confusion could be. So I think what you've done today has really helped me and hopefully everybody else who's listening to really start thinking about this in another way and maybe a little bit clearer thinking about it, especially in terms of the telco stuff. There's a couple of questions coming in from YouTube in the chat, if you see them, Rico Suave. I think that is a pseudonym, but maybe not. Should telco loads be deployed in its own specific cluster or in a generic cluster as long as the CPUs and RAM are available? And then do. Yeah, sure. That's a very good question and I erased through it and as I said, I really oversimplified the history. Generic, we would love to have a write once run everywhere universe where you can write the code, write the software and not think about the hardware in which it runs. And we're constantly moving more and more towards that and but it's not true always and it really depends on the workload too. We have workloads that are maybe closer to the physical world, right? Things that require specialized networking equipment, think of something like an antenna, right? That's not generic, but we have specialized network cards. We have workloads optimized even for one CPU architecture versus the other. Think about x86 versus ARM, for example. So it's not true that you could just deploy something to a cloud and expect it to magically work in many cases. So we're constantly thinking it's not a simple problem to solve and part of it is efforts being baked into existing Kubernetes solution. So Red Hat's OpenShift does a lot of work in terms of managing the infrastructure of itself. So you can have different kinds of nodes. You can have a multi-architectural cluster, for example. And then your workloads would be able to be annotated to say, well, I need an ARM environment and I need this amount of memory and I need this access to this kind of accelerator. So the dependencies are sometimes rather specific. But still the advantage of using cloud technologies is not just that we can write ones from everywhere. Even if it's very specific hardware, using Kubernetes allows us to orchestrate at scale. That's the big C change that I think Kubernetes brings to the table. We have orchestrators everywhere right now. It's different from OpenStack in which you're just providing virtual machines but then something would need to install soft round of virtual machines. So actually Kubernetes manages our software. So yeah. I really like the phrase you used about Kubernetes being and I think it was extensible orchestrator. Right. That I think was a key thing there. He has a follow-up question about what makes a cluster telco grade? He's heard about CPU pinning feature, et cetera, but what is it that makes it specialized? So telco grade is a term used to talk about software and hardware that would match the requirements. Now the requirements are not just, hey, we want it to run fast. There are regulations and standards. There are timings that have to work in order for the whole chain to work. So it's not the only industry with standards, of course, right? Lots of industries have reliability standards and regulations from medical to financial and security standards, et cetera. So I would say what telco grade is just another variation of those kinds of standards. In the end, it's not too special in itself, right? So if you have certain timings that you need to work within, well, other industries do as well and it's not a problem that's unique for telco. So I would say that and CPU pinning definitely not unique to telco. So the question isn't so much as telco grade, certifying a platform for saying this, this Kubernetes implementation on this hardware is telco grade, but rather asking the question over what workloads are you gonna run on it and do they have what they need to run well? And the good thing about that story is that it becomes not a telco story, but a general cloud story. So if we solve it for one industry it will be solved for others as well. And that's an advantage that telecommunication companies understand too moving to off the shelf stuff. Being a snowflake is not a good position to be in. Being in a multi-vendor cloud situation gives you much more power to choose different vendors to switch between them, to negotiate and to use industry knowledge that has been developing for years and apply it to telecommunication. I think it's also interesting, like I started the whole conversation out about how this past couple of weeks it seems that Kubernetes operators and telco have been in every conversation that I've had with people inside of Red Hat and outside of Red Hat. It's really been telco has a history also of being sort of a hotbed of use cases that get then implemented outside in the rest of the world. And we've been talking about edge computing and there's another initiative inside of Red Hat around AI ops in Telco coming from America Mobile did a great talk on Role Race is working on something called the enterprise neuro initiative system or something enterprise neuro system and using AI ops to make those autonomous decisions on the edge and about operations and about operating at telco scale. But those things, those are the kinds of ideas and I say ideas because I'm from New England so I can't say it the other way that help all of the other industries and all of the other spaces, which is why it's, I think recently we've just been seeing a lot of the things that telcos have had to do especially around edge computing and keeping the code close to the data and making those work decisions autonomous and local. And this is really what I think is that the crux of leveraging Kubernetes operators in telco is really just another set of ideas and patterns that we're gonna see applied in a lot of places and move through lots of other industries. So it's really been, yeah, I think telcos, you don't think of them as really personally as bleeding edge thinkers but recently, a lot of the work that we're doing here at Red Hat has been taking telcos use cases and applying them elsewhere. So I'm thinking in your office of CTO work and that telco solutions work, we're gonna keep watching you and watching what you guys do and bringing you back to get some of these big thoughts and big thinking ideas and see how we can apply them in other places. Yeah, without a doubt, I'll add to that that telco use cases, you know, telco grade use cases they do push the envelope. There are, we can definitely say that in terms of just networking and by networking here I mean this low level networking support, TCPIP for example, you can obviously imagine the telco workloads, CNS would require much more sophistication than other than say a database and enterprise application. So I think approaching the telco use cases and trying to solve them benefits everybody in the cloud space. One of the complaints about Kubernetes is that it doesn't, it's pretty weak with networking. It doesn't have a lot of opinion about networking.  You have some sort of SDN, software defined networking solution that you plug in but Kubernetes itself doesn't care too much about that. Well, that's nice until you really need to do a lot of low level networking work and then you're asking, well, can Kubernetes help me with this? And if it can, then you have to develop all these systems on yourselves. But, you know, across the board I think the telco industry is pushing Kubernetes to be better with networking and we see it happening. We have, for example, SCTP support just recently added into Kubernetes and we're seeing the network plumbing group introducing multis that additional interfaces. So yeah, telco is not behind the times in every way. In every way, I think in some ways it's really pushing the envelope forward. And I think some of the conversations I've been having with Paul Lancaster who's sitting out there listening in, I'm sure somewhere and around the certified container CNS and the big push and so a lot of the vendors that have CNS and are working with Red Hat to get them certified to work on Kubernetes and with OpenShift and doing all that stuff. They have been, you know, once those things are there, ah, Paul is right there. Yes, Paul, yeah, if you wanna chime in, I think that that area is, Paul's been preaching to the choir. I mean, the only thing I would add, Diane, is that, you know, a lot of the things that Tall points out the work that we're doing in the CTO's office is actually helping our ecosystem. You know, what we're finding is as these, as the ISVs or the business units that create software within the network equipment providers that are targeted, they're in customers or the service providers, the telecommunication service providers. As they migrate their applications, they actually take advantage of a lot of the work that we've done from an operator perspective. So there's operators that we actually ship with OpenShift to be able to take advantage of things like CPU pinning or SRIOV. These are, you know, and so what we find is not only the work that we're doing upstream in, you know, OPNFB or LFN now, it's for the work that we're doing in CNCF, but it's actually making it into the ecosystem of customer ISVs that they're deploying at scale in the service provider. So that's really what I would add. The other thing, and this we're probably gonna have to, we can go a little bit longer, the live stream may end, but you can hang out in the blue jeans if you like and keep talking about this.  And I know, and Wednesdays, which is today, is our day to talk about operators. So we've had the Java operator, SDK group on last week and the week before, people talking about the operator framework and that. How do you see, I mean, and you didn't mention that in your list on your slide, the operator framework stuff. Have you worked with those crew and are they embedded into your conversations around the Kubernetes operators for Velco? Of course they are, right? Especially for targeting OpenShift because the operator hub and the operator life cycle manager are so embedded in OpenShift that it makes it a very natural place to start. And Red Hat, of course, as a big proponent of operators can give you a big head start. But in the spaces that we think about, I work a lot with standards body like Etsy, and ORAN, and Oasis, and at the end of the day, Kubernetes is an upstream project itself too. So within that space, I think there are a lot of different kinds of opinions and needs. I can't expect, for example, every company to have a go developers, right? Or to be able to invest in the go programming language. Telecommunication companies are kind of interesting. Some of them do a lot of development in-house. Some of them specifically outsource development elsewhere. There's a variety, and because of that variety, I think it's important to also provide a variety of solutions and approaches to doing that. So as I said, you could use Ansible operators. That's a great start if you're already invested in Ansible and designing playbooks. If you're a big Python house, there are solutions to that too. The main thing I wanted to emphasize is that Kubernetes is itself, the API server in Kubernetes is language agnostic. And that's a huge advantage in terms of plugging into it. So it works well with also the microservices approach to development, Agile, where you have teams maybe working on a very specific unit, a functional unit, a network function, or an operator. And they might be using different technologies from other teams, right? For various reasons. Maybe one is written in C++ and working directly with drivers. The other is written in Ruby because it's talking to some middleware database system. But all of these can work together within the ecosystem of network functions and Kubernetes operators. So it's the kind of work that I do, which is very, a lot of evangelism and promoting. I emphasize the truth, which is that there's a diversity of ways to approach this. No, and I think that's great. I think that's one of the things about having the office of the CTO and having people be in that arena and being given the time and space to do the big thinking and the promotion of these new ideas and to help us bubble them up and get them out there into the universe. And Tal, that is one of the things I love about your talks is they make us think. We all have opinions and we're all opinionated. But I think sometimes having that, the overview of the landscape, like you did a previous talk on introducing Tosca and an AMA on that and I throw the link on that too. One of what, and these are the kinds of talks that I think start discussions and start conversations and hopefully drive some standardization and some really useful innovations into the space. So I am grateful for you for taking the time to, first of all, write that wonderful paper, which I will send out over the the internet and send you a post with it, the YouTube video up on our YouTube channel and on the OpenShift Commons. And we are definitely gonna have you back and every time it's surprising to me. So I'm looking forward to whatever it is you're working on next and I hope you'll come back. So thank you very much for today. Thank you very much. I have a few things on the oven. As always, yes, so we'll definitely give you the podium and do this again. So everyone who's out there listening on the internet and we'll put all the links up and the slides shortly. And I think the raw video will be up on YouTube almost immediately because we're doing live streaming to YouTube. So Rico Suave, thank you for your questions and everybody else, Paul, thanks for being here. We'll have you back again soon. Take care everyone. Thank you everyone, bye.