Max Körbächer: Do We Really Need Kubernetes? A Tactical Guide to Cloud Native

In this talk, Max, the founder and Cloud Native Advocate at Liquid Reply, explores the complexities surrounding the adoption of Kubernetes. He presents a balanced view of Kubernetes, acknowledging its benefits while also highlighting the common pitfalls many organizations face when integrating it into their workflows. Max compares Kubernetes to a Lego set, emphasizing the importance of tailoring it to specific project needs rather than approaching it as a one-size-fits-all solution. He discusses the significant cognitive load on developers and the misconception that they should manage Kubernetes themselves. Furthermore, he emphasizes the value of proper training, understanding application architecture, and addressing organizational structures to realize the full potential of Kubernetes. Throughout the talk, Max encourages audiences to rethink their approach and strategy for deploying container orchestration.

[Music] e um hello hi yeah it seems we are on stage yeah uh so we are starting with our first talk today and uh I'm I'm Andre I'm host of this truck today and I want to introduce uh Max uh who is going to talk about kubernetes uh Max is founder and Cloud native Advocate at company liquid reply uh Cloud native Advocate like sounds like Jus right

and uh Marx is going to talk about do we do we really need kubernetes sounds quite Pro provocative so probably you are not Cloud Advocate but you're Cloud provocate so so yeah Max has a great experience with kubernetes uh and open source projects and so on so uh Marx you can start all right thank you very much Andre um yeah uh that's indeed always with uh the

big question is here I'm an advocate I'm a provocate but I think in the end it's always about to find the right solution and um maybe could we need this is not always the answer also I really love to work with kubernetes and spent the last years working with kubernetes so um to round a few things up from from the introduction um beside my job as a

adviser for cloud narative technology are working a lot in open source I founded the technical Advisory Group for environmental sustainability um I'm part of the cncf ambassador program and also part of the Linux Foundation Europe Advisory Board so um all day long somehow something with computer and open source and whatsoever if you're interested in some of the other topics feel free to follow me and get in

touch with me and um I'm happy to chat about so today we are talking a little about kubernetes and I'm pretty sure a lot of you have seen memes like this um people expect like a heavy beautiful sunny weather day with a kubernetes when everything is up and running but um often the reality for looks a little bit different looks a little bit more problematic a little

bit more um yeah how to say uh everything is a little burning everything is a little bit challenging and overall um that might be the reality but it has reasons why it end up like this and usually if you do the things right and you're on the happy path then the expectation most of the time comes true but as soon as you leave this happy PA you

obviously have some problems now um you see there's a tons of jokes about like hey we use kuas now and then asking okayy why everything is getting more simpler and whatsoever and he's like for sure um I'm pretty sure you you maybe remember the scene from Star Wars at someday but um this is really like the average happening for many teams that start adopting kubernetes and first

get hyped and get get introduced to and then suddenly hit the worldall of reality um but again it has a few reasons which we will discover later so when people talking about kubernetes they always compared with container ships um which is a large vessel and have um huge complexity and ships tons of stuff and actually it's not that flexible and and things like that um I would

say that's not really kuus or not only but there's other perspectives how you actually can tell the story so for me when we talk with people about their kubernetes experience it's more like a Lego set you put things together which you like and which you need and which makes you fun to have and which you um in the end need to implement to tell a story to

whomever made this concerns and this Leo principle behind it is I think a little bit better picture however in the past I was usually said like hey this container picture doesn't fit at all but I would say it's more like a mix of both right it's a mixture of like you have a Lego container ship which you can adjust here like the kubernetes line to what you

really need it for because what people underestimate with kubernetes is when you introduce it to lier organization it has a potential to replace um a large part of the infrastructure structure and it become like a container ship because you maybe also need to think about the I would like to say positive side which it has um similar to container ship um these are often operated by a

relatively small crew such ships have something between 15 and 25 people for a time but the value which they transport can be billions of Euro if this containership stuck if this ership think you lose tons of money right but kuas makes it very hard to make it think like modern ships too so I would say meanwhile this analogy somehow fit but we need to be a little

bit more creative in how we see the overall story because this ship can be extended through other things through our Lego now why does now kubernetes fails and why we have and see often that there is problem with it and there's a couple of good reasons for it when you search the internet um you can find very interesting discussions um was good amount of traction quotes and

