Brandon:
Hi there and welcome to Pod Rocket. I'm your host Paul, and today we're joined with Brandon Bayer. Brandon, you're the CEO and creator of Flight Control. You made Blitz JS, and you've been on Pod Rocket before. You were on Pod Rocket twice and we're going to be going over flight control, this great system that you made and talking about Blitz JS and what's new in the web development ecosystem. Welcome to the podcast.
Thank you very much. You have lovely words to say. Thank you very much.

Paul:
You made a lovely thing, man. Preparing for the interview is like, I've never used Flight Control. What is this thing? What does it do? Why do I want to use it? Going through the YouTube motions of watching other people's videos and learning about it. And we have an interesting thing to talk about here. Like I had noted, we talked about flight control before in Pod Rocket. If you want to go into the basic details, you can go check out that episode. But really quickly starting off, if people are fresh on this episode, Brandon, what is Flight Control?

Brandon:
It all started back whenever, a few years ago. I love the developer experience of Vercel, for deploying applications, but I kept running into these various limitations and I wanted to use some AWS services like SQS, or just needed some more control. And I was like, "Why can't we have the good developer experience and full control and ownership on my own AWS account?" And that was the genesis that really got this ball going. It was a year and a half after that I think, or maybe two years until we actually started the company to solve that problem. But that is what it is. Flight Control gives you the deployment experience of Vercel or Heroku, but without the limitations because it is on your own AWS account where you have full control and scalability.

Paul:
That wrapped the idea up in a really nice present in 30 seconds. That was awesome. And I can say coming from somebody who spent their first two years in the tech world, being in DevOps SRE, the thought of having control over your resources is profound. That's huge. And thinking, "Oh, I'm going to write this little JS something, throw it up into Vercel and it's going to run fantastic." That's great. But the unknown is what scares, I think a lot of production teams, it's like, "What happens when X happens? What happens when we get to Y scale?" And it's like that's when having control of your resources is just huge. And you might need a proprietary solution. You don't know. Flight Control, I guess, gives you the ability to make that decision.

Brandon:
The metaphor is that these traditional platform as a service providers are like Fisher Price toys. They're safe, easy, and fun, but rarely found in a large workplace. And what we need instead is a modern flight control system that mostly flies itself but exposes everything you need to understand the system and override it when you need to.

Paul:
I love that analogy. That's why it's called Flight Control. It puts meaning to the name, which helps define the product in itself. That's neat. Thanks for that little tidbit. You started Y Combinator, you're a Y Combinator group, right? Was that a fun experience? Stressful experience? People say so many different things about Y Combinator. What was your takeaway away? Do you think it really helped propel you to that next stage of growth?

Brandon:
It had a massive impact on us because I don't have a FANG background. I didn't come from Facebook, or Google, or whatever. I grew up in the cornfields of Ohio. And when I went to raise funding, it was very difficult. And after three months, I still didn't really have anything to show for it. And we'd basically given up at that point, until we got an email one day from Y Combinator saying, "Hey, we want you to interview on Wednesday." And I was like, "Oh, I had forgot that I had even applied to YC." And we ended up, went through the 10 minute interview and got accepted and that was the coolest thing in the world, but it had a massive impact because within a week of getting accepted, we'd already raised a million dollars. It just was flipping a switch. All of a sudden now you have that YC brand and investors are like, "Oh, we want in too."

Paul:
Was that your first time that you got accepted or did you try prior before?

Brandon:
This was the third idea I had applied with for the first time I got accepted.

Paul:
Were the other ideas AWS and DevOpsy?

Brandon:
No.

Paul:
No? Okay.

Brandon:
Totally random stuff that I would never expect to get into YC in a million years.

Paul:
Brandon, you're also the creator of Bliss JS, which is, it goes hand in hand with Flight Control, we could say, but their not the same thing. Bliss JS is your thing and Flight Control is, you embarked on that with a partner of yours, right?

Brandon:
Correct.

Paul:
What is Blitz JS and how did that lead you into the flight control saga of life?

Brandon:
I've always been working towards having my own software company, but on that journey I became an independent freelancer building applications for clients. And it was during that process of building these new things that I really missed the developer experience of Ruby on Rails in the JavaScript ecosystem. And that's what led me to having this idea to start Blitz, even though it wasn't a business and it was a detour from what I was wanting to do, but I could just feel like the impact that it could have, and I just went all in on it. And it was through that, that I realized that I really like working on developer tools and I'm really good at developer experience and marketing developer tools.

