1:24 Introduction & Guest

1:24 Hello, and welcome to today's episode of Rawkode live. My name is David Mackay, also known as Rawkode across the Internet. Today, I am very happy to be joined by a cloud native ambassador and advocate for the Cloud Native Computing Foundation. Hello, Ihor. How are you? I did. Doing great. Thank you for inviting me. Really excited to be here. Yeah. It's gonna be it's gonna be really good. I think this is one of the most important episodes that I've done today. Like, normally, it's the hands on and playing with our technology. But today, we're actually going to

1:58 tackle some of the more meta questions around what is cloud native and how to adopt cloud native and all of this stuff that you know, people either read about online or consume from talks at conferences. But sometimes it's just nice to sit down and get really specific and and and help break down a few of the barriers to cloud native adoption, which is why I'm so excited for today's episode. I think it's gonna be great. Of course. I'll try it. With that in mind, what I would suggest to anyone watching live is that we really

2:25 do want participation with today's episode. So if you have a question that you would like us to answer and it could be anything cloud native related, we'll do our best to tackle that. The way to do that is use the comment system on YouTube or you can tweet either of us and we'll do our best to bring that into today's episode. We do have a collection of questions that either I, Ehore or people from our Discord community or Twitter have submitted previously. So we're gonna start with a few of those and anything that you want us to drill down

2:54 onto, please do not be shy. Get those questions into us. So let's start with a little bit of conversation around you. You are a developer advocate for the cloud native computing foundation. This must make you the foremost authoritative answer on what is cloud native. Would you would you agree with that? Yeah. Yes. So the the question about what is cloud native is probably the most one of the most simplest and the one most complicated questions in the technology world. So it may take a few hours for us to discuss everything in details. Alright. Well, we can maybe we'll we'll go over the

3:00 About Ihor

3:36 let's say, with the abridged version, I think. So, I mean, is it safe to say that that your job, your role is to help people and promote cloud native? Is is that what a developer advocate at the CNCF is is responsible for? Yeah. So my job is an intersection between the classic technical developer relations, like, in development, we'll go see, like, trying some new tools, working with the developer communities, working with the technical communities, writing some blog blog posts, trying demos, and so on, and promoting promoting technologies across the across the technology world. And at the same time, I'm also deeply

4:20 involved into the various program management aspects and community management aspects of the cloud native community. So we have some unique specifics of of our organization. So cloud native computing foundation is not regular. Let's say, vendor or product company, we are the independent nonprofit foundation, which is hosting various technologies under our umbrella. And we're mostly we're mostly interested in spreading the world around these technologies, but not not adding some, you know, like, some commercial focus to these technologies and so on. So my average job, it can be a bit more different than the average than the average day job, the average responsibilities

5:07 with the typical development we get from the from the product company. At the same time, we are all doing the same job. We're promoting these technologies. We are connecting the bridges between the technical technical communities between the developers' communities and those people who are trying to consume these technologies are making decisions about implementation of these technologies there in their ecosystems. Awesome. Really cool. I mean, you get to, you know, on one hand a play with all of these technologies on a regular basis, but b, you're also very closely connected to the community through those initiatives that you just

5:40 mentioned. So you also get really good first and second hand discourse with people that are either adopting cloud native or already have adopted cloud native. What I wanted and we're we're gonna get all of that knowledge out of your brain today and transmit that to everybody that's watching on YouTube. So oh, we have our first. Hello. Hello, John. Thank you for tuning in. So let's just try and see if we can not spend a few hours, but maybe a few minutes just covering what is cloud native. If we had to sum it up in in a thirty second blurb, what do you

6:01 What is Cloud Native?

6:11 think the most important parts, components, concepts, etcetera are of CloudNative? The most important components of CloudNative is an ability to bundle the different things into some into some shippable and easily distributable units. They typically call this containers, but it's like, being containerized is not absolutely necessary to be to be to be cloud native. At the same time, the the way to implement your technologies, like, we are exposing the APIs and using some sort of mesh technologies or adapting adapting your tools to be easily deployed on the different public or private clouds on premises is the other essential parts of the