um the overall tenor is like oh there is a couple of things which are very hard however if you go into the details it's usually not the platform which is a problem so it's usually not CNAs which is failing but it's often a lack of knowledge or it's often some subcomponents of this whole story and this makes it quite interesting now we think about the reasons there's

often wrong roles we have the devops movement on the last years I personally believe huge part of it is because it's done wrong maybe you have read the book from the devops on the Phoenix project um from J humble which when I read it I was like well that's what we need we need this mindset change we need this organizational change we need to open up we

need to reduce our bottlenecks in my previous company we had for example one guy who was able to set up Ral machines only one guy and in summer he every year goes four weeks for vacation and he becomes this bottleneck because in summer we strategically plan to not launch a new project a new system because we not get a new virtual machine and to replace that person

not replacing of like getting rid of him but Tak him out of this responsibility and put two three more people into it whom he can teach this is a devops mindset but what we do out of it is like we have the expectations that somehow developers uh will do the platform operation I think when fle said 2006 or something you build it you run it that's partially

correct but we interpret it completely wrong people think about you build it you run it from the to full full Zelo from the front end to the last bit and bite in the network and everything in between but that's completely wrong and we see that this fails over and over and over again and the adoption in organization also fails and corrected rather than to rethink what they

are doing they rename it then suddenly you have not only the devops team but you also have the S reliability engineering team and so on so when we take a look about what um do when they're searching for problems stack Overflow is actually funny source of it so I searched here for a couple of topics like Cloud Foundry open stack and so on and you see the

amount of open questions to it Cloud Foundry 3,000 open stack 2 and a half th000 AWS 150,000 W okay these few hyper visor we amware 4,000 kubernetes as you saw also in the first screenshot almost 60,000 so the question is now why there is such a difference between a cloud Foundry an open stack or hypervisor towards kubernetes and this is because on the one hand side people

don't understand correctly on the other hand side the roles are seen wrong yes kubernetes allows developers to do things better faster more automated more standardized but it's not the developer responsibility to manage kubernetes this is completely wrong that's a wrong perspective of doing the things but this is what we see in the large organizations that they force and ask developers to maintain and run everything what they

have developed and so they will fail at one point in time on coitas and the same thing actually also happens on the cloud environment where people still get asked like to run something on cloud the problem here is that most Enterprises and most companies have at least two to three Club provider so you actually don't need to learn once but at least twice and then and konitos

and containers which is Trice or four times and then you maybe have also an Prem environment so the whole thing get very complicated we call this also cognitive load the cognitive load is large for and if we try to put is all out and and stretch the problem understand each single string in this problem case um it's not very very simple to answer it's really complicated because

it's a thing of mindset role definition um demographic change um Financial pressure of companies pressure towards development and platform teams and so on so the the complexity behind is completely um insane and that's because we have this big misalignment in the end um when we take a look at developer and we take a look of operations this model Works actually very fine Mis interpretated devops putting together

it doesn't work fine anymore I elaborate a lot of these points which are written here um but the main thing is like when you go and deel as a developer and want to put something on kubernetes you often have the problem that you need to understand a lot of complexity have learn long learning curve um just to make a little bit code running which is insane if

you think back to times where you maybe used Heroku you just throw your goat and somehow magically runs right why we don't have that well the answer is you can have that if you have a team which maintains and builds such a platform for um and yeah so let's move on um I recently found this phrase and I found it very genius uh which says like you

don't ask a watch maker to build a global watch Factory or factories and this actually describes very well what we nowadays see all the time when we talk about devops right you're not going to developer who let's say make make it more precise um we don't go to a backend developer specialized in writing go or Java with spring um and has a very good background in manipulating

data and working with data in this case you not go to that person so like oh you're now def Ops and now I would like to help that you build me a thing that that goes all around the globe and you need to understand how all the networking works and how um all the the uh multi-tenancy Works how the security works and you need to take care

about the costs and so on this is this doesn't make sense if you if you go deeply into this and you just speak out what do you expect from the draw it doesn't make sense so maybe that's the first thing which you can take with you that the watch maker is not someone who ask for building Global watch factories now the second reason is that we have

a very poor support um we usually see that there's either no time or no budget for proper trainings or for the discovery phase and that's very sad because the best way how a human can learn is by trying things out but it works well when we try things out because we are curious it doesn't make fun if we try things out because we are pressured for it