Paul:
A developer tool, Blitz JS you would market as a developer tool. What does this tool aim to help builders build?

Brandon:
It helps you build full stack applications with Next.js in a 10th of the time that you would from piecing everything together from scratch.

Paul:
Because Next is already marketed as the fast thing.

Brandon:
It takes Next.js and superpowers it. Next.js does a lot of cool stuff, but it's still quite minimal. It doesn't have authentication, it doesn't have anything to help you around API layer. There's no code generation. It's just very bare bones to actually build a real application. And whenever you generate a new Blitz app, there's multiple things that you can select the options, but basically it sets everything up for you from the database to the front end, including authentication. Immediately you can sign up as a user, log in, log out, et cetera. That's all set up for you out of the box. And you have a full stack API layer, which we call Blitz RPC. TRPC has gotten some popularity recently and that was really created as inspiration from Blitz RPC. So TRPC is a generic thing, but Blitz RPC is more tailored to Next.js. And if you're using Next.js, you get a really, really incredible developer experience with this. You don't have to use REST or GraphQL and you still get that full stack API layer and static type safety.

Paul:
And when you say Blitz's version of RPC here, RPC is a different communication protocol that's built on top of HTTP and that stands for, is it?

Brandon:
Remote Procedure Call. It basically just means like, "Hey, I'm going to run a function somewhere else on another machine. I'm going to send some input to that function and get some output. And it can be over HTTP, it can be over really anything, but in this case it is HTTP and it's just like a JSON:API in this certain format.

Paul:
Gotcha. Okay. You're talking about a lot of the API layer here. Gluing together authentication, a lot of that revolves around choosing the library you want to use, integrating that library correctly, and then writing the boiler plate. Could I make a fair argument to say that Blitz JS is removing a 10th at a time by choosing libraries, writing boiler plate, and having a bit of opinion, because this reminds me of Django, when I get Django out of the box, I get user management, I get that database layer, there is an opinion, but once you get it, you can fly through an app in eight hours.

Brandon:
Yes, you perfectly described it. And what I do like to say is that even though there's some opinions of some defaults, you can override those. And Blitz is very flexible in that way. It doesn't require things. We have opinions, but then you can easily change them.

Paul:
We just did an episode of super tokens. They do your custom oth, password list. Could I plug that into Blitz as my off layer, middleware?

Brandon:
Even better, our authentication system was designed by one of the founders of super tokens.

Paul:
Oh, wild. Okay.
Go figure.

Brandon:
It has some of the same things built into it, but yeah, it's self hosted. You don't have to use a separate server for it.

Paul:
Awesome. Looking back at Flight Control, if I made a Blitz app, is Flight Control cowtowing to people who make Blitz apps? We're perfect for you. If you make a Blitz app and use Flight Control, it's hands shaky, everything. There's defaults you can expect, there's jists I can maybe find to deploy, or is that level of handholding there for any framework use of flight control?

Brandon:
Flight control is a really great experience for deploying anything. That's the foundation point. It's really great for anything. And then for Next.js apps, which includes Blitz apps, we have some customization, some optimizations that make incremental static regeneration work and things like this that are the more advanced features of Next.js that just work on Vercel but are really, really hard to get working correctly on AWS. And we solve that as well.

Paul:
You just touched upon a really interesting topic right here. It's the static incremental generation. I would wager that as one of these items. What are some more items that you think developers struggle with in a traditional modern web deployment that you tried to solve for with Flight Control?

Brandon:
If you're using a platform as a service, most of the problems are solved. There's a lot of platforms that have really great developer experience. Where things fall down is when you want that developer experience and more control. For example, if you're on a platform as a service, you have the good developer experience, but you don't have control. If you're on AWS, you have that control, but you have a terrible developer experience, you're writing Terraform scripts, and CDK, and who knows what, but you're not getting that level of developer experience. And that's what we're working to combine.

Paul:
And that's maybe where it really breaks down is to deploy a Next.js app with these modern attributes and features, you need to know Terraform, you need to understand these different, well you don't need to, but in order to make it a sane way to live and maintain your app, you need to have some deployment strategy. You need to be a solutions architect in addition to being a web developer.

Brandon:
Yes, if you need that control, which a lot of companies do, or do at some point. Yeah, one trap people get into is they launch their company on Heroku or whatever and then eventually they reach a point of scale where they have to migrate out to AWS because it's too expensive or they need that level of control. And that can be a very, very expensive, time consuming migration process. And we're like, "Well that's dumb." You should just start on AWS, get the good developer experience and then you can stay there on AWS and Flight Control forever.