7:01 the cloud native world. CNCF has its own specific definition of what cloud native is. You can find it under the CNCF repo on GitHub under CNCF two zero c repo on GitHub. So you can find this brief definition there. On the various language, it's not only in English, so I can share the link later. And, probably, you did, it can share the link later with with all the subscribers here. But in general, again, the cloud native technology is the technology can that can be easily used and easily packaged and easily distributed across where platforms be platform agnostic and can

7:41 be easily distributed across the across I don't know if that's my connection. If anyone can still hear me, if you can let me know, that would be grand. Or if we have potentially just lost Ehar. I'll wait for a thumbs up from somebody. Otherwise, I'm going to the pub. Oh, Ehar, are you back? I'm back. Yeah. Sorry. I had some connectivity issues. For some reason, they're happening exactly that time when I went back to it to live. Sorry. You seem to be perfectly great now. So we'll just put that down as a wee blurb, and we'll see what happens.

8:29 Alright. Okay. So I think you you kinda covered what cloud native was there. The the thing that struck me right away was you kinda you said that you don't need containers to be cloud native. You don't necessarily need containers. However, in, like, 99% of different cases, containers are essential. So containers is the organic part of the cloud native world. And if we'll come back again to the history of the cloud native computer foundation as an organization, our first and second project was Kubernetes, project that has been developed by Google originally to host to host containers

8:33 Containers and Kubernetes: Essential?

9:11 and to manage containers in the various scale in various cases across the across the even across the globe. So the first project even for the foundation was the container focused project. And most of our projects in these days, they are also container centric. Yeah. I mean, I think just from my own experience of speaking to people, you know, you know, at events last year, of course, not this year, but or even online this year is that, you know, I think there's this kind of I don't know if it's maybe it's a rule or maybe it's some

9:45 Can you be Cloud Native without Kubernetes?

9:45 sort of misconception, but the idea of the cloud native and Kubernetes are actually entangled to a certain point. And there's I I I feel just on the conversation I had that people don't think you can be cloud native without Kubernetes. And is that something you you would say is untrue then? It's again, it's not it's not truly true because you can write containers without Kubernetes. You can be even a cloud native without containers. However, again, Kubernetes is the essential part of most of most of the container focused infrastructures these these days. Most of most of the

10:16 container environments these days are powered by Kubernetes for obvious reasons. Kubernetes has enough benefits of why you shouldn't use it in in the various cases. However, it's obvious that you shouldn't use the same technology for all the cases throughout. Whereas scenarios where Kubernetes is not is not truly necessary, can be you you can just use, for example, Docker as the container runtime and the basic container of the straight on your local machine, for example, and so on. So container containers and Kubernetes pretty close to each other, but not synonyms. Yeah. I guess maybe it would make sense

10:58 Benefits of Cloud Native

10:58 if we kinda try and cover what are the what are the main kind of problems that cloud native can help organizations solve? Like, you know, we if we understand what it is and we understand that maybe you don't need Kubernetes, then what does cloud native aim to solve? And then maybe we'll lead us on to what Kubernetes helps solve some of those challenges too. Sure. We can come back to the to the benefits of using containers themselves, not not necessarily the the cloud native as an abstraction. So you you can use containers everywhere it states. And one

11:00 What are the main problems that Cloud Native solves?

11:31 of the benefits of using containers and packaging your applications into containers is that you can use, for example, your your local laptop to write some application, bundle your call with some container, do it, like, in a few commands and then in a few seconds. And is it the shipment run the same the same the same application on on the public cloud or in a private cloud or in a remote data center that is located in a few thousand kilometers from you? And this is one of the obvious benefits of using containers. And, again, being cloud native means that you

