 for questions so if you have any burning questions please interrupt me if it can wait later and if we don't have time you can talk to me just just after the session there were just outside one minutes okay so it starts again thanks everyone for joining me in this talk today both online and physically and the topic for the next 40 minutes is going to be developing cloud native application with containerized database I'm going to be focusing on the developer experience and the tool sets that is required to do this kind of stuff with a more practical approach where I would go through a demo of the you know let's say Kubernetes specific pipeline right and when I say Coup native this is a talk about Kubernetes like I breathe Kubernetes every day I've been working with it for about six years both on the CNI when I was working at Cisco and CSI more recently I've joined a company called on that where we provide distributed storage for communities so sort of a hyperconversion environment for communities with additional capabilities like replication encryption all this kind of stuff but everything I'm trying to do is always with a developer in mind in particular the DevOps tool sets so I'm not going to be talking about how to build you know the best possible Docker images or using cosine this kind of you know security is much more about the DevOps experience in the tool sets that you can use without leaving Kubernetes but first let's define what is a cloud native application you know quite often we heard we are hearing that cloud is just running stuff on someone else's computer and if you do things like lift and shift well in the cloud that doesn't necessarily mean that your application is cloud native so cloud native means a lot of different things but mainly a cloud native application is an application that is aligned with the 12 factor apps so I don't know if you guys already familiar with this hopefully you are some sort of familiar with that you have the link there and in the context of Kubernetes there are a couple of you know patterns or principle I want to highlight so cloud native application you need to stall the configuration in the environment so we all know bad practices how many developer in the room so some of you are developers right so bad practices in development is hard coding variables or anything you need configuration environments as part of your code right so the idea of a cloud native application is to store configuration in the environment and well with communities we have a lot of option to do so there's config maps there are secrets etc so the first thing to you know to to build to do to build a cloud native application is to remove all the hard-coded stuff from your existing app if you want to walk to build a new one and have this principle that is applied and of course the configuration needs to be separate from from the code then a second principle is to treat the backing services as attach resources loosely coupled with your application or with your code so that means that you should be able to swap quite easily for example if you want to talk to another database using another mailing service another you know another bucket or another other external APIs you should be able to to be you should be able to swap fast and without any consequences in your code right so your code should be implementing the necessary abstractions to enable that then there is this principle which is about executing the app as one or more stateless processes and this talk is also about integrating stateful application stateful components and one of them which just appeared earlier was database so effectively a database is a stateful components of the application but here we are really talking about the expectation in terms of the application itself which is if you do things like you know caching for your sessions this is not a line as part of the application not as part of an external or attached service it's not part or you know you're not aligned with the 12 factor apps patterns this should be part of a external components so it's really about the app itself the core app should be stateless running potentially as you know Kubernetes pods communities deployment this kind of things but however and this is where I want to go database can be run in communities we're gonna see how and what are you know some of the best practices to do so but there are a couple of reasons to do it first well it's collocated with your application so in terms of latency well you're inside the same cluster so potentially same host or worst case scenario same availability zone or potentially same region and if you are in the same data center maybe like a different rack so super fast the other reason may be that you want to leverage the or you know leverage the embedded quality I mean I would say the features of communities things like resiliency the fact that it's completely distributed so highly available all that's our features that are present natively in Kubernetes so as soon as you put a workload in communities you can also with the benefits of the same features another one which is really key is dev prod parity and the idea here is to reduce the gap between dev and prod in terms of multiple angle multiple layers so first people where for a clownative application you should have the same person that's are who are deploying the application in development and in production right this is basically the principle of DevOps it's not like the operational team deploying production and the dev deploying in the dev or staging environment that should be the same you know set of people then also a gap in terms of time changing the code in you know as a developer in your development environment should and then having a lag to production of several months this is not how you build a clownative application this should be more in terms of hours and if you really want to go while it can be minutes with a continuous you know deployment kind of life and then the last one is of course reducing the gap between the environment and this is really related to the notion of shifting left so I don't know if as anyone heard about this term shifting left yes some of you so the idea of shift left is to bring testing as close as possible to the early development stages so it can be test driven or have your own driven as well sync type to check a spot of your pipeline very early potentially involving QA in the design session which may be hard but they may require two very early to test very early so that may be part of the design as well and a good benefit of communities is that you can build on the de facto characteristics of communities and communities the way I like to see it is as a as a platform of course but where you can represent your infrastructure requirements as code or today say as Yama right and then you can use technology like github to even increase the level of security and to have better control to just get as your single source of truth and but it is not limited to Kubernetes objects so I mentioned you know I'm working for on that which is distributed storage company and but there are other open open source solution that provide this kind of features as well and the idea is really to use the CSI driver remember we're in the context of stateful workloads right stateful workloads their properties is really to persist data to disk and what is important is that in case of a node failure the data is not scratch the problem is if you use like a traditional you know basic CSI driver in Kubernetes you attach a PVC to your pod if the node fails where there's no replication for your data so of course this is at the storage layer you will have probably if you're building an application or a database let's say a stateful component you would have replication at the application level right you like for example MongoDB you will have multiple replicas so for sure you can you know base your high ability of based on that but the reality is if a node fails and if you have more let's say if you have a three node MongoDB cluster you lose one replica one MongoDB replica then you need to rebuild the new MongoDB database or the replica you need to rebuild it create a new pod that would be created and then MongoDB has to rethink the data right and this depending on the database size they can take this can take hours and during that time you're essentially running in a degraded mode right so a better ID is to implement as part of the CSI like you will do in your you know very expensive storage array right back in the days you had synchronous replication you had encryption all those features for your most critical mission critical application and stateful application or mission critical so the idea is to bring this into Kubernetes this replication this encryption but because Kubernetes has this notion of infrastructure requirement as code embedded the ID is for this extra features also represent them as YAML as code you want to enable replication it's just a label you want to enable encryption another label right that's the idea and of course if you want to shift left it means well just using YAML for that so as you you're developing the Kubernetes application on your local laptop well you can still use this YAML file you can still have the software that is running in production in your local Kubernetes cluster including this DSI drivers for example and so once this is done once you have an idea of how to implement this you have to define where you want to do it right so if we're not using Kubernetes you can also use cloud native services of course to build a cloud native application right that's the principle so if one moment we don't consider probabilities well you can build things in Google cloud AWS you can build things on-prem with your own toolset but the reality is probably I don't know if your different companies are running workloads in depth so who has always running working in different clouds the different public clouds a couple of just one some so you are for other people it's just single cloud so who's running workloads single cloud okay no cloud at all still a couple okay so the way I see it talking to communities and users is most of the time large companies whether it's because of a merger acquisition or to use a specific feature like if you are a Oracle customer you're probably better run Oracle database in OCI right in Oracle cloud so what I see is more and more there is a multi-cloud strategy not necessarily for higher the ability but for you know more tactical or strategical approach because of all those things that happen in your in your enterprise and that you don't control and it means that in terms of skill sets you have to learn once you have learned how to do it in Google and now you have to do it all over again in AWS well it's you have to learn more stuff so the idea is really to use Kubernetes as a standard or as a cloud agnostic operating system to build your cloud native application regardless of the location can be on premises can be in public cloud it doesn't really matter and the way I like to see Kubernetes because it's this foundational layer I would say it's equivalent to the modern gipsy right infrastructure requirements or application requirements that are common across the board and yeah that's basically it but now in terms of the stateful component why could the real question is can you really do it in communities and what is the trend so if you listen to Gardner by 2023 you will have 75% of all databases that would be migrated to a cloud platform but it it's both a mix of DPS a service like RDS and also using Kubernetes to run databases because it's running in the cloud but the big difference trust me will be cost if you use RDS you will have tremendous cost in terms of you know EBS provisioning and in terms of availability as well remember most of the cloud disks they are contained the higher ability is limited to availability zone if you need to recover across availability zone there is downtime you need to script something you need to restore from snapshots all that right so you have to be careful with communities and the right tool sets you don't have to do this you can use local NVMe drives even in your instance using your own instance store as long as you have the right CSI drivers and you can have basically you can build on your knowledge which is Kubernetes and spread it across all the cloud and build databases in the cloud and here this is an example of the most popular images container images the source is a data that was late 2021 so there are 14 of them and most than half of them are stateful anyway right and what is really enable us to run databases and other stateful component in communities this is the operator so for those who are not familiar with the operator pattern it is a way to encapsulate some knowledge into a Kubernetes controller and customer resource definition so it's extending the Kubernetes API to represent anything as a Kubernetes first class citizen including database right so you will find a lot of different databases operators that allows you to do things like build a database because if you deploy a stateful sets which is the Kubernetes native object to deploy stateful stateful workloads well it just build the container does nothing on the app level but how about if you want to build a MongoDB database automatically as the stateful set is scaling up and down this is where the operator comes in it will detect that's the pods the number of pods are growing and then it will increase the size of the cluster do the replication you can do backup restore all these kind of things it's encapsulated in the operator and represented in the end as YAML again so we are back into our favorite format which is the YAML that's great it's love of hate in general with the YAML but again this is YAML it can be committed to Git it can be deployed via GitOps you can use police as code with it so it has all those benefits right so here a couple of examples before jump into the demo here is a data services requirements so I took on that as an example but it's valid with open source one and any other CSI who support this feature you can see here this is just saying I want two replicas oh yeah it's not it's two replicas encryption is true topology aware which is this ability to detect multiple availability zone and spread your replicas across different availability zone to true so it's as easy as this so remember the shift let's paradigm you can already simulate all the production environment in your on your local laptop because all of this is available as software and defined as YAML same thing with policy requirement this is an example of kevernal which I'm gonna I'm gonna have in the demo as well so the idea of police as code extended to the operator pattern for example for databases is to say imagining that in that particular case this is you we require more than two replicas so this is a two here it's a bit light so that means that if the number of replicas that you have sets in the previous YAML file is less than two then you are there are different way that kevernal is implementing the control can be an admission controller in that particular case when you're going to deploy that application in the cluster this state full set is going to be denied in the cluster so it won't be deployed or kevernal which is I'm going to show you also has a command line that is taking as an input all those policies return as YAML but not in communities just YAML taking this matching against your application manifest and as part of a command line result will tell you fail or pass which mean that you can include this into your global pipeline to deny or accept a merge for example right before even deploying into the cluster so that if you have a github's process in the end can only be triggered if the different tests including this has passed so you can do it's like number of replicas but imagine things like size of the database which is another parameter of the custom resource for your database you know for your database custom resource if you're using the database operator things like things like permission if you need to create a user with specific permission you can also check it and validate it with a cluster policy using kevernal everything in YAML so of course there are other tools you can use all-pocket keeper if you want to learn Rigo but this this is kubernetes this is only using YAML probably a bit less flexible than than Rigo but in to my knowledge like 80 percent of the use cases can be managed by using kevernal and again the ID is a couple of things checking this as early as possible in your dev environment and making sure that's in when you go to production you have all the compliances all your complaint compliance rules that can be applied into your different application manifests so I'm 25 that's 15 minute left so I have to go very fast now to explain the pipeline so as you can see there's a lot of moving parts but we can divide it in two section the first one is the top line here from left to right this is Sue our developer she is developing an application which is based on the Marvel API storing Marvel requests into a MongoDB database I'm sorry I know the the abstract mention sequel and the Zellando operator but this is gonna gonna be MongoDB with the community operator but that's basically the same principle so the ID is to have the application a flask application that is going to perform requests to the Marvel API store them into a MongoDB and then the application will be displayed in the front end with sort of Marvel cards so this is our application for today which hopefully is better than just another hello world sort of application and then for this we're gonna use our laptop where we have a local K3S cluster running which is common and what I want to do is to show you like a couple of tools that the first one is going to be a scaffold so scaffold is a software from Google that allows you to build a push and manage the life cycle of your application without committing anything to git and to deploy it into your local K3S cluster you can store the images locally it has policy based image tagging as I said you can choose to keep the image local or to put them on the remote registry in our case they will be stored on Docker Hub anyway but I just put it there but I could have chosen just to keep it locally and so scaffold embed a scaffold file that allows you to define to express environment requirements using customized so customized for people who don't know is basically a way to customize your Kubernetes environment where you have a base of your Kubernetes manifest and then you can build different overlay that are gonna change the base with your specific requirements so typically you don't use customize as a command line except when I'm going to show you with with the police as code but it's supported by scaffold locally on the laptop we're gonna be using tecton in production which is a CI pipeline tool that is staying that is living in Kubernetes where every task is represented as a part as a container and it's of course compatible with customized just you have another task that is going to build the manifest using customized and so we have a novel a4 prod we have a novel a4 dev of course as I was mentioning before we will have some on that file like Yamlify to specify replication well I'm just testing it in my local laptop so I don't need any replication don't need any encryption and then it's going to be de scaffold is going to manage all this part here from there to the end including the deployment as soon as soon as I change the code locally on the file system when I save on my local file system scaffold is going to monitor the folder the directories without committing to get it detects a flat file system change is going to push a new version of your application automatically in your cluster in your development clusters without committing the code to get yet and of course once you're happy with the code you you do pull requests and probably I'm just going to save it anyway and once the pull request is done you can trigger your pipeline there and this is what we're going to do with tecton so now it's we are the bottom we want to do tecton to deploy the application in production so because we are now using communities we don't want to use Docker of course to build the image because you need to mount the Docker I mean now it's been deprecated anyway but you don't want to mount the Docker socket in communities because you need real privileges which is bad right so there's a great tool again from Google which is called Kaniko that allows you to build container images in communities without using Docker at all and without mounting any containers the socket and so that's that will be our first task in tecton so the the role of tecton is going to be to build it so the same thing as scaffold build the image build the application manifest using customize so our second task will be to use customize with tecton to build a manifest push the manifest on a repository here so again build the image image is also uploaded to the registry and the manifest use using customize we generate the file push them to git and we will have flux which is a CD so continuous delivery GitOps tool that will monitor that particular repository and every time it's going to see the modification in the manifest it's going to update what is running in the cluster so no Coup CTL to deploy the application is basically you have single source of truth and you have this is the intent and the intent is reconciled with the states that is in the cluster and finally I'm going to show you Qverno as part of a just manual action so that you can see how to validate or not if your manifest are compliant so I've got 10 minutes for this this is going to be challenging okay so now let me switch to the other environments I need 15 minutes okay okay so now the cool stuff okay so the idea we're going to start with scaffold right so this is my application this is my application there right so on the left you have the different components so this is a flask application so template page dot html this is where I've got my front-end let's say code where I'm just displaying you know the cards I want so here you appears in comic this is the part I want I will want to change in just after to change it to come mix with a with a mess just as modifying the code right let's go cheap to modify the code you see also the docker file that is going to be used by by kaniko by scaffold by all the tools to build the application container image I'm using genic G unicorn as the web server and I've got my main dot P my Python code that is basically connecting to the DB and again displaying some of the or putting together some of the content connecting to the database and finally remember I told you when you deploy you create an application in communities you want to use communities native components to help you do this so originally the idea here is to start with empty database empty application nothing is working and I've got a Kubernetes job to basically if you look at the job made on py is to realize the the API request to the mobile API and store them in the database to prepare the application and that one of the property of communities job is that is going to continue trying I think by default up to 10 times until it succeeds once and you know communities is mainly a highly asynchronous system with eventual covert convergence this is the same ID here where it's gonna I'm going to go deploy the application including the database but the job will only succeed once the database has been completely created and healthy then Python requirements so Docker file for this is for yes the same thing actually yes not using that Docker file so it's using that particular Docker file is the same thing defining some environments variable and the main thing I wanted to show you is the scaffold scaffold file but meanwhile I'm just gonna launch it because so dev mode means that is going to monitor dynamically the file that you are modifying so it's going to be like a demon sort of mode that is going to build everything so just to check here this is my cluster you can see I don't have I don't have like the dev namespace or anything but it's gonna appear as soon as scaffold yes creating stuff already so it's preparing basically the environment for that and you have the good thing is it also logs all the container that are part of the scaffold configuration so you don't have to go into individual container to see what's happening so back to our scaffold content so again it's yamal like you define what builder you want to use so you can use Docker I think I still have like the documentation open there scaffold so for building it supports Docker Maven custom scripts build packs a lot of different things right here I'm just using a custom script I can show you the scripts quickly it's because I'm running on M1 which is an ARM processor so I need to use Docker build X to cross compile on x86 right this kind of things but yeah this is why it's what I want to show you is that X you can extend it's custom is able you don't have to use Docker you can use custom script as well and then you can say if it's image local or here I'm just deploying creating and pushing the image on the Docker registry registry you just need to do to have Docker running on your laptop which I've got locker desktop here and then customize and the path this is the path to my dev overlay this is all you need and then you're on scaffold there and so now I think it should be ready let's check yeah okay here so that now we see error because the MongoDB database was not ready yet when the first job has run so now we need to wait for this job here to be completed and normally we should see so you can see like here you that's the the community's job error miss the logs saying that well I cannot run because it's failing because I cannot connect to the database it's not there yet so we're gonna wait normally it should take maybe another minute me yeah so now it's I'm just displaying all the JSON payload that I'm requesting from from the the Marvel API which is about like 800 different entries when it's done I'm gonna show you what is the application and we're gonna change it so it is there let's just do a pull forward it's running on port 80 t okay now if we go local host okay so this is our application displaying some of the characters there you can reload them so we are happy but here there's a there's a typo in comic we want to put comics with an s well now that's easy the only thing I need to do for this I go to my code I'm just gonna look for all the comic into iteration so that's coming and I want to replace with come mix like this replace everything I'm just gonna kill forward there and go back to my scaffold here so I've replaced everything just double-checking that everything has been replaced comics there everywhere now I'm gonna save just command s and now it detected this is gonna build not rebuild everything just the front-end container that is you know coming from the code I've modified so if I go back into my environment here you can see my DB is still there right if you see the DB didn't change right still like four minutes just those three container the front-end has been updated and so now if everything worked I should go there and pull forward again and if I go back here just back you can see now the code has been modified I'm happy with this in production now I want to go in dev I want to go into production so this is the cluster this is the other cluster I've got nothing running it will be in the default namespace and I'm gonna be using tecton this time to deploy into production so for this let's go first we're gonna kill everything here and when you're done with scaffold just press Ctrl C it's gonna delete all the component for you right and you're back to a to a healthy and minimalist cluster deleting your without your application so now for tecton let's first I want I wanted to show you customize customize which is there so you have the base here that is defining all the job the deployment for my the communities deployment that's representing the wrapper around my container the service to deliver my front-end and this is my database custom resource where I can define the size which is one gig etc etc this is the base and this is the overlay where I'm gonna apply different qualities so here for example in the depth overlay I've got replicas zero encryption false so now let's check to check out master okay and you can see that's now I've got prod there and here replicas encryption my in terms of my CRD for my database I've got two volumes one gig I've got user with permission all of that is just representing my environment for production and now tecton is gonna use customize to build the production application so now tecton so just to put it like very quickly tecton will run all the task so building the image and from one task to another you can also share information in the form of config maps secrets or storage and PVC's if you want to use more than one then you have to have a solution that eliminate the requirement to run a pod and the volume on the same node which on that can do and others as well but by default you won't be able to do that so this is a way to optimize tecton as well using the right CSI so for tecton again same thing what we're going to do is like everything in Kubernetes to trigger the pipeline we can we can create just push the manifest into Kubernetes just by doing this is gonna trigger the whole pipeline that we can monitor using a tecton command line here is gonna run monitor the whole pipeline and same thing as Caffold but now except that it's gonna be in production and I'm gonna also monitor things with flux so flux is monitoring at the end of the tecton pipeline what I'm doing is remember using customize build the manifest push the manifest to a particular repository tecton is gonna pick it up sorry flux is gonna pick it up here you will you're gonna see one line that is basically saying I'm reconciling the state of the cluster waste the intent that is resigning in my github repository and in no time we should see here so you can see here this is the different this is the the the pipeline running in Kubernetes so again this tecton software is basically using Kubernetes to run the pipeline itself so you can run it in a different cluster probably not your production cluster maybe your staging cluster or your DevOps cluster but it allows you to consume communities even I mean also to build your pipelines which is I think a great idea if you want to do everything into Kubernetes again you don't have to use cloud specific tools on AWS and code pipelines all that you can keep everything into communities so now we are it's done one time for every task you will see a new pod that is gonna pop up okay so in the meantime while it's probably like another two minutes which will be the end so if there is any question you can shoot them now I know that was a lot but hopefully that was interesting yeah okay now it's like so I'll go quieter now so my question was to extend on the example that you showed the change to your I think it was a web app you changed some text which rebuilt just the specific portion that you changed I'm gonna give another example like let's say you changed your I made a change to your database model with the same effect that it would only change to the database structure as well yeah so no it will so scaffold will just monitor the directory that you set up in terms of what is deployed in communities right so basically if you change something that is not in that directory and that doesn't affect communities it won't redeploy anything so it means that the only thing it will be able to redeploy for the database is that if you change the custom resource for the database not like the model itself or something that is deeper more than infrastructure one more question if I could it's real quick for the deployment of this could this be done locally as well so you mentioned running it on your local laptop this will work there is also it can be extended to on-premise Kubernetes deployments and so forth yep thank you okay so just to finish you can see that it's been reconciled and you can see that on my github repository now the manifest has been populated by the pipeline so all the manifest done by customized populating like the new image with a new digest all the policy that you have sets everything is there and yeah flux has just picked this up and just we're gonna the application is there just to show you that the application is working now if I go back into here and so the pipeline has finished like again you have all the logs and if I do pull forward this time in production in my cluster I should see that once again yeah it has pick up of course the changes from the code and now it's running in production right if we have maybe time is there any other questions maybe one okay if not maybe online there's no question okay perfect so just to finish this is what we have been talking about today as a sum up so take away for today stateful workloads in communities are possible if you deploying or if you want to create a cloud native application you can collocate your stateful component with the stated stateless components as long as you provide the right additional data services like replication encryption mobility my company of course provide this but this is not the only solution you'll have a lot of open-source solution Kubernetes is great to use it as a cloud operating system as a standard across all different clouds but of course it has a learning curve but once you learn communities it's just enough to deploy your application and create your application anywhere and finally there is a lot of ecosystem tools right now that run in communities I've showed you tecton I've showed you scaffold so the developer experience is getting better better and better and better every day so don't hesitate to check them out if you want to get linked to the repo that I've used I can post them you can find me on Twitter I've put it in the presentation first in the first slide you can just contact me and I can try to find a way also to post it somewhere that you can access so thank you very much for listening to me hopefully it was a cool day thank you