from the cloud native Computing Foundation report also 46% of all the um ask companies and people answered that they have a problem a lack in trainings already now and that's a number which is continuously at this level over the past years so no time no budget we need to do things fast fast um we had a few years back a very large project where a customer came

to us and said like hey we have four mons and we need to be productive until the end of the year we need to build the full platform we need to migrate tons of applications everything is Mission critical and if we fail we have a really really big problem so actually very common problem right everyone has this long but that's the wrong thing to do when you

want to introduce a new technology I'm pretty sure when 30 years 20 years ago maybe 15 you introduced hypervisor to your infrastructure no one was saying like oh I expected tomorrow you have installed everything of this technology which you have never ever seen before it's completely unrealistic but that's how the world is and now um the most Paradox thing which I meet is like we don't need

too complicated too big trainings um I was once with with the organization talking about like hey what is your certification pass how do you and not for the sake of certifications just as a proof of of work but how do you train your people what is your plan for it how do you have an a thought process behind it do they learn Cloud do they learn container

do they learn kubernetes do they learn everything on top of kubernetes and the answer to it was like why that takes too long if I do that my people needs a month to be trained and I was like yeah that's right you you need some time to train them because people fail already on cloud how they should manage them kubernetes and organizations don't want to invest into

that because it would mean that they lose a lot of time for building something so they keep pressure and and driving things forward and expect that someone can learn while they have this pressuring environment while they need to deliver every two weeks some releases and so on it's already when you realistically think about it it's it's meant to fail it's similar like you come to a hospital

and someone tells you like oh you're going to be a doctor and you're going to operate tomorrow someone on the open heart and you can learn that on the way that's not a problem for sure in a kuus environment no one maybe will die from it but it's the same you would not go to that person you would not even trust that person why you should do

this then with your own organization this leads to that we do the wrong things um often we see the teams failing with uh somehow the integration between the development security observability um especially if we talk about multitenancy it's getting complicated and this overall raise frustration so you lose the people and then the last piece even if you manage somehow to overcome all of the problems is that

you're over engineer or that we see a lot of people overend this Ste because they misunderstood kues and for what it is made for and then teams s down drastically into what they could Implement and completely lost track of what they should do um they found a little problem and introduced two three solutions for it which could be also solved in another way in a shorter amount

of time being more reliable this leads to one problem with the kubernetes that we see always these rumors about oh kubernetes is so complex it's always adding up costs and it's difficult to maybe if done right I have never seen that we have seen a couple of very large organization that introduces ganas as a main runtime over the last years and where's platform is adopted from the

organization the teams doesn't increase they always stay around nine maybe 12 people sometimes they get one or two more people to it because they run clusters globally they run systems in America and in Asia and in Europe and a different time zon so it makes sense to have someone who's always on a shift and this is better done with more people but the team doesn't Crow because

of the complexity the team doesn't Crow because there is more workload on it right so if it done right you don't over engineer it then you don't play build something which is too complex in end and so it's actually a little Paradox and problem that people think about over engineering and over engineer it so the result is that they complain about that it's too complex because it

got over engineered just keep it simple keep the things simple um you may know the kiss principle kiss kubernetes something which went stuck in your head so give a kiss to kubernetes and then you will have a very easy life and yeah sometimes you even will fall in love into it even if it sometimes feel a little bit stupid and dump and um annoying you but in

the end it's just a lovely creature right so what about all the other problems well um if you take a look on the market reports what is the problem with scnes they also talk about for example security or the operational overhead or complexity but in my opinion from what I've seen in the past these problems appear because of the other reasons the problem of kubernetes security is

not because kubernetes is unsecure it's because the people don't know how to kuas in my world we are not specialized in doing too much security at least like a few years back but nowadays we do a lot of security advisory and implemented very hardened environments helping to secure the network to put in hard multitenancy to be very precise with a uh user access and stuff like that

and for me it feels meanwhile it's a part it's an integrated part of the platform so you need to learn this obviously also talking with security teams it doesn't matter how good or Worse the organizations are usually they have absolutely no idea they have already problems understanding Cloud then comes containers there off and coones living on another planet I don't want to say that there's just organizations

who have no idea about security but um I can understand that in a world where you have such limited amount of people available who can help you um it's difficult to keep up with such development um so I see this as an integrated part of a team who implements coitus for example and this counts for operational overhead and complexity and other problems too you can have your