12:02 can you can use all the benefits that that that that this extra environments can can bring to you. You know, like, there are even various various cloud providers that are not only offering their public cloud offerings. When I was speaking speaking about cloud, most people when most people are speaking about cloud, they are mostly using this term to to describe some kind of public cloud, example, some well known some well known infrastructure that is being run somewhere by some third party vendor. They don't have any access to the underlying infrastructure. They don't have any control

12:39 to it. However, there's a concept of the on premises infrastructure or private cloud. And if you're using the private cloud, you're basically using the same bare metal machines as you can use in your in your regular physical data center, and private cloud is essentially the same physical data center. However, with the with an additional set of frustrations with the way with an ability to control the infrastructure using the API and the declarative way of managing the things, You can you can convert and you can migrate your your existing legacy workloads and the legacy ways of using applications and deploying applications into something

13:23 different. If we're speaking even about the hybrid cloud approach, so you can you can even use the same the same set of instructions, the same set of API rules in some cases where you can run the same applications on the private cloud within your own data center on an in a public cloud that has been been deployed somewhere. And here comes Kubernetes. So this is this is the answer to your to your next question that you were about to ask, Nick. So why Kubernetes is so is is really beneficial for various use cases? The reason is that you can use you

14:00 can use the same Kubernetes cluster or the same way of controlling of controlling the various Kubernetes clusters because of the Kubernetes API, which is not changing even despite the fact that you can you can use the same Kubernetes cluster in a in a public cloud or you can use the different Kubernetes cluster in a private cloud in your own data center. But you'll still use Kubernetes, the same code base of Kubernetes. This means you will have the same stable API. You can simply run it even, you know, like, simple Biden commands, for example, that will provision some applications for Kubernetes.

14:40 So Kubernetes is the next level of of obstruction, and it doesn't matter which kind of infrastructure do you have below the Kubernetes level. Wherever you can deploy Kubernetes, you can you can interact with Kubernetes. You shouldn't interact with the underlying infrastructure directly if you are trying to deploy manage your applications. Okay. So you can still be cloud native if you're on a public cloud. You can still be cloud native if if you're on private cloud or bare metal or or multi cloud or all these things. These are all cloud native. You can use Kubernetes if you want or

15:17 containers if you want, but you're gonna get a lot of benefits if you do. One of them being that you just said there is Kubernetes gives us an API we can deploy to containers, give us the ability to not just distribute the images, but have some level of idempotency between what we run across machines. You know, there's there's already a lot of layered benefits here that the more you you know, what's that phrase? The sum of the whole is greater than the sum of the parts. Like when you add each of these bits, you're just building out a more robust

15:42 and resilient system. Would you say that is the goal for for people that are adopting cloud native? Is this just to architect their systems in a way that is more robust or more scalable? Is that a core tenant of of of cloud native? It's it's one of the benefits, and it this is this is one one of the primary reasons why people at companies of the different different size and different scale are implementing these tools and using these tools, specifically Kubernetes. Can use Kubernetes on a single node machine on your local laptop, and you can also

16:16 use Kubernetes in your distributed your distributed various data centers across the globe with with the scale of the single cluster of up to 5,000 nodes per cluster. So and you'll still use the same Kubernetes. So this is the benefit. You'll still use the same tool. You don't need to learn some get another tool to to to use it and to transfer pieces of code there. Okay then. So let's let's continue down this path then. So it's something that is very prominent with with cloud native architectures and and people that I speak to that are adopting this

16:50 Do you need microservices to be Cloud Native?

16:55 this methodology of building software is microservices. And I believe that the CNCF original definition did say that microservices were required to be cloud native. Is is that still the case, or do you feel that that's changed a little bit these days? Yes and no. So microservices should be there where where they're required. The same time, the cases where microservices are required are almost everywhere. The most typical use case for still using some monolithic application can be migrating this monolithic application from the like, from some legacy workloads and inability to to easily convert it into the microservice.

