This week we discussed a very interesting paper from Google, released just a few months back on modern cloud applications and the way they can be deployed.
Links:
Meir's blog: https://meirg.co.il
Omer's blog: https://omerxx.com
Telegram channel: https://t.me/espressops
This week we discussed a very interesting paper from Google, released just a few months back on modern cloud applications and the way they can be deployed.
Links:
Meir's blog: https://meirg.co.il
Omer's blog: https://omerxx.com
Telegram channel: https://t.me/espressops
oh my lady yes and action action hello everyone and welcome to DevOps topics episode God knows what 1267 and we have on the line I know it's new or high or male say hello everyone hi hi and today we are going to talk about modern application architectures hmm which is a very exciting topic because almost told me listen I want to talk about this and I told him but I'm not sure what it's going to be about and he said not only will flow with it so this is time where we are going to flow with it like always so only what's the first thing that comes up to your mind when I say modern application architectures the first thing that comes to my mind is obviously I want to say obviously I don't know if it's a very obvious but it's running distributed applications probably something that involves Kubernetes in the process I'm guessing I want to say microservices right taking a large monolith and breaking it down to pieces that are easy to distribute on something like Kubernetes or other orchestration not even talking about serverless and lambda type of functions now and the ability to manage the entire lifecycle right the development building deploying in the lifecycle that keeps going on throughout the life of the application that's the first thing mm-hmm okay so now the trainer in me you know the educator with me has many has many questions but the first question is like who is this who should listen to this episode about this modern application architecture like who is this little event for like DevOps engineers software engineers VPR MD you know architects so who is it best suit for this episode I'm gonna say two things first of all I'm going to give you a very annoying answer it because there is no there is no such thing as a DevOps engineer right the developer should be their own ops engineers I'm part joking part serious but I think everyone should know about it so the answer is everyone and the solution proposed let's give context for the conversation there's a paper by Google released on June this year so five months ago and it's the title is towards modern development of cloud application we'll get into what it says in the story what stands behind it background and everything but this is involving everyone in the process it starts from how you build the structure it goes on to how you define things literally configuration which is I think more on the side of what we do day-to-day how you configure stuff and prepare them for deployment and after that there's that deployment process so in that regard it's kind of let's compare it to something like the serverless framework serverless framework is known for its simplicity and anyone any developer even if they're not very familiar with a cloud can take serverless dot com the framework build the function that they want to run and then have it deployed with a simple CLI command right have it deploy any two will do everything around it authentication API gateway anything that involves the function and obviously have the function run in the cloud so you can access it externally what is proposed here is something of that nature and it wants to do the same with any type of application so I'm going back to your question anyone anyone DevOps ops production engineers SRE is obviously the developers team leaders they were in scale so the solution like is this for small applications maybe my application doesn't have so many miko service maybe I only have a font and backend and the database or maybe I have Kafka and God knows what else in mind back and so how would you it's like it's like I prepared you with questions and honestly I didn't if someone's listening to it I didn't prepare me with questions but that is a perfect question and why let's go to the background there's a problem today right if you'll be able to do an application within your organization your team in your company what do you go for you go for a monolith or you go for you start with breaking the things into components and then develop them separately it depends it depends on the it depends on the time to mark it depends on the size of the team depends on the you know the frameworks that the team are familiar with it really depends on the resources maybe we don't have even money for GitHub Paul and we need to do everything locally with some meat silver whatever so it really depends on so many factors you know okay so that's actually a perfect answer to what I'm asking because that that's actually the answer it always depends things matter context matters are you a large team like the small team what are the skills maybe you're used to monolith because you know how to build them maybe your DevOps engineer quote-unquote is used to monolith because he uses Jenkins and he knows how to only deploy these large deployments there are three main problems okay first of all we mentioned the skills the next one is what do you start it's it's something it's a debate you start like a small team two three people we start working on a solution a tool our company our application what do you go for a monolith which is easier to start with because it's just a bunch of code packed together into one thing to deploy or do you go to microservices because maybe that's easier or we're preparing ourselves to scale or because we don't want to engineer that later or do you think that's actually premature engineering and you're over engineering etcetera and the last one the last one sorry is what do you want to focus on where's your focus which I think you mentioned are you focused on the technology aspect of things or the business side because if you're if you want to run fast with the business and you just want to make things quick and dirty like we love to say you probably better off with something unengineered a monolith that's easy to deploy right these are three problems so we want to solve them how do you do that that's the proposed solution so do you want me to jump ahead or do you have yes yes yes I'm writing questions me meanwhile did you talk I'm like I have so many questions that I want to interrupt you so I'm writing questions so go ahead and tell us what is this up all about okay perfect so these guys came up with a solution which they called Weaver service Weaver Weaver I'm not sure it's a W A V R I'll share all the links below including the paper YouTube on from Go for Cone Europe a couple of months ago and everything you need to know it's obviously open source written in Go and it's very easy to use something you should care that's written in Go or not but the idea is taking a bunch of code you basically write your code as a monolith it builds one binary and then that binary can be distributed among different machines you can run one process multiple process you can have things run together kind of like a sidecar you can have them completely distributed and the way it works is basically and it's very superficial what I'm going to say because it's not diving into the deep aspects of it one because I don't really understand everything and two because I haven't had the time to play enough with it but the idea is you build one base one code base and then that thing takes the monolith build builds a bunch of the same binary actually but every binary runs a subset of components so for example you write one binary and the example that they give is let's write a game that's called rock paper scissors okay you build three components rock paper and scissors and then when you want to run the game you'd say wiver these are the three components build yourself so it builds the same three binaries each of them will run a subset of the game one will run paper one will run rock and the last one will run scissors and then that will deploy them distributed among whatever you want it's pre-baked with templates for Kubernetes for GKE for just normal instances and it helps you do everything under the hood including telemetry logging scaling even profiling of the application with memory and everything you want you have everything is baked in the stool or this framework or I don't really know how to put it in a box that's basically that's the idea it goes a lot more in depth in the paper on how things can communicate they actually remove GRPC from the process they claim they build something even faster on top of that that communicates over TCP they they improved so many things and it's benchmarked across many many other systems and frameworks and it's really interesting I mean my mind was blown and apparently it's not it is new it's five months old but it's not like from yesterday and my mind was blown like how did I not know okay so now time for my question right so I think I think I'm doing something very similar usually when I'm handling lambda functions for example let's say I've created so I'm trying to take your the things you just talked about about this architecture or having the same codebase and spreading around maybe multiple services or monolids so I think this is what I'm doing when I want to do a quick start projects like creating a Python application let's say this Python application has a requirements TXT you know with all very relevant requirements whatever so for example requests which is like Axios or whatever HTTP request a package in any other language and that's it okay and my application has let's say five functions so one of them is you know get CA generate delete whatever I don't really care what I'm saying is usually when I deploy lambda function I take the whole code and usually there's also a maybe a shared folder or a global folder like you know for utils or utilities or whatever you call it which is yeah shared components between those functions but eventually if you think about when I when I build the code usually what I do I take the whole code together in the k8 function and in the generate function even though it's not necessary even though there is code so when you build it there is code that is not relevant to the part of the application it is running the service so for example if I take my function and each function is a service each function has its own API health even though I only do the you know HTTP to get the if for some reason a hacker would access my end point and would be able to do whatever he would be able to invoke other code but the way I cover it is by permissions so usually even though the code all the code is in the same lambda function I protected with permissions so we can't it can't really do the other things in the code you know what I mean so this is usually what I do is this the type of architecture you're talking about like having a single repo with multiple services showing the same code but deploying them separately like kind of one problem with what you mentioned is I think efficiency because you're by you're actually building everything and packing everything into each of the lambda functions which necessarily means I think that you're running you always have some kind of a of an overhead buffer on top of what you're running you always have unused code if I'm not mistaken in a sorry and I understand correctly we were solved that as well it only builds what's relevant for the single component that needs to run at the end of the day it is a single binary it does come from the same codebase but it only runs what's necessary for that like a country shaking like it's kind of what doing the compilation it searches for what was implemented or not and yes pushes the way the way you configure that you can rid later but the way you configure that is you define a few interfaces for different components and then we've weaver weaver weaver picks up on that and picks up only what's relevant so that's the interesting bits so beyond yes what you mentioned is the concept it's actually building the same thing over and over and then running the single component the problem with what you're saying is that you're still stuck in the uh what do you what do you call it waste you're still stuck with the same waste of kilobytes now it's like the pros and cons so I'd say the only thing that happens so it really depends on the side of the application so for example if I had such a large application I would split it according to the requirements so if some parts of the API doesn't use requests and use numpy or pandas I would split it according to the requirements this way I wouldn't have this waste and the only waste is a kilobytes of code you know that's no more bit that's one bit uh but when things you're right but when things scale and you're building really large systems you might get into a point that one of the components is really heavy and it takes a long time to build something that takes a lot of time to build is not only a CI problem it takes a long time to ship the image and then it takes a long time to pull the image to every new new node so this one so I think this is my breakdown this is like this is my breakpoint I mean like this is like when I get there where you're talking about like listen it's too big we cannot continue building everything when we only need your like two megabytes we produce every time 50 megabytes so this is what I'm saying okay let's redesign the architecture but until that part I don't have to deal with any code isolation and multiple zip archives and storing artifact per build so you know because you when you build something you're like okay if I only a single file it's way easier to manage your artifacts because a single file is all of your application and the only difference is during runtime so it makes I think everything easier so when it comes to what you said when the differences of I don't know the parts of the application or maybe this like it's very small this is very big I would split it I see that's the thing exactly to build on what you said Weaver is the solution to that because you always we started with one of the problems being what do I decide to go with am I focused on technology on the business should I go with a monolith should I go with something that's already separated from the get go and Weaver say you shouldn't care do the same thing when you start and when you scale it'll work the same you don't have to decide now just start writing code and then configure an additional component if you need afterwards right you start you build something you decide that there's a logical component that needs to be separated from its neighbor just do it just add a component and keep building and keep building and keep deploying and you'll slowly spread the application across however many servers pods application so is this a is this a framework because we've already think yes it is a framework so what's the name of the framework again uh Weaver it's a service weaver as is I live it it's on GitHub it's on GitHub there's a website there there are talks there are papers it's apparently in my mind they see Weaver and I see those go along the beavers and I don't know why it reminds me of Weaver go first go first go first go first yeah weaver weaver not so it's not weaver it's Weaver I think is a is a network layer in Kubernetes it's a network provider if I'm not mistaken with works maybe the one who invented traffic I don't know anyways yeah so weaver kafik male kafik kafik and baggy yeah all right so you'll leave a link and we'll see how it goes or anything else you want to add about those so because we can dive on many many monorepo uh monolids of whatever so anything else you want to say about this paper you want to focus on there are many many aspects that are interesting to dive into but what I think is now we know about a new technology relatively new and I would need to make a decision on like on the surface sounds like it solves everything right and and as an earlier adapter I'm saying why don't we just jump ahead and start using it today I mean we're building something in my company right or you in yours let's just take this thing and run with it so that's where uh I think technology decision making process needs to come into play and I want to jump on it I want to take this thing now and start using it but we need to make a decision so I want to ask you what's your process if you now figure out let's say that you've decided tomorrow you read the paper and everything and you decided that's the best framework you've ever met what is your process to making the decision how you integrate it back and awesome question because I think every every engineer has its own way of examining new tool or you know how do you approach something you know so I would also like to hear what you're going to do like let's like really manage it like I'm doing it so I imagined that after this talk I'll go to the website and search for a quick start or a demo just to feel it you know just to see what does it mean to look at the code base and you know just to get a quick glance of does it interest me or not let's say it's super cool you enjoyed every second of it okay and if I didn't okay and assuming that like there's not enough I would look full and I don't do it that much because usually the lead me of the positive is okay sometimes I go to YouTube and search for practical life demo of the person who created the project if it's a big project and then I can see okay so this is how it works great right and after I see that I just I just a comment the creators are five or six Google researchers it might not be the best presentation you've ever seen but still there are people like us who take tools and do YouTube videos for them just free you know sure so so I look for that you know I like to see customers I don't also I don't like to see the creators I like to see consumers how because if a consumer feels like us you know when we see a good tool what do we do we're like I get a publish it I want to work to know it's amazing even though I didn't even write it but I want to use it I want to I want to share it you know I want to rewrite everything everything I want to rewrite no no that's you if you say it in Python you want to rewrite in go you know but yeah and so I take the project I create probably and you'll get up repository and then I follow the read me for a quick start to see how it goes with the with a blank project okay so my first go is try to do it on my own with a very very short and simple example to see if I like the basics once I feel real comfortable I try to go to the advanced topics in this same project and once I'm like okay maybe this is a very good option maybe like Pulumi you know it's a if you want to migrate from terraform to Pulumi you're like how do I do it so do what I just said see the videos can I do a repository try provisioning infrastructure on maybe your your test account or whatever see if you like the flow you like it good now go ahead and read but but don't waste too much time on this because if you plan to move read the migration process that's super important so if I find new technology and I want to migrate from something that I'm already doing I gotta see if the migration process makes sense so Pulumi for example have a great they have an amazing doc because they know people need to migrate because the cloud is too advanced you know like everybody already has the cloud it's not like there are millions of new startups that was like I don't know five years ago 10 years ago we always have new startups but a lot of them are already using telephone or open tofu right they they changed it from OpenTF I think they changed it really to open tofu something like that yeah yeah I don't think that's worth the name or something so if you choose a technology like Pulumi read the migration docs if I like it and I feel comfortable with it you know that's the part when you start involving other people and ask them for their opinion like maybe other DevOps engineers maybe developers VPRD whatever so what's your take on that on embracing new technology or whatever okay so sure so we can talk about general which I can start from but I must be honest with this kind of thing this is like the everything this is the framework for everything for writing the codebase it would mean let's take my situation today we have somewhat of a problem with lambdas because surprise surprise lambdas are hard to scale because lambdas we have problem with lambdas so we are making a little bit of an effort to move what's relevant and what shouldn't be on on serverless functions to something else to another technology obviously we're going to things to areas like Kubernetes or other container orchestration solutions but that's the idea weaver might be an entire replacement for this thing so we've made some effort does it make sense to take this you talked about migration process it might not be the easiest thing in the world moving from one distributed in not one sorry a distributed codebase across dozens of repose and dozens of applications deployed in different and various systems and then moving to something that takes them into one place and then deploys them redeploys them with a whole other level system technology tools everything so you need to replace quite a bit so with other things for example you mentioned Pulumi versus Terraform CloudFormations things like that this would mean translating your code into something else and start moving on from there I would approach both debates let's call it I would approach both problems in the same way I would start building new applications if I decide that this is my technology to go or at least test I would try to take a new application that we're building and go with that and start understanding the concept go with it first of all to staging if I have other environments in the process I'll do that go through an entire there's a reality issue there is a reality issue with the things you mentioned because usually when you need to develop a new application your VPL and details you listen we're getting a new customer he gave us $10 million we need to give this this service needs to go live in the next three weeks or in the next two months go and then you're like you can't really do what you're talking usually I mean usually it's like if you need to bring to provision a new service it's not like let's discuss about it we have time you know you're right so more often than not there is this one feature that someone or something is writing because next week the customer wants it and for whatever reason there is always a developer sitting in the back room and working on rewriting a certain service always you always find someone trying to improve the process from three for something some I don't know how many years ago the guy that works on legacy and maybe this guy can take his code base and move that to weeper for example so that's what I try to do for example in our context we're making a shift right we're making a shift from functions to containers on our end this thing works with containers still it doesn't mean we were trying to move a bit to Kubernetes it doesn't mean we ditch Kubernetes in this case it just means we need to take a bunch of work load and translate it air quotes to something else to work in one repo one code base and instead of building multiple Docker files or multiple binaries or different pipelines we use an entire new system instead of our go for example or whatever other CLI you're using to build you're now using weaver to manage your code base and deploy your services and build them and everything it doesn't I think the summary owner of like okay so what's what's our I don't know five rules or three or whatever we come up with of migrating from one architecture not choosing a framework all right so maybe changing architecture from one to the other like moving from Kubernetes to ECS or moving from lambda functions to K native or moving from whatever whatever so what's your let's sum it up let's have some it's hard to put everything into one box because you mentioned a container orchestration system then a framework and then I don't know a cloud provider it depends let's go with this thing this is it's hard to put in a in in one frame but I think we can call it a framework a build deploy build deploy manage solution it's it's hard to box this thing because it's it's a new animal this thing comes in a context if your situation within your team company slash wherever you're working it fits right now if it makes sense for example like us we're making a shift or maybe you're just starting out maybe you're just exploring you're testing the waters this is the time to try something new like this however you do need to make some kind of attack to diligence understand that it not only fits your needs but you have the skills to work with it and its scales and it works it is coming from Google it was researched but it is very much new to remind you Kubernetes came from Google it was named Borg it took years until it was production grade and released and still been in the early years of Kubernetes it was very still is yeah but it was very hard to work with and take things to production and you'd encounter I don't know endless endless problems on on multiple layers some just saying you need to test you need to understand that it fits that it makes sense and then go through with it I wasn't testing it too much but from the general the first impression that I had with it it's a great tool easy to test and easy to get started with so if I would start a team today or tomorrow I think I'd go for that if we were shifting something with with with Weaver if I'm shifting towards a new technology I think I try to integrate it God it's kind of a summary not to your five-point system but let's shift it okay so let's shift it okay we talked about modern application architectures like that's the main topic of this topic all right so let's let's focus on you talked to me about maybe embracing new technology writing new code or whatever I just want to see like I want to hear how you approach you want to develop something very fast and I think we always have this I think I almost heavily episode I asked you this question in a different flavor like when you when you want to develop something right you want to create a new API a new telegram bot or God knows what you want to create you know you have this hectic head where I don't know what's going on in there so whenever you want to do something in you how do you approach it like I have my own approach I want to heal your first and I want to hear like what's the difference between us and maybe we can combine our ways together you know to get the best mix of starting a project with choosing the right modern application architecture so let's put it in context let's talk about a site project for example site projects can grow but we start from a site project I think like most other people my immediate approach is going with my comfort zone which means going to the system slash language slash tooling that I'm already familiar with for example if I need to start a site project today I won't write it in Rust deploy it on GKE or use Azure and you know add a new tooling like weaver for example okay I won't I would go to things I know I would deploy it on AWS or something that's deployed above that like fly or Heroku I would go for goaling because I know the tooling in my libraries sometimes it would make sense if I need to build like full stack application maybe I'd go for JavaScript or TypeScript in my case because I'm experienced with it I know Nest right so I can start working rather easily and quickly with Nest and I'll be able to ramp up pretty pretty quickly I think that's my system that's my go-to when I work on site projects I go to my comfort zone you always say try to step out of your comfort zone I think to build quickly I don't want to break it down okay you said stuff I'm working you said AWS you said types get you said good but now you actually need to start doing stuff so assuming you have this idea of application in your head you have a feeling of how the backend looks like how the frontend looks like unless you have a database you know let's do a normal application without many many more services yeah how do you start when it comes like how do you choose and say okay so I think I'll build it on AWS at first I think I'll use ECS no no no no first I will create a Docker compose locally I will develop everything locally and only when everything works well at least like my MVP works locally good I'll start working on the cloud no no no no first I will create EKS class there I'll deploy it over the bell and then so what's your see how I'm trying to there are so many options to actions I will just doing stuff your last sentence is probably never applicable ever not even if you're Google never start with deploying a Google and Kubernetes cluster and then start thinking no yeah surely I would start working locally on my application even thinking about architecture and the way it's going to be deployed will be on the next phase I don't want to say numbers but on the next phase I'm starting to work on the application once there is something ready process compose locally or would you don't all you don't gonna even I think about we need a database so maybe very much the office place between services and the network and whatever so would you go with Docker compose locally before you even go to the cloud I usually will I usually will actually start working locally because it's easy to start for example I'm running this bot you mentioned I have a backend I have read this for a cache and a Postgres as a DB I just run the two processes it's very easy to run ready send a Postgres in the background of your machine and just run the code against them and then when I'm ready to pack them kind of pack them I would start with Docker compose just to see how things play together and to actually see that the you know they can be baked as images rather easily that I have Docker files and everything ready and if they can play together still play together that I'm not in local host kind of not in local host but across a bridge network from Docker I can move them onto the cloud in my case I didn't even need a cluster singular so at the point okay so I like it so we started I think we have a baseline where we both agree first develop everything locally everything you can don't even touch the clouds don't let it complicate your project it will destroy you it's like dealing with the you know simple harmonic motions in physics we don't even know what is a collision you know so it's like so first let's put a star let's put a star here I'm working on a side project and I used something that I said no you know what I want to go even a step backwards yes you start locally obviously don't think of deployment from ticket code it doesn't make any sense when you don't have even one line of code and you're a single person team however you do have services like fly IO for example fly IO all you have to do is just pull the CLI to your machine you can deploy it as easily as you would write the first line of your code because basically as as soon as it's pushed to GitHub they'll even give you a GitHub action that deploys immediately to fly and we mentioned Redis and Postgres that'll give you services to immediately launch your Redis and your Postgres and it'll probably work safer because they have their own backup system and upgrade system that will work better than your local host that said when you don't really have a process running and it's not doing anything it doesn't make sense to deploy it but a week later when you do have something it's very easy to get started if you're not using a service like that and this is actually something that's going to grow into a startup and you are going for something like AWS I would wait quite a while before I go there because it takes time to build an architecture like a well-architectured a well-architected architecture yes it takes time to build the terraform corridor whatever and if you're if you're not starting with terraform you're just deploying stuff please don't it will take time not only to build that but will later take time to back it up with code or with other systems so so I'm taking back your style okay this is your style I'm picking it back I'm gonna get away for a second so local development covered this is the first part okay that's the baseline when do you involve the CICD because what I'm asking is I can't even say CD because CD means deployment it means you have infostructure so when do you involve the CI during your development process when you don't really know the architecture like you don't really know where it's going to be maybe you need to build a local image maybe you need to build a zip file because it's going to be a Lambda function like what's your how do you choose or start choosing I think that's the most interesting part in our job when you have this crossroads of way zip it or build it as a local image and push it like yeah which way I'm gonna go I'm gonna go almost always rather quickly to build a Docker file and if it requires I'll build a script around it Docker file is basically can be your CI right multi-phase Docker file with two phases the first one is a build the next one is the one that's production ready it's pretty easy to build it'll take you if you're very very slow and you're not familiar with it it'll take you an hour if you are familiar with it it'll take you 10 minutes and once you have a Docker file ready to go not only you can run it locally with something something like compose you can deploy it pretty much everywhere every system that's you know mimicking the cloud can take a container and run it and even if you go to something like AWS just run it within ECS is a no-brainer and by the way you have a tool that takes Docker compose and deploys it directly into ECS Fargate so if that's your thing I think it's dedicated you know I think it is it makes sense because it was very complicated it was very complicated to understand a few months ago and then I saw something a Docker compose to duplicate it and we need to check it I don't want to say it for nothing but let me correct myself it worked flawlessly it was very easy to deploy but once you want to change something it was it was hell but it does work if you're only if you want your container running and you don't want to mess with target groups and load balancers and stuff it works yes so I fairly quickly I would build the container hopefully with two stages one for building one and when do you involve this yeah okay so that's like building it locally so when do you involve writing a yammer file in GitHub actions GitLab drone or whatever looks that's pretty much you're really good that's pretty much the CI once you have an actual production environment then write the CI but if you have a Docker file that does the build and it runs itself that's pretty much the CI right what else when do you feel calm okay moving on moving on I'll keep asking the question when do you feel comfortable enough on wasting money in the cloud you know provisioning infrastructure okay hang on before we even go to wasting money when you want to deploy it in the cloud and you know it's like your MVP and maybe you want to show it to investors or friends and family of course first to get their opinion you want to show it on your phone you know bringing from and say listen this is my new website demo dot whatever let's check it blah blah when is the part when you say okay so I'm going to create everything with AWS let's say console you know the graphical user interface or before you even do that you're like listen we are going to do it good from scratch first of all I'm doing it with Pulumi just as an example I will provision the infrastructure to deploy the application and whatever like do you go immediately to infrastructureless code or first you're trying stuff with AWS console or Google console or whatever okay you're going into areas where context matters and not only matters I can ask like 100 questions now where are we what's the size of the team is that we have and yeah where are we going with it do we have an investor do we not we do we have a money I just you mentioned that I just want to give a link to someone let me introduce you to a great tool that's called Enbrok you know Enbrok yeah yeah you know Enbrok is amazing you can just share your locally running process with somebody else if you pay for it you get a constant URL that you can share you can just mimic the API or the backhand or frontend or the component that you're running so Enbrok would be great for the investor as for example with my my Mac on their table which is also by the way that's also a very good go-to tool I'm glad you say so if we put it again on a straight line develop publicing locally use the local compose if you really want to check services in their communication and whatever once you're done and you're satisfied you can integrate some CI just to see if it works but don't invest too much in it once you're done with that you can use Enbrok to publish your websites to show you to friends family investors before you even go to the cloud and waste time on choosing the architecture yeah so look how many steps we have before even we are choosing the architecture and services because when you go to the cloud you have an option to create a stateful set for a database or for example or using AWS RBS you know their relational database service so even before you do that we have so many steps so you chose and you hope you presented it to investors show to friends and family they like it all congratulations you have a great telegram bot thank you now what how do you how do you go to the cloud with it so to your cloud question I would usually write some terraform code to deploy it just because I know the material right I am familiar with terraform it'll be fairly quickly for me to write something that raps whatever I'm building even if it is a Kubernetes cluster by the way for Kubernetes I just probably would use something like EKS CTL or something around that but at the end of the day I will write some templates to help me deploy destroy and really deploy that afterwards that's me I'm familiar with it we you do have tools like chaggpt which we just talked last episode they're not that good with terraform for some reasons sometimes it works sometimes it's not and you're not getting consistency with with the answers but it's an option i'd go another template you don't pay when you when you say by chaggpt it's not consistent and whatever you don't pay if you pay you get good results to be honest whenever something is free you know what's the sentence if it's free you're the product so obviously when you use chaggpt for free you're the product you just use you to drain the model but when you pay for it you actually get results so actually chaggpt was a codename I'm used in mestral for that which supposedly is on the same level as chaggpt for and this is including everything everything that was released by OpenAI in the past week it's okay it wasn't as good surely you can have different opinions with your premium premium subscription or certificate yeah so anyway by the way if it works great so that's just strengthening the point so you go immediately to terraform you know that I would first try to create everything like let's say a demo environment I would do it from AWS CLI even if it's a VPC because I don't know if you know but AWS really improved in creating stuff with the wizard you know like a bootstrap so if you want to create a VPC you choose two subnets private two subnets public not gateway yes no what likely terraform VPC module you know that it's very famous so it's just like that but with the graphical user interface and then if I like it and I think it's good and I wouldn't also go with EKS I would first maybe create an easy to instance and install Kubernetes on that you know what I mean I would first go very very very very small so asking my question again would you do the same or would you go definitely I would do the same any day any time because what you just mentioned is at least twice doing the same thing one for the first for your demo and then the next time when you decide that demo works right and again it depends on how familiar you are with templating or what's your subscription level with Chagititi and whether it can provide some good results because if honestly if it's good with terraform just give it a prompt I want VPC and a private EC2 instance that I can SSH or SSM into better yet and it'll provide the template that all you have to do is terraform any than terraform apply and you're done right and you have a repeatable template that you can use over and over why not it's amazing you know that you've changed my perspective just from this one sentence that listen we are living in a world where you're using Chagititi so much so why are you still using the graphical residential space why don't you just get a template yeah why bother yeah so that made me think yeah why bother maybe I will change my philosophy and start working you know with generated templates and whatever because it's very today I mean in the past year it's been way easier than before I think the the greatest thing about AI which I didn't have when I googled for stuff is an application doesn't have like when you need to solve something something big there's no one question to it there's no one component so for example if I need to solve my application connection with Postgres so the odds that someone on the internet have the exact same question of how nestjs Postgres on AWS on ECS with Fargate but on arm and not you know has the answer for that or I'll find it on Stack Overflow is very very very slim but when we're using Chagititi and everything go to provisional resource and whatever it just takes it all and mix it up and gives you a great answer of it all so I think that's like the greatest power of Chagititi you know what it takes so many sources so many stack all of those answers give you a better result you fix it and it works I think that's that's exactly the power of these tools this is usually how this is the power of these tools how we use the Chagititi that's what it's meant for it's not look uh not all the developers in the world are going to lose their jobs next year they won't however many of them can be really good engineers only by leveraging that it helps you with automation it helps you with the simple stuff that's that I think that that's the biggest message that's the biggest announcement here it can do really simple stuff really really quickly if you want to create a CI for GitLab or GitHub action or even drone just ask it it's it was trained on so much data that includes so much code on GitHub specifically for basically everything it's it's so hundreds and thousands of yamls it can do better than you can just ask it and be it it can also help you search for your modern example i'm asking it later and see what it comes up with okay so I think we have let's let's do a summary so we can move to the corner of the week let's do try to end summary so I'd say the local development like as we said choosing maybe when I have a site project I want to start something starting to develop locally Docker compose whatever I'm satisfied with it adding maybe a CI in GitHub actions or whatever CI service you're using satisfied with that you want to show it to someone else great use and you hope to expose your computer to clients investors friends and family you like it take commerce advice and write telephone polynomial any other infrastructures code to provisionary sources on the cloud and push it to the cloud and then you can start moving around regarding the architecture itself if it's ECS EKS maybe a monolith or whatever when you get there you'll know what you do but first you need to run the application and see the loads like if it's not a very big application maybe Kubernetes. So once everything is quite ready you'll know like you'll know when you get there to to picking up which of which architecture you need or want it'll be after you use the application developed a lot of features a lot of things happen and then you'll be like listen I need something stable I need maybe replication needs to provision containers very very very fast that is Kubernetes if you need fast but not ultra fast and fully managed maybe it's AWS ECS Fargate so then it depends on the applications requirements anything else you want to add about the summit to ask if you touched on our first topic which we started our conversation with from Whiver I like it when you do a like and then in the video it's like you do a like it's amazing so when it comes to Whiver you know using this framework I'd say it's even a step back of what I just said with the local development so if you're starting a new project or you want to experiment with a new framework that uses the modern application architecture whatever you can use Whiver and see if it works for your workflow and your just to say it we are also yes many of your problems quote unquote because it works on so many levels it's how you manage your code and then it takes you through how you manage internally your components within the code and then how you pack them how you build them how you ship them and how you deploy them which by the way it offers plugins for I think I've said but many many solutions GKE for example pro-cubernetes yeah I need to sit with my eyes it's like you're talking and I'm like I need to sit with even though I see you I'm not not all the viewers can see you but I'm just saying it's a it's a different animal it works on many levels and it's a solution to many problems you have if if yeah to put a star in it if it works as advertised that's it we'll put their name to the test I like it 300 you know where is it from you know it's reverse yeah emotes we'll put their name okay so now that we have done our summary for the modern application application or application architecture we are moving to corner of the way you were mostly the corner of our now I always like it when you follow along and it was like yeah I'm preparing myself to what I want to say okay so corner of the week welcome everyone to the core of medical omen and I share anything that we've done in our in our lives okay in the past 100 years any experience knowledge or whatever so maybe we'll focus on something we did on the past week or maybe something we'll do in next week so omele any experienced knowledge tool or something you want to share yes this would uh to first of all just a random cool tool or another tool uh group of tools so you know how you find yourself sometimes you need an online checker for JWT tokens and then you need to encrypt or decrypt uh base 64 to the word would be actually encoder decoder not encrypt and then you actually need to encrypt or decrypt or parse a JSON or convert to YAML etc there are many many great tools for all of these things and more however there's one place that is kind of trying to be a Swiss Army knife for everything and it's called devtoys.app so you just have everything there not everything but pretty much most of what you need and you can actually install it it's a cask on brew so if you're working on a Mac a brew cask can install devtoys and you can see that or just go go to their website that's one thing the other is as i was watching the presentation for weaver uh they wanted to demo it and in many times or or many lectures and stuff courses that i've done in the past i needed an example application like a demo to run to teach with it to help with it to show something to run an MVP so apparently google have it's under the github for google cloud platform and they have a service that's called micro server is demo that's an online boutique okay it's just an online shop that you can it has fake stuff on it but you can basically shop for clothing and shoes and stuff like that that's it it's a demo that's distributed into a few services and you can run it with it has a health chart and it's ready to go with the east your staff and Kubernetes and customize etc etc so pretty cool and pretty useful nice i think AWS has its own patch of pets so i was using that a lot and then i figured that they have online boutique and it's pretty cool these are my two eyes okay i think i only have one a quick one about github actions and i wanted to so sometimes you have an application where you have maybe even six environments you know development one development two staging one for customers or whatever and you also have a flavors of your application so flavor number one flavor number two flavor can also be maybe a release of the bug you know it's really daily depends so you have many flavors and many deployment environments came in live environments or you want to deploy so i really liked it that in github actions i created a reusable workflow so if you're not aware that is something which is called a usable workflow you just create a workflow where you can use it in the same repository you can use it also in other repositories only if it's public or only if your github enterprise user sucks so you can't really share your workflow if you're not an enterprise i don't like that anyways you can use a local workflow and then let's say create a reusable workflow for deployment and then in your actual workflow which consumes the reusable workflow you can use a matrix which is which is crazy because in github actions if you want to do a mix and match between maybe an application flavor and a target deployment so what i'm using is like a workflow dispatch you know this well you can manually to get a workflow and then it according to the inputs of that workflow you know the manual inputs of that workflow it will decide whether to do this matrix or that matrix and everything is using the reusable workflow this saves so many lines of code and uses the process of managing and maintaining so many configurations you know because every every environment has its own maybe Cloudfront ID, S3 bucket, API endpoints so every environment has its own sets of values but if you use a github actions matrix with a reusable workflow it's a great mix and i really recommend it okay that's my amazing fault you can pretty easily do the same on github in running a matrix within github cis and github is crazy because you all have templates github took it way further you can create a repository with templates and consume it from there you know which is way more amazing but yeah github actions are doing their step by step on the one another thing i can give to github is their CI CI system and the docs is not bad at all everything else is amazing i i agree i i like i also like to see a lot okay so we've been to the corner we did our summary anything else you want to and before we try to go back to our lives good and quiet weekend everybody or a week whenever you're listening to that yeah yeah so actually it was good because we we are recording this like after we had an alarm over here you know for bombings so it's good because after an alarm usually there is a pause so luckily i didn't have to run to the shelter enough you know so we need to do it i do have something to add i have i have an apology to the audience yes not an apology and it's an explanation not an apology you may have noticed that there is an ad or two during the episode and the reason is we passed the number of listens per episode that it uh it's eligible for basically advertisements so we run a quick ad with every episode if you have a problem with that please let us know somehow we live our you can always get our links and contact points uh but it's just supporting us and it's not even covering the uh you know what it costs to use the platforms for recording or hosting the podcast but it's doing something so thank you for helping us by listening to six seconds of advertisement that is it six fifteen you know it depends as much as we can okay okay so thank you thanks everyone so for the advertisement and have a good week and next week bye