team taking this over without a problem if you help them to understand it and learn it and how to do it right so this leads us to the question when is actually kubernetes wrong and I need to underline here again that no one ever said that kubernetes is solution everything um when I on different conferences developer conferences um Cloud summits I often hear like oh yeah but

you're a kubernetes guy so what why why everyone wants to have coitas why we just don't use VMS or serverless and it's like oh you can right as a good consultant I always would say like it depends on because kuas is not always the right solution especially if you're organization has limitations and we come to them in a while then maybe you should go for something which

is easier to understand which is the first reachable step for organization so to keep some short when you have commercial software kubernetes is often not always not the right system um with face that commercial software requires a lot of Windows sometimes it maybe can go on Linux a few more solutions are going on being containerized but even there we see finally development that they can run a

container but they're very difficult to run on kubernetes because they are not able to scale that way they're not able to run on Parallel and so on so usually um buying some random software often leads to that you can cannot run on kubernetes then the classic a large monol they could run on kubernetes that's not a problem I have we have done all the dirty things already

it's possible you have a monolit which needs 20 minutes startup time reindexing things and organizing itself somehow until it's preheated and ready to serve it will work I have no worries no doubts in it but the platform is not made for it not that kubernetes is not stable you can run the things forever without any problem the thing is that you have a proper release cycle with

incites and I personally believe you should follow this release cycle and be able to run this three 400 updates for the kuus cluster and all components on top over the whole year if you have a single application that prevents you to update take this application off that's two different worlds doesn't fit together it's like you want to run with a f bully bus against Maserati or whatever

it's two different things memes um yeah memes your team when your team shows already that are against this technology your team has a bad picture usually they often don't have the the right understanding or any understanding at all but continuously make joke about it I would recommend you not to introduce you kubernetes because then you first have to change the mindset then you have to introduce a

technology um it's complicated to motivate people to work with a technology which they don't like even they have never worked with it if this is successful you have the biggest fans for it it's not like that but the way for introducing this successfully is super duper long and you most likely will lose over that time and yeah you run a container somewhere in some way and you're

happy with it then why you should change it recently I had a discussion discussion with an e-commerce provider Who currently runs everything on on Docker swarm and container and ask me like hey do you think it makes sense to upgrade to kubernetes I said like no but you are the kubernetes guy you you build platforms why you think it doesn't make sense and the answer is well

you are happy you do not have limitations do you need anything from kubernetes do you need the network encryption on the platform do you need that that's selfhealing uh that it distributes your workload and they're like no we don't need it but we just s like we get more maure if we go to kuas well that's wrong you're not getting more mature if you go to kubernetes

you can be very mure sure running things just in a container if you want um coitus is not always the right solution so for me nowadays this discussion also feels sometimes I'm sorry to say very stupid because people think too small they think about kuus when I'm talking with Cloud people who come with serverless and manag kubernetes and managed container and whatsoever I don't want to compare

that you're like comparing a full feature set of a couple of hundreds of services with a bare infrastructure that allows you to PL and play whatever you need how you want to compare that it doesn't make right so kuus is not your target infrastructure it should not be th as your target infrastructure it is one component of allowing you to build a platform so you need to

change your mindset and say like I don't want to buy uh build kuus I am building a platform when I think about building a platform then I need to clear Target for it I need to clear Focus what it is a good for and then when you get this holistic approach of a platform then kubernetes as an underlying foundation will suddenly be an eye opening component because

it simplifies all of the integration part all of the development part you can very easily integrate the whole development cycle from the first lines of code until the check test deploy whatever you just need to integrate one's security you just need to integrate one cost management compliance observability and these platforms are usually extremely easy to reuse at least if it's some concept which you keep in mind

but when you run this way when you think a little bit bigger then you can start comparing also a platform with a cloud provider because a cloud provider is nothing else than just a platform as a service in the end which is very very complicated with tons of other tools but this is the only level where you can compare if someone goes with you into the discussion

comparing kubernetes with Cloud capabilities turn it off it doesn't make sense to discuss that only if you want to think big and only if you want to go away from thinking small so how do we find now when kubernetes is right and what do I need for it actually this question is very complicated because you have a lot of factors in it um I try to pick

out five very Elemental questions to answer so that when you can find an answer to those you either have a 90% Insurance you shouldn't or a 90% Insurance you should the last 10% is up to details so we have the questions do you introduce it just for one application or is it for the whole organization how does the application architecture look like is it a monolith is