17:41 So I know that there are even some customers and some companies that are using Kubernetes even to to bundle some things, some applications that have been developed even, like, twenty or thirty years ago in the mainframe era, for example, that they're using Kubernetes. They're using some kind of language to bundle that code within within some abstraction that can be easily consumed by Kubernetes, and it can be provisioned in the run of the Kubernetes cluster. However, if you are if you are developing and building the new applications, specifically from scratch these days, it's more or less obvious for most cases that

18:21 you you may and should use microservices because it's the most most efficient way of managing various resources, especially if we're speaking about the debate about the public cloud infrastructure. For example, if you're not using some bare metal machines which have kind of limited capacity, comparing with the with the public cloud where you can you can basically run anything and everywhere anywhere, so Microsoft is the preferred way of front end applications. It will be way more way more resource efficient for you. It will be way more efficient in the terms of the life cycle management of your applications and so. So there

19:01 are enough benefits why should you use microservices these days. However, as I mentioned before, it's not you shouldn't use microservices everywhere, like, in 100 of cases. If you feel that you don't need microservices, you probably don't need. Okay. Let's let's prod into that a little bit then. So I think that's definitely a question that probably most people have is, you know, I'm starting on your side project. You know, do I start with microservices in which is that gonna have an effect on the velocity that they could ship the first version? Because they're, you know, there are

19:20 Should my new project start as microservices by default?

19:36 whole lot of challenges that come with microservices. Mean, maybe we could talk about how Kubernetes solves a few of those. Yep. Or, you know, for someone starting up a new state business or a new startup, you know, building a monolith might just be a lot quicker for them, but then the technical debt they accrue as they build that out is also gonna have all these challenges too. Like, what what is the answer? Is there a single answer? There is no single answer. There is no single answer for all use cases for all companies, for all applications,

20:07 for even all the types of applications. There are various applications that can be easily easily bundled and packaged into into Microsoft's team. Even even some legacy applications that been built, like, ten years ago, they can they can be easily split into the Microsoft's phone even today when we're speaking about some stateless applications. For example, some state of websites and and so on. So some stuff something like that. When we are speaking about some something more complex, especially when we're speaking about some cases where where you have to store your data, like databases for some some complex storage solutions,

20:51 especially in the African storage solutions. So probably it's not the best case just to go ahead and convert your existing applications into the into the form of microservices. You can also combine it. So there's no direct answer. Should you use microservices all everywhere in all the cases? However, I would strongly encourage people to consider using microservices. And if there is a possibility to use them and if there is a possibility to be cloud native from from scratch, from from from the first steps, this should be the it can be the preferred way of fusing things these days.

21:30 Okay. So so right away, like, let's let's try and play this on on both sides of the fence then. Let's assume you and I were speaking to a new company and we're saying, like, microservices are the best way for you to start this new application. Now, immediately, to me, the first thing I'd wanna say is is a tangible benefit is the microservices should be small enough that they're really easy to iterate on, build, test, and deploy. Are the other advantages then to microservices? There are enough advantages around microservices. So you can easily again, you can easily develop them.

22:05 So if you can easily develop the different components of the microservices microservices of the microservices architecture just on the single atomic basis. The whole complex structure of the microservices application compared to the monolithic application can be even more complex because of the of these various connections between the microservices between the microsources pieces and the different ways and even probably even different language languages which are used to try different parts of this microservices application. Again, with monolithic application, it's way easier for you. As I mentioned before, there is a for some startup, it can be way easier just to write some

22:48 monolithic application just from the scratch. Just try some some basic things there and ship it even in production, but what about scaling it? What about migrating and distributing this this application across whereas cloud providers, for example? So let's say you have you have an analytic application that is being run on the public cloud provider a, but you may have some issues with that cloud provider. You can have some. For example, your country can restrict your access to that to that cloud provider, like, on the next day, and you have no access to that. And you

