Hey everyone, so glad to be here in this cool conference speaking about the way that my team is developing in the day to day with calling, sharing with you the experience that we have in the way that we are working on local development. So before we starting, let me introduce myself. My name is Matan Cohen and I'm software development team lead lead at the production platform in Wix and my team is called Dev Extra production. We are responsible for the dev experience of the production engineers in the group. We are responsible for some automation and make the life easier. Ciscds and a bunch of other stuff before that. I've been in Walkme also for several other years now. The agenda for today is that we're going to discuss about Skaffold and Scaffold is this amazing tool made by Google for local Kubernetes development. And we're going to discuss about it of course today. And we're going to discuss also about two great integrations that Scaffold have, which is helm and Basel, helm for deployment and Basel as a builder. And we're going to discuss this as well. Now let's start from discussing about local development in general. Now I know that every team or company doesn't really matter, have its own way how to develop. But in my point of view you must take into consideration three things. When you are thinking about the way that you are going to use the tools, you must have velocity, good experience and a fast feedback loop. Now if you would put it on a scala between, the way you are working is exactly like production or nothing like production. You can think about it in a very general way in those four options. First of all, you can run your code just via test. You are running this exact code that you wrote with the test and you want to see if it's working or not. A second option is running the service now. It can be a binary, it can be a dockerized stuff, whatever, but you are running all the service now. Something that it's more like production can be like dockerizing all the environment. When you want to work on your environment, you are going to work with your service and maybe some external dependencies like database or message queues and other stuff. And the Thor option, it's running all the services with all the stuff with local full integration, maybe the environment variables would be a little bit different. Now, when we thought about which way we should take in order to develop in Golang in our local development experience, we wanted to take into those three points that we discussed about velocity, good experience and fast feed the clue. But also we want to make it as much as possible like production. And now this is where Skaffold helped us with this concept. What is Skaffold? Actually Skaffold is a local development Kubernetes tool that you are using in order to run your services. And basically what it does scuffled is watching your files and every change that you are made it's going to continuously deploying to your local Kubernetes cluster. Now it can be a remote Kubernetes cluster but today we're going to see it like just from local Kubernetes cluster in Docker for Mac. And actually what it does is pay attention that you changed your service and then is doing a very fast build of the docker image and it pushes to your Kubernetes cluster and we're going to see it in a second. Now when you finish it's automatically clean up for you. This concept that's called continuous development. Now I've seen it in several places and it's like a general concept continuous development. But this concept, the way that I'm taking this phrase is to you want to work continuously when you are developing and get this fast feedback loop inside the Kubernetes cluster and you constantly deploying your code and getting the feedback. So let's see the first demo very very fast. Let's take a look how scaffold can help us with a local development experience. Now before the demo I have installed several stuff. First of all I installed Docker for Mac and I enabled kubernetes. Also you can install scaffold very easily with brew, install Skaffold. And last thing, I installed a Google cloud extension on my vs code and you can use it also in Intellij. Okay guys, so as I said before the talk, I have installed Docker on the machine docker for Mac and also I enabled kubernetes. Here I enabled kubernetes. Now let's see scuffled in action. Now in order to have this quick template of how scuffled is working, let me open this cloud code new application. This is an extension that also was made by Google just to download a template. So it will be Kubernetes application of course and we want to have a go guest list. So let me open this one. Let's give it a sec. You can see on the bottom right that it's downloading. Now this is the template and this is basically a very simple skaffold project. Now this skaffold project, as you can see here, have two main artifacts, which is the backend and the front end. And if you would go to the Kubernetes manifest, you would see also there is MongoDB and what scuffle does. The way that scuffle is working is that you have two main parts inside scuffle. You have the build and the deploy. Now the build case is in the build phase. You need to point where are your artifacts. Now you are pointing on the back end and the front end. Cool. Now in order to deploy those artifacts you need to point on the Kubernetes manifest which is in the Kubernetes manifest directory. So in order to unscaffle and see all the magic, you just need to do scaffold dev and then Scaffold will start running and building the artifacts. And also it will deploy to my local Kubernetes cluster. So let's give it a second and you can see that those back end and front end services are being built now became, now you can see that it's actually building because it's the first time it's actually building from those containers, those images, sorry. And then it will deploy the containers to my local Kubernetes cluster. Now we are waiting for the deployment to stabilize. Let's give it a second because it's the first time, it's taking a little bit more time, but next time it will have catch of course, and it will be very fast. Let's give it one more second. Okay, now we can see the logs. We can see that we have the backend and the front end logs. And also we can see that MongoDB already deployed. So we can see it. I have Lance which is local id for Kubernetes. And you can see in the pods that we have now go gasp. Backend, front end and Mongodb. And everything is working. Now let's run on the browser localhost, which is the service that the front end is listening. And then we can see that we have this, my guestbook. So now we can run post guest book and then you can see that it works. Now let's see what scuffle gives us actually. Now if I'm going to change, for example, you can see here that the name of the app is called my guestbook. And if I want to change this, let's search for this one, my guest book, let's call it Conf 42 guestbook. Now you would see that stuffel noticed that just the front end need to be built and it automatically rebuild our front end and it's already been deployed to our Kubernetes cluster. Now if I would go to lens you would see that now we have a new pod with a new front end production. It was very fast, I don't know if you catched it. And actually now we have a new application with a new deployment and we can refresh. And now we have conf fourty two. Now we change just the front end. Now let's do something a little bit different. Let's add a back end stuff or a method in the main review. Now let's see the handlers here. And you can see that it's using this HTTP handler. So let's create another one. Let's call it, let's have a ping. Okay now you can see that it's automatically paying to build and it's rebuild for every change that I'm doing. So let's do this function called ping and let's just return second it. It's now let's give it a second and let it finish to be deployed. And that's it. Now we can do bingo tooling and it will work as expected. Okay now it's worked. We can see that probably it took a second for the service to be stabilized and that's it. Now it's been redeployed. So the thing is that when I'm working with scaffold it's always rebuild the environment that I'm working. It doesn't really matter if it's front end code or back end code and even kubernetes stuff. So if I would go here and I would go to the front end service for example, and I would change it from 80 80 to for example 3000. It will also will pay attention to that and it will be very fast deployed. You could see that because it was not a change in the artifact. It was like amazingly fast. So if I would go now to the browser it should not be worried. Just a step. It took it a second to pay attention to it. Now we can change it to 3000. What I've done here. Oh I changed the back end. Sorry for that. Let's change the front end. Okay, now it will be, now it will work. Just one sec. And now it's working on local 3000. And probably you are asking yourself, I can't hear you but how can I debug inside scaffold? Because there is part of the local experience is to have a great debug skill. Now you can do also with Skaffold a remote debug inside the Kubernetes cluster. And let's see how it looks like you can see you have run on kubernetes. By the way, if you would go to the vs code, you can check the configuration. So let's run on kubernetes now. It will redeploy a new pod in order to do the remote debugging. So yes, and I'm going to wait for a second to wait it to work. Now it's building the front end again and it will deploy to my local Kubernetes cluster. Okay, cool. It's finished with the front end. Now it's building the back end. In the meanwhile I would go to the front end app and let's search for the post. Let's debug the post process and run from the front end to the back end. So I would go to the back end as well. And let's search for the post message handprint. So I created two breaks. Now I'm waiting for scuffled for the first time to build those remote debugging containers, pods. So we're going to wait until it's going to say that it was finished. Let's give it another second. Okay, now we are doing the mapping inside the remote debugging and hopefully now everything will be working. Now let's try to add something here. Post yesbook and the debug didn't started yet. Let's see why. Let's try again. Okay. And now you can see that I'm on the front end app and I have a breakpoint and now I can jump over the lines and debug like I wanted to. And if I would go play I would go to the backend app as you can see now, giving me the ability to do a debugging cross microservices, which is amazing. And this is one of the things that SafO gives me on my local experience working with. Go. Cool. So let's continue. I'm just playing up the stuff and also in the terminal here and clean up everything when you are finishing with coupled is cleaning up for you. So it's very tools. You can see that everything is clean when I finish. Cool. Actually what scuffled gave us, the way scuffled works is it's pluggable. Now I don't know if you notice, but the parts in the scuffled yaml file are very easy to extend. For example, if you want to use another build tool, it's like Skaffold gives you the ability to choose which build tool you want to use. Now you can use the local docker demo that you have, like I just did. But you can use other ways to build your artifacts, like Bazel for example. And we're going to see it later on. Also, it gives you a few options how you want to deploy your artifacts through the Kubernetes that you are using now. It can be in Kubectl like we just saw, but we can use helm for example. And we're going to discuss this as well. So scaffold is very pluggable, which you can use it in different places, in different teams in other ways, which is very useful. Now let's say that you have this microservice that you are working on, but you need an external dependency, for example, you need the message box or you need for example a mysql database or something like that. And this is where helm getting into the picture. Now we're going to discuss how we can use helm to integrate with Skaffold in order to help us in the deployment phase. So what is helm in general? Helm is the Kubernetes package manager that is commonly used when you are using Kubernetes. Actually what it means, like you can do NPM, install something or use other package managers like Nugget and C sharp or pin Python doesn't really matter. You can use helm for kubernetes. So you can do like helm install MySQl. And then you have MySQl in your Kubernetes cluster, which is very cool. This is a very high level of helm. Now let's see how Helm can integrate with scuffled and how easy it is working with scuffled and Helm. By the way, for those of you who don't know helm, there is something called Helm Hub, which you change the name to Artifact hub. And here you can search for all the artifacts that you want to install via helm. For example, we're going to go for PostgreSQL for example. And you can see here if you want to use Helm, you can just do helm repo edit for this repo and then you can do helm installed for example, for that. So now let's write this in our Skaffold project that we just created. So I'm returning to the project that we just saw. And now we can inside the Skaffold here, let's have another file. Let's call it Skaffold services, yaml for example. And here I have an extension here for writing and stuff. It's also the cloud code. Now I would go for shuffled Helm deployment and you can see that it gave me a cool template out of the box. So let's remove all of this for now. And the chart path would be. No, the values, I don't need those values as well. And also I don't need this build artifact. I just want to have here box and the chart path will be. Let's take it from here. I already done this before the talk, so after you run it, it will be very easy to use. So we're going to use it here. And we should say that this chart is denote. So let's say true. Now in order to use it, we can just run skaffold. Now I will not run Skaffold dev this time. Now I will just do. Now we can use scuffled run. Now the difference between scuffle dev and scuffled run is scuffled dev is like watching your files, but scuffled run is not watching your files. It's like one time deployment. So you can do scaffold run to Skaffold services. Skaffold service yaml minus f. If you are not using scuffle yaml, we must pass the minus fuffle run minus f. And now you would see that scuffled is using helm to deploy this service to my local Kubernetes cluster. Now you can see that this is a regular helmet install if you're familiar with it. And what can actually reduce is actually connecting to this very easily. And for example, if we want to have a few other stuff, let's say for example that I'm using Kafka, for example, so I can have here Kafka and I think it would be kafta again. And also if you are using redis, you can do this as well. I mean, you should change the parameters and pass maybe a different port or you want to have some reverse proxy for the URL or something, but you get the idea. So here you can have redis for example. And if I would run Skaffold run again, now I'm going to have Redis Kafka and process like very easily, which is giving me so much power when I'm working locally. So if I would check this inside lens, you would see that Kafka is starting and zookeeper as well, and also Redis master and redisplay. Of course you must do some fine tuning to the parameters that you are passing. But this is the general idea of how scuffled integrating with helm, which can help us a lot in the way we are working with external stuff. Now let's clean everything here. We can run scuffled instead of run. We can run scuffle delete. Scuffle delete minus f scuffle. Cool. Now it will clean up everything and you will see that all the things here are going to be removed in a few seconds. You can see that the pods are terminating and we finished. Cool. So after we saw how Skaffold is integrating with helm, let's check out another amazing tool called Bazel and how it's integrating with staff. Now, Bazel in general is agnostic build tool and also by google. And I think in Google, internally in Google, it's called Bazel. And what actually Bazel gives us is this very efficient way that it builds the artifacts. And we're going to see it in a few seconds. In very general idea, you're going to have on each directory, a basel file that you can connect between the artifacts, each directory having its own bazel file. And then when you want to build the artifact, it's building it very efficiently. And in the tree that you can see here, it has a cache for each layer in the tree, meaning that if you already have it cached, Bazel will not build it again. And we are using Basel a lot in wix. And for example, there are some groups that most of the groups in wix on the back end using Scala. And when they moved to Basel, it changed the time that they are doing the CI of building all the artifacts and the cv from hours to minutes. So it's amazing in a very large monorepos and big repos. So the things we're going to discuss now is that what buzzer gives us in the local dev experience, why it's helpful. So let's say that we have two services, right? We have service one and service two. Very easy. Now, service one is dependent on very simple sum package, and service two is dependent on some and more packages. Now, if I'm changing just service one, so we saw that before, Skaffold already knows to change service one now. And if I change service two again, it will rebuild service two and redeploy. But what's going to happen if I'm changing the dependencies of those services, how skaffold or any other tools is known, which service you need to build. So, for example, if I'm changing the mole package, so of course I need to build just service two. And if I'm changing the code of the sum package, then I should rebuild service one and service two. And because of the power of Bazel, Bazel knows because of all the targets, which packages and services I should build in the local development. And this has improved dramatically the local experience of the way that I'm working. So, let's see in action, skaffold and Basel together. Okay, so let's see how Skaffold is integrating with Bazel. So, before the demo I created, this very simple project includes Basel and Skaffold. So let's see how this project tools like we have again, this skaffold file, which contains the main parts, which is build and deploy, and the deploy is via Kubectl and the build. Now, as you can see here, it's made via buzzword. Now let's open the directories and see what this project contains. So, as we saw in the slide, we have two services and two packages. Which service one is dependent on the sum package. Very easy. One and service two. It depends on mold and sum. Now, as you can see here, each directory holds a bazel file, which declare the targets inside the directory. You can see here, we will not cover it in this talk, but in general, you are not writing those bazel files. It's generating with generating it for you. Now, if I want to run this project, we will do as we've done before, stuff like that. As you can see here, the service one and service two already been in the cache, and that's it. They have been deployed. Now, if I change in service one, we know that just service one needs to be redeployed. So you can see here that service one is now rebuild and will redeploy again. But what's going to happen? And it's going to change the dependency, the modules, and this is where Bazel can help us and in other places in the local experience, of course. So let's change this package here, and let's see what's happening. Because service one and service two is dependent on this package. Scaffold knows to build them. And this is where Basel gives the strength to scaffold in this situation. And if I would change the multiply, for example, you would see that only service two that rely on the multiple packages will be changed. And this gives a lot of strength to scaffold and to the local development experience. So with Skaffold, it feels like you're writing coin production. I mean, if before people worked with dockerizing their environments in order to be like production, now we can actually work with Netflix and helm and some other tools that can make my local experience else like production, which give me a lot of strength. So thank you very much for your time. You can ask me questions on Twitter. I will be glad to answer. And that's it. Thank you very much,