Start-up Phase Summary

[00:00:00]
>> Erik Reinert: Through what did we change? We added a docker file. Like I said, that's literally all we did. We made sure that the application ran, we tested it, but we only really added a docker file as our change. Everything else we did was in the cloud. Everything else we did through navigating through the ui, clicking stuff around, we did it all in the cloud.

[00:00:23]
Again, a note here is that this change made us heavily dependent on vendor based solutions, right? We're using supabase for our database, we're using Amazon for the parameter store and ECR and blah blah, blah, right? So we're definitely like heavily vendor locked in right now. But again, we're also solving the problems that we're trying to solve.

[00:00:45]
What are the pros? Well, for starters, this is a turnkey environment. It really is in pretty much every aspect of the word. Sure, you had to set some stuff up, but. But the reality of it is 99% of the work you just did was in the browser. Clicking around, copying things, configuring things.

[00:01:02]
You didn't have to learn Terraform or have more blockers to get you to where you were trying to be. You basically just did all of the work in the browser. They're easy deployments. You guys got within. Once you got it successfully working, that is, you got really comfortable very quickly with managing it going in, in making a parameter change, save and deploy, push an image, same thing.

[00:01:31]
If you want to, I would recommend making a change to the docker file. Make a build and push and then see if it triggers a build. You should, you should see it trigger a deployment to production. Meaning that basically you'll automatically update your deployment or your service whenever you push an image.

[00:01:48]
So whenever you push that latest tag, you'll get a deployment triggered. And then whenever you want to make a configuration change, you'll just go to ssm, update that and then click, you know, rebuild basically and it'll deploy those changes. So you have the ability to not just get a turnkey environment, but you have an ability to easily update it, to keep moving with it.

[00:02:07]
And again, if you're a single person, you know, one person team. That's nice. Like, that's really, you know, I'm sure you can kind of see the process here and how you write some code. Write some code. Okay. Deploy, so forth and so on. Yeah.
>> Speaker 2: So how would you set up where you would have like a, let's say production branch in GitHub and when you commit or like do a pull request, then it kicks off this deployment.

[00:02:33]
>> Erik Reinert: Yeah. So if you were to say, all right, I just want to stay in this phase. I don't want to go to other phases. Because to be fair, we do that in another phase, right? What I would say is you would just create new SSM parameters for that new service.

[00:02:48]
You would create a new database in Supabase for the database, and then you'd create a new app, but you would tell it to track a different branch or a different tag. So latest would go to production and then dev would go to your other one. The real separator for each environment in this scenario is just the little image tag.

[00:03:12]
You can tell if we go back here just to show visually, you could see that my source is latest right here. So if I told another app to run off of dev, and then when I merge to dev, I only push to that dev tag, then I have releases to dev every time I merge to main.

[00:03:35]
And then if I just create a new branch called prod, and then tell it to build just the latest image and push to that, then if I merge into Prod, I have deployments to produce. Does that make sense? Yeah. And then, there you go. All you need is.

[00:03:51]
Yeah.
>> Speaker 2: And then in this scenario, you're charged based on, like CPU utilize.
>> Erik Reinert: Yeah.
>> Speaker 2: What is the actual billing model under the hood of this?
>> Erik Reinert: So what's really cool about this is like it kind of incorporates everything into one, right? So you're paying for the CPU cost, right.

[00:04:12]
You'll be paying for a little bit of bandwidth, but more than likely the main overhead here would probably just be CPU. Yeah. And you're paying for that, like you would a like per minute model. So it's like a very small, like pennies per minute, basically model that I would imagine.

[00:04:30]
I don't know the exact cost. Like, I can do this AWS calc app runner. So let's see here. If we go here. And if you're curious about like costs and stuff like that, you can use this as a way to do it. So there you go. App runner configure.

[00:04:51]
So we said 0.255 auto scaling concurrency. We set 200 minimum enter numbers of hours per day. I would say, maybe like 8. I guess, if you've got like a full day's worth of traffic, right? Probably you would not be at 100 requests per second. You'd probably be like 10, requests per during peak off, like one, right?

[00:05:18]
So there you go. It'd probably be around 12 to $14 to host it a month, right? It'll auto-scale. It'll self-heal, right? You have a complete deployment process, right, for like 12 bucks a month.
>> Speaker 3: [COUGH] This doesn't include the database, right?
>> Erik Reinert: No, but it's free for now.