23:30 you're trying to migrate the the tool. You're trying to migrate the the application to the different place, but the cloud provider b has no has no direct way how can you just click and run the same application and migrate it from cloud for the data to cloud provider b or the different cases? Like, even even if you have some, for example, billing issues with your current cloud provider and you're trying to resolve your issues with the with the outstanding payments with your previous cloud provider, but you already have enough credits on the cloud provider b. So in the in

24:05 the microservices world, you can you can easily move these pieces from cloud provider a to the cloud provider b and run them almost seamlessly. With the monolithic tools, it can be complicated. It's not necessarily complicated in in all cases, but monolithic monolithic application make makes you less flexible. You are less flexible on also in terms of development. So if you if you are trying to upgrade some minor piece, but minor but essential piece of your monolithic application will have to rebuild the whole application. It will take some time. It will take some development resources. It may

24:44 it may have even some compatibility issues in the future. But if you upgrade in the small piece of the model, we take a look of the microservices application, I'm sorry. If you upgrade in a small piece of the microservices applications, you're just upgrading the same that that single piece of that seed. All the remaining all the remaining parts of your microsources microsources structure will remain the same and unchanged, and we don't don't have to rebuild them again from scratch and test the complete compatibility with the new platform and so. So, again, various cases, if you're running if you're just running something

25:21 like the basic front end application on a single machine that is located somewhere and this is the primary business case for your organization, you may consider just using that static website even not containerizing that just running something like an engine x and that's it. Yep. At the same time, if you'll run different pieces of the application like the front end front end app, back end apps, some database, some as traditional pieces of code that should be added as the extensions and so on. So this was considered in a conversion days for the capture into the microservices

25:56 one. Okay. There I mean, there was a lot there. There's some really great points I think that people need to consider when they're they're they're tasked with this question at their organization. I mean, I think what I'm taking away from what you said there is, like, cloud native should probably be the default, and you should identify which use cases, which applications shouldn't be rather than the model if it's a default and then trying to work out when to be cloud native. So the people that are listening to this should just say, this is a cloud native application until I

25:58 Understanding Cloud Native Complexity

26:25 have a reason not to do it. Another kind of really prominent thing that you were you came back to a few times there was just the fact that the microservices allows you to contain logic into small sections, small parts that we can move out, we can replace, we we can iterate on and the amount of knowledge you need to be able to do that is much more minimal than having to understand like a whole car for instance. You might just understand the steering wheel, the gearbox, the clutch, etcetera. And I think that works really well. So

26:53 let me turn the question around a little bit then. Macro services and cloud native architectures allow us to build smaller components that we can understand. Do we need to move the simplicity from our app do we need to move complexity from our applications or is it just pushed away somewhere? So fun fact that with when we're comparing, again, microsources and monolithic monolithic applications, we're adding extra complexity to to the microservices applications. Because, again, you have to you have to connect together various pieces of the different, like, different pieces of code. For example, how can you hear how can

27:00 Where does the complexity go when we adopt microservices?

27:33 you bundle easily? How can you connect these also piece of code that is written in pilot, for example, in Go? It's almost impossible in the in in the different in the different cases, like, with the monolithic applications. With microservices, you'll have to add some extra extra level of instructions just to connect it. In this case, you'll you'll need you'll need to have some universal set of set of APIs within your application where you can connect these different different pieces of your applications that are located on a different different size of this field, let's call it.

28:09 Let's call it this way. Yes. The minute we we apply this architecture to our applications, we have a distributed application, and that brings a whole host of complexity to it. So whether services are getting simpler, we're I guess that's all now in the infrastructure there, which is where Kubernetes comes in and and saves the day. Would you say Kubernetes solves a lot of the complexities or undistributed applications, and how does it do that? Again, Kubernetes is an extremely complex tool. So it will add enough complexity to your general architecture, but it will remove enough endpoints for you to manage or and to

28:11 How Kubernetes Manages Complexity