it a micro Services is just functions which expectations do you have for the scalability and does your team have the experience and the capacity to learn and last but not least who will run that environment now answering the first question do you introduce it for one app or the whole organization if it's one app Frankly Speaking if it's just a simple web application for a handful of

people don't do it um we see one of our clients doing this continuously wrong because someone defined the blueprint kubernetes is for everything and especially for web applications so use it they reintroduce all the time kubernetes for running a simple web application which you can run for I don't know $2 a month on a random cloud provider if you want to but the story changes if you

have hundreds of developers and services if all of them are very small kubernetes is a very good choice because you can automate all the complexities around around it simplify the software deployment and allow a very reliable platform for the simple simple services so even if the services are not that relevant to your organization you can move it from a pron class support mechanism to silver or gold

standard um another good direction is when you introduce it for your whole organization if you strategically plan to implement such a platform for everyone you have already good direction and it usually will help you to simplify after a while the whole development and operational processes around it but it's a question of like how experienced you are and how well does things run so if you have a

single initiative a minor app and from my Enterprise architectural time a few years back I know that most organization have this with 80% of their apps or more you better go for VM better for an app engine container service or serverless so how does your application architecture looks like that will be the next question to answer if you go for microservices micr monolit distributed um and you

need something that is Fault resistant that can run multiple times it can run in parallel and access the same data source and has no problem to be shifted left and right and up and down it's a good way to go if you have application that doesn't fulfill that and even if it's microservices that are not very good with fault resistency or not very good with accessing the

same data source at the same time even then this is maybe the worst platform for it and if it requires a long preheat time to start up it's also not the right thing to do as said monoliths can run on kues absolutely no doubts if you monolith needs ages to get ready to serve don't do it because in an Ideal World the platform team responsible for kuas

will never ever tell you when they run an update and can be on the daylight while in production they just updated and your application should be able to handle that without a problem then you in good State monoliths often can't do that so this is a clear noo and a very large monolit um one two three million lines of cod is also not a good thing to

have it on kubernetes again it can run there it's not good to have it there it will cause more problems in the operational perspective than if it brings benefits to you there's a few little exclamations out of that which we have seen already in the past that we enter a project got told we have a large monolith and that somehow needs to run somewhere in the cloud

environment and in the end it ends up that this monol actually has a couple of components so it's not really one piece of software it's like five six seven larger compon components that run together and they are orchestrated for example through a messaging system those things can run in kubernetes because while you introduce something like a message streaming in between all of these moving Parts it gives

you the right reliability and ensures that your system has not a problem with running in parallel most of time so you see it's not that easy to answer that question you need to go to detail to detail um but this is also the wrong approach if you just talk about one single application only if you build a very if you have the Strategic Target let's say to

rebuild for example Spotify or Netflix um with hundreds of microservices where you have hundreds of teams around it maybe not hundreds but tens or tens of teams then this is a good platform but if we really talk about always single applications this discussion is already ridiculous so you need to find the right level what you're really talking about um yeah often said this um also what is

um from the cloud environment and Cloud providers are often an answer is like hey why you don't go serverless you don't need containers go serverless yes you're right serverless is fantastic if you just need to go started if you want to develop right now an application and you don't want to waste any time go for serverless the reality is when this amount of serverless have crown to

a huge environment we see organization frequently moving away because it become too costly too costly because of uh frequent database Access Network traffic um API costs observability is very complicated um and and require some expertise in it and very often you end up with a question like okay this function is now getting called 100 times per hour why we just don't run it continuously if it's the

same price why not so this demigration from serverless become a thing um but it's not that you should always Dem migrate I really like serverless to get started simple prototype something have a first application within a few weeks running and then you can decide where you go um to transfer nowadays an app from one thing to the other is very easy to be done at least in

my opinion so what's your expectations for scalability if you need to go from zero to 100 and back kuas is maybe a good Target um especially if you have events and metrics or triggers that forces you the scaling but if your expectation that it scales up within a second or less especially for the hardware underlaying it then right now it's maybe not the right solution even though

containers are fast the underlaying infrastructure isn't the large Cloud providers sometimes need a couple of minutes until a new node has started that will rise we know some nice infrastructures a service provider which need less than the 30 seconds but that doesn't count for everyone and um if your app doesn't need more than a container so it doesn't scale at all then it's like a TW thingy

