This message was deleted.
# platform-toolboxs
Slackbot
11/03/2023, 6:57 AMThis message was deleted.
c
Clemens Jütte
11/03/2023, 10:44 AMDepending on what you’re running inside the RDS instance, you should be able to use the corresponding provider, e.g. use this provider for
postgresj
jonny s.
11/03/2023, 1:24 PMYes, RDS nudges you to creating on DB per instance. Having lived both lives (last job we loaded everything in only a handful of instances), the one-db-per-instance method is a bit more expensive but overall much easier to maintain.
jonny s.
11/03/2023, 1:25 PMTo the developer, they should only care about their actual DB. If I was operating at a scale where shoving multiple DBs into an RDS instance was an effective cost savings, I'd try to abstract the RDS concept away -- devs request a DB, my platform gives them a DB, they don't care where it lives.
jonny s.
11/03/2023, 1:26 PMSame idea of they give the platform a container, the platform runs that container per their specifications, but they don't care what it lives.
n
Nathan Hruby
11/03/2023, 5:16 PMCDK has a notion of using a lambda to provision the db after the RDS is created. This includes, roles, db, schema, etc... it's a smidge fussy, but a great way to run some code of your choosing to get the inside of the db correct. Previously, I did this with ansible as part of the app setup with a "initial provision" flag for the app's role that then ran a setup task from the checked out app code, which allowed me to delegate ownership fo the setup to the people who knew best, the devs
k
Kief Morris
11/05/2023, 4:48 AMI always recommend separating the concerns of defining the infrastructure (e.g. the database instance) and defining the application (e.g. the database schema structures). Your infrastructure code should not know the specifics of your applications.
Triggering execution, e.g. deployment and schema creation, as with the lambda execution Nathan mentions, can be ok if kept clean.
3 Views