28:48 manage and to use your your whole your whole level of of the your whole set of instructions there. So Kubernetes is an extremely complex tool, but will simplify your life in some in some different cases. Again, a good sample of where where and how Kubernetes can be essential for you, I just mentioned, like, five minutes ago. So you can have you can run the same set of applications and control them from the single control plane, from the single control point even if your applications should be should be provisioned in the private cloud data center that is located in The

29:00 What are the common pitfalls / missteps when adopting Cloud Native?

29:28 United States and on a public cloud that is based somewhere in Japan, for example. But you can still control the same applications from the same place, your single control plane, and you, as an operator, you'll you'll have to interact only with that single control plane. Control plane. Everything else will be handled by Kubernetes. Excellent. Let's tackle a viewer question then, which I think kind of segues nicely right now. So John McCabe is asking, what are some of the common or avoidable missteps or pitfalls when organizations adopt cloud native? The most the most common the most common misstep is that

29:50 Common Pitfalls in Adoption

30:12 sometimes people are considering cloud native as you know, like, when people are considering that cloud native can solve all their questions, but it doesn't. And the reason here is that CloudNet is not a silver bullet. Kubernetes and containers are not a silver bullet. You still have to develop your locations and your your configuration and and design your architecture in the most efficient way. You it's it's a big mistake to to think that if even if you develop your architecture and your application in in some where way the next will solve it for you. It's not the case.

30:57 Even even it will be more more difficult to to adapt and redesign your application and your your architecture if you've if you develop this in in some non efficient way and to enhance it to be more efficient later. So the the the the basic the basic probably the basic point here, you still have to write some good code and some efficient code to be to be to be run somewhere, and it doesn't matter if we would be around containers, we should buy Kubernetes or just be around somewhere on the pure bimetal SDS. Yeah. Definitely. I think that, you know, there's a

31:41 lot of maturity with regards to writing software that has to be kind of understood and you have to have solved a lot. You've you've got to understand some of the problems that cloud native solves before you can start applying it as a solution for everything. I think is what's really important. And that's kinda what I got from what you were saying like Yeah. If you don't understand the past problems and you're just applying a solution that you don't really know what is solving yet, and that's gonna lead you down probably a trap, a whole bunch of errors

32:00 What is the first step for a Cloud Native migration?

32:07 that otherwise you may have you may be able to fix. I think I made it right now. I get it. Okay. Yeah. So It's something I I've seen a lot. You know, I go to a lot of conferences as I'm sure you do as well. People are always asking for what is what is the first step? And I'm I'm gonna say what I normally say and then say that it's also the worst advice that I always give. And I still give this advice but I think there's some there's a reason for that. So when people say what is

32:20 The First Step to Adoption

32:33 the first step, I normally tell them just containerize your application and and deploy it as it is. Like, know, just getting and and when I say that, what I'm asking them to do is to build a CI pipeline where they build an image and run a places which pushes them down the 12 factor path. But then it's also the worst advice to give because people take that container image and throw Kubernetes. And it's the only service, the only pod and they're just scaling it on the architecture using the Kubernetes API. And I think that's also has a huge

33:00 detrimental effect on them because they did again, they don't understand the problems that Kubernetes is solving with with networking and service discovery and health checks and all this stuff because they're not necessarily using those components. So I'm curious. I give a bad advice, it sounds, but I'm hopefully trying to help people. What do you think is, like, a good first step for people that wanna adopt Cooper adopt cloud native coming from maybe a monolithic background? My first my advice about the first step would be learn your own code. Know what you are writing, know what you are building, know what are

33:38 deploying. If you if you don't know what what you're using, you don't know what you're trying to adopt for the cloud native for the cloud native infrastructure, you there is a high chance that you'll have some issues with with the immediate adoption or you you may have some issues later during the adoption cycle. Learn what you want what you're doing, and the second the second first step is learn that that technologies that you're planning to use. Learn Kubernetes. Play with Kubernetes. Play with Kubernetes, deploy on each on your local machine, your local laptop, for example.