in between like yes you could use kubernetes but no you don't need to use kubernetes especially if you have already Cloud environments like AWS you can go for container service now you need to be careful I think that container services have also their own amount of overhead and not everyone can wrap around the head about how does it work but it's a good starting point and if

it's a single container it's maybe even a small enough to fit into a server list but if you target a shared cluster with couple of smaller Services you can also go for that for me scalability is not anymore a factor the question is more about how fast it should scale if it extremely fast it needs to be in a split seconds milliseconds you need Ser list you

maybe should think about re architecture for web samply based server list mechanisms they partially can go up to 50 60 milliseconds to scale up if you need very fast okay we can go with containers and kuas it has its limits the limits of the current existing nodes under it but if you have some room for for breezing it's fast it's very fast if you need something which

is okay fast go with the VM you need to be careful there are some service providers which needs minutes there are some service providers which needs less than a minute if you need less than a minute this is service provider I mean with VMS are fast if you need more than a minute it's moderate it's very slow and if you really really don't care go for bare

metal don't mix bare metal with bare metal but you know you got the things and thanks for the acinx fox for this nice picture I really love it now does your team have experience or capacity to learn and there is just yes and no if yes perfect give it time give it room give it the chance to implement something you can definitively go for it if no

you want to finish your platform in three months you actually have just two people working on it uh the first customer staying there everything is critical nope there will be no chance that this will be successful because kuas has a very very hard learning curve and I found this picture actually kind of kind of cute there's also another one which is like even going back and then

like a cliff where people falling down um I think that's a little bit too harsh on it because the foundation of kuus is simple it's very easy to understand how does it work you have a platform you define somehow how your container should run on add all good that's a that's a very easy part of it the complexity comes when you think about the possibility the extensibility

of KU is on top of it and all the open source solution which are out there to help you to solve one specific problem at a time plus you need to understand how you manage actually the life cycle of kubernetes it's the most challenging problem out there is to the life cycle management of kubernetes it's not to bring UPS on it um also because we see organizations

like building platforms very stiff with Terror form and then oh we can manage through it but we see that then the update procedure often is like unsure and like oh do we really kill now something and so on so slowly coming to an end um for sure people feel like they have a lot of power if they run kubernetes cluster I can prove that but it's also

something which everyone can do and then who will run the environment if you have a dedicated team then the team is um responsible for it perfect but if you have a dedicated team that is just there to operate the platform but not to maintain it not to develop it it's maybe wrong because your team working with it needs to also understand how does it work and how

does it goes on and they need to do Implement new features in the future they need to be able to re-evaluate if what is implemented is not outdated and can be replaced this happens very very frequently that we need to replace one function with a standard tool because there so coming slowly to an end what is the future talking us or showing us well Frankly Speaking cloud

is a commodity but already many organizations fail on cloud impr introduction so also they will fa with kubernetes you will see an evolution of the runtime and thanks to the colleagues from cosmic here um I really like the picture you can see how we evolute and we are just like in the middle part with kubernetes which gives us um a good amount of compatibility we can run

any kind of um small medium and and uh large workload it's kind of portable and so on what comes next is web assembly maybe as a continuously very cool safe environment and this will improve also the security for example for a lot of these platforms and then last but not least kuas is not the answer to everything we answered this already it helps you to streamline things

it helps to focus on the user if you want to um build the as value and it be the foundation for your platforms thank you very much and I think we have a couple of questions yeah thank you Max unfortunately we have very few time left probably I can ask you one question uh from Andre Ignat what is your opinion on running stateful work flow workloads in

kubernetes like database engines is it worth the effort um it's not that complicated um with the software defined NW storage which you usually have and the possibility here that your copones can um reassign the same storage to database I think it's not a problem for me it's more a question about who wants to operate it and how you manage the service for it if you're running on

a cloud provider and you have a managed service maybe you should go there because someone else takes more or less care about the the database if you run it on your kubernetes you have to take care by yourself right but to run it it's fine we have seen large database clusters running kubernetes they have a dedicated team for or good you can do mhm okay clear uh

I wish we have run out of time uh we had few comments in chat but these are just comments not questions I guess uh so we uh I guess we will have small uh pause now between the next talk thank you Max for for this overview of kubernetes and thank you for the attention yeah see you after 15 minutes on next talk thank you bye-bye [Applause]