WEBVTT 1 00:00:05.240 --> 00:00:08.519 Hey, welcome to React Around Them, the podcast where we 2 00:00:08.599 --> 00:00:11.880 keep you updated on all things React related. This show 3 00:00:12.000 --> 00:00:15.240 is sponsored by Reagan and produced by Top and Devs 4 00:00:15.240 --> 00:00:15.919 and Onvoid. 5 00:00:16.320 --> 00:00:17.640 Top and Deves is very great. 6 00:00:17.679 --> 00:00:20.039 Top and Deves we get top and pay and recognition 7 00:00:20.440 --> 00:00:24.160 or working on interesting problems and making meaningful community contributions 8 00:00:24.399 --> 00:00:29.399 an Void which provides remote design and software development services 9 00:00:29.440 --> 00:00:33.399 on the most client friendly business model, so clients only 10 00:00:33.520 --> 00:00:38.719 pay after the tasks are delivered and approved. In today's episode, 11 00:00:38.759 --> 00:00:45.200 we will talk about flight flight Control and basically this 12 00:00:45.399 --> 00:00:48.439 is a tool that allows developers to not have to 13 00:00:48.479 --> 00:00:52.240 worry too much about the box when they deploy their applications. 14 00:00:52.640 --> 00:00:57.560 So it's going to be around the subject of developer operations. 15 00:00:58.079 --> 00:01:00.840 My name is Lucas Pagani your a podcast. 16 00:01:01.000 --> 00:01:05.159 Joining me in today's episode is also the host Chris Bruin. 17 00:01:05.920 --> 00:01:11.439 Hello everybody, and we have a very special guest which 18 00:01:11.519 --> 00:01:17.760 is the CEO and co founder of flight Control, Brandom Buyer. 19 00:01:17.760 --> 00:01:18.680 Excited to be here. 20 00:01:20.480 --> 00:01:24.239 Thank you for being here, Brandom. Well let's just get 21 00:01:24.280 --> 00:01:28.079 into it. So Brandon, I'm sure you have explained this 22 00:01:28.560 --> 00:01:32.719 a million times already, but let's do it one more. 23 00:01:33.480 --> 00:01:35.879 Can you pitch flight Control to the audience. 24 00:01:35.920 --> 00:01:41.760 Please good thing never gets old. It's my baby. So 25 00:01:42.319 --> 00:01:48.599 flight Control is a platform as a service for deploying application, server, database, 26 00:01:48.599 --> 00:01:53.200 aesthetic sites to your own AWS account. Now why your 27 00:01:53.239 --> 00:01:57.319 own AWS account? Because it enables us to leap frog 28 00:01:57.439 --> 00:02:01.400 traditional platforms as a service on one most every metric. So, 29 00:02:01.519 --> 00:02:05.040 for example, you get two to six x faster built 30 00:02:05.359 --> 00:02:09.120 than any other platform, fifty to seventy five percent cheaper 31 00:02:09.159 --> 00:02:12.199 compute in near perfect reliability. 32 00:02:13.159 --> 00:02:13.639 Awesome. 33 00:02:13.840 --> 00:02:18.439 Okay, so let's bring it to something that might be 34 00:02:18.719 --> 00:02:22.199 a bit more popular in the eyes of front and developers, 35 00:02:22.199 --> 00:02:24.319 and then we can make a comparison. 36 00:02:23.759 --> 00:02:24.840 To flight Control. 37 00:02:25.240 --> 00:02:28.280 So to me at least, I know there are many 38 00:02:28.319 --> 00:02:32.400 platforms built on top of the AWS infrastructure and other 39 00:02:32.719 --> 00:02:37.960 big CLAWS, but I think Heroku might be one of 40 00:02:38.000 --> 00:02:42.800 the most famous and popular ones and it is known 41 00:02:42.919 --> 00:02:45.800 to be built on top of AWS. You can actually 42 00:02:45.919 --> 00:02:50.240 literally do a one on one mapping between the Heroku 43 00:02:50.639 --> 00:02:54.280 zones and the AWS zone. So if you want something 44 00:02:54.319 --> 00:02:56.719 to be in the same data center that you have 45 00:02:56.800 --> 00:02:59.439 deployed on AWS, you can just literally choose it. 46 00:02:59.319 --> 00:03:02.719 And Heroko and it's going to be there. So how 47 00:03:02.840 --> 00:03:07.120 does flight control compare to HEROICU or is that not 48 00:03:07.560 --> 00:03:09.439 the kind of comparison that we should be making. 49 00:03:10.159 --> 00:03:14.039 Yeah, that's definitely definitely the right comparison. Uh. And then 50 00:03:14.080 --> 00:03:16.319 the other you know, Heroica has been around a long time, 51 00:03:16.439 --> 00:03:18.759 so there might be actually new people that don't even 52 00:03:18.840 --> 00:03:21.759 know about it, but they probably know about versaill especially 53 00:03:21.800 --> 00:03:24.719 being you know, in the React space, so Vercell is 54 00:03:24.759 --> 00:03:30.520 another you know comparison there. And you know, both of 55 00:03:30.560 --> 00:03:35.879 these platforms were created because infrastructure is really hard and 56 00:03:36.240 --> 00:03:40.080 developers want to be able to build applications quickly, ship 57 00:03:40.120 --> 00:03:43.199 them product production, and scale them to users all around 58 00:03:43.240 --> 00:03:47.199 the world. But if you're using abs directly, like you, 59 00:03:47.639 --> 00:03:51.479 it requires lots of specialized knowledge skills, time, like, it's 60 00:03:51.599 --> 00:03:54.800 just a pain in the butt. But these platforms like 61 00:03:54.840 --> 00:03:57.639 Heroca and Versail were created to make that so much easier, 62 00:03:58.080 --> 00:04:01.919 and they are so much easier it's it's incredible. But 63 00:04:02.080 --> 00:04:05.719 the problem is that at some point you end up 64 00:04:05.800 --> 00:04:11.280 hitting problems and limitations. You had technical limitations where you know, 65 00:04:11.319 --> 00:04:13.919 maybe you need to customize some part of your infrastructure 66 00:04:14.000 --> 00:04:19.040 for security or something else and you just can't, or 67 00:04:19.079 --> 00:04:22.680 maybe you start getting charged a lot of money because 68 00:04:23.040 --> 00:04:26.240 Heroka and Ursell have very high markup over top of 69 00:04:26.279 --> 00:04:29.399 the aws cost. You know, so when you're just getting 70 00:04:29.480 --> 00:04:33.800 started like who Care, you can run anywhere. But as 71 00:04:33.839 --> 00:04:37.000 you start scaling your app then it becomes, you know, 72 00:04:37.120 --> 00:04:40.680 a bigger question there. And I'll just share briefly an 73 00:04:40.720 --> 00:04:42.879 experience I had a while back. I think that helps 74 00:04:42.879 --> 00:04:46.480 illustrate this. So I was on a trip and as 75 00:04:46.480 --> 00:04:51.240 I entered my Airbnb, I was taken aback because almost 76 00:04:51.399 --> 00:04:55.160 every door cupboard in Appliance had a sticky note on 77 00:04:55.240 --> 00:04:59.319 it and either saying it was off limits or describing 78 00:04:59.360 --> 00:05:03.439 the content. And it was it was painfully obvious that 79 00:05:03.519 --> 00:05:06.519 I was living in someone else's house, like they were 80 00:05:06.560 --> 00:05:10.279 dictating everything you can or cannot do this, And that 81 00:05:10.360 --> 00:05:14.160 approximates the experience of using a traditional platform of the service. 82 00:05:15.000 --> 00:05:17.879 You are living in someone else's house and you have 83 00:05:17.959 --> 00:05:22.240 strictly limited access, unable to go into the utility room 84 00:05:22.279 --> 00:05:26.519 for example, or make upgrades as you as your needs change. 85 00:05:27.600 --> 00:05:31.439 But with flight Control, you fully own the house and 86 00:05:31.480 --> 00:05:34.439 you invite flight Control to come in and fully manage 87 00:05:34.480 --> 00:05:37.839 all the cleaning, painting, mowing the yard, even doing upgrades 88 00:05:37.839 --> 00:05:41.319 and renovations for you. And yes, you pay flight Control 89 00:05:41.360 --> 00:05:44.759 and modest fee for this service, but even after counting 90 00:05:44.800 --> 00:05:49.319 your mortgage payment, and your total cost is significantly less 91 00:05:49.759 --> 00:05:54.480 than the Airbnb or the Bursell markup with their ridiculous 92 00:05:54.519 --> 00:05:55.120 cleaning fees. 93 00:05:58.000 --> 00:06:00.839 Okay, I like the analogy that this makes a lot 94 00:06:00.879 --> 00:06:06.600 of sense, But I guess my next question would be 95 00:06:06.959 --> 00:06:13.720 how do you balance having full access while also getting 96 00:06:13.920 --> 00:06:18.519 well also giving users a simpler facade into how to 97 00:06:18.639 --> 00:06:22.560 interact with it? Right? So, for example, when I initially 98 00:06:22.759 --> 00:06:28.000 went to flight Control's website, I initially made a connection 99 00:06:28.160 --> 00:06:34.879 between that and infrastructure as a code pools, so for example, 100 00:06:34.920 --> 00:06:36.720 pullooni or Terraform. 101 00:06:37.480 --> 00:06:40.920 And I'm not sure if this is. 102 00:06:40.879 --> 00:06:43.720 The right comparison that I should be making, but that's 103 00:06:43.839 --> 00:06:45.800 what I did at the time because I thought, Okay, 104 00:06:45.800 --> 00:06:48.680 it's going to simplify how I interact with AWS, but 105 00:06:48.720 --> 00:06:52.079 it's still going to give me control. So perhaps could 106 00:06:52.160 --> 00:06:55.480 we also make this comparison between Okay, like we sure 107 00:06:55.560 --> 00:06:58.600 can compare Heroku and ver Sell to fly Control, can 108 00:06:58.639 --> 00:07:01.759 we also compare flight control your Terraform and movie. 109 00:07:03.360 --> 00:07:08.120 So the reason we created flight Control was we wanted 110 00:07:08.240 --> 00:07:11.600 the ease of use of our cell and Heroku, but 111 00:07:11.839 --> 00:07:14.959 the full control and the scalability of my own AWS account. 112 00:07:15.959 --> 00:07:18.439 And so before flag Control you had to choose between 113 00:07:18.560 --> 00:07:24.079 good developer experience or full control and scalability and no markup. 114 00:07:24.639 --> 00:07:27.600 You couldn't get both. But now a flag control you 115 00:07:27.800 --> 00:07:30.959 get the best of both the worlds because flag control 116 00:07:31.079 --> 00:07:35.399 provides that that super easy platform of the service developer experience. 117 00:07:35.920 --> 00:07:37.959 It's just you know, click buttons whatever you want to do, 118 00:07:38.120 --> 00:07:42.959 super fast to set up, fully automated. But also it 119 00:07:43.040 --> 00:07:45.879 deploys to your own AWS account, So if you have 120 00:07:46.480 --> 00:07:51.120 the skills, then you can, you know, go into your 121 00:07:51.160 --> 00:07:55.519 AWS account, you can customize things to override and you 122 00:07:55.560 --> 00:07:56.439 don't have that markup. 123 00:07:59.519 --> 00:08:01.560 But where does that configuration live? 124 00:08:02.040 --> 00:08:05.920 Like in the sense of Terraform and Polumi, I can 125 00:08:06.079 --> 00:08:13.120 literally maintain the infrastructure with my versioning system. So if 126 00:08:13.160 --> 00:08:16.120 I'm using GID, I can just push commits and change 127 00:08:16.199 --> 00:08:21.759 my infrastructure with flight control, and where does that configuration 128 00:08:21.959 --> 00:08:22.759 would live? 129 00:08:24.800 --> 00:08:31.519 So you get to choose two ways. You can store 130 00:08:31.560 --> 00:08:35.399 the configuration in flight control, so similar to Heroka oversell, 131 00:08:35.480 --> 00:08:38.360 where you're just clicking buttons and then I saved for you, 132 00:08:39.120 --> 00:08:41.799 or you can use infrastructure as code. And this is 133 00:08:41.840 --> 00:08:44.960 the infrastructure's code that we have designed that is a 134 00:08:45.080 --> 00:08:48.759 higher level abstraction than terraform or POLLUMI. And so our 135 00:08:48.919 --> 00:08:52.919 infrastructure's code is designed for developers. So instead of managing 136 00:08:53.039 --> 00:08:57.559 IP addresses and sub nets and networks in the infrastructure's code, 137 00:08:57.879 --> 00:09:01.240 you're defining your services. I need, I need a database, 138 00:09:01.320 --> 00:09:03.639 I need a static site to find your built command, 139 00:09:03.720 --> 00:09:07.000 your start command. So it's it's literally the same configuration 140 00:09:07.120 --> 00:09:09.240 that you can do through the UI, you can also 141 00:09:09.360 --> 00:09:13.440 do it through code and store that in your your repository. 142 00:09:13.559 --> 00:09:16.519 So we really give you the option. And so everything 143 00:09:16.600 --> 00:09:19.480 we do we try to give We try to make 144 00:09:19.519 --> 00:09:23.320 it super easy to adopt, but then also cover the 145 00:09:23.480 --> 00:09:27.720 complex use cases you know as your company scales, because 146 00:09:27.720 --> 00:09:31.039 that's the problem with traditional paths is you hit these 147 00:09:31.080 --> 00:09:36.159 scaling limits. And so that's where we're basically systematically removing those. 148 00:09:37.919 --> 00:09:42.440 And how do you approach when the situations where users 149 00:09:42.519 --> 00:09:47.159 want to do something that goes beyond the abstractions that 150 00:09:47.279 --> 00:09:50.279 Flight Control has created or are this just not the case? 151 00:09:50.759 --> 00:09:55.039 Because AWS is a universe of things, right, it's gigantic. 152 00:09:55.480 --> 00:10:01.360 So if you were to provide uh, develop friendly abstraction 153 00:10:01.600 --> 00:10:04.159 in the form of infrastructure as a code for every 154 00:10:04.240 --> 00:10:07.879 single thing that exists on AWS. Then you would be 155 00:10:08.000 --> 00:10:14.600 maintaining a gigantic compilation of commands, right and maybe that 156 00:10:14.840 --> 00:10:19.200 is what you did, but I'm not sure. And if 157 00:10:19.320 --> 00:10:22.039 that's not what you did, then what happens when a 158 00:10:22.200 --> 00:10:27.399 user wants to use something from AWS that the infrastructure 159 00:10:27.480 --> 00:10:32.360 as a code provided by flight Control doesn't have a 160 00:10:32.480 --> 00:10:33.519 connector yet? 161 00:10:35.320 --> 00:10:39.840 Great question. So our goal is to take the BESTWS services, 162 00:10:40.600 --> 00:10:44.200 which are like I haven't done the math, but it's 163 00:10:44.279 --> 00:10:48.200 like a few percent of all DEVELOABLEWS services are like 164 00:10:48.320 --> 00:10:51.360 the core things that everyone is using so easy to 165 00:10:52.639 --> 00:10:58.360 cloud front Land, the rds and so these are the 166 00:10:58.840 --> 00:11:02.039 most common and so they're the long tale of AWS 167 00:11:02.080 --> 00:11:04.799 services that most people aren't going to need a go 168 00:11:04.919 --> 00:11:07.279 to use. So we're focusing on the most common use 169 00:11:07.360 --> 00:11:11.919 cases and continually adding support for those. But the beauty 170 00:11:12.080 --> 00:11:17.159 of deploying to your AWS account is that you can 171 00:11:17.240 --> 00:11:21.320 do custom stuff alongside flight Control. So you can use 172 00:11:21.360 --> 00:11:24.440 flight Control for everything that it manages, and if you 173 00:11:24.480 --> 00:11:26.480 need to do something custom, well, you can do that 174 00:11:26.679 --> 00:11:29.600 however you want, and both things can live alongside each 175 00:11:29.639 --> 00:11:33.039 other really well. And so we see this, you know, 176 00:11:33.600 --> 00:11:38.440 a scale larger companies. You know, some companies are their 177 00:11:38.519 --> 00:11:41.879 product is such that the infrastructure is like almost their product, 178 00:11:42.000 --> 00:11:44.840 Like it's very critical, it's a core part of their product. 179 00:11:45.600 --> 00:11:48.240 But they also have a lot of other applications like 180 00:11:48.320 --> 00:11:52.559 their web application and in portals and things that are 181 00:11:52.600 --> 00:11:55.399 not core infrastructure, and so it's a waste of their 182 00:11:55.440 --> 00:11:58.200 time to manage the infrastructure for that, and so they 183 00:11:58.279 --> 00:12:03.320 use flight control for so they will manually manage their 184 00:12:03.360 --> 00:12:06.399 own product infrastructure and then everything else you use fly 185 00:12:06.519 --> 00:12:09.440 control for because it allows all the other developers to 186 00:12:10.120 --> 00:12:13.240 ship their stuff, you know, without taking time from the 187 00:12:13.440 --> 00:12:14.440 product infrastructure. 188 00:12:15.440 --> 00:12:20.639 Gotcha interesting, very very interesting, very complex as well. So 189 00:12:21.399 --> 00:12:26.480 I appreciate you for creating this that that definitely saves 190 00:12:26.600 --> 00:12:33.320 up a ton of time for for us Mere Mortals. So, Peter, Chris, 191 00:12:34.600 --> 00:12:38.200 any questions thus far? Like, Chris, maybe do you have anything? 192 00:12:39.039 --> 00:12:41.440 Yeah, just just a small thing, I guess because I'm 193 00:12:41.480 --> 00:12:43.879 looking at the site here and so you mentioned you 194 00:12:43.960 --> 00:12:48.120 can do kind of infrastructure as code. Is there a 195 00:12:48.200 --> 00:12:50.279 way can I even do you guys have like plug 196 00:12:50.360 --> 00:12:54.720 in via a code where like I have my Jason, 197 00:12:54.759 --> 00:12:56.360 you guys are using and I can I still get 198 00:12:56.399 --> 00:13:01.440 the visualization are there are they possible a guy through 199 00:13:01.600 --> 00:13:02.440 through the website. 200 00:13:02.679 --> 00:13:07.000 So the we have Jason schema build into this right 201 00:13:07.120 --> 00:13:13.039 now where the Jason field has a Schema field and 202 00:13:13.240 --> 00:13:14.960 a lot of a lot of editors support that, and 203 00:13:15.039 --> 00:13:17.279 so you do get kind of the the in line 204 00:13:17.360 --> 00:13:20.720 hints as you're you're typing your Jason there. You don't 205 00:13:20.759 --> 00:13:23.759 get any of the guy showing up there. That is 206 00:13:23.799 --> 00:13:27.360 something we could add. But whenever you create a project 207 00:13:27.440 --> 00:13:30.960 in a flight control you can you know, use the 208 00:13:31.080 --> 00:13:33.720 UI to can figure set up all your configuration and 209 00:13:33.840 --> 00:13:35.440 then you just mark that you want to start in 210 00:13:35.519 --> 00:13:38.000 your code and we give you the Jason for that. 211 00:13:38.799 --> 00:13:41.039 So that's it kind of covers that use case where 212 00:13:41.440 --> 00:13:43.279 you know you can easily see everything you can do 213 00:13:43.480 --> 00:13:46.200 with the UI and then just copy and paste the 214 00:13:46.720 --> 00:13:49.399 the or download the Jason file and you're good to go. 215 00:13:51.679 --> 00:13:52.399 Yeah, very cool. 216 00:13:52.759 --> 00:13:56.919 I'm with Lucas because if anyone's ever tried to deploy 217 00:13:56.960 --> 00:13:59.600 even something as soon simple as like a server, you 218 00:13:59.639 --> 00:14:02.480 think it's super easy. But even with tools like Columbia 219 00:14:02.559 --> 00:14:04.440 is like, hey, you need a gateway and you need 220 00:14:04.600 --> 00:14:05.919 rules and you need security. 221 00:14:06.879 --> 00:14:12.200 Yes, you need like five to fifteen different AWS primitives 222 00:14:12.320 --> 00:14:15.039 put together in just the right way to run a 223 00:14:15.080 --> 00:14:18.720 simple server, and like there's so you know, five to 224 00:14:18.799 --> 00:14:20.919 fifteen different ways and you multiply all the ways this 225 00:14:21.039 --> 00:14:23.720 can be connected together or whatever, like there's so many 226 00:14:23.759 --> 00:14:27.759 ways to mess up on security, on whatnot, and so 227 00:14:28.080 --> 00:14:32.000 we just do that for you. You know, AWS is 228 00:14:32.320 --> 00:14:36.759 super awesome at the low level primitives, Like that's what 229 00:14:36.879 --> 00:14:40.759 they are world class at. They're not good at developer experience. 230 00:14:40.799 --> 00:14:43.559 They're not good at the higher level layers, but they 231 00:14:43.600 --> 00:14:48.000 are absolutely world class at those low level building blocks. 232 00:14:49.080 --> 00:14:51.000 And so it actually works out kind of nice because 233 00:14:51.000 --> 00:14:54.759 they can focus on the operational stuff, they're the reliability 234 00:14:55.200 --> 00:14:57.240 and then another company like US can come in and 235 00:14:57.799 --> 00:15:02.200 really like focus on the developer experience, which is this 236 00:15:02.559 --> 00:15:07.399 This split also enables it's a unique thing advantage that 237 00:15:07.480 --> 00:15:10.960 we have over the traditional platforms of the service because 238 00:15:11.000 --> 00:15:14.320 the traditional platforms are reinventing the wheel on every single 239 00:15:14.399 --> 00:15:19.440 thing because they are like literally have this custom layer 240 00:15:19.519 --> 00:15:22.960 of custom software between you and AWS. But with US, 241 00:15:24.000 --> 00:15:28.240 we just use whatever AWS has ECS plus fargate or 242 00:15:28.279 --> 00:15:32.039 ECS plus e C two RDS for the database, et cetera. 243 00:15:32.600 --> 00:15:34.759 And so we can spend all our resources on the 244 00:15:34.799 --> 00:15:38.279 developer experience layer instead of reinventing the wheel on infrastructure. 245 00:15:41.120 --> 00:15:46.240 Okay, so I am very eager to bring a different 246 00:15:46.360 --> 00:15:50.960 side of things, which is what about other cloud providers 247 00:15:51.039 --> 00:15:56.399 that maybe already provide a pretty decent developer experience. Talking 248 00:15:56.480 --> 00:16:00.360 specifically about Digital Ocean, it's not the hottest skin in 249 00:16:00.399 --> 00:16:03.799 the block, but I've always been amazed at how easy 250 00:16:03.919 --> 00:16:09.679 they make things. And they are their own provider, right, 251 00:16:09.799 --> 00:16:12.799 they have their own data centers, They're not relying on 252 00:16:13.080 --> 00:16:19.360 infrastructure from other companies. Why don't just go with that 253 00:16:19.879 --> 00:16:24.639 instead of using AWS and trying to figure out what 254 00:16:24.919 --> 00:16:28.200 is the right abstraction layer, why not just go to 255 00:16:28.320 --> 00:16:31.639 a provider that it gives you access to the low 256 00:16:31.759 --> 00:16:35.399 level stuff and it's also very easy to set up everything. 257 00:16:39.080 --> 00:16:44.759 Well. I have, so I personally have not like went 258 00:16:44.879 --> 00:16:47.360 down that road to Digital Ocean. I've done simple stuff. 259 00:16:48.240 --> 00:16:51.799 So I can't fully speak to that, but what I 260 00:16:51.879 --> 00:16:55.879 can say is that the market says the AWS is 261 00:16:55.919 --> 00:16:58.879 the winner. People keep coming back to AWS over and 262 00:16:59.080 --> 00:17:04.559 overuse because of its reliability, its longevity, it's it's uh, 263 00:17:04.839 --> 00:17:09.400 you know, price performance and the breadth of cloud native services. 264 00:17:10.319 --> 00:17:11.880 So if you need to use if you want to 265 00:17:11.920 --> 00:17:14.880 use Lambda, you want to do service deployments, you're going 266 00:17:14.960 --> 00:17:17.119 to be on a w S. R d S is 267 00:17:17.200 --> 00:17:21.240 one of the best managed database services, and so like 268 00:17:21.359 --> 00:17:25.279 you're probably gonna want that. Also, you're gonna at some 269 00:17:25.400 --> 00:17:29.839 point work with other vendors that you're you know, you're 270 00:17:29.839 --> 00:17:31.920 maybe purchasing some kind of software or the service and 271 00:17:32.000 --> 00:17:33.880 you want to self host it. It's going to be 272 00:17:33.920 --> 00:17:36.519 designed to run on a w S. It's it's kind 273 00:17:36.559 --> 00:17:40.519 of this network effect with a w S where you know, 274 00:17:40.640 --> 00:17:42.920 other other clouds are running on a w S also, 275 00:17:43.000 --> 00:17:45.440 and so the fastest way to access to them is 276 00:17:45.519 --> 00:17:47.960 you run on a w S in the same a 277 00:17:48.160 --> 00:17:50.920 w S data center. So there's just a long list 278 00:17:51.000 --> 00:17:54.640 of things like that that just push people towards a 279 00:17:54.880 --> 00:17:57.640 w S in the in their level of scale. 280 00:17:58.200 --> 00:17:58.319 Uh. 281 00:17:58.400 --> 00:18:00.519 I think digitaltion is fine, it's good, but you know, 282 00:18:00.640 --> 00:18:02.640 maybe we'll add support for that at some point. 283 00:18:05.039 --> 00:18:07.920 Yeah, gotcham that. 284 00:18:08.720 --> 00:18:12.359 With regards to adding support, how do you see support 285 00:18:12.519 --> 00:18:16.240 for the other three major players, Because I completely understand 286 00:18:16.279 --> 00:18:19.319 that Digital Ocean is at the bottom of the list 287 00:18:19.400 --> 00:18:23.359 in terms of like people actually using it on a 288 00:18:23.559 --> 00:18:24.200 large scale. 289 00:18:24.680 --> 00:18:25.640 I like it very much. 290 00:18:25.759 --> 00:18:28.720 But every time it's like I'm trying to convince people 291 00:18:28.920 --> 00:18:31.400 of hey, why don't you just start there, like you 292 00:18:31.480 --> 00:18:35.039 can migrate to to a big cloud afterwards, Like there's 293 00:18:35.039 --> 00:18:38.519 no need to start with that complexity migrate later. 294 00:18:38.720 --> 00:18:40.880 Why not? Why would you start on somewhere that you're 295 00:18:40.880 --> 00:18:41.920 going to have to migrate. 296 00:18:42.519 --> 00:18:45.480 Because I think that forces you to think about your 297 00:18:45.559 --> 00:18:49.319 infrastructure in a way that is independent of the cloud provider. 298 00:18:49.720 --> 00:18:52.480 If you already start by knowing that you're going to 299 00:18:52.559 --> 00:18:56.759 have to migrate clouds afterwards, then you're not gonna make 300 00:18:56.960 --> 00:18:59.519 choices that are too specific to one cloud. You're going 301 00:18:59.559 --> 00:19:02.359 to think of about serveralist functions, not with regards to 302 00:19:02.640 --> 00:19:06.119 aws LENDA, You're just going to think about servileist functions. 303 00:19:06.839 --> 00:19:10.279 And that makes that forces the engineers to think about 304 00:19:10.440 --> 00:19:12.640 how to architect the system in a way that is 305 00:19:12.720 --> 00:19:16.640 going to be easy to migrate to others afterwards. And 306 00:19:16.759 --> 00:19:19.160 even if you end up staying in just a WS 307 00:19:20.000 --> 00:19:23.720 for a very long time, just knowing that your infrastructure 308 00:19:23.839 --> 00:19:28.799 can be somewhat ned easily migrated because it's never really 309 00:19:28.880 --> 00:19:32.160 easy to migrate infrastructure, allows you to have a very 310 00:19:32.279 --> 00:19:35.480 good leverage in sales and it is known that the 311 00:19:35.640 --> 00:19:38.759 AWS consultants are going to give you a huge discount 312 00:19:38.920 --> 00:19:40.920 if you try to negotiate with them because they know 313 00:19:41.000 --> 00:19:42.319 that you have the power to migrate. 314 00:19:42.480 --> 00:19:44.000 So that's basically why. 315 00:19:46.359 --> 00:19:50.960 So yeah, here the last point is what the point 316 00:19:51.039 --> 00:19:52.599 I think you should start with. I think that is 317 00:19:52.680 --> 00:19:56.599 really the I think that's the only reason, in my opinion, 318 00:19:57.279 --> 00:19:59.559 that you would want to be able to migrate clouds 319 00:20:00.240 --> 00:20:06.039 is to negotiate deals like that, because you know, if 320 00:20:06.079 --> 00:20:09.599 you're just like theoretically doing building an application that to 321 00:20:09.680 --> 00:20:12.319 be portable, then you're also wasting a lot of time 322 00:20:13.519 --> 00:20:18.079 engineer brain cycles thinking about that and building that. Whereas, 323 00:20:18.200 --> 00:20:20.559 like you know, most companies are going to be totally 324 00:20:20.640 --> 00:20:23.160 fine on NWS for a very long time. If you 325 00:20:23.240 --> 00:20:26.559 reach a point of scale at which it becomes a 326 00:20:26.640 --> 00:20:29.440 problem and you and you need to migrate to your 327 00:20:29.480 --> 00:20:31.519 own data center or something, you're going to have so 328 00:20:31.640 --> 00:20:34.920 much money and engineers like who cares at that point. 329 00:20:36.960 --> 00:20:37.880 But yeah, that's a good point. 330 00:20:38.720 --> 00:20:41.000 Now that that that's also a good point. Yeah, in 331 00:20:41.160 --> 00:20:45.279 terms of just pushing things to the reality. It's it's 332 00:20:45.400 --> 00:20:48.279 hard to have startups that actually reach that level. 333 00:20:48.839 --> 00:20:52.920 So it at a certain point it would be just 334 00:20:53.039 --> 00:20:55.400 easier to not worry about it and just choose one 335 00:20:55.480 --> 00:20:56.079 and stick to it. 336 00:20:56.480 --> 00:21:01.480 Yeah, that that does make sense, and way I do 337 00:21:01.599 --> 00:21:04.160 think it's it's hard to choose one nowadays because there 338 00:21:04.240 --> 00:21:07.720 are some interesting choices popping up, not just speaking about 339 00:21:07.799 --> 00:21:10.839 abstractions on top of providers, but cloud. 340 00:21:10.640 --> 00:21:11.440 Flare, for example. 341 00:21:11.559 --> 00:21:15.680 It's a very good content contender that has come up, 342 00:21:15.920 --> 00:21:21.559 and there are particular points about cloud Flares services that 343 00:21:21.759 --> 00:21:25.400 I really like. So I wouldn't really say that I 344 00:21:25.440 --> 00:21:29.519 would migrate an entire application to cloud Flare or even 345 00:21:29.559 --> 00:21:34.160 build an entire application on cloud Flares infrastructure, because they 346 00:21:34.319 --> 00:21:38.799 don't support containers in any form. 347 00:21:38.920 --> 00:21:45.400 They just have serverlusts and I haven't really bought one 348 00:21:45.440 --> 00:21:47.319 hundred percent serviles for all cases. 349 00:21:47.400 --> 00:21:49.480 I think they're the right cases for it, and there 350 00:21:49.519 --> 00:21:53.039 are cases where it's just not the right choice. But 351 00:21:53.319 --> 00:21:57.160 for many other things, I would definitely go with cloud Flare. 352 00:21:57.279 --> 00:22:01.640 So I like having a hybrid approach to clouds and 353 00:22:02.240 --> 00:22:05.880 picking the parts of their services that best fit my 354 00:22:06.079 --> 00:22:09.200 needs and also their their pricing and et cetera. 355 00:22:09.519 --> 00:22:11.160 But in any case, I think. 356 00:22:11.039 --> 00:22:13.759 I got a bit sidetracked. But what I was going 357 00:22:13.839 --> 00:22:17.079 to say is you you mentioned, oh, perhaps we add 358 00:22:17.160 --> 00:22:20.519 support for digital otion later on. How do you see 359 00:22:20.720 --> 00:22:27.640 support for just Google Cloud and Asia for flight control? 360 00:22:28.960 --> 00:22:32.559 I think that we will support that, probably GCP first 361 00:22:32.599 --> 00:22:34.480 and then ASURE later, but it's probably going to be 362 00:22:34.519 --> 00:22:38.240 a couple of years out. You know, maybe we never do. 363 00:22:38.599 --> 00:22:42.079 I don't know. I do know that the GCP is 364 00:22:42.640 --> 00:22:47.000 like has so many issues around shutting down services, poor 365 00:22:47.079 --> 00:22:50.440 customer support. Like Railway is one of our competitors, for example, 366 00:22:51.160 --> 00:22:55.519 that is still mostly built on top of GCP, and 367 00:22:55.880 --> 00:22:59.319 they've had like these terrible stories where GCP or just 368 00:22:59.480 --> 00:23:02.400 like Rank revoke their quotas and all of a sudden, 369 00:23:02.519 --> 00:23:04.680 like stuff is failing and then they can't get in 370 00:23:04.720 --> 00:23:07.640 contact to support, and like you just don't have these 371 00:23:07.720 --> 00:23:11.200 kind of things with AWS and you know, so like 372 00:23:11.400 --> 00:23:16.599 definitely there's some advantages there. And then Azure. I think 373 00:23:16.880 --> 00:23:19.119 the main reason I hear people going to Azure is 374 00:23:19.200 --> 00:23:22.759 because either they're doing dot net stuff or they got 375 00:23:22.799 --> 00:23:26.440 a really good deal on you know, discounts and whatnot. 376 00:23:27.640 --> 00:23:33.400 So you know, eventually we'll probably support for them. But 377 00:23:33.799 --> 00:23:36.480 the one thing we do is is really go deep 378 00:23:36.599 --> 00:23:39.359 on each provider that we support. So there's other competitors 379 00:23:39.920 --> 00:23:42.480 that are, like, right now, they support all the clouds, 380 00:23:43.119 --> 00:23:45.559 but it's the least common denominator approach. For like, it's 381 00:23:45.559 --> 00:23:48.920 probably Kubernetes, and you can deploy the thing wherever, but 382 00:23:49.119 --> 00:23:52.240 you don't really get the best version of each cloud 383 00:23:52.319 --> 00:23:54.559 because you're just getting the lowest common denominator. And so 384 00:23:54.720 --> 00:23:57.839 we were intentional to say, hey, let's go deep on AWS. 385 00:23:58.000 --> 00:24:00.240 Let's take the things that AWS is really good good 386 00:24:00.279 --> 00:24:01.960 at and make those really easy to use. 387 00:24:03.759 --> 00:24:09.559 Nice okay, And let's let's bring this closer to a 388 00:24:09.680 --> 00:24:12.640 developer actually wanting to use flight Control. What would be 389 00:24:12.759 --> 00:24:16.160 the situation we're talking about React developers here. So let's 390 00:24:16.160 --> 00:24:19.839 say that somebody's listening to this. They have started a 391 00:24:20.000 --> 00:24:23.880 React application and they just want to put it online, 392 00:24:24.359 --> 00:24:27.640 and they know that versall is an easy choice, netli 393 00:24:27.759 --> 00:24:30.599 fi is and is an easy choice when they hear 394 00:24:30.680 --> 00:24:32.359 AWS doesn't. 395 00:24:32.119 --> 00:24:36.039 Sound easy, How does in practice. 396 00:24:37.519 --> 00:24:40.960 Would look like for this developer to actually use flight 397 00:24:41.079 --> 00:24:43.160 Control to develop to deploy their application. 398 00:24:44.079 --> 00:24:46.960 So it's it's going to be almost exactly the same 399 00:24:47.039 --> 00:24:50.680 as versell or netleth i. You sign up, you connect 400 00:24:50.720 --> 00:24:54.319 your GitHub account, you also connect your AWS account. So 401 00:24:54.400 --> 00:24:58.039