 Hello, good morning. Welcome to our live webinar about how to make your app cloud-native. My name is Marijn. I work at True. True is a nice company we do manage hosting. Mostly a technical crowd. 70% of us are an engineer. We tender mostly to startups and scalabs. And we've been in web hosting for about 20 years. We do public private clouds and Azure. And also hybrid environments. And we've been doing Azure and Kubernetes since 2017. And we've gone in the last 20 years from a traditional operations company to a DevOps company. And we're Mavericks at heart. Then, of course, you'll immediately think of Top Gun. We're not that kind of Maverick. We're not flying any F-16s or jets. But we are the type of Maverick that always questions your direction you want to go. And in that sense, we love to talk about cloud-native development and cloud-native applications in general. My name is Marijn. I'm a Solutions Architect at True. My background is in systems engineering. And I've been around in managed hosting since 2013. I'm a Kubernetes-certified administrator. And True, as of today, is also a Kubernetes-certified solution provider. I'm here with Marijn. I think you can introduce yourself. Well, thank you, Marijn. It's very nice to have a colleague that has almost the same name. And it has a lot of challenges within the company. But I'm Marijn van Kalka. I'm working at True since April this year. And within my role as a solution architect, I'm mainly focusing on clouds and Kubernetes and to get people onboarding on that platform. So today, I want to give you some insights in what we're doing, where we're talking about, and how you can take advantage of this topic, the cloud-native environment and services. Let me get the clicker. The topics. Today, I will be talking about our definition of cloud-native. We have to set a definition to make sure everyone has talking about the same thing. We're going to tell you a little bit of what that's going to, how cloud-native and the cloud is going to impact your application and the advantages it can bring to your organization and your application as well. Last but not least, we will tell a lot of Kubernetes and we will mention it a lot. But we're going to tell you what a container is and how you can take advantage of it. And if you need to go to Kubernetes or not, we're going to end up with a demonstration in which we will show you some workarounds, how you can work with containers, and how you can set up pipelining for them to get some really nice benefits from that. So before we continue, I forgot to mention, for those of you that are watching live, feel free to ask any questions and I'll ask them to Martijn as we go along, or maybe I'll answer them myself. Or if you're watching a recorded version, feel free to shoot us an email or a message on LinkedIn. Definitely, thank you. Cloud-native and it's a very booming topic right now and we need to define what it is and before we can use it and fill it in. So to do so, I want to start with the definition of the cloud and the cloud for us means some computational units you usually can consume as a service. You can consume those by API and so they are scalable. There are more than two servers within your rack, within your data center and if you're doing it right, sometimes you don't have to manage the hardware, sometimes you don't have to manage the middleware and we'll have a look at that as well and that all you will be able to, and that all is available in the pay as you go model. So you only pay for the usage you're doing there. So I talked a little bit about the services and the cloud products and you can consume those via an API and you need to think about infrastructure as a code. You can also think about platform as a code where we will come to in the next slide but if you're going to consume your platform via infrastructure as a code, you need to make sure that you are aware of all the things that you have to manage your own virtual machines, you have to patch them, you have to update them, so you still need to manage a lot. However, you don't have to manage the infrastructure, so the physical hardware, the data center, et cetera. So it can have some benefits but you still need to do a lot. If we continue, the next stage is platform as a service which you can consume and the platform as a service is an interesting one because it has a very wide variety of services you can consume and you can consume Kubernetes as a service or you can consume storage as a service and both come in different versions but you have complete different separations of concern and what you need to manage and what they're managing for you. So make sure that when you start using platform as a service within your organization or within the cloud that you understand what kind or where you are responsible for. The fun part here about Kubernetes is when you're using Kubernetes as a platform as a service you're still responsible for that runtime and the middleware because you need to store them, to build them within your container without that and if you're doing that or not correct you don't get the benefits of that platform and it will work against you. The last platform I want to talk about is Functions. Functions has a service and this is a really nice booming. Well, service products are created around it where we saw a few years ago that you're only available or capable of storing some single file script files to execute them to do some input and you get some output from it. They're evolving and currently you see that they're also able to have a container runtime so they support your own container and that has created enormous services around it which are very nice but you still need to build your own container if you want to do it that way. So what is Cloud Native? And I think the CNCF sums it up very correctly. You have that cloud and you want to integrate with that cloud and you want to take advantages of it. So you need to understand all the components the cloud has to offer you before you can take advantage of it. So if you understand what your, if you understand the components you also need to understand your application and where your application is capable of doing. If your application really depends on storage for instance maybe functions is not the way to go because functions well then to don't have storage in general you have to configure that in some kind of way. So it's not quite simple and to go to the cloud you really need to think of both of them. So when you're ready the impact it has on your application and when you should think of when you move to the cloud you're probably gonna start with some decoupling all the services within your application. And your application needs to be as stateless as possible and if you want to have that functionality within your application you want to extract that to a different service. So you see that all the components within your application you're gonna make services around to provide to that application. You want that components to be as immutable as possible. So if one dies or crashes it can spins up a new one. Your orchestrator can spins up new ones. And that really is one of the benefits of the cloudware. If you're doing it right your container might be killed because it crashed and a new one is already running for you. You haven't even noticed the downtime there. And to achieve that you need to design your application and everything around that for automation and to make sure that it is able to run within that environment. So the question is then where to start and probably when you're starting there will be some kind of questions and you're gonna start searching for the right tooling. And there is a lot of tooling currently available within the landscape of CNCF. And what CNCF has done they have created the landscape of all the available toolings right now which you can use to take advantages of that cloud to integrate with the cloud. And you can use them for scaling, for orchestrating, et cetera. Well we usually see that this landscape is a bit overwhelming. So before you start using this before you when you look at this for the first time you might think where do I need to begin? And that's why the CNCF also created the trail map. The trail map is really nice when you want to say make your first step within the cloud native landscape. And it starts with containerization. You should containerize your application and I will come back to that in the next two slides. When you've done your containerization you need to set up proper CI-NCD for that application to make sure that whatever you do, whatever new commits you do to your application whatever changes you do it will be delivered in the environment what you're targeting. And it's fine when you're starting with CI-CD to only start with building and testing. You don't have to go to production yet make sure you get confidence within that process though that you know what the output is and when you have it that's your confidence to go to such environments. When you're done with that you're probably going to look at an orchestration platform. So how are you going to run that container or your code that you've built within? And from there if you're running it you want to observe it. And from there you're going to go to step five you probably want to have a service proxy or a service mesh to manage more than just your application. From there on you're going probably to networking and policies. How Kubernetes itself is very open and a lot of cloud providers are open by default so you need to set some rules about who's going to talk to who and who's allowed to consume those services you've created and deployed. So you want to create some policies about it to make sure that it's correct and updated when you need it. And when you've done that I think the next step should be security but that's the only thing I'm missing on this trail map because security when you're going to the cloud or you're going to anywhere with your software is something you need to think of. The rest of these steps so seven, eight, nine and 10 are a bit out of scope I think for this presentation and I don't want to touch them. And I want to continue with the advantage of containers. We've already mentioned it a lot but building your application packing your application into a container really gives you the advantages of portability where you can build one container and run it anywhere. So on my laptop, in the cloud, in Kubernetes two internet of things devices on the edge or even functions as I mentioned. So you have a consistent operations of all those environments you will create and want to deploy to. By so, you can benefit of scalability. If your application, your container is tiny enough and it doesn't depend on too much and it is immutable you can scale it quite easily across all the options you have. And by doing so, containers usually tend to have less overhead than virtual machines. It's quicker. You don't have to manage the virtual machines. All your dependencies are already in your container. So it's quite easy to take those advantages. Last but not least is isolation. And it's possible to achieve that. As you see, there is a star behind it and that's because you need to do it very good. You need to think of how you can isolate your container because by default your container will be running probably as root, can do anything, can connect to everything. So you need to make sure that your container is isolated. All right. So now that you've talked a bit about the advantages of using containers are there any moments that you would advise against using containers or maybe even advise against using Kubernetes? Yeah, definitely. For applications that don't have to be the portability or don't need the portability or the scalability or have a very hard dependency on storage for instance, databases currently. Not making sense. You see a bit of flip within the world right now and you operate the pattern Kubernetes is providing you. It's more easier to schedule the containers on the note you want to have. But Kubernetes itself doesn't is not aware of the underlying infrastructure. So it will just schedule your container everywhere on that platform. So if you have a hard dependency on networking or maybe storage, you might think twice to go to containers or to go to Kubernetes. All right. And then another question is, at what point should you start working with Kubernetes? Do you need to have this wonderful microservice application before you start looking into this or can you just move any application to Kubernetes? Definitely, you can move, I think almost any application to Kubernetes. I think that's where the challenge currently is. We see a lot of people adopting it but we also always ask questions to a customer, do you really need to run on Kubernetes? We see a lot of function providers, app services in the cloud where you can deploy a single container for your single application and for your probably a single WordPress installation that's gonna be a very good runtime for that application as well. So you don't have to go to Kubernetes all the time. All right. Well, it's time for some demo. Do you have some questions already? That was it for now. That was it for now. If anybody has any questions, please do send them in. We'd love to hear from you to get some interaction. Let's see if we can switch screens. I think that will be nice. And I'm wondering if the audience can see my screen. I have no clue if that's possible right now. I believe that we're live with the demo. Cool. So in this demo, I'm gonna demonstrate the advantages containers can bring you and the advantages you're pipelining when you have created them can give you as well. And what we're gonna focus on is the application. So we're gonna make an application. We're gonna create an application. We're gonna build it and we're gonna push it first to a registry. And from there on, we're gonna use it to create an environment for to run it on. So what we're gonna do, I've prepared a few things. And I think I'm going to do my last slide first. Because when we're gonna deliver this application, what we're gonna do is we're gonna use the registry in where we've pushed the charge and the application. Little technical difficulties I see. Ooh, it's switched. There we go. Aha, very nice. And we're gonna use, normally you would use if you're moving to Kubernetes, you would start with some GitOps methodology. And what that means is that you have your registry of your application, the definition of your application living within a Git repository or within a Helm registry. From there on, your GitOps tooling and in this case that's argocd for us, it will pull continuously for changes within that registry or that repository. So on the other side, it will look in Kubernetes to see what the state of that application is, what you've defined in Git and it will compare those constantly. So when that application is out of sync, so I've updated my application spec and I want to go to a new version, argocd will notice that we'll prepare a deployment and if I want it, I can sync that automatically to my environment. The advantages of this and of all those tooling is that you can integrate them with your own workflow and I really want to take advantage of using argocd and today I'm gonna not, I'm not gonna work from a GitOps perspective. I do, however, have a Helm repository prepared for this demo but I'm gonna use Argo to dynamic generate all the environments I need for this, in this example. So let's see if it's work. Let's see. So here's where the magic gonna happen. We have, let's see if I can make my screen a little bit bigger and everyone can see it. So what I've prepared is a code repository in GitLab some technical issues. Is it working or should I stop mirroring my screen? Okay, right. Yeah, I should stop mirroring the screen. Apparently when your computer goes into sleep it will do the magic for your display settings. It's not live if everything works in the first go, right? Yeah. This should be it. Cool, cool. Thank you. So what we're gonna look at today or now in this session is this repository and I've prepared it in GitLab because GitLab is my way to go tooling but feel free to use your own tooling and you need to be confident with tooling you're using and to take advantage of integrated in within your workflow and eventually within your cloud as well. So this automation repository I've created I've set up some templates and that template is gonna help me with all the other projects I'm gonna create to build and to run in my cloud environment. So what I have here I've created the build stage in which I the only thing I'm doing is I'm building a container from a Docker file. I'm logging into my registry so from there on I can push that container that I've built to the registry. Then the first step I've showed so here, then it's mirroring again, right? Interesting how this works. When I've pushed it we've completed the containerization of our application and then it's living inside the registry. From there on I can probably trigger RGocd to update my application or to create the environment for that application and use it and test it if that's what we want. So let's go. I've set up a demo and what I'm gonna do here I have the same as on Git, on GitLab but I've created a very small is it still there? Apparently we're not on screen. Yeah, yeah. Now we're on screen or we're not on screen. And we're not on screen. What we're seeing. This. At least you have a very, very clean desktop. Yeah, for demo purposes. I'm sharing my screen way too often. Yeah, you should see this. So what I have is the automation repository here and I have a very small script. That script is gonna create a new repository and populate it with a CI CD file which only includes the templates I've created here. I do create a very tiny Docker file to make sure we have a working container. It's only based on Nginx. So if I create a new repository, my pipelining should be in place directly. Let's see if that's still working. Create a project name and I've already populated this one with we are going to the cloud because that's where we wanna end up today. I've registered a domain name for it so I want to use it and the help chart I've created for this one as well and the version of my help chart. So when I do that, it will trigger a few APIs to make sure GitLab has the repository and have set up all the stuff I need. There it opens directly my code editor and from there on, if I run this one in, that's the, you should have a presentation mode of this one but it's always under the, It's never where you expect it. Yeah, exactly that. So if there is someone in the chat that can lie on me, that would be brilliant. You could probably search under help. Where did you saw that one? Now if you go all the way to the help on the right, now just there in the top bar are there a presentation mode, there we go. Ah, there you can configure it. That's nice, that's nice. Run, I would window, I would say it would be on the window or under view but otherwise I just gonna continue tools appearance and the presentation mode. There we are. So as I said, the script I'm running, what it does, it creates the GitLab CI YAML and the pipelines I want to use and it includes the projects, it includes the scripts I've set up. So the build, I want to build that Docker image and I want to run it as well. The Docker file is very easy. I've set up a, well, a waiting page and that's where it coming soon. So we're gonna serve that one in our application. What's happening now, it's already pushed to GitLab and when I'm here you see there is a new repository. That repository is already been populated and you see that here, it's the same, it has the same Docker file and it has the same GitLab CI YAML specification. When we go to the CI CD environment, you will see that there are three pipelines created. Or at least one pipeline with three stages and we have done that in the automation part and I want to start with that first. Because the automation part is what I've done here is I've set up a default branching deployment strategy and what I'm using there, what I'm doing there is that all comments that are pushed to the main branch, so in this case it should be master, will be deployed to the staging environment. We're gonna use ARGO CD first to check if such environment already exists. So if the application is configured and when it's not, we will create the environment and after that we will update the image tag to make sure it has the latest version of what we've built. So it's very nice, you will make sure of your sure that each project you're creating will have a staging environment which has already been populated with a working CI CD experience. Well, that's nice, but let's see if it's worked and if I go to ARGO CD, you see a new app is appearing on the right and that's that we are going to the cloud staging environment and there you can see that the Helm chart I've specified, ARGO CD, well, kind of enlightens you what the resources are you gonna deploy or it has deployed on Kubernetes. I've automated this step, so everything I'm giving ARGO CD will be deployed directly to the staging environment. You can however choose to make that a manual step but for this demo I wanted to have this automated. If I press this demo, there I have a coming soon landing space for this application. So what we've done is we have created a repository and from there on your pipelining is direct in place, you have a Docker file which you can extend to other well, needings for applications and from there on your pipelining is in place to not only deliver it, but eventually we can extend that to testing as well because when we've built a container you definitely want to test it on all reasonable abilities. So just to make sure this website is now live, right? It's live, I have a look on it. So I can actually go use my browser and go to staging.we are going to the dot cloud. Yes. And there it is, it works on my machine. So I'm hoping it's working on yours. That's nice. We have this application and I think from here on we do want to have, well, something more than just this landing space and which you normally would do in a company if you have this environment and you want to iterate for a new version, you probably will check out a new branch based on this current version and from there on start changing the code of that application. The challenge you most of the time have is that you want to create a temporary environment to check out the changes you're having and you've done. So what we're gonna do is I've set up a different piece of pipelining of templating which allows me to create environments based on feature, well, namespacing. So each branch that I commit to a feature branch will be delivered in a new environment. New environments will be created. So what we're gonna do, I have a demo application or at least a demo landing space, landing space which is a little bit better than this one and what I'm gonna do is I'm gonna deploy it in four different feature branches and then you can vote on which of those feature branches we will eventually push first to the acceptance environment when we merge it and after that we will take it for production. Shall we see if that's working, if that's gonna work? Let's see. Cool. Looking forward to it. So we have the, we are going to the cloud repository over here. I have to admit I did some work before so what I'm gonna do is I'm gonna copy my, it's a dot temp and from here I have the red to HD. Index.html. So if I now performing a git diff, you can see there is a lot of stuff changed. I'm gonna check out a feature branch. Let's see which color I had. I had the red one. So I'm gonna git checkout feature with the ID that I'm gonna create a new environment which will be prefixed with feature red. And from there on I'm gonna see all the changes that I've made. Git commit, I'm gonna commit all the changes. Test red landings page. Yeah, very nice. Always be secure. I'm gonna do the same for the yellow one. So what I'm gonna do here, I currently git status don't have any changes because I've already commit everything. I'm gonna use the same copy command. Yellow should write it correctly. I'm gonna check it out in a different branch. I'm gonna commit this as well. So check the yellow landings place, landings page. Always be secure. So what we've done, within the, we are going to the cloud repository. We have created branches, so two branches and you see that automatically the pipelines are running for those branches. So you see here, I have two new pipelines, two feature pipelines. One is already finished, the red one and the other one, the yellow is currently still running. If I go back to Argo CD, you see there is a new environment created, a new application created, which is based on that branching model. So if I'm going to, if I'm clicking on that and wanna see the application, apparently it's still waiting for the SSL certificates, but it's not, ah, there it is. We have a red version of our landings page. I would say it's a great success from here, but we're not there because we've also deployed the yellow one and that one should be ready in a few seconds as well. Aha, it's working as well. It's always nice if something is working or almost everything is working. On my end, I'm still getting a certificate warning. So I think you might have some point to prove that certificate while you were testing. We'll see. So I'm gonna push two more colors and then let's have a vote about which one we will have to ship to production. I have a purple one as well. Committed, my changes. View. Purple landings page. And then we have the last one and the question is what color did it was? We have a red one, a yellow one and the purple one. So I think we also have a blue one. So if people would like to visit this, where would they find these pages now as they're being created? You mean the domains to visit the website? So I've prefixed the branching name within the domain name. So if you go, if you have the main domain name, we are going to the cloud. If you prefixed that domain name with a subdomain as feature dash red, you should be able to visit that one. So feature minus red, let's, I can only zoom in my, I cannot zoom in my. In your browser. Yeah, my domain name. To your domain name. But it's feature dash red. We are going to the dot cloud. Yes, it is. And then of course you also have feature dash yellow. Feature dash yellow for sure. And currently the purple one is being deployed. So the feature purple and I'm quickly going to create the, I've already been there. So I'm going to copy this one. And I have the blue one. And that will be the last one. Good. Check out. And then we're going to have the blue one. So we want to deliver the blue one. Get commit blue landings page. I like my really descriptive commit messages today. Thankfully the branch names speak for themselves. I hope so. So these pipelines are being created and you can already have a look. And what we want to have is to have your vote. Marijn is going to open the poll to see which color, the red one, the blue one, the yellow one or the purple one. We are going to merge into the main branch. So the main branch, what we have created this one, we want to change that one to the new version. And it's up to you which one it's going to be. It's going to be the blue one, the red one, the yellow one or the purple one. If you open the poll. I have opened the poll. There should be a poll. And you should be able to choose which color you like most. And that's what we're going to deploy eventually to production for we are going to the cloud. And while we wait for that, so you've been showing how you've basically created feature branches based on copy pasted HTML files. But I guess this is just your normal Git workflow, right? Yeah, you can do this with anything. And this is now a basic aesthetic HTML file but I can also change this container to a PHP container and run my PHP application. So my Laravel backend or a symphony backend or maybe even a WordPress backend. I can use this same pipelining methods what I've created for all those applications. Right. So if you were to have a larger application than this static landing page, you could just make a... Definitely, definitely. You could definitely clone this repository, make some changes, push a new feature branch. Yeah. And I think one of the things what might be nice to see if we can get this to work is if I do a Git checkout going back to my default branch, I haven't updated my Git yet. So I'm still using the master terminology. Sorry for that. And what I'm gonna do is I'm gonna do a Git checkout. I do gonna use the feature as well but switch to PHP. And let's see if we can create a PHP container in which we're gonna do from PHP. And what's currently the latest version, 8.01, I think so. What we're gonna do here is a echo. Gonna do a little bit of magic here and I advise you to not do this in your production environment as well. But for the sake of this demo, let's use this, expose port 80 and I'm gonna use as command PHP dash as I want to serve PHP internal web browser. And as I said, I would not recommend you to do this in production. I want to listen to port 80 as I'm exposing it and I want to serve the index. PHP and I see I'm forgetting that here, index.php. Close this one and from here, this should be it. And I think this is gonna work. Looks same to me. If we'll find out. We're gonna find out for sure. Yes, that's what I expected. I'm gonna commit my changes into my feature branch and switch to a PHP backend. And if I'm pushing this change, I first need to make sure I insert my password and then within here, get up, you should see a new pipeline for that feature branch. We're gonna wait on that. But first I wanna ask you mind, how is the poll going? I'm not actually sure. I'm seeing that the poll is running. I'm not quite sure if someone behind the screens can see whether we have results in already. Or maybe do have results. So I think we're eager for the answer. So I'm gonna end the poll and I'm hoping, hoping that it will then let me do something. But of course this is live and I don't get to click anywhere. I do however made a mistake here. I don't have to export the, but I need to expose this one for sure. Get commit and I'm gonna change it while I'm fix. There we go. Yep, I see them now. Thank you, I had a little issue with my browser and I also see that there's some questions that came in. So that's also really cool. Very nice. While I end the poll, we see that 25% went for blue and this is wonderful because I ended the poll and now it disappeared. But I think everybody overwhelmingly chose red. Chose red, that's nice of you. So there was an overwhelming, there's a 50% red, there's 25% blue and 25% purple. Somehow nobody went for yellow. For yellow. So there we have it. So that's cool. So I think we should merge the red branch into the main branch. Into the main branch. Cool, let's do that. I don't have any merge request yet. So I'm gonna create a new merge request and I want to merge in the correct branch. No, I want to change branches and I want to merge the feature red into master. I want to compare it. And I should see the changes here that have been done. It's only the static content of the index.psp. And we're gonna, yeah, description. I think the title is enough for this merge request. Create it and then I'm gonna merge it directly as well. All right. Some sanity checks over there. You also got some questions. I had some questions, yeah. I'll start at the top. We had Tim ask us, hi guys, can you tell me what the difference is between app cloudification and app modernization? That's a very good question. I'm not very familiar with the app modernization and app cloudification terms. Do you have any context about that? There was none that was given, but I'm gonna add a little bit here a little bit then. I think that if you modernize your application is usually a play where you take your application and you change, you really change it to work in a cloud native or in a modern ecosystem. Whereas I think that app cloudification would refer more to taking your application and is basically running it in the cloud. So more like a lift and shift. Lift and shift indeed. Yeah. And I think the advantage of modernizing your application is that you take advantage of all these cloud native capabilities that you now have. And I think that will give you either performance or security or financial benefits in running your application. Sounds good. I had another question from Robert, asking, what are the typical pitfalls in an app modernization project? And when should you not do it? Ooh, that's a very nice question. I think it really depends on your application. And what we tend to see sometimes is like the legacy applications that people are not sure what's inside that. You can try to containerize it and to see if you can run it on that machine within that container as well. But you need to make sure that stuff is configurable. So if you're gonna lift it to another platform that you can configure the endpoints, et cetera. So if you're not sure about that, you really need to ask yourself if you want to do that. It is, however, a very nice challenge. But it's definitely a, how do you say it, a fuck apart? Yeah, it's definitely a profession. Yeah, definitely a profession. Thank you for that one. Yeah, yeah. So there's the, I think another thing, when should you not do it? I think you need to realize that you have to go into it for the right reasons. So if your reason to go to the cloud is because somebody once heard that it's the next thing, that's not maybe gonna bring you the results. Maybe think about what you want from your app monetization, what the desired outcomes are, and work from there. And another one that you need to realize that is this, depending on your application size, of course, for a simple HTML landing page, it's a relatively small project, but if you have anything that's of any size running in production, I think really think about how much time this is gonna take you. Yeah, if it's worth the effort and the cost. And definitely maybe find help. There are a lot of companies like us that would love to help you do this in a structured way. And you see that the cloud native landscape is overwhelming. We already mentioned that. Find the right people, pursed companies to help you to get familiar with the context about it. Especially with those legacy applications. We're back, I think, at the staging environment. We've merged the red branch into the staging environment, and you've probably already updated your application. But let's see, or your application, yeah, your environment, but let's see what happens when I refresh my page. And there it is. Oh, that's pretty easy, I would say. So the red one is on staging, and now we have to do one thing. And I've chosen for this one, before I go to production, to only do that with text commits. So when I go back to the, we are going to the cloud, I've created the same set of automation templates for text commits. So what happens is when you take a commit, it will run the same pipelines, but then it will end up on the production environment. There is one catch. After the refactor, I did not test it, so we will see if it's still working. I'm going to the commits. This is my last commit. I merged the branch, and I'm gonna attack this one, and let's start with version 2.0. 0, because I like that. And from there on, we should see some new pipelines being created. And before that's running, let's see that we are going to the cloud, doesn't have a backend yet. So it's all live, nothing has been configured in advance. The pipeline will create the environment, et cetera. Are there more questions? There are, actually. Paco asks, how to deal with app-to-database latency in a cloud context? So how to compete with, for instance, ZOS app-to-database contiguous memory use when transposing your app and your database to the cloud? Ooh, that's a very specific question. Don't you think? Super specific. I'm very curious about the context as well, but what we see is when people are moving to the cloud, hmm, my pipeline is failing. I will dive into that one after this question. But when people lift and shift their stuff to the cloud, the cloud environment is tend to be different than, well, your local environment. So where your server is standing, probably close to the database, the cloud environment, yeah, we cannot guarantee that it's so close to each other. And those delays, we would always recommend you to keep your environment as small as possible. And we're not a big fan of going, you can go multi-cloud and deploy application over multiple regions, et cetera. But we try to keep all the components for a single application, for a single service within a region. So that should prevent delays, et cetera, or at least minimize the delays. So we would recommend you to keep them within that application or within that environment, within that region. And if it's not working for you, you should probably ask yourself a question, if this is the right way, have you used the correct services and maybe you should get some help from an expert because the landscape is very wide, very different. And we see each month, each year, new services pop up, which are probably better. So you need to keep in line with that. I completely agree. And I think to add to it, what you see often is if you have a single instance running both your application and your database, you're introducing a network, so you're introducing latency between the two. And also what people often tend to forget is that these cloud network environments tend to have transient error. So maybe the network is just slow for a little bit or there might be a little congestion somewhere on a switch. And you should really make sure that your database connection, your application is ready to really deal with that sort of transient error and also detect whether this is something that you maybe need to retry once or twice. But never forever, or that you should just give up because things are really, really down. And I think the better that you do this, the better that you're gonna be able to leverage a cloud environment. Cool. So while I'm trying to deburke this one, ah, I probably see what I did wrong over there. Yesterday I had a really nice question, session with a client where we did exactly that as well. And that is deburking YAML, make sure that everything is on the same line. Should do the trick. Fix YAML, I like it. Let's see if we can retry and then I'm not sure if it will retrieve the same template as I've already provided or it will refatch the updated version of this one. Let's wait for the bill to run. We're all very tense. I'm hoping that this, is it? No. No, it's not, it's not. Oh, yo, yo, yo, yo. This is how you know that we're really live. Yeah. Is the error message I expected still the same error? So I'm not sure if it's, it will retrieve the new updated version of this template. So that's a challenge. I'm gonna re-tag it to at least make sure that I'm starting a new pipeline and that I will retrieve the new version of the templates I've created. All right. I have to go to commits. I have my commit over here and I'm gonna tag this one to a serum. Let's see, I would. Release two, the one that has a fixed YAML? Definitely. Should use the pipeline with the fixed YAML. And then let's see if it, let's request our close. Always trouble finding the right icons on the left sidebar. We're gonna wait. So do we have any other questions waiting? I didn't see any more, any more questions coming in, but if you do have a question, feel free to ask it. Absolutely. I'm glad to see that we have some questions and some interaction with the crowd. And I'm curious if we answer the questions and expectations you had from this session. So after this, you should be able, or we hope you have some guidelines to start with your cloud native journey. This is fingers crossed. Looking promising. I think it did. There we have it. Hey, and this is very nice. It's out of sync and it's not deployed. And how does that come? Cause I've disabled automatic deployment to production. I want to have that manual trigger. And that really is one of the advantages of using ARGA CD in this use case. So if I'm gonna roll this to production, I first can check the version that's there. And from there, I'm gonna synchronize it to the environment. I think I don't have a production namespace. So I'm just gonna leave that checkbox there and I'm gonna synchronize it. And from there, it should obtain the TLS certificate and it should deploy the application. So this is where we ended last time. We didn't have any backend. If we refresh it, we should see the red website live. There we go. So if you visit, we are going to the dot cloud right now, then you should see this wonderful red. See the same as me. And all the ingredients you used basically were a GitLab pipeline, ARGA CD, a Helm chart. I have an Helm chart. It's a very easy one. I do not want to go in detail about that one, but it exists of a deployment, which is a very small definition about container. I want to run on this environment. It has a service because I want to expose this container and a piece of ingress in which I've set up some TLS for that. So it will obtain an automatically generated certificate for that environment. We do have one more environment running and let's see if I can open it because we have created the PHP branch. Do you remember? Yeah. Let's see what happens when I open it. Ta-da. That's nice. So we did a PHP version, well, more of a dump of all the configuration. And there you can see that we have successfully deployed this PHP container. All right. So it's super cool that this works. And this also shows you the flexibility of this whole process. So you could just take your own application. I mean, if it takes this little time to even change coding language, well, is HTML really language? But if it takes you this little time to really remodel your app in such a way and just see it running in a place where you can see it, where maybe your clients can see it and approve of it. Yeah, definitely. It seems like a really powerful way of developing to me at least. I have one more follow-up question from Paco and his question is, so if you were to move this legacy application to the cloud with millions of records being dealt with from both database and flat files in the cloud, what would be the best practices? And his question specifically is, would you remodel the process so it does not deal with more than a million records? Sorry, can you just repeat the question? So the question is really, if you're moving your application to the cloud and you're dealing with millions of records being dealt with from both the database and flat files, then what are your best practices? Should you remodel your process so it doesn't have to deal with these millions of records? It's an oddly specific question. Yeah, again, again. I like it. If you have any follow-up questions about this, by the way, Paco, feel free to contact us. Yeah, definitely. Because I think we need a little bit more context for this sort of a situation. But I think there's some general stuff you can say about this. Yeah, can you, is it allowed to have downtime for your application? Can we just pick it up, shut it down and transfer it to the cloud? Or is that not possible? That are basically the first question to ask. And if it's not, then we need to probably design something around it that maybe you can, how do we, how do you tend to say it? The store different, God, wait it now. You can distribute specific resources to specific end points. So you start using the cloud and you slowly kind of fill that one up with your new resources. So you have a very smooth transition. If that's not possible, we should probably think of some other methods. Exactly. Yeah, and I think another one, I mean, you're talking about a batch process. So the biggest question is, what is your application doing here? Is this maybe an ETL process that you're running? There are strategies to deal with this. One could be using a message queue to split up this work into different applications. So this is super application specific. But if you wanna get started on looking at how you might use this strategy, other than contacting us, obviously, or a party like us, is that you could go and have a look at 12factor.net and they will have some guidelines on how to deal with these kinds of operations. And it might give you some inspiration to rework your application, to live in a cloud context really. Cool, cool. So I'm not sure if you were able to see my screen while I was doing some magic stuff for most of the people that were watching. I've created a new repository in the same way. I've set it up the first one and I've given that the name of myself, so Martijn van Kalker, and I've configured that with the domain name of Martijn van Kalker.net. It's pointing to the same server and it will make sure that over a few minutes, a future environment or at least a staging environment will be populated with a coming soon welcome message. So if you want to have a look at that, check it out. And I think for now we're, well, it should be deployed. I see that's for someone else and later on, yeah. Cool. I think we're currently at the end of our, we're at the end, we're slightly over time I see. So thanks everyone for watching. We hope to talk to you or see you again soon. Feel free to hit us up on LinkedIn or shoot us an email if you'd like to. Definitely. Thanks all for joining and we'd love to hear from you.