Paul:
Right. And where do you think that scale gets hit? What level does that scale crop up at? It's hard for me to wrap my head around that.

Brandon:
There's a number of different things. On Vercel, they have a massive markup over AWS Lambda. And if you're doing a bunch of service side processing on Vercel, you're going to very, very quickly hit their enterprise plane, which starts at I think is $36,000 per year. And for that level of plan on Vercel on AWS plus Flight Control, it's going to be maybe $300 a month or something. That is one level. It depends on the control and things you need.
One problem these platform as a service providers have is that they have a custom layer of infrastructure over top of AWS, or GCP, or whatever it is, and all their customers are going through that infrastructure. And their infrastructure has to serve a massive amount of scale. But the difference is if you're on AWS, you have your own custom infrastructure that no one else's stuff is going through. And you have more reliability issues and things at scale with platform as a service versus your own AWS.

Paul:
That markup is insane. To put that in a perspective, even if we're talking about $500 of function in vacations a month, if we were to boil that down to CPU cycles on a nook under your bed, I'm pretty sure you could do that for $50 for the rest of your life. And when you put that into your perspective of like, "Okay..." I understand it comes up a lot of protections and reliability and all that, but when you think about the markup you're paying on some of these platform as a services, it makes me cry like I'm cutting an onion. That's crazy how fast you will hit that enterprise plan from running a dinky app. Do you find that a lot of people come into Flight Control from a Heroku background because of the demographic of teams that Flight Control is apt towards?

Brandon:
We really have a strong pool from both sides of the market. The people that are on the Heroku's of the world but need more control, want more power features. That's part of it. And then we also get a strong pool from people who are AWS experts who have been managing their own Kubernetes clusters and they're realizing it's not worth, it's too much effort, we need a better developer experience. And it feels like we have a really good abstraction because we're solving these diverse use cases with the one single thing.

Paul:
When people move into Flight Control, do you usually find to be a seamless experience? Or what is the number one area that people are usually like, "Okay, I have to change in architecture," or do people need a change in architecture?

Brandon:
Most of the time people can just migrate seamlessly without any problems and most of our customers have migrated existing production applications and we actually offer free migration assistance for people doing that. One thing is we don't yet support serverless functions or any of the fully serverless stuff. We will. If you need that right now, you might have to change to run a traditional server, but a Next.js app... On Flight Control right now it runs using Next Start. And there's benefits to this because you don't have the Cold Start issue with the Lambda's and all of that, but our philosophy is like, "Hey, people, developers need control over how they deploy stuff and being able to choose between the trade-offs themselves instead of us making those trade-offs for them." And we're going to support everything and let you choose of, "Do you want to deploy the server or do you want to use serverless?"

Paul:
Which way do you lean Brandon? If we step aside from Flight Control. Because I feel like serverless is easily the go-to for a lot of people, but there's a lot of arguments to be made for the server deployment.

Brandon:
So much depends on your use case, and the business requirements, and the level of usage. For example, if you have a really low traffic application then it's going to be way cheaper on serverless because it's not standing there running while nobody's using it. But if you have a consistent level of traffic, then a server is probably going to be better because you don't have the Cold Start issue for serving the direct traffic. Another place a serverless is really good for is just handling events, spontaneous things like background processing, because in those cases you don't care about Cold Start, it's not serving a user request. Let's say you check out, you make an order, and then that triggers a Lambda function that sends a shipment, or updates an inventory, or whatever. That's a perfect use case for serverless that can scale really well.

Paul:
It's almost like a passing function.

Brandon:
Yeah.

Paul:
A hook function, yeah.

Brandon:
And then also, but if you have a massive amount of traffic going through a serverless function, you're going to be cheaper on a server. A serverless function is actually more expensive for the CPU and memory time than a long-running server. It depends on that crossover of your utilization of how much are you using on a server versus if you have a bunch of empty capacity, unused capacity, then serverless function is probably better.

Paul:
It's like we're taking an economics class here, it's some supply and demand curves about how much we want the CPU and how much utilization you're getting out of it. Brandon, I'm curious since we're talking a little bit about architecture and the way we might put together an application, let's say we hang up and you want to go make a cute cat app or something, what technologies are you reaching for in 2023? Fire ship put out their technology's a 2023 video. I'm curious what's going through Brendan Bayer's head right now.