[00:05:41]
It's free, right? Lean on those free plans as much as you can, right? And so that's what I would recommend. You know, it's like if Supabase lets you create two free databases, do it. Right. Actually, thank you for asking that, because you don't get that with rds. With rds, you're going to pay for the database right out of the box.

[00:06:01]
That's another reason why I took this approach. Again, Mark, I remember you asking me why Supabase? That's exactly why. Because in this deployment, in this model, I can literally start from zero free plan across the board. This would be a part of it. You do get free plan stuff.

[00:06:18]
I would imagine that you'll probably get some of this off even. But yeah, realistically, your database is free until you get to a point where you need more. And then your application running in the cloud would be like 12 bucks a month, basically. Again, it's not just that you have an application running in the cloud, but you have an application in the cloud with logs and metrics and scalability and SSL and everything else underneath the hood.

[00:06:49]
That's the turnkey environment you get, right? That's the turnkey environment you get if you're in the startup scenario. Again, it's horizontally scalable. We told it. Hey, these are the requests per second I want you to track. And this is when I want you to scale. So you have complete control over how often you want to scale, when you want to scale.

[00:07:07]
And it has basic monitoring into it. Is it crazy monitoring? No, but it'll get you through the door. It'll at least help. Cool. Awesome. So, yeah. So, you know, what are the cons to this? There, There are quite a bit. You know, there are some downsides. As always, the.

[00:07:26]
The four cons that I tried to note or note out here are no reproducibility. Again, we all had to have like notepads open. That's what I meant by the pain was literal. [LAUGH] That's why I meant by like, I literally. I knew it was going to be slightly annoying and a little bit more cumbersome to do this part, but because I can't just give you code and say, run it right, this is you going through the process of having to create this and do this manually.

[00:07:50]
And the reality of it is you don't really have a lot of reproducibility with that, you're gonna have to remember everything and redo these things by memory rather than having code to do it. Not a lot of extensibility either. Now, granted, we are an Amazon, so if we decided we wanted our app to start using S3 or SQS or all that other stuff, we can.

[00:08:13]
That's awesome. We're kind of out of the box with that. But the actual way that the service is deployed and how that's managed, we don't really have a lot of control around. App Runner takes care of all of that. We can't change how the logs show or things like that.

[00:08:30]
There's no real extensibility or things that we can change there. I said no automation. But what I mean by that is just, again, there's nothing here that's helping you do this process. You're pretty much doing it manually, you know, and that means that when you want to push an image, you're going to build that image yourself manually.

[00:08:49]
You're going to push that image yourself manually. There's no like CI process involved in this solution. Right. But the expectation here is, is that you would be working as like a single person, again, you know, by yourself. So you don't. You may not really need any of that stuff.

[00:09:04]
Right. And then again, multiple vendor lock ins, aws, supabase, right? You're kind of really putting yourself. And I would say this, when you do multiple vendor lock ins versus singular lock in, it becomes even more challenging, right? Because then you got to figure out why Amazon isn't talking to Supabase and blah, blah, blah, and you know, versus just having everything in your own VPC and stuff like that, you have, you know, a little bit more of like, leeway of like, okay, well, at least no it's in my network so I don't have to worry about it, you know, and stuff like that.

[00:09:37]
Cool. Okay. So we got through the first phase. We got through the first phase. That was the startup phase. And if anything, again, it was really meant to kind of exemplify what it feels like to be in that phase. Like really dirty, just moving, trying to get stuff up and running, debugging on the fly.

[00:09:59]
It's funny, somebody said in chat this is the DevOps experience, but yeah, you did. You really got the feeling of a startup phase environment. That is it showing to people. I don't know. Let me debug. Okay, cool. Green, all good to go, whatever. And you could kind of see why you wouldn't be able to go fast in that scenario, right?

[00:10:20]
Like, if you have to constantly be clicking things yourself manually and doing all this other stuff, you wouldn't really be able to do that. And so that's what will impede your growth. Like, that's what will stop you from being able to grow as a software company or application, whatever you're trying to grow or.

[00:10:37]
And so that's why, again, if you think about what we just did, think about running that for a solid month, you'd be able to run everything, you'd be able to deploy everything, but the moment you wanted to change something, that would immediately slow down. So it really only solves the use case of exactly the environment that we're in.