Start-up Architecture: Database & Secrets

[00:00:00]
>> Erik Reinert: So we have our application deployed in App Runner. Great, awesome. However, App Runner needs a container image, right? And so this is where we're gonna start jumping into Docker. We're gonna create a very simple container image, and then App Runner will actually use Amazon storage to run that image.

[00:00:19]
So we'll actually create the image, put it in Amazon's storage, and then App Runner will use that as a reference to pull the image and run it. So now we've got two pieces, right? So we've got App Runner and we know that we need a container image. What about database?

[00:00:35]
Okay, so here's the fun part. I've said multiple things about Amazon, I actually really do like them. As a cloud provider, they're one of my favorites. But RDS sucks, it really does. RDS is like its own beast, and don't worry, we're still gonna be working with RDS today.

[00:00:56]
But I think I get this, not a thing, I get this a lot. Where people will be like, well, should I set up my own RDS instance? Should I create my own database instance? There's so much management that comes into managing your own database. How many here knows what a DBA is?

[00:01:15]
Okay, so, yeah, a few of you. A DBA is basically a database administrator that companies hire because nobody else knows what postgres is or how to use it. That's the easiest way to put it. It's like we have this massive database with millions and millions of rows. We're gonna hire somebody dedicated to that.

[00:01:34]
When you're at a company, that's normally what you end up doing, right? If you're in a scenario where you aren't gonna do that or don't have the ability to do that, then I would make databases as less of a problem for you as humanly possible. That's my personal opinion on it.

[00:01:48]
I don't like having to think about my data retention or my backups or uptime, all that stuff. So in this scenario, in this start-up phase, we outsource it, right? There's a lot of really good options outside of RDS that exist out there. And there's actually options that we're gonna be using today that use RDS that made a company model on top of it, that then give you basically RDS, but with a few clicks of a button, and that's Supabase.

[00:02:15]
I really do think that these kinds of services that just say, here's a public endpoint with your, I know, it's scary, I get it, I get it. But just having a public endpoint to start off with easily, not having to deal with the networking part of it, makes it easier to go to production directly.

[00:02:36]
And so that's another decision as to why we chose this infrastructure the way that we did is because then I don't have to worry about security groups or firewalls or any of these other stuff. It's just there's a connection string. They manage it, they manage the connections. They'll take care of all that stuff.

[00:02:52]
Fantastic. Put it on them. So that's why we chose Supabase in this first setup. Does that mean we're gonna stay on Supabase? No, because more than likely, Supabase will end up costing us a lot of money. That's how they end up making their money, right? But in the early stages, especially, dude, especially if you're making no money, don't pay for a database online.

[00:03:14]
You are now in the red, my friend. Lean on free services as much as you can. Amazon's got a free tier, Azure's got a free tier. Pretty much all of these places have free tiers now. And if you can lean on that and use it, yeah, feel free to.

[00:03:28]
And so that's why we chose Supabase in this model was just to say, I don't have database knowledge, I don't know how to manage those things. So I'm gonna let another provider take care of that for me. I'm gonna throw money at the problem, but I know it'll work reliably and I'll be real.

[00:03:45]
This could save you tons of maintenance hours. Think about it. Migrations running, failures, like all that kind of stuff, all the databases down, you don't have to worry about any of that with this approach. Yeah.
>> Male Student 1: So you're hoping to save some cost by not having a database administrator.

[00:04:02]
And especially when your scale is small, these costs can be small, right?
>> Erik Reinert: Absolutely, yeah, absolutely. Where I am today, where I work, we're currently making the evaluation of moving our CICD. And one of the first arguments I made was, well, when do you ever worry about our CICD?

[00:04:20]
Because we don't. It's so abstracted. Thankfully, we don't have to worry about that. Those are the kind of solutions you wanna find, right? I know it's fun to play with the technology, but part of it is to make it so it works [LAUGH]. So, yeah, that's exactly it.

[00:04:35]
You don't wanna have to worry about hiring somebody to do it or the knowledge around it, so you can just pay them to do it, right? The last thing, and this is just kind of an additional thing and this is something that I chose which is, I need a place to store credentials and secrets for the service, right?

[00:04:57]
Now I would assume you want some sort of security, [LAUGH] you know what I mean? You can, if you want, say, I'm not even gonna use this. I'm just gonna put secrets directly in my environment variables and the security's up to you, man. However, personally, I would like some kind of secure place to put my configurations and secrets and stuff like that.

[00:05:18]
And so we're using Parameter Store for this. It's a really nice tool. The reason why we're using it, if you're like, why aren't you using Vault or blah blah, blah. Well, for starters, I don't wanna deploy anything, right? That's the first thing, I don't want to have to manage that.

[00:05:30]
Then the second thing is I want a UI, I don't wanna manage credentials in some kind of code base or anything like that right now. It's just easier for me to go to UI, make a couple changes, click a button. Out the door it goes, right? So now we're kind of building the developer experience around it.

[00:05:47]
And that's why the second part is the developer side of it. So what you'll note is that everything is basically manual, right? The user has to go to App Runner to view your page. But then if you want to change anything that the user sees or interacts, interacts with, you have to do it manually yourself, right?

[00:06:06]
This is the other side of that start-up phase, right? You normally don't have a whole bunch of automate. How many of you guys have created a project and then just done everything manually by the CLI? Right, we've all done it. And that's really where you'll be in the start-up phase of a company.

[00:06:21]
You'll more than likely be just running commands. Because the amount of effort and requirement it takes sometimes to get to that automation is something you have to pay for, right? So yeah, that's what we're gonna be building. Again, I know it was a little bit of a long winded discussion, but I feel like now at least you understand why we chose the way or the infrastructure that we did, right?

[00:06:45]
And again, each part of these or each one of these components were picked for a very specific reason to solve the problem that we're trying to solve, right?
>> Male Speaker 2: What do you think of AWS Secret Manager to solve the credential management?
>> Erik Reinert: Yeah, so I have used Secrets Manager.

[00:07:04]
I use it at my job and I use Parameter Store mostly personally. Secrets Manager, you can kind of look at it as a book with a ton of pages in it. And those pages can be super long and super big or they can just be one or two entries.

[00:07:25]
You just grab that document and then you get all your secrets. Awesome. That makes it really nice if you have tons of secrets to pull it in one request, right? Systems SSM or Parameter Store is really meant to be value by value, right? So it's like a real key store storage.

[00:07:45]
So what you would do in Parameter Store that you probably wouldn't do in Secrets Manager is only have one value for database password, right? You have a new parameter for user password versus database password, right? Technically, that's the real difference between the two. However, it's mostly preference. They both store and encrypt the same way.

[00:08:09]
They both work effectively the same way. I tend to lean towards more service discovery, which is where key value is more helpful than pulling down huge Secrets Manager objects and things like that. So it's really just a preference. But Parameter Store is meant to be more like, I just want this one value, right, I don't want the whole thing.