WEBVTT 1 00:00:06.400 --> 00:00:10.720 Hello everyone, and welcome to React Round Up, the podcast where we keep 2 00:00:10.720 --> 00:00:16.719 you updated on all things React related. We have a bunch of new hosts 3 00:00:16.800 --> 00:00:20.600 in the show, so this is going to be fresh for all of you 4 00:00:20.719 --> 00:00:24.920 that are listening us for a very long time. And yeah, let's get 5 00:00:24.920 --> 00:00:27.879 into it. So this show is produced by two companies, Stop and Doves 6 00:00:27.879 --> 00:00:30.879 and Onvoid. Pop and Doves is where we create top and dows so get 7 00:00:30.920 --> 00:00:36.600 top and pay and recognition while working on interesting problems and making meaningful community contributions. 8 00:00:36.880 --> 00:00:41.640 And Onvoid which offers remote design and software development services on a performance basis, 9 00:00:41.840 --> 00:00:46.640 so clients only pay when tasks are delivered and approved. My name is 10 00:00:46.679 --> 00:00:50.399 Lucas Paganini. I'm the founder of Onvoid and one of the hostess in the 11 00:00:50.439 --> 00:00:56.640 podcast today and joining me in today's episode is first the one and only Charles 12 00:00:56.679 --> 00:01:00.280 Maxwood. Yeah, old host, same as the new or new host, 13 00:01:00.359 --> 00:01:04.719 same as you. I started the show way back when and uh yeah, 14 00:01:06.200 --> 00:01:10.319 helped post it for the first three years. So anyway, I'm back. 15 00:01:10.560 --> 00:01:15.879 Good to see y'all. The king is back, yeah, and we also 16 00:01:17.000 --> 00:01:21.840 have some new faces around here. Well, my voice is probably new to 17 00:01:21.920 --> 00:01:26.920 a lot of people, but we also have Peter Osa. Yeah, hello, 18 00:01:26.920 --> 00:01:34.599 everone, so nice having nice nine Misten everyone in the panel list. 19 00:01:34.200 --> 00:01:38.400 Yeah, it's great to talk about reactuff. It's you all. Yeah, 20 00:01:40.439 --> 00:01:46.599 great to having Peter. And we also have Chris Fruan yep Hi. Everyone 21 00:01:47.319 --> 00:01:52.599 super happy to be here, Very excited to get into this episode and future 22 00:01:52.640 --> 00:02:00.079 episodes. Awesome, awesome. Okay, so we have very high cal of 23 00:02:00.120 --> 00:02:04.719 our professionals here. They're probably all smarter than me, so I'm going to 24 00:02:04.799 --> 00:02:09.000 introduce the topic and rely on their intelligence for us to really have that into 25 00:02:09.039 --> 00:02:16.560 this episode. So we were discussing talking about how we deploy or single page 26 00:02:16.599 --> 00:02:21.319 applications. Of course we're going to talk more specifically about REACT, but I 27 00:02:21.199 --> 00:02:23.159 imagine that a lot of what we're going to talk about here today is going 28 00:02:23.199 --> 00:02:29.680 to apply to a lot of folks who are using other frameworks. So you 29 00:02:29.800 --> 00:02:36.680 might be using View or anything. Actually, really any single page application framework 30 00:02:36.759 --> 00:02:39.560 would probably benefit from the things that we're going to discuss here today. And 31 00:02:39.639 --> 00:02:45.719 yeah, so we're going to talk about how we deploy our single page applications. 32 00:02:46.039 --> 00:02:51.639 So I'm going to just get things rolling and say that thus far, 33 00:02:51.840 --> 00:02:57.719 I've been a very happy, heroical customer for the front end. I don't 34 00:02:57.719 --> 00:03:05.439 think Heroical is the most costive effect alternative, but it is so easy to 35 00:03:06.120 --> 00:03:09.680 get things deployed into Heroku. There are many other alternatives that also make it 36 00:03:09.719 --> 00:03:16.599 easier nowadays. But I know that I sound young, but I'm actually quite 37 00:03:16.599 --> 00:03:23.039 old. So back in the days, Heroica was the easiest one and the 38 00:03:23.120 --> 00:03:25.719 other ones were not as close as easy as Europa, and I just stick 39 00:03:25.800 --> 00:03:30.000 to it, so I think it serves me well for most projects. But 40 00:03:30.520 --> 00:03:38.360 I've been looking a lot into cloud Flare cloud Flare pages because it's a servilis 41 00:03:38.439 --> 00:03:44.840 alternative, which means that I don't first if my website isn't being accessed as 42 00:03:44.960 --> 00:03:47.879 much, I don't have to pay for a dedicated server, which is a 43 00:03:47.919 --> 00:03:53.159 problem that I have currently with Heroku. Even if like my super old website 44 00:03:53.240 --> 00:03:58.400 is not being accessed anymore, I'm still having to pay for it, which 45 00:03:58.960 --> 00:04:03.800 I think could be a better use of my money if I could spend it 46 00:04:03.840 --> 00:04:09.240 somewhere else. So I would like to pay on a performance basis. But 47 00:04:09.560 --> 00:04:16.800 also I can't also have scalability issues because if I really have like millions of 48 00:04:16.959 --> 00:04:20.920 users trying to access my website at the same time, I'm gonna have to 49 00:04:21.120 --> 00:04:26.639 go into Heroko and increase my dinos, which is the name that they give 50 00:04:26.720 --> 00:04:30.680 to the servers. But if I go with a Servil's approach, I don't 51 00:04:30.720 --> 00:04:34.439 have to worry about scalability at all. So that sounds really interesting to me. 52 00:04:34.519 --> 00:04:39.720 I gotta be honest, I haven't migrated yet, but I'm really interested 53 00:04:39.800 --> 00:04:43.560 in the benchmarks I've seen so far. And yeah, I wanted to know 54 00:04:44.160 --> 00:04:46.519 what is the experience that you guys have with that, and if you think 55 00:04:46.560 --> 00:04:51.680 that this would be a good move or if I'm setting myself for failure if 56 00:04:51.720 --> 00:04:56.240 I go that route, My experience is totally different, So I'm curious what 57 00:04:56.439 --> 00:05:00.519 Peter and Chris have to say. So experience, Yeah, hero cool, 58 00:05:01.319 --> 00:05:05.879 Yeah, Yeah is very great. Yeah, like I'm actually it's actually very 59 00:05:05.920 --> 00:05:12.600 awesome. Although yeah, but I'm kind of like a fan of like Netli 60 00:05:12.680 --> 00:05:15.439 five or just starting pages, so I think I'm that kind of guy. 61 00:05:15.560 --> 00:05:20.639 So just okay, once I get once I connect notified to my ripportor and 62 00:05:20.879 --> 00:05:27.439 just build the application and then boom. Also, I just love how how 63 00:05:27.480 --> 00:05:30.040 simplistic it is. Yeah, and then there still the old fashioned way of 64 00:05:30.120 --> 00:05:35.720 GiB and trying to do some configurations on how to set up like spas and 65 00:05:35.800 --> 00:05:40.319 how to kind of like build it and then push it up to the top 66 00:05:40.319 --> 00:05:43.439 pages. But they, yeah, take away bit bias to netli Fi and 67 00:05:43.480 --> 00:05:47.519 then Heal came along, so I'm still find of visual as well too. 68 00:05:47.839 --> 00:05:51.720 It's kind of very easy, especially for next year's applications. So it's just 69 00:05:53.279 --> 00:05:58.079 so so easy. Yeah, I think, well, in yeah, I 70 00:05:58.120 --> 00:06:01.000 when I started with when I then with SPS, I kind of if you 71 00:06:01.000 --> 00:06:06.480 look at you kind of fleet for a little projects, so kind of Jeyted 72 00:06:06.560 --> 00:06:13.800 as well. I found then I think subsequently then I found Metlify and then 73 00:06:13.920 --> 00:06:17.160 Stevins. Yeah, so Chris, what do you think? What do you 74 00:06:17.199 --> 00:06:21.639 think? Is like, yes, so actually I are more on page with 75 00:06:21.720 --> 00:06:27.040 you. I'm also a huge Netlefy fan. Typically, like when I write 76 00:06:27.040 --> 00:06:29.680 about it or talk about it, I always say that it almost feels like 77 00:06:29.720 --> 00:06:35.240 stealing because they they're so generous with the build time and I think you can 78 00:06:35.279 --> 00:06:39.680 have I don't even know if there is a sight limit, but it's just 79 00:06:39.759 --> 00:06:43.480 it's yeah, they make it super easy. With that said, though, 80 00:06:43.519 --> 00:06:47.920 I I did start also back back in the days like like Lucas on Heroku, 81 00:06:49.439 --> 00:06:53.120 and I think, at least in my mind or what I remember, 82 00:06:53.120 --> 00:06:57.360 Heroka has a more you have like access to your terminal and everything, which 83 00:06:57.560 --> 00:07:00.199 you maybe have as well with Netlefy, but loves much more. I think 84 00:07:00.199 --> 00:07:05.319 it's much more for maybe someone who is more like a more like a CIS 85 00:07:05.399 --> 00:07:10.639 admin type person where it's really like point and click, whereas Roca you can 86 00:07:10.680 --> 00:07:15.279 kind of drill down and get more into the technical stuff. But yeah, 87 00:07:15.360 --> 00:07:17.560 like you Peter, like, I think I moved away because I think I 88 00:07:17.600 --> 00:07:21.600 believe they took away the free tier entirely not too long ago. Yeah, 89 00:07:21.920 --> 00:07:27.439 yeah, I think that's kind of missed everything. Like there's so many guys, 90 00:07:27.480 --> 00:07:30.519 like I know, so many guys were like, oh you want the 91 00:07:30.759 --> 00:07:33.319 lovely look. They just want to spin it for a little side project you're 92 00:07:33.360 --> 00:07:38.920 working on Boom the freeta was going and we're like, oh no, and 93 00:07:39.000 --> 00:07:43.639 then start seeing the cell and other options and yeah, the joke on it. 94 00:07:43.839 --> 00:07:47.399 So I think that was kind of like the main in Guns for Men, 95 00:07:47.480 --> 00:07:50.360 because yeah, it was, it was really nice. Like the it's 96 00:07:50.439 --> 00:07:57.279 filthality for small projects like Ebody for Reactor for even might not just back in 97 00:07:57.439 --> 00:08:01.680 projects little projects like you just spin it off. Yeah, but I think 98 00:08:01.680 --> 00:08:09.000 that was like what do you think, because do you think did the foods 99 00:08:09.040 --> 00:08:15.000 affected any of its use at any point? Oh? Man, you really 100 00:08:15.040 --> 00:08:22.240 needed to go there right like that. I was almost closer. Yeah, 101 00:08:22.319 --> 00:08:28.519 you're right, I did felt that. I just felt that I know that 102 00:08:28.680 --> 00:08:33.919 we're not supposed to rely on free stuff. I mean, there's always somebody 103 00:08:35.039 --> 00:08:39.720 doing the work, so if we really want to use it, we should 104 00:08:39.960 --> 00:08:46.799 be paying something for the value that we're getting. But honestly, they made 105 00:08:46.879 --> 00:08:50.919 me used to the free servers, and then when they took it away, 106 00:08:50.960 --> 00:08:54.720 I was like, oh, come on, like, there's so much that 107 00:08:54.799 --> 00:09:00.200 we're gonna have to pay now. But one thing that I really like about 108 00:09:00.240 --> 00:09:03.960 Heroku is that it allows me to push entire doctor containers. I don't know 109 00:09:05.480 --> 00:09:07.960 that's an option for Netlify, because, as you said, I always saw 110 00:09:09.000 --> 00:09:15.120 Netlify as more of a platform as a service. So as you were saying, 111 00:09:15.159 --> 00:09:20.159 it doesn't give me much control over the infrastructure, which it might be 112 00:09:20.559 --> 00:09:26.799 just a misunderstanding from my end because I haven't really used netlified that much. 113 00:09:26.840 --> 00:09:31.399 So I don't want to put a Netlify in a position of saying Hey, 114 00:09:31.440 --> 00:09:33.919 lookas everything that you're saying is wrong, because it might just be. I've 115 00:09:33.960 --> 00:09:39.799 never used it for production applications, but I know that Heroico allows me to 116 00:09:39.840 --> 00:09:46.600 push Doctor containers, and I really like that because I tend to always containerize 117 00:09:46.679 --> 00:09:48.799 everything that I'm doing, even if it's just the front end, even just 118 00:09:48.919 --> 00:09:54.799 front end applications. My experience has always been to containerize it as much as 119 00:09:54.840 --> 00:10:01.639 possible. It just makes all the other parts of my continuous integration pipeline easier 120 00:10:01.679 --> 00:10:09.480 to do because if I can containerize my application, then I can just substitute 121 00:10:09.600 --> 00:10:13.440 one project for the other and reuse all the other setup that I have for 122 00:10:13.559 --> 00:10:18.919 continuous integration, like running my and to and test with Cyprus and building and 123 00:10:18.919 --> 00:10:22.840 serving, et cetera. So I really like that, and I really like 124 00:10:22.960 --> 00:10:28.039 the consistency of knowing that if it's working on my local Doctor container is going 125 00:10:28.120 --> 00:10:31.480 to be working the same way in the cloud environment. So I try to 126 00:10:31.639 --> 00:10:39.639 stay away from those smart algorithms that you just like, integrate your GitHub repository 127 00:10:39.720 --> 00:10:43.000 and they see that it has a package Jason, so they understand that it's 128 00:10:43.039 --> 00:10:48.440 not then they automatically build and serve. I try to avoid that because I 129 00:10:48.480 --> 00:10:54.879 am a freak for control, so I really I wanted to be sure of 130 00:10:56.039 --> 00:11:01.039 what I was deploying. So yeah, I really like when I can just 131 00:11:01.080 --> 00:11:05.639 deploy a doctor container. But I know that if I go into a server 132 00:11:05.720 --> 00:11:09.000 list path, I won't be able to have that. So this is being 133 00:11:09.120 --> 00:11:16.159 my current question, right, So would it makes sense for me to give 134 00:11:16.240 --> 00:11:24.039 up control to have that speed and scalability and ease of serverists or do I 135 00:11:24.080 --> 00:11:26.600 still want to have control and have doctor containers. And by the way, 136 00:11:28.360 --> 00:11:31.960 one of the things that also make me want to have doctor containers instead of 137 00:11:33.039 --> 00:11:41.000 just a regular static serve is because I almost always use Service I rendering, 138 00:11:41.240 --> 00:11:46.840 and it's not always just a pre rendered or pre generated static website. There's 139 00:11:46.919 --> 00:11:52.559 always some pages that are indeed dynamic and they need to be dynamically rendered. 140 00:11:52.960 --> 00:11:58.639 So I can't just serve static files. I really need to have a little 141 00:11:58.679 --> 00:12:03.840 bit more more power on the server to make sure that the pages that need 142 00:12:03.879 --> 00:12:09.919 to be dynamically rendered are dynamically rendered on the server. So I don't know 143 00:12:09.000 --> 00:12:16.679 if if that changes for you guys, if your experience is more like just 144 00:12:16.679 --> 00:12:22.879 just relying on client side rendering, or if you also had this experience with 145 00:12:22.000 --> 00:12:26.879 service I rendering and how you tackle that. So I'm going to jump in 146 00:12:26.919 --> 00:12:31.519 because you made me feel less weird because we're all talking about, you know, 147 00:12:31.600 --> 00:12:37.240 deploying to something like Heroku, which my first experience with Heroku was when 148 00:12:37.279 --> 00:12:41.480 they initially launched, they were an online id for Ruby on Rails, and 149 00:12:41.519 --> 00:12:48.840 then they pivoted and did the push to deploy, and so I've been using 150 00:12:48.840 --> 00:12:52.960 Heroku for years and years and years and years. There are definitely things I 151 00:12:54.039 --> 00:12:56.799 like about Heroku, but yeah, it's usually the cost that keeps me off 152 00:12:56.799 --> 00:13:00.559 of it. I just I'm not willing to pay for it. I was 153 00:13:00.559 --> 00:13:03.759 a SISS admin before I was a programmer, and so I'm pretty comfortable going 154 00:13:05.000 --> 00:13:07.519 I'm just going to set up a server to run this myself, and so 155 00:13:07.519 --> 00:13:11.159 I've done that before with the front end framework. Shoot have to do that 156 00:13:11.279 --> 00:13:16.759 nearly as often, but anyway, what I tend to do is, yeah, 157 00:13:16.799 --> 00:13:22.679 I tend to reach for Docker for my deployments. I'm tip typically writing 158 00:13:22.759 --> 00:13:26.240 Rails and React. If I'm writing React, and so a lot of times 159 00:13:26.240 --> 00:13:31.960 the deployment is effectively whatever build systems built into Rails pointed at my React files 160 00:13:33.000 --> 00:13:35.759 and it just you know, it deploys it as part of the assets, 161 00:13:37.440 --> 00:13:43.120 and so a lot of the deployments have just been you know, kind of 162 00:13:43.120 --> 00:13:46.360 a standard thing, and you know, we've gone through all the stages where 163 00:13:46.840 --> 00:13:52.480 you know, initially it just kind of, you know, put a digest 164 00:13:52.600 --> 00:13:56.240 on your JavaScript files. This is before React. Once React kind of came 165 00:13:56.279 --> 00:14:00.799 around. Then we had Webpack integrated with Rails, which was a huge pain 166 00:14:00.840 --> 00:14:05.120 in the neck because Webpack and I mean it was better than the alternatives at 167 00:14:05.120 --> 00:14:09.919 the time, but now we've got much better alternatives, I think than Webpack. 168 00:14:13.000 --> 00:14:16.000 But yeah, so you would just when you deployed, it just installed 169 00:14:16.000 --> 00:14:20.159 all the libraries for Rails, you had note installed on your server, It 170 00:14:20.240 --> 00:14:24.240 did the build, it put it where Rails could find it, and then 171 00:14:24.279 --> 00:14:26.159 you just pointed your app at that and then it would hit your APIs on 172 00:14:26.200 --> 00:14:31.120 your Rails app. The other thing that I'm starting to get into now, 173 00:14:31.240 --> 00:14:35.440 and this is part of launching the React Geniuses, which is going to be 174 00:14:35.440 --> 00:14:41.679 the video series and the meetups, is I want to build apps in kind 175 00:14:41.679 --> 00:14:45.759 of the big major frameworks, and so I've started playing with Redwood JS and 176 00:14:46.519 --> 00:14:52.080 I'm still of the opinion that i want to do most of this with doctor 177 00:14:52.120 --> 00:14:56.799 containers, and I've been using the new Rails tool for that and it's called 178 00:14:56.879 --> 00:15:03.360 camal and effectively, what it does is you have docer containers that are built 179 00:15:03.399 --> 00:15:05.200 with your app in it, and so it knows how to build, right, 180 00:15:05.360 --> 00:15:09.960 which is what Lucas is talking about. But the difference between using it 181 00:15:09.000 --> 00:15:13.159 to push to something like Heroku versus using camal is you go and you set 182 00:15:13.240 --> 00:15:20.519 up servers on Digital Ocean or linod or something like that, and then what 183 00:15:20.600 --> 00:15:24.639 it does is it actually logs into that machine, it installs Docker on it 184 00:15:24.679 --> 00:15:28.360 if it doesn't already have it, and then it updates the images for you 185 00:15:28.480 --> 00:15:31.320 as you go. And so then you deplay it, you have your secrets 186 00:15:31.360 --> 00:15:35.799 on your local dev machine, you push it all up, it does the 187 00:15:35.840 --> 00:15:37.759 thing. There's also a way to integrate that with like one password if you 188 00:15:37.799 --> 00:15:41.720 want your secrets in one password, and so yeah, so it does all 189 00:15:41.720 --> 00:15:46.519 the build and push and deploy and everything like that, and so that that's 190 00:15:46.639 --> 00:15:50.720 kind of the way that I've been rolling lately. I will say though that 191 00:15:50.759 --> 00:15:54.120 it's really nice to playing something like netlafire ever sell where they have kind of 192 00:15:54.159 --> 00:15:58.559 the they know how to build these apps, and so effectively, what you 193 00:15:58.559 --> 00:16:02.360 wind up doing is you say push it up to Versell, and Versell says, 194 00:16:02.519 --> 00:16:03.639 oh, I know what to do with this, and it builds it 195 00:16:03.679 --> 00:16:07.000 for you. And so then you know, unless you've got something a little 196 00:16:07.039 --> 00:16:11.399 bit different going on outside of the norm, which most people don't, it 197 00:16:11.559 --> 00:16:15.600 just happily does it for you. So there are definitely trade offs. The 198 00:16:15.639 --> 00:16:18.159 Heroku thing is another. If you don't want to fuss with your server setup, 199 00:16:19.320 --> 00:16:23.600 right, they manage all that stuff, I wind up The only other 200 00:16:23.679 --> 00:16:27.759 drawback I guess th Heroku versus some of the other ones is that I feel 201 00:16:27.759 --> 00:16:33.320 like I wind up paying for Heroku and like six add ons on any app 202 00:16:33.320 --> 00:16:37.519 that I run on it. And so if I yeah, but I've been 203 00:16:37.519 --> 00:16:42.039 doing contract work. So if I have a client, right who isn't going 204 00:16:42.120 --> 00:16:48.120 to pay me ongoing whatever to maintain their app, then Heroku is actually the 205 00:16:48.159 --> 00:16:52.720 way that I go because then nobody has to figure anything out, right if 206 00:16:52.240 --> 00:16:56.440 they if they have a problem with it running and I get hit by a 207 00:16:56.480 --> 00:17:00.639 bus, they can call Heroku and say my app isn't running Heruku may be 208 00:17:00.679 --> 00:17:03.679 able to help them out. So anyway, that's kind of the long and 209 00:17:03.679 --> 00:17:07.000 the short of how I do deployments, which is different I think than most 210 00:17:07.000 --> 00:17:10.319 of the people in the React community. Yeah, one thing I also wanted 211 00:17:10.359 --> 00:17:14.119 to say about things like netlefi. Ninety nine percent of the time you can 212 00:17:14.240 --> 00:17:17.799 just rely on. However, they're, like Lucas said, they're reading your 213 00:17:17.960 --> 00:17:21.839 MPM. But if you really want to get into the weeds, they have 214 00:17:21.920 --> 00:17:26.799 this this TOMIL file and you can define I mean, you can't do everything, 215 00:17:26.799 --> 00:17:29.799 but you can define quite a few things like if you need I don't 216 00:17:29.839 --> 00:17:32.880 know, if you if you change domains or something and you need some custom 217 00:17:32.960 --> 00:17:37.039 redirects. And I actually needed it recently. It wasn't in the TOMIL file, 218 00:17:37.119 --> 00:17:41.720 but one of the environment flags because so I'm a primarily a Gatsby guy, 219 00:17:41.880 --> 00:17:45.319 so not not quite a SPA, but you know, building multi page 220 00:17:45.359 --> 00:17:51.839 sites with React, it's quite a big site, and I needed to bump 221 00:17:52.359 --> 00:17:56.680 like, there's a built in environment variable for the memory that it uses when 222 00:17:56.759 --> 00:18:00.359 building, so I needed to bump that up. But yeah, I face 223 00:18:00.440 --> 00:18:04.359 that too, Okay, Yeah, and but yeah, I would wonder. 224 00:18:06.000 --> 00:18:10.359 Uh, I don't believe you can do darker anything like that, but I 225 00:18:10.359 --> 00:18:12.359 don't know. Maybe Peter could speak a bit to that, but I don't 226 00:18:12.359 --> 00:18:18.319 have experience with that, just just with a tune of file. So yeah, 227 00:18:18.599 --> 00:18:22.200 I don't think it starts much like ability kind of. So it's just 228 00:18:22.720 --> 00:18:27.559 mostly I think that's where he cartually shines, and I think, yeah, 229 00:18:29.279 --> 00:18:33.119 Charles Mitchells come out, yeah, and it's really actually interesting. I think 230 00:18:33.119 --> 00:18:37.200 I read it for me boost from yeah, the creator of the blower. 231 00:18:37.680 --> 00:18:41.440 I think it's yeah, I don't forget his name, Chris also yeah, 232 00:18:41.480 --> 00:18:48.480 so it's actually nice too. So but apparently I think one thing about why 233 00:18:48.559 --> 00:18:52.240 I actually preferend that I think it's based on my use kis so most of 234 00:18:52.279 --> 00:18:56.599 the time I usually like to bundle, like just show my applicasions are just 235 00:18:56.680 --> 00:19:03.559 like static. So if if I'm maybe trying to do some other kind of 236 00:19:03.880 --> 00:19:07.960 gymnastics or whatever configuration, I I just I just limit it to that kind 237 00:19:07.960 --> 00:19:11.039 of thing because I actually feel maybe it's best to just bound the digitals, 238 00:19:11.319 --> 00:19:14.599 just build it and bonded it and then just push it up. So I 239 00:19:14.599 --> 00:19:18.880 think it's just my philosophy though, so I'm really not simply key. So 240 00:19:18.000 --> 00:19:22.440 most of the time they may be usually cases for me to actually just you 241 00:19:22.480 --> 00:19:26.759 know, try to explore or maybe the options, but I think it's just 242 00:19:26.759 --> 00:19:30.480 based on how I handle think about the ocation. I just want to build 243 00:19:30.519 --> 00:19:34.920 it and just yeah, maybe it's something someone can just go this is the 244 00:19:34.960 --> 00:19:37.680 five, push it to vessel, push it to the five something. It 245 00:19:37.839 --> 00:19:41.720 just is obvious in my own opinion. Yeah, I don't know if you 246 00:19:41.839 --> 00:19:47.599 have any Oh yeah, so look, as I think you said something about 247 00:19:48.640 --> 00:19:53.039 the using like for all your projects using DOCA, Like you always docker as 248 00:19:53.079 --> 00:19:56.519 your applications to put front and on. So is it do this for all 249 00:19:56.599 --> 00:20:02.279 the applications, both your side projects or you company projects, So like, 250 00:20:02.359 --> 00:20:04.759 I just want to know if it's for all the applications you work it's just 251 00:20:04.759 --> 00:20:14.559 for specific types. Okay, so actually it's for all of them. I 252 00:20:14.599 --> 00:20:23.000 don't remember any project that I haven't containerized everything. Yeah, yeah, it's 253 00:20:23.039 --> 00:20:26.319 for every project. It's sort of company projects. For personal projects, I 254 00:20:26.359 --> 00:20:33.240 always containerize everything. There are definitely some projects I've worked on in which I 255 00:20:33.400 --> 00:20:37.000 was not the person that did the architecture and they were, uh, they 256 00:20:37.079 --> 00:20:41.519 were not containerizing the front end, which I just left it as it is 257 00:20:41.559 --> 00:20:45.559 and worked in the way that they that they were already doing it. But 258 00:20:47.079 --> 00:20:52.000 every time that I had control over the architecture, I went to the route 259 00:20:52.039 --> 00:20:59.759 of containerizing it. But now like, so, okay, my back ends 260 00:20:59.799 --> 00:21:04.359 are always definitely going to be containerized. I don't see myself migrating the back 261 00:21:04.480 --> 00:21:11.119 ends in which I'm architecturing to like a fully serverist approach or something like that. 262 00:21:11.799 --> 00:21:17.039 I really think that there's much more benefit in containerizing the back ends and 263 00:21:17.079 --> 00:21:22.400 having that level of control over the back end because it's generally not as straightforward 264 00:21:22.480 --> 00:21:26.279 as front and builds in front end deployments. Also, that makes sense to 265 00:21:26.319 --> 00:21:27.759 me. I primarily do back end. That makes a lot of sense to 266 00:21:27.799 --> 00:21:32.400 me. Yeah, yeah, I think for back ends the new BUNA you 267 00:21:32.440 --> 00:21:38.519 just have to, I feel. But I actually am reconsidering my position on 268 00:21:38.559 --> 00:21:44.240 that for the front end because in the back end, I generally don't have 269 00:21:44.319 --> 00:21:49.440 a single monalytical application in the back end like sometimes I do. But in 270 00:21:49.519 --> 00:21:55.599 other cases I have a bunch of micro services and I want to deploy them 271 00:21:55.680 --> 00:22:00.000 and orchestrate them in the cloud. So of course it makes a lot more 272 00:22:00.160 --> 00:22:06.799 sense to use doctor containers in that case and containerize the entire thing and don't 273 00:22:06.920 --> 00:22:11.079 use a platform that it is so simple in that sense that doesn't give you 274 00:22:11.160 --> 00:22:17.720 all the control that you want to orchestrate and take care of the scalability of 275 00:22:17.759 --> 00:22:22.839 your back end. But it's like it's not even the same chart. Right. 276 00:22:23.359 --> 00:22:29.480 If you think of the chart of how your application connects, and you 277 00:22:29.559 --> 00:22:36.200 think about every piece that makes the back end work, they're really not connected 278 00:22:36.200 --> 00:22:40.880 to the front end. Like they are completely separate environments and separate servers. 279 00:22:41.200 --> 00:22:45.759 And for the front end to scale, we really only need to put a 280 00:22:45.799 --> 00:22:51.960 low balancer and throw as many servers as we want because we're never gonna do 281 00:22:52.920 --> 00:22:59.160 multiple services or micro services for a front end server. Why would you ever 282 00:22:59.599 --> 00:23:03.039 want to purchase that complexity just to serve a front end, Right, So 283 00:23:04.079 --> 00:23:11.119 this is why I really think that front ends are an excellent, excellent candidate 284 00:23:11.519 --> 00:23:19.759 for serverists, because every single drawback the server licet has is irrelevant for front 285 00:23:19.839 --> 00:23:25.759 end deployment. Like what I see people complaining the most about servertists is the 286 00:23:25.799 --> 00:23:32.200 difficulty to debug and to see what's going on, to understand the flow of 287 00:23:32.319 --> 00:23:36.559 data. And also it comes to a point where you're deploying four hundred Lambda 288 00:23:36.640 --> 00:23:44.000 functions and you're just crazy trying to understand what's calling what. But if you're 289 00:23:44.000 --> 00:23:48.400 going to deploy front end using serverle lists, then you're just gonna deploy one 290 00:23:48.440 --> 00:23:55.200 function into one cloud environment and that's it. You're done. You're not gonna 291 00:23:55.440 --> 00:24:00.880 do anything else besides that. So I actually think I'm doing in it wrong 292 00:24:00.119 --> 00:24:06.799 in terms of front and the deployment specifically, But for back in I would 293 00:24:06.960 --> 00:24:10.440 I would definitely keep the structure that I have. And by the way, 294 00:24:10.599 --> 00:24:15.680 just one note check you're mentioning the costs of Heroku add ons. I never 295 00:24:15.880 --> 00:24:22.759 used any Heroku add on. I always used other options. And what I 296 00:24:22.920 --> 00:24:29.160 really like about Heroku is that they don't have their own data centers. I 297 00:24:29.240 --> 00:24:32.920 know that might sound really weird, Like what I like the most is the 298 00:24:32.960 --> 00:24:36.680 fact that they don't have something. But the thing is because they don't have 299 00:24:36.759 --> 00:24:41.039 their own like Digital Ocean has their own data centers, yes, because Heroku 300 00:24:41.160 --> 00:24:49.519 doesn't. They use AWS, which is great to me because I can host 301 00:24:49.759 --> 00:24:56.759 my main application in Heroku, but I can host my Radis and moguldb on 302 00:24:56.880 --> 00:25:02.160 a WS and I'm not gonna have any latency because it's in the same data 303 00:25:02.200 --> 00:25:07.319 center. So this is what I always did instead of using the Heroku add 304 00:25:07.400 --> 00:25:12.559 ons I would I would plug everything else from AWS. So for example, 305 00:25:14.079 --> 00:25:18.799 I may use Mongo Atlas, which is a managed service for Mongo deb and 306 00:25:18.920 --> 00:25:22.720 you can host that on AWS. And I might use Radus Labs, which 307 00:25:22.759 --> 00:25:26.440 is a manager. Oh, I see where you're going radis, and I 308 00:25:26.559 --> 00:25:30.519 host it on a WS and then my main container is on Heroku, which 309 00:25:30.720 --> 00:25:34.880 is also a WS, so I don't have to use the the add ons 310 00:25:36.000 --> 00:25:38.000 from hero You just make sure you're in the same region, and then your 311 00:25:38.039 --> 00:25:47.079 secrets point exactly the other services exactly, and so then Heroku just becomes a 312 00:25:47.119 --> 00:25:52.400 harness to deploy or manage your main app and your accessories, which you have 313 00:25:52.440 --> 00:26:00.799 to manage on your own anyway as exactly. Okay, so look in an 314 00:26:00.799 --> 00:26:04.640 instance of changing regions, let's assume I don't know, maybe it is just 315 00:26:04.720 --> 00:26:10.880 being been paranoid. Maybe there's a change of regions, and yeah, maybe 316 00:26:11.240 --> 00:26:15.480 today you could just decide, oh, we know, we don't use the 317 00:26:15.519 --> 00:26:18.200 doubles anymore. I just want to patonize maybe we know or something else on 318 00:26:18.359 --> 00:26:25.759 the service just that instance, wouldn't that solution not? Yeah, because at 319 00:26:25.759 --> 00:26:29.240 the end of they I can of be seck with like I'm just looking at 320 00:26:29.279 --> 00:26:33.720 how spontaneous some changes could be. And so what do you think in that 321 00:26:33.799 --> 00:26:37.359 kind of situation, what would you do if there's a change at any point, 322 00:26:37.400 --> 00:26:41.279 maybe a massive change, we just start think about how to migrate out, 323 00:26:41.440 --> 00:26:45.319 or how to look for a new solution or something. Great question. 324 00:26:45.559 --> 00:26:49.400 I would definitely if that happened, I would definitely fully migrate to a w 325 00:26:49.599 --> 00:26:56.000 AS, which is where all my other add ons, if we're calling them 326 00:26:56.039 --> 00:27:03.599 adoms are. Yeah, I would definitely migrate to AWS. And they would 327 00:27:03.640 --> 00:27:07.359 never do that out of the blue. They would definitely give us a lot 328 00:27:07.400 --> 00:27:15.319 of a lot of previous notice before doing that, so we would definitely have 329 00:27:15.480 --> 00:27:23.000 enough time to migrate. And I don't like that everything needs to be AWS. 330 00:27:23.200 --> 00:27:26.079 Okay, Like, let me make that clear. I don't like the 331 00:27:26.079 --> 00:27:33.559 AWS interface. It's so confusing. It's hard to explain to other developers on 332 00:27:33.599 --> 00:27:37.759 my team. I think it could be so much simpler. Jeff Besis, 333 00:27:37.799 --> 00:27:45.720 if you're listening to the show, please please, like you have so much 334 00:27:45.799 --> 00:27:52.519 money, just hire one designer to make that simpler. Okay, So yeah, 335 00:27:52.559 --> 00:27:55.720 I definitely think it could be way simpler, and they have done some 336 00:27:55.799 --> 00:28:03.240 initiatives to simplify that like we have AWS light Sale, which is a direct 337 00:28:03.279 --> 00:28:07.359 alternative to Heroku, where you can simply push one container and it's going to 338 00:28:07.400 --> 00:28:14.759 take care of serving that you don't have to configure the DNS and a bunch 339 00:28:14.799 --> 00:28:19.880 of other settings yourself. It's simpler. It's still not as simple as Heroku, 340 00:28:21.039 --> 00:28:25.160 but it is way simpler than all the other ways in which you can 341 00:28:25.200 --> 00:28:30.480 host an application on AWS. But yeah, if that happened, I would 342 00:28:30.519 --> 00:28:33.680 migrate to a WS. What I really would like to do if I could, 343 00:28:34.359 --> 00:28:40.400 would be to have my main application on Digital Ocean. And the only 344 00:28:40.440 --> 00:28:45.519 reason why I don't do that, and actually one of the reasons why I 345 00:28:45.680 --> 00:28:49.200 want to do that is the pricing, and the other is because Digital Ocean 346 00:28:49.319 --> 00:28:56.920 has the simplest Kubernaties managed service out there. Like if you compare deploying Kubernetes 347 00:28:57.000 --> 00:29:03.200 to Digital Ocean, a WS, Azure and GCP, I haven't compared that 348 00:29:03.319 --> 00:29:07.440 to Lenode, which I think they changed the name to Akamai or something like 349 00:29:07.519 --> 00:29:15.119 that, but I know that come I bought them. Yeah, so Digital 350 00:29:15.119 --> 00:29:23.119 Otion is just so much simpler to deploy Kubernetes cluster and the pricing is a 351 00:29:23.119 --> 00:29:30.559 lot more friendlier too. But I don't deploy on Digital Ocean because I would 352 00:29:30.640 --> 00:29:37.720 have to get rid of Mongo Atlas, which is my managed service for Mongo 353 00:29:37.759 --> 00:29:45.119 deb because Mongo Atlas only allows me to serve on a ws GCP or Asia, 354 00:29:45.279 --> 00:29:48.519 and even if I put it in a very very close data center, 355 00:29:48.720 --> 00:29:52.000 it's not going to be in the same data center. So I don't want 356 00:29:52.160 --> 00:29:57.880 that actual latency. So I would rather have more complexity on my plate to 357 00:29:59.039 --> 00:30:03.079 the to the play everything in the same data center, then using a different 358 00:30:03.160 --> 00:30:11.079 cloud provider and having my dB in a different data center. Yeah, that 359 00:30:11.200 --> 00:30:15.359 sounds that sounds nice. I think that's unsolid. Yeah, that's so. 360 00:30:15.920 --> 00:30:22.680 But then I think maybe let's look for an instance, maybe going to consider 361 00:30:22.720 --> 00:30:26.440 the cost for example, or yeah, let's ass you like, still the 362 00:30:26.440 --> 00:30:33.119 same case case where the heroes decides to attract yours or you know, migrate 363 00:30:33.279 --> 00:30:36.559 or Swish jounelers or maybe they want to patronat you know, then they just 364 00:30:36.559 --> 00:30:40.279 fish to them. So if imagine if you're working on it, like you 365 00:30:40.400 --> 00:30:45.759 putjet on a business, it's the example like the cost of migration and the 366 00:30:45.799 --> 00:30:48.279 cost of kind of moving that yeah, I know, yeah, obviously costs 367 00:30:48.480 --> 00:30:53.240 a bit with it because you know it's a business and so many things will 368 00:30:53.240 --> 00:30:57.599 be involved. But then don't you consider that that would be also cost because 369 00:30:57.680 --> 00:31:04.640 yeah, you have your switching doesn't tally it screen to affect the performance at 370 00:31:04.680 --> 00:31:08.240 the point, so you just have to switch be moving from here to a 371 00:31:08.359 --> 00:31:15.559 others. Yeah, so InStyle, it's not better to just use the dying 372 00:31:15.759 --> 00:31:21.599 like the Adoms. Maybe you can moves on. You're okay, you're handle 373 00:31:21.640 --> 00:31:26.400 the Adoms and so on, Like, I don't know what do you think? 374 00:31:26.599 --> 00:31:30.839 I actually think the opposite. I think that if you use the heroical 375 00:31:30.880 --> 00:31:37.799 Adams, then it makes migration much costlier because they're more locked into the platform. 376 00:31:37.160 --> 00:31:44.000 Like, okay, I can only I can't use Digital Ocean because they're 377 00:31:44.079 --> 00:31:49.519 not gonna deploy on the same data center that is my red disk containers and 378 00:31:49.559 --> 00:31:56.680 my mom go de b okay, But I can choose from a ws Asia 379 00:31:56.759 --> 00:32:02.839 and GCP and I can go to either of the tree. And because everything 380 00:32:02.920 --> 00:32:07.839 is containerized, moving the application would be a breeze. And if it is, 381 00:32:08.200 --> 00:32:14.119 if I'm already outside, because every project starts as a monolith, and 382 00:32:14.160 --> 00:32:19.279 then if it really really needs then it becomes a micro service. So if 383 00:32:19.319 --> 00:32:23.240 it's a micro service and is using Kubernatis is also pretty easy to migrate. 384 00:32:24.039 --> 00:32:31.519 So if you're a single monalytic application and it's containerized, you can go to 385 00:32:31.559 --> 00:32:37.119 any cloud provider that you want. It's very easy to migrate. If you 386 00:32:37.440 --> 00:32:43.640 have multiple containers and you're using kubernatis still pretty easy to migrate. What I 387 00:32:43.920 --> 00:32:51.759 avoid is every cloud provider specific solution. Like I would never advise for a 388 00:32:51.839 --> 00:32:58.559 new project to use cloud Formation because now you're stuck with AWS. You now 389 00:32:58.640 --> 00:33:01.720 a WS is to pricey. Any want to migrate to Azure or GCP, 390 00:33:02.119 --> 00:33:07.079 you can't, Like you can, but like the migration is going to be 391 00:33:07.240 --> 00:33:14.759 much harder because you have a bunch of orchestration rules that only work on AWS 392 00:33:14.799 --> 00:33:20.880 because they're using their proprietary tool to orchestrate your attach. So the same goes 393 00:33:20.880 --> 00:33:29.160 for the add ons. I would never use the AWS managed they don't have 394 00:33:29.240 --> 00:33:32.759 reddits right, but they have an alternative to raddis that is like exactly the 395 00:33:32.839 --> 00:33:37.440 same thing, and I always forget the name. I would never use that 396 00:33:37.000 --> 00:33:45.519 because now I'm stuck with AWS. I would always use a managed reddis solution 397 00:33:45.160 --> 00:33:50.319 that is not specific to a cloud provider, but that allows me to deploy 398 00:33:50.680 --> 00:33:53.920 in whatever cloud provider I want, if that makes sense, And then if 399 00:33:53.960 --> 00:34:00.440 I want to migrate, everything in my application is ready for them migration, 400 00:34:00.839 --> 00:34:06.720 even my script to provision cloud resources. I always use Terraform for that, 401 00:34:07.359 --> 00:34:12.280 so it's super easy to migrate. If you're using Terraform, like, all 402 00:34:12.320 --> 00:34:15.679 your configuration is already and it doesn't need to be Terraform. You could be 403 00:34:15.719 --> 00:34:22.440 using Pulumi like any infrastructure as code tool will do. The trick is just 404 00:34:22.840 --> 00:34:27.639 having all your setup in your code base and making sure that you're not using 405 00:34:27.719 --> 00:34:32.559 anything that is specific to that vendor, and any migration is going to be 406 00:34:32.599 --> 00:34:38.079 easy as easy as it could be. Saying that migration is easy would be 407 00:34:38.639 --> 00:34:44.719 a misunderstanding, but it's as easy as it could be. Yeah, that 408 00:34:44.880 --> 00:34:49.760 sounds also so Charles, what do you think, Like, do you have 409 00:34:49.920 --> 00:34:58.679 like any beta with you? Like? What do you think? I mean 410 00:34:58.760 --> 00:35:00.960 a lot of it just depends on how implicated your application is and what you're 411 00:35:00.960 --> 00:35:05.639 trying to do with it, right, I mean I've put some toy apps 412 00:35:05.760 --> 00:35:10.400 up on you know, Netlify or what have you. But yeah, I 413 00:35:10.719 --> 00:35:16.639 tend to agree with Lucas to a certain extent. I think there are certain 414 00:35:16.719 --> 00:35:24.159 levels of how do we put it, like economy or whatever, that you 415 00:35:24.280 --> 00:35:31.440 get from using the resources on AWS right in the AWS way like they designed 416 00:35:31.480 --> 00:35:35.039 them to work together. But I also agree that, yeah, if you 417 00:35:35.079 --> 00:35:38.119 ever have to move it, then yeah, you're kind of locking yourself in. 418 00:35:38.239 --> 00:35:42.199 So I think I think there's a lot of it depends in a lot 419 00:35:42.239 --> 00:35:45.920 of this stuff. I've also worked for larger companies that had their own data 420 00:35:45.000 --> 00:35:50.199 centers right or had presence in data centers, and so then it was, 421 00:35:50.880 --> 00:35:54.159 you know, provisioning resources was effectively calling the ops team and having them get 422 00:35:54.199 --> 00:36:06.320 you a server. So yeah, that would Yeah, almost every time I've 423 00:36:06.360 --> 00:36:08.679 been in that situation, it was more of a pain to get my resources 424 00:36:08.719 --> 00:36:12.639 than it would have been if they had just said, here's your budget, 425 00:36:12.920 --> 00:36:15.960 you know, go to AWS or whatever. But yeah, I'm also not 426 00:36:16.119 --> 00:36:21.519 a huge fan of the big cloud providers for most apps because most of the 427 00:36:21.519 --> 00:36:23.800 time what you're building out is pretty small and simple, and so you can 428 00:36:23.840 --> 00:36:30.639 get away with a lot of things. And so anyway, I guess I'm 429 00:36:30.679 --> 00:36:34.960 just putting a whole bunch of caveats around what Lucas pointed out in the way 430 00:36:34.960 --> 00:36:38.440 he does things because yeah, you know, just just do what works and 431 00:36:38.920 --> 00:36:44.719 evolve from there is kind of my approach. So you know, I'll add 432 00:36:44.719 --> 00:36:47.519 things in. I don't generally use Mongo, so the Mongo Atlas isn't an 433 00:36:47.559 --> 00:36:53.480 issue for me. But you know, I you know, I've been using 434 00:36:53.480 --> 00:36:57.480 Postgress forever, and I've used the cloud hosted, and I've used my own 435 00:36:57.559 --> 00:37:00.719 and it mostly just works. And so you know, Okay, it looks 436 00:37:00.800 --> 00:37:07.119 like this, what's all this problem we're starting to have with scaling or accessibility 437 00:37:07.320 --> 00:37:10.159 or whatever, And so you know, I'll pick up some other technology and 438 00:37:10.199 --> 00:37:14.760 add it in. And uh, yeah, I think for most apps, 439 00:37:14.800 --> 00:37:19.599 for most companies, small to medium businesses, you probably get away with, 440 00:37:20.679 --> 00:37:24.000 you know, putting everything in on one server and just kind of running it 441 00:37:24.039 --> 00:37:30.119 from there until you decide you need a service that does something different. How 442 00:37:30.159 --> 00:37:40.280 about your thus cause yeah, yeah, so I'm I've done a few different 443 00:37:40.320 --> 00:37:47.320 things that I am very guilty of just running like without any containers. So 444 00:37:47.400 --> 00:37:52.039 I started, like my first back ends were like probably like I don't know, 445 00:37:52.280 --> 00:37:57.079 twenty fifteen, twenty sixteen, so doctor was around, but by maybe 446 00:37:57.320 --> 00:38:00.519 I don't know, for some reason, I didn't get into it working on 447 00:38:00.000 --> 00:38:04.480 getting that because I do agree with Lucas, like, if you can get 448 00:38:04.719 --> 00:38:09.239 your applications to this you know, this docrized standpoint, then yeah you can. 449 00:38:09.280 --> 00:38:13.000 Really you could basically go anywhere, right or you know, if you 450 00:38:13.039 --> 00:38:15.639 want your own service on premise in the cloud where you can move it around. 451 00:38:16.239 --> 00:38:21.360 So we I experienced a little bit of that with the startup I was 452 00:38:21.400 --> 00:38:30.519 working with the last two years and we were eventually going to migrate everything to 453 00:38:30.920 --> 00:38:34.840 I think Google. We chose GCP I think due to price, and we 454 00:38:34.920 --> 00:38:38.599 found the pricing best for what we needed. But like, yeah, that's 455 00:38:38.719 --> 00:38:42.119 what we experienced. We said, well, okay, if we can dockrize 456 00:38:42.159 --> 00:38:49.920 everything on our current server, then it theoretically should work anywhere. But with 457 00:38:50.159 --> 00:38:55.119 what Juck said, it's it's funny because a lot of people, I mean, 458 00:38:55.159 --> 00:38:59.079 it's fun to think about huge scale, right, like millions and millions 459 00:38:59.079 --> 00:39:01.719 of users and you know what, you know, do we need load balancing 460 00:39:01.800 --> 00:39:07.159 and you know, geographical servers and all this stuff. But it's amazing, 461 00:39:07.519 --> 00:39:10.639 at least in my opinion nowadays. What you know we were doing. We 462 00:39:10.679 --> 00:39:15.360 had go Lang as our back end I think Gin and with just like four 463 00:39:15.440 --> 00:39:21.920 cores, you can handle. You can handle a crazy amount of request. 464 00:39:22.000 --> 00:39:25.559 We had. So the startup was in Switzerland and they were on the their 465 00:39:25.679 --> 00:39:31.000 version of Shark Tank, and so we we already had done some load tests 466 00:39:31.000 --> 00:39:35.800 and stuff, but of course you're always unsure, like what's actually going to 467 00:39:35.840 --> 00:39:39.760 happen when when the TV Aaron came. But yeah, it handled. I 468 00:39:39.760 --> 00:39:45.800 mean we had like I think, like ten thousand new users and like we 469 00:39:45.880 --> 00:39:52.719 didn't even hit I think fifty capacity on any resource like memory or anything. 470 00:39:53.440 --> 00:40:00.519 So yeah, I'm definitely h I'm definitely a fan of It's like, yeah, 471 00:40:00.519 --> 00:40:04.719 the right tool for the right job. I mean, of course I 472 00:40:05.480 --> 00:40:09.280 would argue it would have been nicer like all the for my applications had I 473 00:40:09.360 --> 00:40:15.840 docrized it in the beginning, because I think we all know that that like 474 00:40:15.000 --> 00:40:22.280 when something breaks, you're sshing onto the server and doing some debugging and you 475 00:40:22.280 --> 00:40:24.440 don't know exactly where it is. But with Doctor at least you have like 476 00:40:24.480 --> 00:40:29.760 a starting point like okay, it's something in the container blow up or something 477 00:40:29.800 --> 00:40:36.239 like that. So yeah, I guess I don't know really where I'm going 478 00:40:36.280 --> 00:40:39.719 with that, but I think it's like start small and pick you know, 479 00:40:40.039 --> 00:40:45.159 the resources and things you need, you think for the project, and you'd 480 00:40:45.159 --> 00:40:52.119 be surprised how many how much power small resources can manage. Yeah, and 481 00:40:52.159 --> 00:40:55.159 then go for there. Yeah, I like that. I like that, 482 00:40:55.239 --> 00:41:00.280 And just to reater it. I know that we've talked a lot, so 483 00:41:00.400 --> 00:41:05.800 I know we're close to start wrapping up the episode, but I really want 484 00:41:05.840 --> 00:41:09.280 to make it clear for everyone that is listening and thinking, what the hell 485 00:41:09.320 --> 00:41:13.440 are you guys talking about. I don't know anything about that, Like, 486 00:41:13.920 --> 00:41:19.360 don't worry. My first deployment I think was a PHP my admin, you 487 00:41:19.400 --> 00:41:24.679 know, so back in the day, so I didn't start out doing all 488 00:41:24.719 --> 00:41:30.239 those crazy things to make sure that the deployment was as killable and as organized 489 00:41:30.239 --> 00:41:36.400 as possible and super flexible to move around. And if you put that as 490 00:41:36.440 --> 00:41:42.159 a requirement for your app to go live, if you don't have the expertise 491 00:41:42.239 --> 00:41:45.840 to do that quickly, then you might just not go live ever, you 492 00:41:45.880 --> 00:41:52.719 know, So just get things deployed grow from there. But if I could 493 00:41:52.840 --> 00:42:00.239 give one advice is have that little voice in your hand saying and I locked 494 00:42:00.840 --> 00:42:07.840 with my current provider yes or no? And what could I do to make 495 00:42:07.960 --> 00:42:14.039 myself less locked in? I know stories of people that like they were using 496 00:42:14.119 --> 00:42:22.039 companies that were using AWS and their bill was super expensive, but they had 497 00:42:22.199 --> 00:42:28.039 everything organized in a way that was so easy for them to migrate to GCP 498 00:42:28.280 --> 00:42:34.599 or Azure or any other cloud provider they that they didn't even have to because 499 00:42:34.639 --> 00:42:39.039 they could negotiate with AWS a major price reduction. And if your company is 500 00:42:39.079 --> 00:42:44.559 like super locked in into your provider, if you get to a point where, 501 00:42:44.599 --> 00:42:49.360 like I'm investing a lot of money into the cloud provider, what leverage 502 00:42:49.440 --> 00:42:51.960 do you have to negotiate? Where are you going to tell them, hey, 503 00:42:52.400 --> 00:42:58.559 please reduce the bill or else I'm gonna stick with you. So that's 504 00:42:59.679 --> 00:43:04.360 not very compelling, right. But if you say, hey, my entire 505 00:43:04.360 --> 00:43:08.800 application is containerized. We're using Kubernatives to orchestrate, so we're not using our 506 00:43:08.880 --> 00:43:21.760 proprietary technology. And plus even our cloud provisioning is already documented with Infrastructure as 507 00:43:21.880 --> 00:43:27.360 Code tool, So would you like to give me some discount so that I 508 00:43:27.360 --> 00:43:30.280 can stay with your platform, That's a much much better position to be in, 509 00:43:30.639 --> 00:43:35.559 right. But this is like so far in the future, So far 510 00:43:35.599 --> 00:43:38.639 in the future, you should not be worrying about that scenario when you're just 511 00:43:38.719 --> 00:43:45.480 starting out a project. So start out with whatever you know is the best 512 00:43:45.599 --> 00:43:52.559 you can do quickly, and then grow from there. But just be mindful 513 00:43:52.760 --> 00:44:00.000 what you're growing. Be mindful of every decision that you make, because every 514 00:44:00.199 --> 00:44:05.039 architectural decision that you make from the moment you start and what you're growing is 515 00:44:05.079 --> 00:44:09.280 gonna make it easier or harder for you to migrate to a better cloud environment 516 00:44:09.320 --> 00:44:16.159 in the future. So yeah, yeah, that's that's actually true to it's 517 00:44:16.159 --> 00:44:22.280 actually past to consider. Like en showing that you're not kind of locked into 518 00:44:22.320 --> 00:44:28.559 your vendor very important because most services, like for example, I actually referenced 519 00:44:29.360 --> 00:44:37.559 David's post on his migration from I Think A Ways to the its own best 520 00:44:37.760 --> 00:44:42.159 cloud I think thirty six six now. So I really loved that because I 521 00:44:42.280 --> 00:44:45.239 kind of followed it down. I was kind of wondering, how like, 522 00:44:45.480 --> 00:44:50.159 because the movesus. I know, I know a lot of people that used 523 00:44:50.199 --> 00:44:54.679 hate the email sets and the like no downtime, they didn't experience much. 524 00:44:54.719 --> 00:44:59.119 I was like, WHOA, did you guys really move like? I was 525 00:44:59.199 --> 00:45:06.360 really fascinated about the fact usually they move usually could cast some setting things, 526 00:45:06.360 --> 00:45:10.199 maybe customers complainer, the sarvice is down here, this and that, but 527 00:45:10.280 --> 00:45:15.239 it was so smooth. So yeah, I think it's actually based on what 528 00:45:15.320 --> 00:45:17.440 you said. So I think they ensure that they were not locked into their 529 00:45:17.440 --> 00:45:21.400 window. So when they made them move, it was so easy to just 530 00:45:21.760 --> 00:45:25.800 plug out and plug into down custom myself. So this wasn't really a big 531 00:45:25.960 --> 00:45:30.920 bid for them, but you just move that And no, I don't think 532 00:45:30.960 --> 00:45:36.039 any of the customers just noticed that until they until the media announcement that I 533 00:45:36.079 --> 00:45:40.480 hear we've moved, and I think I'm Charles. I don't know if you 534 00:45:40.519 --> 00:45:45.400 followed the I think the meet up and think in the Netherlands or so will 535 00:45:45.400 --> 00:45:53.519 be a waste away. Yes, also yeah, yes, exactly, and 536 00:45:53.719 --> 00:45:59.400 we're like I think it was like a countdown where I think it was Fernando 537 00:45:59.559 --> 00:46:04.599 someone and the seen those times to remove the last close the last like that 538 00:46:04.679 --> 00:46:10.039 was really before Like I was like like wow, so much to pervision on 539 00:46:10.239 --> 00:46:15.199 kind of thought putting into the code, so do able to just switch out 540 00:46:15.559 --> 00:46:17.159 there was really no difficulty. I think they did it on stage. I 541 00:46:17.719 --> 00:46:22.639 think Charles was probably basically kind of this a little bit it halfway. So 542 00:46:22.239 --> 00:46:27.400 it's actually very vital that you don't become like vendor looped in so I think 543 00:46:27.480 --> 00:46:35.039 I understand that very work kind of Yeah, what did it increase? Yeah, 544 00:46:35.079 --> 00:46:38.480 I think it goes back to what Lucas mentioned too, like and what 545 00:46:38.519 --> 00:46:45.519 you're saying is, yeah, this, this vendor lock can be a headache. 546 00:46:45.000 --> 00:46:47.440 Also, like if you're a beginner, don't don't worry about it, 547 00:46:47.480 --> 00:46:51.840 but as you build your stuff. I think a big part of this could 548 00:46:51.840 --> 00:46:58.159 be perhaps its own episode about like some of these doctor is documentation. Right, 549 00:46:58.239 --> 00:47:04.280 So even if it may seem trivial something small, but I'm telling you 550 00:47:04.360 --> 00:47:07.519 now, I know from experience, if you forget like oh yeah this this 551 00:47:07.639 --> 00:47:14.119 service here talks to this service and you only remember that by seeing when the 552 00:47:14.119 --> 00:47:21.920 bug shows up. Yeah, so document you know these whatever it is interfaces 553 00:47:22.199 --> 00:47:25.760 or how how services talk to each other, because that helps so much and 554 00:47:27.000 --> 00:47:35.559 would hopefully lead to these these much smoother transitions between vendors. So yep, 555 00:47:36.639 --> 00:47:40.280 that was a lot. I think we can start wrapping up before we get 556 00:47:40.280 --> 00:47:47.840 to two hours of Actually, if I may say, just one last thing 557 00:47:49.239 --> 00:47:53.920 regarding this subject is vendor lock in is not just about cloud providers, you 558 00:47:53.920 --> 00:48:00.800 know. For example, recently I was thinking about links that I had in 559 00:48:00.840 --> 00:48:04.760 some of the projects, like when you have links pointing to external services. 560 00:48:05.320 --> 00:48:09.119 For example, a lot of companies use Calendly, for example, to handle 561 00:48:09.199 --> 00:48:15.639 the bookings. You know, so Calendly is going to generate a scheduling link. 562 00:48:15.960 --> 00:48:19.920 If you put that link directly into your website and you use that in 563 00:48:19.960 --> 00:48:24.000 your emails and your documents, et cetera, you won't ever be able to 564 00:48:24.119 --> 00:48:29.880 change that link. Ever, Like if you want to change the system that 565 00:48:29.920 --> 00:48:32.039 you're using to book their meetings, you can't because you're going to be worried 566 00:48:32.079 --> 00:48:37.280 about every single sales material that you're sent in the past with the previous link. 567 00:48:38.039 --> 00:48:43.039 So even for that, it makes sense for you to think about vendor 568 00:48:43.079 --> 00:48:45.239 lock in. You know, it's even in those scenarios. And in that 569 00:48:45.400 --> 00:48:51.559 case, what you could do is use a link management system and then you 570 00:48:51.559 --> 00:48:57.360 could have like a vanity link that redirects to the tool that you're actually going 571 00:48:57.440 --> 00:49:00.440 to be using, and then if you ever want to migrate, you can 572 00:49:00.559 --> 00:49:04.400 just migrate where the link is pointing. But yeah, these are just things 573 00:49:04.440 --> 00:49:07.960 that we need to keep in mind as we're building our system. So it's 574 00:49:08.000 --> 00:49:15.519 not just locked into your cloud provider, it's being locked into any external tool 575 00:49:15.079 --> 00:49:21.679 that your company depends on and think about how would you handle a migration to 576 00:49:21.800 --> 00:49:25.880 another tool if you ever need to face that situation, because I'm telling you 577 00:49:25.880 --> 00:49:30.440 you're most definitely going to face that situation. The only scenario where you're not 578 00:49:30.480 --> 00:49:35.519 gonna have to worry about migration is if your company dies. So you don't 579 00:49:35.559 --> 00:49:38.239 want to prepare for that scenario, So you better prepare for the scenario where 580 00:49:38.280 --> 00:49:44.400 you're going to need to migrate. Okay, let's start wrapping up. So 581 00:49:44.559 --> 00:49:49.559 let's just do a quick round of promos and then we can close. Or 582 00:49:50.519 --> 00:49:53.440 you may need to explain what you mean by promos. Oh yeah, that's 583 00:49:53.519 --> 00:49:59.840 true because we didn't have promos in this show before, right, So pros 584 00:50:00.159 --> 00:50:05.440 is our shameless way to talk about the things that we're working on and promote 585 00:50:05.480 --> 00:50:12.199 our stuff so that we can convert some of you beautiful people that are consuming 586 00:50:12.239 --> 00:50:19.800 our free content into maybe followers on our social medias or customers in some of 587 00:50:19.800 --> 00:50:24.599 the projects that we're working on. So this is the promos section. Check 588 00:50:24.679 --> 00:50:30.280 do you want to kick things off? Sure? So I've been jumping back 589 00:50:30.320 --> 00:50:36.320 in a little bit on the React stuff, so top end devs, I'll 590 00:50:36.360 --> 00:50:39.719 try and keep this really brief, but it's hard anyway. So top End 591 00:50:39.760 --> 00:50:44.719 Devs initially we just did the podcasts, and then as I've talked to people 592 00:50:44.960 --> 00:50:50.360 over the last years, it's become pretty apparent that some people are just getting 593 00:50:50.360 --> 00:50:52.559 stuck in their careers. Now. A lot of the people that I talked 594 00:50:52.599 --> 00:50:55.960 to that don't know what to do next or new right, and so they're 595 00:50:57.000 --> 00:50:59.480 just like, what do I do? And it's like, just keep learning, 596 00:50:59.559 --> 00:51:01.559 you know, keep moving forward, keep you know, meeting people. 597 00:51:01.840 --> 00:51:05.480 But then I talk to people who have been doing this for two, three, 598 00:51:05.599 --> 00:51:08.000 four, five, ten years and they're like, where do I go 599 00:51:08.079 --> 00:51:14.719 from here? Right? And so top End Devs has I've kind of taken 600 00:51:14.719 --> 00:51:16.440 it to that next place where it's like, Okay, let me help you 601 00:51:16.639 --> 00:51:22.400 know what to do to get to that next level of your career, right. 602 00:51:22.440 --> 00:51:28.519 And the principles still apply to newer developers. It's just that the fruit 603 00:51:28.599 --> 00:51:34.119 is a little lower hanging for newer developers. So anyway, what we're doing 604 00:51:34.280 --> 00:51:37.800 is I tell people that the three things you need to do in order to 605 00:51:37.840 --> 00:51:40.320 take your career to the next place are build your skills, build your network, 606 00:51:40.320 --> 00:51:45.840 and build your personal brand. And so we're putting together essentially systems for 607 00:51:45.920 --> 00:51:51.000 people to use to build their skills. And so we're putting together meetups and 608 00:51:51.079 --> 00:51:55.679 videos and courses and things like that right to build their network. We're putting 609 00:51:55.719 --> 00:52:02.000 together three times a week for our different genius plans, which are going to 610 00:52:02.039 --> 00:52:07.639 be React, JavaScript, uh Ruby, We're gonna meet three times a month, 611 00:52:08.719 --> 00:52:13.039 and we're gonna talk about different stuff. So we may have somebody come 612 00:52:13.039 --> 00:52:15.039 and present on something one of those weeks, but the other weeks we're going 613 00:52:15.079 --> 00:52:19.239 to have more of a Q and A or open discussion, or we're going 614 00:52:19.360 --> 00:52:24.159 to have you know, maybe members present or a networking session or something like 615 00:52:24.199 --> 00:52:28.360 that, right where we bring in some of this other stuff. And then 616 00:52:30.519 --> 00:52:34.280 for building your personal brand, we're also going to have content and courses about 617 00:52:34.280 --> 00:52:37.480 building content, you know. And so for for me, the ones that 618 00:52:37.519 --> 00:52:43.880 have worked best for me are YouTube and podcasting, and so that's where I'm 619 00:52:43.880 --> 00:52:49.920 going to push people, right. I tend to pan the blogging. You 620 00:52:50.079 --> 00:52:52.559 can make it work, but that's not really my cup of tea and I 621 00:52:52.559 --> 00:52:58.400 don't think it's as effective. So anyway, so what I'm working on is 622 00:52:58.559 --> 00:53:05.119 getting launched the Javascrip geniuses and the React Geniuses and effectively getting those meetup scheduled 623 00:53:05.159 --> 00:53:07.639 and then start putting out the videos. And the videos are going to be 624 00:53:08.199 --> 00:53:12.559 I'm gonna build this thing in React, right, So I may do it 625 00:53:12.599 --> 00:53:19.199 in Redwood JS or Remix or next or Gatsby or something else, or maybe 626 00:53:19.239 --> 00:53:21.760 I'll you know, I'll say, hey, I've got this custom back end 627 00:53:21.800 --> 00:53:23.360 that I built in Rails and I'm gonna build the front end on it or 628 00:53:23.440 --> 00:53:27.360 whatever, right, And so then we'll build different kinds of apps, and 629 00:53:27.360 --> 00:53:30.639 that way you can see how some of these things go in It's rather frustrating 630 00:53:30.679 --> 00:53:36.159 to me when I get in and it's like this tutorial on this toy app 631 00:53:36.199 --> 00:53:38.800 that doesn't really have to integrate with anything, and so it works great there 632 00:53:38.880 --> 00:53:42.159 and if I follow the steps, it works great for me, and then 633 00:53:42.199 --> 00:53:45.239 I try and go and do it in real life and it's like it doesn't 634 00:53:45.280 --> 00:53:51.719 work. So anyway, so React Geniuses is what's coming. I'm also just 635 00:53:51.760 --> 00:53:54.360 going to toss out there that we're getting ready to launch the premium podcasts. 636 00:53:54.639 --> 00:53:58.400 So if you want the podcast without the ads, you can get that. 637 00:53:58.519 --> 00:54:00.679 If you want the if you get any of the others, So the video 638 00:54:00.760 --> 00:54:05.840 series or the meetup series or both. Then you'll get access to the podcast 639 00:54:05.920 --> 00:54:08.559 without the ads for free. So anyway, that's what I'm getting ready to 640 00:54:08.639 --> 00:54:13.119 launch. We should have it up here within the next week or two, 641 00:54:13.840 --> 00:54:19.239 so go check it out and that'll be at react geniuses dot com. Nice, 642 00:54:19.480 --> 00:54:22.840 nice, awesome. So I want to send the link to it. 643 00:54:22.960 --> 00:54:27.800 Here's a react genius dot com. Yeah, I'll put it in the comments. 644 00:54:28.440 --> 00:54:32.199 It's not up yet, so it'll be up. My birthday is two 645 00:54:32.239 --> 00:54:36.880 weeks from today. It'll be up by then. Okay, Peter, you're 646 00:54:36.920 --> 00:54:40.440 gonna you're gonna say something. Yeah, I mean, that's very awesome. 647 00:54:40.599 --> 00:54:45.079 Like I know a lot of people to actually need this, right because starting 648 00:54:45.159 --> 00:54:52.480 out closed from my own experience starting out, it wasn't really easy because then 649 00:54:52.079 --> 00:54:57.639 I wasn't kind of in the neighborhood where I didn't we have masters, developers 650 00:54:57.760 --> 00:55:02.000 and maybe people help completely mantors you and so on and so forth. But 651 00:55:02.159 --> 00:55:07.760 then with these I think this is agate with very nice for beginnails and people 652 00:55:07.800 --> 00:55:12.239 are starting out. Yeah, I think this is a great it's important. 653 00:55:12.760 --> 00:55:17.400 Yeah, yeah, I agree. A lot of tutorials are too into a 654 00:55:17.519 --> 00:55:22.159 perfect universe and it ends up not being very realistic, So I appreciate the 655 00:55:22.199 --> 00:55:30.239 thought that check is putting into making this more real world experience. All right, 656 00:55:30.320 --> 00:55:34.599 So my proma is going to be on Void, so is you n 657 00:55:35.159 --> 00:55:43.679 Void dot com And they offer all kinds of food tack software development services, 658 00:55:44.280 --> 00:55:47.920 and we do that in a performance basis. The difference between that and every 659 00:55:47.960 --> 00:55:53.519 other company that provides software development services is that in every other company, you're 660 00:55:53.559 --> 00:55:59.239 going to pay by the hour and you don't really know how much value you're 661 00:55:59.280 --> 00:56:04.960 getting from the But at Onvoid, you're only going to pay when the tasks 662 00:56:05.079 --> 00:56:09.400 are delivered and approved by the client. So even if they are delivered and 663 00:56:09.519 --> 00:56:15.159 the client doesn't like the quality in which they are or the code standards or 664 00:56:15.199 --> 00:56:17.559 something like that, they can just ask for changes and it's only going to 665 00:56:17.639 --> 00:56:22.840 become billable after the client says that they are adhering to a center to a 666 00:56:22.880 --> 00:56:30.840 certain quality standard. So it's really the safest way for any company to outsource 667 00:56:30.000 --> 00:56:37.800 or staff augment their software developments teams. And also, every single engineer at 668 00:56:37.039 --> 00:56:43.199 Void works in the United States time zones, so companies don't have issues with 669 00:56:43.679 --> 00:56:47.760 trying to talk to their engineers and they're being in a completely different time zone 670 00:56:47.800 --> 00:56:52.679 and not being able to talk to them. So yeah, if you're interested 671 00:56:52.719 --> 00:56:54.800 in that, or you know someone that might benefit from that, I highly 672 00:56:55.159 --> 00:57:01.000 encourage you to check out Void dot com, you and oid dot com. 673 00:57:01.280 --> 00:57:06.719 So yeah, how about you, Chris, do you have anything you'd like 674 00:57:06.760 --> 00:57:10.480 to promote? Sure? Yeah, I'm a little bit probably stretched too thin 675 00:57:10.639 --> 00:57:15.519 recently, so I'm just gonna keep it simple. I guess I would just 676 00:57:15.559 --> 00:57:21.039 point people to my blog, Chrisfreut. I N I do have some other 677 00:57:21.079 --> 00:57:27.079 products and projects hopefully coming out, but yeah, I guess following this theme, 678 00:57:27.199 --> 00:57:30.360 what I really focus on in my blog is really how my blog started 679 00:57:30.440 --> 00:57:35.920 is basically, whenever I would encounter anything at you know, I've worked for 680 00:57:35.960 --> 00:57:39.679 startups or an industry and it was either really hard or like a bunch of 681 00:57:39.800 --> 00:57:44.639 just trial and error that we all know, I would just be like, 682 00:57:44.760 --> 00:57:46.880 Okay, I'm going to write a blog post about this and hopefully someone will 683 00:57:46.880 --> 00:57:50.440 find, you know, if they ran it the same thing I ran into, 684 00:57:50.679 --> 00:57:53.960 And this is how this is the solution I came up with. And 685 00:57:54.000 --> 00:58:00.119 so with that, along with my blog, I have various courses so in 686 00:58:00.679 --> 00:58:07.960 quite spanning quite wide languages and frameworks. I have some typescript courses. I 687 00:58:07.000 --> 00:58:13.400 have a going course, and it's really focused on more. I mean, 688 00:58:13.440 --> 00:58:15.320 of course you're not going to build an entire SaaS app, but they are 689 00:58:15.559 --> 00:58:20.559 like I built a go course recently that's you know, how to deploy it 690 00:58:20.559 --> 00:58:23.159 on doctor and get everything up and running like it was. It's like a 691 00:58:23.239 --> 00:58:29.559 Crown Job service. So really trying to focus at integrating more than just one 692 00:58:29.599 --> 00:58:37.000 thing and and what like some toy example. So yeah, by the way, 693 00:58:37.159 --> 00:58:43.559 I highly encourage everyone to check out Chris's website just because it's so much 694 00:58:43.599 --> 00:58:46.800 fun. I was just looking at it and there are just so many random 695 00:58:46.920 --> 00:58:53.960 bits of rainbows and colorful things. It's just that's a cool personal website. 696 00:58:54.039 --> 00:58:59.360 Dude, Like, that's really really cool. I like the as key computer 697 00:58:59.440 --> 00:59:02.440 that you did on the left and you can actually click on subscriber or close 698 00:59:02.519 --> 00:59:07.519 forever. I thought that was that was really well done. That's really interesting. 699 00:59:07.559 --> 00:59:12.880 Congrats. Yeah, thanks. I'm a bit I've been kind of paranoid 700 00:59:12.920 --> 00:59:15.960 recently because I've heard stories like because right now I only have dark mode, 701 00:59:16.000 --> 00:59:19.719 I know, that's kind of like a bad practice, and people are like, 702 00:59:19.800 --> 00:59:22.760 if I see a website like that, I won't even read it, 703 00:59:22.840 --> 00:59:27.559 So maybe I have to bring back a light mode pretty much. And Benjamin 704 00:59:27.639 --> 00:59:31.960 used to say that, Yeah. Nice. How about you, Peter, 705 00:59:32.519 --> 00:59:36.760 Yeah, I don't really have much. Yeah, I think I write articles 706 00:59:36.760 --> 00:59:42.559 for publications, so we'll find that day. And I think I was simply 707 00:59:42.760 --> 00:59:47.519 lead to. So yeah, I just had publications, and I don't talk 708 00:59:47.639 --> 00:59:52.599 about things constantly, react and soon, so just check we find that them 709 00:59:52.679 --> 00:59:57.519 as well. Yeah, I didn't know if you've walked it. It's kind 710 00:59:57.559 --> 01:00:02.400 of like he played nice work for building the act applications can spin off your 711 01:00:02.400 --> 01:00:08.000 ain dashboards or b two the applications at one go. Yeah, so I 712 01:00:08.079 --> 01:00:13.039 think it's one thing worth checking out. Let me just pist the link and 713 01:00:13.079 --> 01:00:19.239 what is the best place for people to read your articles? Yeah? Many 714 01:00:19.239 --> 01:00:22.760 of my LinkedIn Yeah, I just post them on my LinkedIn, right, 715 01:00:22.840 --> 01:00:28.280 So I think my LinkedIn is correlated all my articles, so yeah, I 716 01:00:28.480 --> 01:00:31.760 just passed them on my LinkedIn. I will share my LinkedIn profile as well. 717 01:00:31.960 --> 01:00:37.039 So yeah, I just most of the time I'm there looking at all 718 01:00:37.079 --> 01:00:42.079 some pos like maybe migration posts. Yeah, because I really enjoyed the series 719 01:00:42.119 --> 01:00:45.920 of David Crital always migrating. Yeah, I just look at some of that 720 01:00:46.760 --> 01:00:51.079 post and so on and so forth. So yeah, I think it does 721 01:00:51.159 --> 01:00:55.880 cast me upon linkeding with my post. I think that works nice. Nice, 722 01:00:57.159 --> 01:01:01.639 Okay, all right, everyone, thank you so much for joining. 723 01:01:01.880 --> 01:01:07.400 It was a pleasure to meet Peter Chris Jack. I already know you for 724 01:01:07.440 --> 01:01:10.679 a while, but it's always good to to to be on the show with 725 01:01:10.719 --> 01:01:16.880 you guys. It was it was really nice. I really liked this this 726 01:01:17.039 --> 01:01:21.599 format. It was a bit of a longer episode. We're maybe going to 727 01:01:21.719 --> 01:01:25.039 try to keep it shorter in the next ones, but but yeah, I 728 01:01:25.400 --> 01:01:30.840 really enjoyed how how much depth we were able to put into it. So 729 01:01:31.079 --> 01:01:37.000 I just wanted to thank everyone for for joining, and I'll see you all 730 01:01:37.239 --> 01:01:37.960 in the next one.