Brandon:
It would definitely be run Blitz new in my terminal and then I'd be ready to start building.

Paul:
One answer.

Brandon:
Yep.

Paul:
It's one thing. He'd run blitz and he is done.

Brandon:
Yup.

Paul:
If you are looking forward to 2023 on the Flight Control side, what are you folks looking forward to building that you can tell the public about right now?

Brandon:
We've had an explosion of growth these past several months and we've proved that we're basically getting into product market fit. And now we're taking a step back and we're addressing tech that we're redoing some of the systems that we need to provide a much better developer experience. We're working on filling in holes, polishing things and just really, really improving what we have now. The problem that a lot of companies get into is that they ship stuff that's like, "Oh, it's decent right?" But then they just want to keep expanding, adding new and new features, and they never go back and actually really improve and polish what they have. And we're in that phase now of just really polishing and we're not expanding any new features at the moment. But once we finish this phase, then the next thing that we'll be moving into is serverless support, like serverless functions.

Paul:
I think that puts a lot of confidence in me as a developer because I'm like, "Okay, the team who's making this thing that is my Flight Control, they're making sure the buttons don't stick and the switches don't fall off if I smack it if I'm really mad." Those types of things. It's going to give me confidence that it's not going to go off the rails, so to speak later on. What's one of the areas, being in the Y Combinator, "Oh, we're a startup, we're moving so fast, we got product fit," that is so exciting. That must feel like you found your calling for the next decade. You're going to make some cool stuff. What's one of the things that maybe you glossed over that you're going back now and you're just like, "Wow, I can't believe we went so long and it's so good we're looking at this right now."

Brandon:
Yeah, as I found, there's no choice but to grow, or get left behind, or get ran over is more like it. I learned so much about just how to be a good manager, how to hire well. We're still learning on proving our engineering, how to work together as a team really, really efficiently. Not just at haphazardly, but how can we really optimize everything that we do through communication, and testing, and shipping, and all of that.

Paul:
It sounds like it's in addition to the tech stack and filling in tech debt, you're filling in person personnel debt, you're really fine tuning the way your company runs. You're making sure that your teams are effective and going through these motions right now. That sounds like a really big growing period for your group.

Brandon:
Culture and associated things is really everything. You can have a bunch of absolute geniuses in the room, but if you don't have a good culture, and good structure, and leadership around that, you're not going anywhere.

Paul:
On the podcast notes we have this little section, I was like, "Okay, I'm going to ask Brandon to go into... We'll go one or two features about things that are coming in 2023." And it's interesting that you said, "Okay, we're actually fine tuning, we're tidying our screws and greasing things up." And that makes me think, "Okay, we're not going to go over a new technical feature you guys are working on." I wonder what's a new maybe way of organization or way that teams work that you guys have been working on, I guess. And to formalize that question, is there a way that you reorganize your team in the way that you organize work that maybe you didn't expect to end up working right now? Because everybody instantly reaches for a Trello, or scrum, a two week sprint, and then every time you work in a team it always manifests a little differently. During this process, did you have any cool takeaways where you're like, "I didn't expect we'd work this way, now we're doing it this and this way and it's great."

Brandon:
We started out where basically for the most part we've had an engineering team of three we'll call it. And each person was off in their corner working on some isolated thing and there wasn't that much communication and collaboration between them. It was more split things apart and then everybody would go their separate ways and work on it and then come back later. And we read this blog post by Swisick about basically high performing teams and it really changed the way that we work together. And now instead of everyone being in their separate corners, we're actually treating it like a team. And everyone is together, working very closely together on the things. And you have a much higher team morale and cohesion because you actually feel like you're working on something with someone else. There's just a lot more intense collaboration and it results in a better product and just a better work experience.

Paul:
Do you feel like you guys are more in a tiny WeWork table room now versus in separate offices around the world doing your own thing?

Brandon:
Yeah, I think so. Even though we are fully remote.

Paul:
If somebody wanted to try out Flight Control, they're hearing what you're saying Brandon, they're really into it. AWS, they log into AWS, is that something I can just go through their UI and hook myself up with?

Brandon:
I would just start with flightcontrol.dev, and you just sign up there, and you walk through the process, and there'll be a button to either create a new AWS account or connect an existing one. And then you link your AWS account to Flight Control with, it's just a one button click and it gives our account access to yours.