34:16 Try to run some some basic applications, understand what kind of potential even potential issues and potential complexity that can Kubernetes and to the application and that Kubernetes can add to the environment. Good case, you may have the, like, the tiny tiny machine somewhere in a public cloud, you know, data, etcetera. Whereas cloud providers that are offering, like, something like the micro micro VM or tiny VM or something like that, and their public public cloud offerings, typically, is a part of the free tier where you can you you may receive you may receive something like 500

34:58 megabytes of the of of RAM, something like one virtual CPE, which is shared across across the whole across the whole rack where this this machine is this virtual machine is deployed. So sometimes people are trying to use this this tiny tiny VM, tiny machine to run Kubernetes and run some applications within it. But the typical Kubernetes cluster these days might require around one one gigabyte of RAM just to just run itself it it it itself. So you can run even Kubernetes itself without any without any workloads on that machine. But you can easily run your

35:44 your small single goal and based application there, for example. So, again, learn your code and learn your tools that you're trying to use. As much as as much as difficult to run Kubernetes cluster on a 500 megabytes RAM machine, the same in absolutely the same way, it's terribly difficult to run some simple simple application in a highly highly distributed, highly scaled environment on a few thousand nodes without any kind of orchestration, without any kind of containerized solutions like Kubernetes. Okay. Awesome. So let's go back to something that you you mentioned earlier. You when you were talking about

36:30 Stateful Workloads and Databases

36:32 microservices, you talked about databases. Now we did have a a viewer submit a question before we started, and their their question was, do I really need a database per service? This sounds like an awful lot of work. So do you have any thoughts or opinions that or even advice to people that are not sure how to structure their their stateful services and databases and back end stores, etcetera? Yeah. Again, it depends it depends on the use cases the use cases of your application and the use cases for your databases. The most typical way especially the early days of Kubernetes that I've

37:08 I've been following, and I've I've noticed that multiple companies and even multiple enterprises have been using this that use can try services in the cloud native the cloud native technologies and the cloud native architecture for the stateful for the stateless services. But for the stateful workloads, you use some dedicated use some dedicated database cluster that you that is just plugged into your Kubernetes cluster, for example. So your database should not be necessarily should not be necessarily containerized, and it should not necessarily be being run within within the Kubernetes cluster, for example. But you can still use all the benefits

37:50 of using devs k full services with Kubernetes. But, again, there are so many various cases where you should use even databases with Kubernetes and try enough cases where you shouldn't do it. Yeah. I I think I I think this is a hot topic and a about should I run staple workloads in in Kubernetes? Yeah. I'm firmly on the yes. I think we should be running a database using Kubernetes. I think if we look at the benefits, you know, of health checks, reconciliation, as as long as you can solve the storage problem, you know, and we can talk about

38:27 CSI drivers. Not something I'm particularly knowledgeable about, so maybe I'll avoid that as as much as I can. I think, you know, there's a lot of benefits to having a stateful workloads in Kubernetes and been able to plan and plan for failures, know, like it's things aren't gonna go wrong, but then we learn how to fix them whereas I don't know. I that the concept that I've got a Kubernetes cluster, sorry I'm ranting now. Got a Kubernetes cluster and I'm running my state for workloads on VM somewhere else that could still have the same problems they

38:54 would inside a container environment. I mean, like, in fact, here's a question. Sorry. I'm Of course. Going off on one. I always tell people there's no difference from running a database in Kubernetes using a host path mount and fixing it to a node. So there is just running that process on a node. I mean, is that something you would agree with or something that you you think I should stop saying? I can't I can't respond immediately. We have to we have to follow-up on that. So as as you I'm not sure about the about the correctness of this statement. So let's

