Speaker 1: Hey, welcome to React Around Them, the podcast where we
Speaker 1: keep you updated on all things React related. This show
Speaker 1: is sponsored by Reagan and produced by Top and Devs
Speaker 1: and Onvoid.
Speaker 2: Top and Deves is very great.
Speaker 1: Top and Deves we get top and pay and recognition
Speaker 1: or working on interesting problems and making meaningful community contributions
Speaker 1: an Void which provides remote design and software development services
Speaker 1: on the most client friendly business model, so clients only
Speaker 1: pay after the tasks are delivered and approved. In today's episode,
Speaker 1: we will talk about flight flight Control and basically this
Speaker 1: is a tool that allows developers to not have to
Speaker 1: worry too much about the box when they deploy their applications.
Speaker 1: So it's going to be around the subject of developer operations.
Speaker 2: My name is Lucas Pagani your a podcast.
Speaker 1: Joining me in today's episode is also the host Chris Bruin.
Speaker 3: Hello everybody, and we have a very special guest which
Speaker 3: is the CEO and co founder of flight Control, Brandom Buyer.
Speaker 4: Excited to be here.
Speaker 1: Thank you for being here, Brandom. Well let's just get
Speaker 1: into it. So Brandon, I'm sure you have explained this
Speaker 1: a million times already, but let's do it one more.
Speaker 2: Can you pitch flight Control to the audience.
Speaker 4: Please good thing never gets old. It's my baby. So
Speaker 4: flight Control is a platform as a service for deploying application, server, database,
Speaker 4: aesthetic sites to your own AWS account. Now why your
Speaker 4: own AWS account? Because it enables us to leap frog
Speaker 4: traditional platforms as a service on one most every metric. So,
Speaker 4: for example, you get two to six x faster built
Speaker 4: than any other platform, fifty to seventy five percent cheaper
Speaker 4: compute in near perfect reliability.
Speaker 2: Awesome.
Speaker 1: Okay, so let's bring it to something that might be
Speaker 1: a bit more popular in the eyes of front and developers,
Speaker 1: and then we can make a comparison.
Speaker 2: To flight Control.
Speaker 1: So to me at least, I know there are many
Speaker 1: platforms built on top of the AWS infrastructure and other
Speaker 1: big CLAWS, but I think Heroku might be one of
Speaker 1: the most famous and popular ones and it is known
Speaker 1: to be built on top of AWS. You can actually
Speaker 1: literally do a one on one mapping between the Heroku
Speaker 1: zones and the AWS zone. So if you want something
Speaker 1: to be in the same data center that you have
Speaker 1: deployed on AWS, you can just literally choose it.
Speaker 2: And Heroko and it's going to be there. So how
Speaker 2: does flight control compare to HEROICU or is that not
Speaker 2: the kind of comparison that we should be making.
Speaker 4: Yeah, that's definitely definitely the right comparison. Uh. And then
Speaker 4: the other you know, Heroica has been around a long time,
Speaker 4: so there might be actually new people that don't even
Speaker 4: know about it, but they probably know about versaill especially
Speaker 4: being you know, in the React space, so Vercell is
Speaker 4: another you know comparison there. And you know, both of
Speaker 4: these platforms were created because infrastructure is really hard and
Speaker 4: developers want to be able to build applications quickly, ship
Speaker 4: them product production, and scale them to users all around
Speaker 4: the world. But if you're using abs directly, like you,
Speaker 4: it requires lots of specialized knowledge skills, time, like, it's
Speaker 4: just a pain in the butt. But these platforms like
Speaker 4: Heroca and Versail were created to make that so much easier,
Speaker 4: and they are so much easier it's it's incredible. But
Speaker 4: the problem is that at some point you end up
Speaker 4: hitting problems and limitations. You had technical limitations where you know,
Speaker 4: maybe you need to customize some part of your infrastructure
Speaker 4: for security or something else and you just can't, or
Speaker 4: maybe you start getting charged a lot of money because
Speaker 4: Heroka and Ursell have very high markup over top of
Speaker 4: the aws cost. You know, so when you're just getting
Speaker 4: started like who Care, you can run anywhere. But as
Speaker 4: you start scaling your app then it becomes, you know,
Speaker 4: a bigger question there. And I'll just share briefly an
Speaker 4: experience I had a while back. I think that helps
Speaker 4: illustrate this. So I was on a trip and as
Speaker 4: I entered my Airbnb, I was taken aback because almost
Speaker 4: every door cupboard in Appliance had a sticky note on
Speaker 4: it and either saying it was off limits or describing
Speaker 4: the content. And it was it was painfully obvious that
Speaker 4: I was living in someone else's house, like they were
Speaker 4: dictating everything you can or cannot do this, And that
Speaker 4: approximates the experience of using a traditional platform of the service.
Speaker 4: You are living in someone else's house and you have
Speaker 4: strictly limited access, unable to go into the utility room
Speaker 4: for example, or make upgrades as you as your needs change.
Speaker 4: But with flight Control, you fully own the house and
Speaker 4: you invite flight Control to come in and fully manage
Speaker 4: all the cleaning, painting, mowing the yard, even doing upgrades
Speaker 4: and renovations for you. And yes, you pay flight Control
Speaker 4: and modest fee for this service, but even after counting
Speaker 4: your mortgage payment, and your total cost is significantly less
Speaker 4: than the Airbnb or the Bursell markup with their ridiculous
Speaker 4: cleaning fees.
Speaker 1: Okay, I like the analogy that this makes a lot
Speaker 1: of sense, But I guess my next question would be
Speaker 1: how do you balance having full access while also getting
Speaker 1: well also giving users a simpler facade into how to
Speaker 1: interact with it? Right? So, for example, when I initially
Speaker 1: went to flight Control's website, I initially made a connection
Speaker 1: between that and infrastructure as a code pools, so for example,
Speaker 1: pullooni or Terraform.
Speaker 2: And I'm not sure if this is.
Speaker 1: The right comparison that I should be making, but that's
Speaker 1: what I did at the time because I thought, Okay,
Speaker 1: it's going to simplify how I interact with AWS, but
Speaker 1: it's still going to give me control. So perhaps could
Speaker 1: we also make this comparison between Okay, like we sure
Speaker 1: can compare Heroku and ver Sell to fly Control, can
Speaker 1: we also compare flight control your Terraform and movie.
Speaker 4: So the reason we created flight Control was we wanted
Speaker 4: the ease of use of our cell and Heroku, but
Speaker 4: the full control and the scalability of my own AWS account.
Speaker 4: And so before flag Control you had to choose between
Speaker 4: good developer experience or full control and scalability and no markup.
Speaker 4: You couldn't get both. But now a flag control you
Speaker 4: get the best of both the worlds because flag control
Speaker 4: provides that that super easy platform of the service developer experience.
Speaker 4: It's just you know, click buttons whatever you want to do,
Speaker 4: super fast to set up, fully automated. But also it
Speaker 4: deploys to your own AWS account, So if you have
Speaker 4: the skills, then you can, you know, go into your
Speaker 4: AWS account, you can customize things to override and you
Speaker 4: don't have that markup.
Speaker 2: But where does that configuration live?
Speaker 1: Like in the sense of Terraform and Polumi, I can
Speaker 1: literally maintain the infrastructure with my versioning system. So if
Speaker 1: I'm using GID, I can just push commits and change
Speaker 1: my infrastructure with flight control, and where does that configuration
Speaker 1: would live?
Speaker 4: So you get to choose two ways. You can store
Speaker 4: the configuration in flight control, so similar to Heroka oversell,
Speaker 4: where you're just clicking buttons and then I saved for you,
Speaker 4: or you can use infrastructure as code. And this is
Speaker 4: the infrastructure's code that we have designed that is a
Speaker 4: higher level abstraction than terraform or POLLUMI. And so our
Speaker 4: infrastructure's code is designed for developers. So instead of managing
Speaker 4: IP addresses and sub nets and networks in the infrastructure's code,
Speaker 4: you're defining your services. I need, I need a database,
Speaker 4: I need a static site to find your built command,
Speaker 4: your start command. So it's it's literally the same configuration
Speaker 4: that you can do through the UI, you can also
Speaker 4: do it through code and store that in your your repository.
Speaker 4: So we really give you the option. And so everything
Speaker 4: we do we try to give We try to make
Speaker 4: it super easy to adopt, but then also cover the
Speaker 4: complex use cases you know as your company scales, because
Speaker 4: that's the problem with traditional paths is you hit these
Speaker 4: scaling limits. And so that's where we're basically systematically removing those.
Speaker 1: And how do you approach when the situations where users
Speaker 1: want to do something that goes beyond the abstractions that
Speaker 1: Flight Control has created or are this just not the case?
Speaker 1: Because AWS is a universe of things, right, it's gigantic.
Speaker 1: So if you were to provide uh, develop friendly abstraction
Speaker 1: in the form of infrastructure as a code for every
Speaker 1: single thing that exists on AWS. Then you would be
Speaker 1: maintaining a gigantic compilation of commands, right and maybe that
Speaker 1: is what you did, but I'm not sure. And if
Speaker 1: that's not what you did, then what happens when a
Speaker 1: user wants to use something from AWS that the infrastructure
Speaker 1: as a code provided by flight Control doesn't have a
Speaker 1: connector yet?
Speaker 4: Great question. So our goal is to take the BESTWS services,
Speaker 4: which are like I haven't done the math, but it's
Speaker 4: like a few percent of all DEVELOABLEWS services are like
Speaker 4: the core things that everyone is using so easy to
Speaker 4: cloud front Land, the rds and so these are the
Speaker 4: most common and so they're the long tale of AWS
Speaker 4: services that most people aren't going to need a go
Speaker 4: to use. So we're focusing on the most common use
Speaker 4: cases and continually adding support for those. But the beauty
Speaker 4: of deploying to your AWS account is that you can
Speaker 4: do custom stuff alongside flight Control. So you can use
Speaker 4: flight Control for everything that it manages, and if you
Speaker 4: need to do something custom, well, you can do that
Speaker 4: however you want, and both things can live alongside each
Speaker 4: other really well. And so we see this, you know,
Speaker 4: a scale larger companies. You know, some companies are their
Speaker 4: product is such that the infrastructure is like almost their product,
Speaker 4: Like it's very critical, it's a core part of their product.
Speaker 4: But they also have a lot of other applications like
Speaker 4: their web application and in portals and things that are
Speaker 4: not core infrastructure, and so it's a waste of their
Speaker 4: time to manage the infrastructure for that, and so they
Speaker 4: use flight control for so they will manually manage their
Speaker 4: own product infrastructure and then everything else you use fly
Speaker 4: control for because it allows all the other developers to
Speaker 4: ship their stuff, you know, without taking time from the
Speaker 4: product infrastructure.
Speaker 1: Gotcha interesting, very very interesting, very complex as well. So
Speaker 1: I appreciate you for creating this that that definitely saves
Speaker 1: up a ton of time for for us Mere Mortals. So, Peter, Chris,
Speaker 1: any questions thus far? Like, Chris, maybe do you have anything?
Speaker 5: Yeah, just just a small thing, I guess because I'm
Speaker 5: looking at the site here and so you mentioned you
Speaker 5: can do kind of infrastructure as code. Is there a
Speaker 5: way can I even do you guys have like plug
Speaker 5: in via a code where like I have my Jason,
Speaker 5: you guys are using and I can I still get
Speaker 5: the visualization are there are they possible a guy through
Speaker 5: through the website.
Speaker 4: So the we have Jason schema build into this right
Speaker 4: now where the Jason field has a Schema field and
Speaker 4: a lot of a lot of editors support that, and
Speaker 4: so you do get kind of the the in line
Speaker 4: hints as you're you're typing your Jason there. You don't
Speaker 4: get any of the guy showing up there. That is
Speaker 4: something we could add. But whenever you create a project
Speaker 4: in a flight control you can you know, use the
Speaker 4: UI to can figure set up all your configuration and
Speaker 4: then you just mark that you want to start in
Speaker 4: your code and we give you the Jason for that.
Speaker 4: So that's it kind of covers that use case where
Speaker 4: you know you can easily see everything you can do
Speaker 4: with the UI and then just copy and paste the
Speaker 4: the or download the Jason file and you're good to go.
Speaker 2: Yeah, very cool.
Speaker 5: I'm with Lucas because if anyone's ever tried to deploy
Speaker 5: even something as soon simple as like a server, you
Speaker 5: think it's super easy. But even with tools like Columbia
Speaker 5: is like, hey, you need a gateway and you need
Speaker 5: rules and you need security.
Speaker 4: Yes, you need like five to fifteen different AWS primitives
Speaker 4: put together in just the right way to run a
Speaker 4: simple server, and like there's so you know, five to
Speaker 4: fifteen different ways and you multiply all the ways this
Speaker 4: can be connected together or whatever, like there's so many
Speaker 4: ways to mess up on security, on whatnot, and so
Speaker 4: we just do that for you. You know, AWS is
Speaker 4: super awesome at the low level primitives, Like that's what
Speaker 4: they are world class at. They're not good at developer experience.
Speaker 4: They're not good at the higher level layers, but they
Speaker 4: are absolutely world class at those low level building blocks.
Speaker 4: And so it actually works out kind of nice because
Speaker 4: they can focus on the operational stuff, they're the reliability
Speaker 4: and then another company like US can come in and
Speaker 4: really like focus on the developer experience, which is this
Speaker 4: This split also enables it's a unique thing advantage that
Speaker 4: we have over the traditional platforms of the service because
Speaker 4: the traditional platforms are reinventing the wheel on every single
Speaker 4: thing because they are like literally have this custom layer
Speaker 4: of custom software between you and AWS. But with US,
Speaker 4: we just use whatever AWS has ECS plus fargate or
Speaker 4: ECS plus e C two RDS for the database, et cetera.
Speaker 4: And so we can spend all our resources on the
Speaker 4: developer experience layer instead of reinventing the wheel on infrastructure.
Speaker 1: Okay, so I am very eager to bring a different
Speaker 1: side of things, which is what about other cloud providers
Speaker 1: that maybe already provide a pretty decent developer experience. Talking
Speaker 1: specifically about Digital Ocean, it's not the hottest skin in
Speaker 1: the block, but I've always been amazed at how easy
Speaker 1: they make things. And they are their own provider, right,
Speaker 1: they have their own data centers, They're not relying on
Speaker 1: infrastructure from other companies. Why don't just go with that
Speaker 1: instead of using AWS and trying to figure out what
Speaker 1: is the right abstraction layer, why not just go to
Speaker 1: a provider that it gives you access to the low
Speaker 1: level stuff and it's also very easy to set up everything.
Speaker 4: Well. I have, so I personally have not like went
Speaker 4: down that road to Digital Ocean. I've done simple stuff.
Speaker 4: So I can't fully speak to that, but what I
Speaker 4: can say is that the market says the AWS is
Speaker 4: the winner. People keep coming back to AWS over and
Speaker 4: overuse because of its reliability, its longevity, it's it's uh,
Speaker 4: you know, price performance and the breadth of cloud native services.
Speaker 4: So if you need to use if you want to
Speaker 4: use Lambda, you want to do service deployments, you're going
Speaker 4: to be on a w S. R d S is
Speaker 4: one of the best managed database services, and so like
Speaker 4: you're probably gonna want that. Also, you're gonna at some
Speaker 4: point work with other vendors that you're you know, you're
Speaker 4: maybe purchasing some kind of software or the service and
Speaker 4: you want to self host it. It's going to be
Speaker 4: designed to run on a w S. It's it's kind
Speaker 4: of this network effect with a w S where you know,
Speaker 4: other other clouds are running on a w S also,
Speaker 4: and so the fastest way to access to them is
Speaker 4: you run on a w S in the same a
Speaker 4: w S data center. So there's just a long list
Speaker 4: of things like that that just push people towards a
Speaker 4: w S in the in their level of scale.
Speaker 1: Uh.
Speaker 4: I think digitaltion is fine, it's good, but you know,
Speaker 4: maybe we'll add support for that at some point.
Speaker 2: Yeah, gotcham that.
Speaker 1: With regards to adding support, how do you see support
Speaker 1: for the other three major players, Because I completely understand
Speaker 1: that Digital Ocean is at the bottom of the list
Speaker 1: in terms of like people actually using it on a
Speaker 1: large scale.
Speaker 2: I like it very much.
Speaker 1: But every time it's like I'm trying to convince people
Speaker 1: of hey, why don't you just start there, like you
Speaker 1: can migrate to to a big cloud afterwards, Like there's
Speaker 1: no need to start with that complexity migrate later.
Speaker 4: Why not? Why would you start on somewhere that you're
Speaker 4: going to have to migrate.
Speaker 1: Because I think that forces you to think about your
Speaker 1: infrastructure in a way that is independent of the cloud provider.
Speaker 1: If you already start by knowing that you're going to
Speaker 1: have to migrate clouds afterwards, then you're not gonna make
Speaker 1: choices that are too specific to one cloud. You're going
Speaker 1: to think of about serveralist functions, not with regards to
Speaker 1: aws LENDA, You're just going to think about servileist functions.
Speaker 1: And that makes that forces the engineers to think about
Speaker 1: how to architect the system in a way that is
Speaker 1: going to be easy to migrate to others afterwards. And
Speaker 1: even if you end up staying in just a WS
Speaker 1: for a very long time, just knowing that your infrastructure
Speaker 1: can be somewhat ned easily migrated because it's never really
Speaker 1: easy to migrate infrastructure, allows you to have a very
Speaker 1: good leverage in sales and it is known that the
Speaker 1: AWS consultants are going to give you a huge discount
Speaker 1: if you try to negotiate with them because they know
Speaker 1: that you have the power to migrate.
Speaker 2: So that's basically why.
Speaker 4: So yeah, here the last point is what the point
Speaker 4: I think you should start with. I think that is
Speaker 4: really the I think that's the only reason, in my opinion,
Speaker 4: that you would want to be able to migrate clouds
Speaker 4: is to negotiate deals like that, because you know, if
Speaker 4: you're just like theoretically doing building an application that to
Speaker 4: be portable, then you're also wasting a lot of time
Speaker 4: engineer brain cycles thinking about that and building that. Whereas,
Speaker 4: like you know, most companies are going to be totally
Speaker 4: fine on NWS for a very long time. If you
Speaker 4: reach a point of scale at which it becomes a
Speaker 4: problem and you and you need to migrate to your
Speaker 4: own data center or something, you're going to have so
Speaker 4: much money and engineers like who cares at that point.
Speaker 4: But yeah, that's a good point.
Speaker 1: Now that that that's also a good point. Yeah, in
Speaker 1: terms of just pushing things to the reality. It's it's
Speaker 1: hard to have startups that actually reach that level.
Speaker 2: So it at a certain point it would be just
Speaker 2: easier to not worry about it and just choose one
Speaker 2: and stick to it.
Speaker 1: Yeah, that that does make sense, and way I do
Speaker 1: think it's it's hard to choose one nowadays because there
Speaker 1: are some interesting choices popping up, not just speaking about
Speaker 1: abstractions on top of providers, but cloud.
Speaker 2: Flare, for example.
Speaker 1: It's a very good content contender that has come up,
Speaker 1: and there are particular points about cloud Flares services that
Speaker 1: I really like. So I wouldn't really say that I
Speaker 1: would migrate an entire application to cloud Flare or even
Speaker 1: build an entire application on cloud Flares infrastructure, because they
Speaker 1: don't support containers in any form.
Speaker 2: They just have serverlusts and I haven't really bought one
Speaker 2: hundred percent serviles for all cases.
Speaker 1: I think they're the right cases for it, and there
Speaker 1: are cases where it's just not the right choice. But
Speaker 1: for many other things, I would definitely go with cloud Flare.
Speaker 1: So I like having a hybrid approach to clouds and
Speaker 1: picking the parts of their services that best fit my
Speaker 1: needs and also their their pricing and et cetera.
Speaker 2: But in any case, I think.
Speaker 1: I got a bit sidetracked. But what I was going
Speaker 1: to say is you you mentioned, oh, perhaps we add
Speaker 1: support for digital otion later on. How do you see
Speaker 1: support for just Google Cloud and Asia for flight control?
Speaker 4: I think that we will support that, probably GCP first
Speaker 4: and then ASURE later, but it's probably going to be
Speaker 4: a couple of years out. You know, maybe we never do.
Speaker 4: I don't know. I do know that the GCP is
Speaker 4: like has so many issues around shutting down services, poor
Speaker 4: customer support. Like Railway is one of our competitors, for example,
Speaker 4: that is still mostly built on top of GCP, and
Speaker 4: they've had like these terrible stories where GCP or just
Speaker 4: like Rank revoke their quotas and all of a sudden,
Speaker 4: like stuff is failing and then they can't get in
Speaker 4: contact to support, and like you just don't have these
Speaker 4: kind of things with AWS and you know, so like
Speaker 4: definitely there's some advantages there. And then Azure. I think
Speaker 4: the main reason I hear people going to Azure is
Speaker 4: because either they're doing dot net stuff or they got
Speaker 4: a really good deal on you know, discounts and whatnot.
Speaker 4: So you know, eventually we'll probably support for them. But
Speaker 4: the one thing we do is is really go deep
Speaker 4: on each provider that we support. So there's other competitors
Speaker 4: that are, like, right now, they support all the clouds,
Speaker 4: but it's the least common denominator approach. For like, it's
Speaker 4: probably Kubernetes, and you can deploy the thing wherever, but
Speaker 4: you don't really get the best version of each cloud
Speaker 4: because you're just getting the lowest common denominator. And so
Speaker 4: we were intentional to say, hey, let's go deep on AWS.
Speaker 4: Let's take the things that AWS is really good good
Speaker 4: at and make those really easy to use.
Speaker 1: Nice okay, And let's let's bring this closer to a
Speaker 1: developer actually wanting to use flight Control. What would be
Speaker 1: the situation we're talking about React developers here. So let's
Speaker 1: say that somebody's listening to this. They have started a
Speaker 1: React application and they just want to put it online,
Speaker 1: and they know that versall is an easy choice, netli
Speaker 1: fi is and is an easy choice when they hear
Speaker 1: AWS doesn't.
Speaker 2: Sound easy, How does in practice.
Speaker 1: Would look like for this developer to actually use flight
Speaker 1: Control to develop to deploy their application.
Speaker 4: So it's it's going to be almost exactly the same
Speaker 4: as versell or netleth i. You sign up, you connect
Speaker 4: your GitHub account, you also connect your AWS account. So
Speaker 4: that's the unique thing and then you know, you just
Speaker 4: define your command start command, or it might even be
Speaker 4: automatically detected. And we have like presets for different frameworks
Speaker 4: that you can just click and it'll deploy it. So
Speaker 4: you can deploy static site or you can deploy server database.
Speaker 4: So we really support the full breadth there. And but
Speaker 4: like why you know, if you're if you have a
Speaker 4: side project, you know, we have a free tier, but
Speaker 4: like you still have to pay for the a WS cost.
Speaker 4: The static sites are free, but if you pay, if
Speaker 4: it's a server, then there's still going to be a
Speaker 4: little bit of cost. So you're you're probably fine on
Speaker 4: on versell, but if you're building a real business, then
Speaker 4: why at WS becomes a really kind of important discussion.
Speaker 4: And reliability is one of the most one of the
Speaker 4: most big important things. So for example, uh, just this
Speaker 4: week I was refreshing our my kind of industry stats
Speaker 4: and our railway, Fly and Versell have all had like
Speaker 4: almost twice a number of incidents in the past ninety
Speaker 4: days as a as a one prior, so to give
Speaker 4: you some numbers, Fly has had thirty nine incidents in
Speaker 4: the past ninety days and Vercell has had twenty four
Speaker 4: incidents in the past ninety days, but AWS has had
Speaker 4: on the services that we support is zero. So there's
Speaker 4: just a huge difference on the reliability side. And this
Speaker 4: is because the traditional platforms have this whole custom layer
Speaker 4: of infrastructure that they have to manage and all their
Speaker 4: traffic is going through that, and so that that infrastructure
Speaker 4: has to support you know, millions and billions of request
Speaker 4: and it's really hard to build that level, you know,
Speaker 4: scale of software. But when you deploy through AW through
Speaker 4: Flight Control, we set up your dedicated infrastructure and so
Speaker 4: it sets up a cloud front, sets up servers, and
Speaker 4: it's only your traffic going through that. There's no custom
Speaker 4: stuff that's serving billions of users. Besides, you know what
Speaker 4: AWS does on the back end, but it's nearly flawless.
Speaker 2: Nice nice, Okay.
Speaker 1: So that means that besides creating my AWS account, Like
Speaker 1: after the account is created, I would let's say that
Speaker 1: I only need the abstractions that Control provides, right, like
Speaker 1: I don't need anything custom, then I would only need
Speaker 1: to create my AWS account and then I can close
Speaker 1: AWS and never open it again.
Speaker 4: Yes, if you need a uh some a WS billing stuff,
Speaker 4: then you can but we show you like the cost
Speaker 4: that you're paying AWS in our dashboard, we show you
Speaker 4: the logs. You know, we support the get pushed automated deployments,
Speaker 4: We support preview environments, so we support all the things
Speaker 4: that that you expect, you know, CP and memory charts
Speaker 4: and whatnot.
Speaker 2: Nice. Okay, Okay, that that got me.
Speaker 1: Yeah, So.
Speaker 6: I think my question is based on, like, how does
Speaker 6: flag control our system like deploying les obuside next year's applications,
Speaker 6: because I think that's usually like a very big issue
Speaker 6: for most people on days like to really deploy SSR
Speaker 6: applications next year. So I don't do like is it
Speaker 6: something that has been experienced or it's something that we
Speaker 6: flight controlso finds you into address.
Speaker 4: That's a spicy topic. So yes, we uh, many many
Speaker 4: people deployed next year as applications through flight Control, including ourselves.
Speaker 4: Our own application, our dashboard is next yea ass application
Speaker 4: with the app router. Unfortunately, it's one of the worst
Speaker 4: decisions I made in my career. We'd gotta be using remix.
Speaker 4: But uh and and in fact, I literally just published
Speaker 4: a blog perst today on the flight Control blog called
Speaker 4: the Secret Knowledge to Self hosting next JAS, and the
Speaker 4: reality is that next JAS when deploying to a server,
Speaker 4: so okay, moving back up. Deploying to server is the
Speaker 4: only officially supported way to deploy next JS. Outside for sell,
Speaker 4: there is a project called open next that helps you
Speaker 4: deploy serverlessly, but it's not officially supported by next, so
Speaker 4: you have to do a bunch of hacks or the
Speaker 4: open next to us. Also, deploying next to a server
Speaker 4: out of the box is not production ready unless you
Speaker 4: do not have a CDN. You only have one instance
Speaker 4: and you're not using image optimization. So for most people,
Speaker 4: there's a number of things that you have to do
Speaker 4: to be set your next GS application up to be
Speaker 4: production ready. And the blog that I published today at
Speaker 4: fleccontrol dot dev covers all the things that you need
Speaker 4: to do to make that production ready, and those are
Speaker 4: things that you have to do even when you need
Speaker 4: a pla going through flight Control because it's it's next
Speaker 4: year specific and it's in your coat. So one of those,
Speaker 4: for example, is like hooking up and adding a custom
Speaker 4: cash provider UH to rettus. Fle Control makes it easy
Speaker 4: to add the Rettus, but you still need to add
Speaker 4: that cash handler and your next chass can fig and
Speaker 4: so there's examples how to do that and whatnot. But
Speaker 4: so we do as much as we can, and the
Speaker 4: infrastructure that we that we set out fully supports that.
Speaker 4: We use cloud front for a CDN, which supports the
Speaker 4: stale WI revalidate header, which is important for next GS.
Speaker 4: Cloud Flare does not support that for example, And so
Speaker 4: deploying if you're going to deploy next gas outside brocell
Speaker 4: fleck control is one of the best ways to do
Speaker 4: that because of the infrastructure we create. That's really good.
Speaker 6: Actually, yeah, because I think that's usually been like a
Speaker 6: very big problem for so many days kind of like
Speaker 6: I know a lot of people like.
Speaker 2: Like, oh, next I can't.
Speaker 6: Deployed some the basis like a lot of people I
Speaker 6: know see next to those kind of vendor locked in
Speaker 6: like vendor like its kind of encourages this vendor lock
Speaker 6: to vessel kind of. So so most people that are
Speaker 6: building up people be like, oh, yeah, why don't we
Speaker 6: just use vessel. So I think since you have like
Speaker 6: an alternative for that using flight contos also deployed that
Speaker 6: that would really be awful and I think maybe to
Speaker 6: it to drive people from that whole dilement of time
Speaker 6: to deploy it on the using whatever means they do.
Speaker 4: Yeah, yes, yeah, we we often have people, you know,
Speaker 4: they hit the scaling limits on versail much much sooner
Speaker 4: than they think they hit the limits of the pro plan,
Speaker 4: and then they're paying one hundreds or thousands of dollars
Speaker 4: per month to versaill, which is ridiculous, and they'll switch
Speaker 4: the flight control and cut that, you know to a fraction.
Speaker 4: So it's maybe only twenty percent, maybe fifty percent. It
Speaker 4: kind of depends on you know, your unique set up there.
Speaker 4: But you can save a ton of money by using
Speaker 4: your own aws because you get rid of all those markups.
Speaker 2: Yeah, that's that's the one. Yeah, So look as you
Speaker 2: have any question, of course, I mean I could go
Speaker 2: on forever here. There's a lot of things, but I
Speaker 2: think that we were able to cover the most critical pieces.
Speaker 2: But Brendan, do tell me, is there anything that I
Speaker 2: haven't asked that you feel that is important enough that
Speaker 2: we should be talking about?
Speaker 4: I think I think I'll just talk about the thing
Speaker 4: that we that were the latest thing we shipped and
Speaker 4: the next thing we're working on. So the latest thing
Speaker 4: we shipped is a new build system, which is two
Speaker 4: to six x faster than any other build system on
Speaker 4: any other provider, and so this is a huge difference.
Speaker 4: So for example, you know the cow dot com web
Speaker 4: that takes around a seventeen minutes to deploy in verse,
Speaker 4: and it only takes about three minutes on the new
Speaker 4: Flight Control build system. And so if you have slow
Speaker 4: builds anywhere, like you might like fly Control because of
Speaker 4: this new build system. So we're super excited about that.
Speaker 4: And then the next big thing that we're going to
Speaker 4: be shipping is LAMB to support.
Speaker 2: And so.
Speaker 4: Right now Vercella is the only kind of managed platform
Speaker 4: that enables servilest next year as deployments, and so we're
Speaker 4: going to be adding support for Serverleist next year as
Speaker 4: deployments also, and then beyond that deploying LAMB as for
Speaker 4: any language, whether it's a web request or even triggers
Speaker 4: from like sqsques or databases or things like that, and
Speaker 4: so that's going to be exciting as well. So we
Speaker 4: really think that Servilest versus servers is not a one
Speaker 4: size fits all solution, Like each one has its own
Speaker 4: strengths and weaknesses, and you need to build to use
Speaker 4: both whenever the situation kind of requires it. And the
Speaker 4: problem is that a lot of these platforms only support
Speaker 4: one or the other, and so then you get a
Speaker 4: lot of this dogma and you know, propaganda about oh,
Speaker 4: like Servilis is the best or servers is the best, whatever,
Speaker 4: and it's just dumb because really you should have the
Speaker 4: ability on one single platform to choose from all the
Speaker 4: options and really do what works best for you.
Speaker 1: Yes, I completely agree with this. I don't think that
Speaker 1: serviles is the future necessarily. I think that in a sense. Sure,
Speaker 1: like it's different from what we had in the past,
Speaker 1: but it's not for everyone. It's not for all cases,
Speaker 1: and I think people are missing the pointing there. So nice, awesome, awesome, Okay,
Speaker 1: let's do Let's start wrapping up and do a few
Speaker 1: rounds of promos as well. So Chris, why don't you start?
Speaker 5: I I don't have much this week. I'll just point
Speaker 5: people to my blog, the criscrew dot I end. Actually yeah,
Speaker 5: I posted recently for one of my sass i rewrote
Speaker 5: I had a giant legacy dot net API, which I
Speaker 5: like dot net, but the way I grew the code
Speaker 5: base it became too much of a mess, and I
Speaker 5: just I rewrote the whole thing and go too much shorter,
Speaker 5: and it's it's so don't understand that the performance will
Speaker 5: go I think they're really doing magic behind the scenes,
Speaker 5: but it's way more performant than Yeah, it will be
Speaker 5: easier to maintain. So it's the blog post is about that,
Speaker 5: not really the rewrite, but more of like philosophy and
Speaker 5: like I also state that you, you know, so clean
Speaker 5: at the very beginning, because you just mean yet.
Speaker 4: Uh yeah, so.
Speaker 5: I guess post a link if my computer can keep
Speaker 5: up with me.
Speaker 1: Okay, your computer is definitely going kind of crazy, man,
Speaker 1: Like there were moments where your audio is like that.
Speaker 2: I can't even reference it. But I do hope that
Speaker 2: this goes.
Speaker 1: Live this way because it's way more funnier than just
Speaker 1: the regular audience. Yeah, and I had that with my
Speaker 1: my previous MacBook. It was Intel based and it would
Speaker 1: just go crazy doing during a few meetings. Yeah, I
Speaker 1: totally totally catch you, all right, man, So Peter, how
Speaker 1: about you?
Speaker 6: Yeah, So I just wanted to not really more do,
Speaker 6: I just wanted to weference, like because I woulte on
Speaker 6: educative more like you put on web components with leads.
Speaker 6: So I just kind of experimented with leads recently, and
Speaker 6: since I think there's been a kind of OPA for
Speaker 6: this open web as okay, see and try to use
Speaker 6: the native web and web components for so much.
Speaker 2: So I just said to just test with leads. So yeah,
Speaker 2: posted a link on ditch out. It's so yeah, I
Speaker 2: think that's just basically yeah, okay, cool.
Speaker 1: I've been hearing a lot about it, so perhaps we
Speaker 1: should talk about this eventually. I will send both of
Speaker 1: your lengths in the comment section, So for those of
Speaker 1: you that are watching from YouTube or any other place
Speaker 1: that has a comment section, then you should probably be
Speaker 1: getting those links.
Speaker 2: All right, So, Brendan, how about you?
Speaker 1: Like We of course talked about like and show, but
Speaker 1: anything specifically you would like to promote.
Speaker 4: Yeah, a couple of things. One is the Flight Control
Speaker 4: Engineering blog. It's mostly me writing on there, but I've
Speaker 4: gotten really good feedback on the article that I've been
Speaker 4: putting out around next jass type script type safety and
Speaker 4: things like this, so definitely definitely check that out. Fly
Speaker 4: control dot deav slash blog. And then I'll also wanted
Speaker 4: to promote the idea of being a pilot and flying
Speaker 4: your own small plane something I've been obsessed with since
Speaker 4: I was a kid, And so if anyone is interested
Speaker 4: in talking about that, you can find me on on
Speaker 4: socials and chat it up.
Speaker 2: Oh, so do you talk a bit about that?
Speaker 1: Like you said, if anyone wants to know more about that,
Speaker 1: they should hit you up. But what can they expect
Speaker 1: from talking to you about this? Like were you able
Speaker 1: to accomplish this?
Speaker 2: This go?
Speaker 3: Like?
Speaker 2: Are you officially a pilot? Are you in the middle
Speaker 2: of the process?
Speaker 4: How does that I started my training when I was
Speaker 4: fifteen years old and got my license when I as
Speaker 4: soon as I turned seventeen, I was just a minimum age.
Speaker 4: So I've been been flying for a long time and
Speaker 4: it's an absolute blast. Like just if it makes you
Speaker 4: feel like a bird, just a level of freedom you
Speaker 4: can just I need to go to the airport and
Speaker 4: get on my plane and go fly anywhere I want
Speaker 4: the States.
Speaker 1: That's so cool, Like, okay, that there are two there
Speaker 1: are two levels of of nice things about what you said.
Speaker 1: So the first one is being a pilot and being
Speaker 1: able to fly, and the second is you say I
Speaker 1: can just go to a to my plane.
Speaker 2: And I don't think that everyone could purchase a plane.
Speaker 1: But maybe there's another that's another myth, Like is that
Speaker 1: something that we can debunk quickly here, Like, yeah, how
Speaker 1: would it cost for someone to have a popular plane?
Speaker 4: Almost everyone can learn to fly a plane. It's not hard. Uh,
Speaker 4: it only takes about forty hours of training, so it's
Speaker 4: not super expensive either. Also, you can own a plane.
Speaker 4: You can buy a plane. That's super than a car.
Speaker 4: So you know, I drove a junker car for a
Speaker 4: long time so that I can buy a plane. It's
Speaker 4: junk cars are totally fine. You don't need a forty
Speaker 4: thousand dollars car. You can get a forty thousand dollars
Speaker 4: plane or even cheaper than that.
Speaker 1: So forty thousand dollars I can get a semi decent plane.
Speaker 4: Yeah, you can like pointy to in the twenty starting
Speaker 4: at like twenty thousand. That's probably where the planes start.
Speaker 4: But you can also do shares, so you you know,
Speaker 4: buy a plane with a few other people. That is
Speaker 4: also common. But if you don't have a plane, you
Speaker 4: can always rent and it's just on an hourly basis,
Speaker 4: and so that's really affordable and no commitment. You can
Speaker 4: just fly as much as you want on an hourly basis.
Speaker 1: Interesting, Okay, okay, what is the regular hourly basis to
Speaker 1: rent a plane?
Speaker 4: It's I'm going to say one hundred and fifty dollars
Speaker 4: an hour. It varies on location, but approximately that and
Speaker 4: that includes gas.
Speaker 2: Okay, that's that's pretty fine. So that's a reasonable number. Yeah, okay.
Speaker 1: Like the thing that scares me about just having a
Speaker 1: send me like a nice plane but not like a
Speaker 1: super top one, is that.
Speaker 2: I mean, it's a plane you don't want to fall,
Speaker 2: you know, it's different than a car. It's like, oh,
Speaker 2: if it's not working one hundred, that's fine, Like I
Speaker 2: can even push it a bit. But if I have
Speaker 2: to push a plane, then I don't think I'm gonna
Speaker 2: be able to tell that story. So that that part.
Speaker 4: They all planes, no matter you know, how much the
Speaker 4: costs are or what they are, require annual inspections or
Speaker 4: even more often, and so they go to this rigorous
Speaker 4: inspection process to make sure that they're actually airworthy. So
Speaker 4: that that's part of the deal. Secondly, if your engine quits,
Speaker 4: it just turns into a glider and you can just
Speaker 4: glide down and land on airport or a field or
Speaker 4: road or anything. It's no big deal. And so it's
Speaker 4: also significantly significantly safer than driving in a car. You're
Speaker 4: more likely to die in a car driving to the
Speaker 4: airport than flying your plane.
Speaker 1: Okay, still the idea that, ah, the engine would stop
Speaker 1: and I would just have to glide until I find land,
Speaker 1: it's a bit terrifying, but yeah, okay.
Speaker 4: That's it's something you cover in training, you practice it,
Speaker 4: it becomes just normal, so it becomes a non event
Speaker 4: some so you definitely train for all the things that
Speaker 4: can happen. So it's it's a good it's a good
Speaker 4: fun process. On it involves your your mind. There's a
Speaker 4: lot of like regulations and navigation and things, so that's
Speaker 4: kind of and systems fun to learn. And then it's
Speaker 4: also skills the actual skill of flying. So it's a
Speaker 4: good kind of holistic activity.
Speaker 2: That not.
Speaker 1: Okay, all right, that that's very interesting, Like you definitely
Speaker 1: got me interested about that, And that explains the name
Speaker 1: of the company. So now knowing that the company is
Speaker 1: like control that that that makes a lot of sense. Okay, Well,
Speaker 1: on my end, I'm just going to promote the two
Speaker 1: companies that produce the show.
Speaker 2: So Top and Downs if very interested in other shows,
Speaker 2: not just react related.
Speaker 1: And Onvoid is U n v O I D dot
Speaker 1: com and the I'm actually the founder of onvoid, so
Speaker 1: that's why I also speak about it that much. And
Speaker 1: we created a business model that is very different from
Speaker 1: what other traditional software agencies provide.
Speaker 2: We actually only charge clients after the tasks are delivered
Speaker 2: and approved, and that's just so.
Speaker 1: Much more client friendly because every single company complains that
Speaker 1: when they hire outsource developers or our designers, they have
Speaker 1: to pay by the hour and they never know how
Speaker 1: much is it going to take, and if something takes
Speaker 1: longer than expected, sometimes there's the feeling that like, oh,
Speaker 1: that's actually because the professional that are hired maybe is
Speaker 1: not good enough. But then the company ends up having.
Speaker 2: To pay for that. So it's just this really weird situation,
Speaker 2: you know.
Speaker 1: And we fixed all those problems by bringing them to
Speaker 1: our side, so the problems to exist, it's just that
Speaker 1: we make it very client friendly and all the complexities
Speaker 1: are leaned towards us. So we estimate the effort of
Speaker 1: tasks beforehand, and we present that to the client and
Speaker 1: we only start to work once they approved, so they
Speaker 1: already know beforehand how much each individual task is going
Speaker 1: to cost and we only get paid by our work
Speaker 1: after it's delivered and approved, So even after delivery, the
Speaker 1: client can still do quality assurance before they say that
Speaker 1: the work is actually approved. So it's a really interesting
Speaker 1: and very client friendly business model, and it's so much
Speaker 1: that we are actually having to choose our clients because
Speaker 1: we can't really say yes to our companies just because of.
Speaker 2: Human resources available. So it's a really good position to
Speaker 2: be in.
Speaker 1: Well, so that's it if you're interested U n v
Speaker 1: O I D dot com BOYD. That's a thank you
Speaker 1: for sticking up until the end.
Speaker 2: That was a really interesting episode and I will see
Speaker 2: you in the next one.