Paul:
Can I expect to use a UI, a CLI? The AWS console CLI thing?

Brandon:
We provide both configuration through our dashboard where you can find your build command, your start command, you can add a database, you can add Redis, you can add static site and private workers. You can do that through our dashboard or you can use our infrastructure as code feature, which most commonly known as flightcontrol.json. And you have that flexibility whether you want the point and click or you want infrastructure as code.

Paul:
Awesome. Start with flightcontrol.dev. They'll walk you through it. One last technicality that I'd love to jump into the podcast because we don't have unlimited time here, but I think one of the coolest things that you guys do is use temporal for your backend. And we haven't gone too much into temporal on the Pod Rocket podcast, but I'd love to pick your brain for a sec, Brandon, and just ask what has been your experience using this backend, this framework? Do you self host it? Do you use the Cloud? How long did it take you to integrate with it? And what are your immediate takeaways about this behemoth powering your company?

Brandon:
Temporal is amazing. It is what you call a Workflow Orchestration Engine. And it came out of Uber. Uber created it. It was an open source project and now there's a company around it, and essentially it's an abstraction over top of queues, crime jobs, and scheduled jobs. It's almost like react for the backend is one way to think about it, and another way is that, you know the difference between... It changed how we wrote code when we went from callbacks to promises and async await, specifically, async await allows you to just write code that looks synchronous, but it's actually asynchronous.
That is how it feels writing Temporal. Instead of dispatching some queue and some scheduled thing, instead of that, you just write code where it feels synchronous and it's actually asynchronous. For example, in your code you could sleep for a day or 30 days, and after that sleeping period, the code after that will run on some other machine, maybe. You don't know where. And it's this really, really powerful way to manage these things. You get really great observability, really great reliability and robustness, and it's perfect for wrangling the complexity of deployments to AWS.

Paul:
And it allows you to really be discreet about every life cycle hook, and plan out a very stable system for us to use. When users interact with Flight Control, I'm just curious, for my own selfish wants here, do you run a separate Temporal name space for every customer or do you have one big cluster that you just have some masterful orchestration over?

Brandon:
We are using Temporal Cloud, and we just have one name space, but then we have many different workflows. We have a workflow for a deployment, a workflow for creating a project and things. A deployment workflow would have... It would be named something like deployment dash deployment id, dash, maybe something else. Those work really well. We were just looking at the metrics and we've passed over a million events or activity, a million things in Temporal.

Paul:
Yeah, it's such an interesting new way to code. Do you think that Temporal, and I think your specific use case is so cool because you're using it for deployment in DevOps, and it makes me wonder, is Temporal coming for Terraform and big organizations?

Brandon:
No. Because Terraform is like an infrastructure thing. Temporal is not infrastructure. Temporal is code and business logic. And it just happens for us that our business logic deals with infrastructure. But for anyone using Terraform to manage infrastructure... If you want code, you'd be using CDK instead of Temporal.

Paul:
Gotcha. Different lanes.

Brandon:
Yes.

Paul:
I just think your use case is really interesting because deployments inherently are very event driven, but there are a lot of other tool. You get actions, you get all these integrations that it's almost like why would you use a company implement your own hooks and stuff if it already exists out of the box? It is just an interesting use case that you guys are really orchestrating several different deployment environments using business logic. But I guess, hey, you need business logic for that level of complexity. Awesome use case for Temporal. Well Brandon, thank you for your time coming on. If people wanted to learn more about what's happening with Flight Control as you guys are maybe rolling out updates, is there a Twitter that people should look to?

Brandon:
Yeah, my Twitter is most active. It's Fly Bayer, F L Y B A Y E R. There's also Flight Control HQ for the Flight Control Twitter. Yeah, I think that's most of that.

Paul:
That's it. And then flightcontrol.dev, obviously you already mentioned that, people should check there for updates. And then there's the Blitz.js GitHub, and the Flight Control resources out there. You can go to the releases and look at... Wasn't it last fall, Blitz.js just came out with this huge 2.0.0 update, which unfortunately we didn't get time to go into too much today. But go check that out if you want to see the updates on Brandon's own framework.

Brandon:
Yeah, and if you would like free Blitz and Flight Control stickers, go to blitzjs.com/stickers and you can put in your address and we'll ship you free stickers anywhere in the world.

Paul:
Oh, that's where I'm going. I love stickers on my laptop. Let's do that. Brandon, thank you for your time again.

Brandon:
You are welcome. Thank you.