39:33 let's skip this and discuss later. No problem. I'll I'll maybe just run a bit on Twitter at some point and have the Internet tell me why I'm wrong. But I Good good good good point for the Twitter for the Twitter poll. Right? Okay. Let's say I jump back to a few of your questions then. So we had a few questions that were essentially along lines of do I need x in order to be cognitive? One of them was CICD. One of them was good monitoring. You know, are there any prerequisites that people need to be

39:50 What are the pre-requisites for Cloud Native?

40:03 good with before they could be cloud native? Or, I mean, is this just good code hygiene in general? Like, people probably should have CI and CD regardless of being cloud native. What are your thoughts on that? I agree I agree with your point on on call hygiene. I agree with your with your points that with your point that CI, CD tools are mostly essential in the most in the most complex environments these days. Even if you're not using Kubernetes, for example, or if you're not using the contrast clusters, if you are running and if you're releasing

40:37 your applications into it, if you're developing your applications frequently, if you're releasing new pieces of code regularly, you have to use the CI and CD tools to to to deliver them properly. So it's it's an unrelated it's it's a related but unrelated topic to to the cloud native world and to the to the cloud native cloud native architecture markets. It's a good practice to use CICD tools with the complex environments. It's not truly necessary in some cases. Again, if you just if you have just released your your single version of your application and you don't expect to release any any version of

41:17 your application in the over over single future. So, again, CICD tools can x CICD tools can add extra complexity to to your code base and to your infrastructure. But if you are releasing your your applications frequently, if you are releasing some updates frequently, so you have deployed some patches there, so you should use these tools. Again, not necessarily with Kubernetes exactly and not not only with Kubernetes clusters, but it's just like it's just a a good practice for everyone who is doing this. Alright. So, yes, you should have CICD. Yes. You should have good monitoring.

41:58 It's not necessarily a prerequisite to to call the cloud native architecture. Exactly. Yes. Exactly. So it's not a definition of cloud native to use CICD. Yeah. And it's not the definition of the cloud native application, but in the in theory. Right? But in the practical world, not in most of the use cases you should use, you you you should have some good monitoring tool. You should have some CICD tools that will be embedded into your into your architecture. It should be the organic parts of your architecture. I think I think we've kind of also answered the final

42:31 Cloud Native, Agile, and DevOps

42:32 viewer question there as well with with our kind of answer there. The final question was, you know, does Cloud Native complement or compete with methodologies like agile and DevOps? And I think the same answer applies here is that you just should have all these good practices in place regardless of being Cloud Native or not. And then cloud native is just gonna hopefully enrich those processes that you've already built through good engineering, I guess. Yep. Yep. The term DevOps or agile, they've been they've been emerged way before cloud native definition has emerged. But today today, they're typically used in the same sentence.

43:10 Again, they're not sign in names. They're not meaning the same, but they are complementary and with with the cloud native technologies, you can you can boost your you can use your you can boost your DevOps DevOps partners in a way more efficient way that you can do before, like, ten years ago, for example, when how many was noticing. Excellent. Cool. I think we've answered a lot of of of really good questions there. Awesome. So is there Good news. Yeah. Yeah. Yeah. No. It's like it's such a I think there's a lot of misconception. I think there's a lot of

43:36 Conclusion

43:49 ambiguity. I think people you see so much, you know, on Twitter and through articles about cloud native, about Kubernetes, about all these tools. Of course, you know, KubeCon and the CloudNativeCons are just such massive events. So there's a lot of buzz and a lot of I guess for the people that haven't gone down this path yet, maybe a lot of fear as well. It's quite intimidating and, know, hopefully just taking a few of these questions and giving people a little bit of confidence and insight into what they need to do this is really gonna help.

44:17 So thank you very much for joining me today. Thank you for inviting me. If you have any final thoughts, you may drop them now. Otherwise, again, thank you very much. It has been an absolute pleasure. Of course. Thank you for inviting me, and glad to be here. Alright. Well, thank you. You have a great day, and I I will speak to you soon. Adios. Sure.