Answers: <p>The choice of the approach is a risk assessment, if one of the DB client (application) goes wild and bring your server instance down, what is the cost in term of human hours lost during the outage ?</p>
  <p>If you run the DB yourself instead of managed you have to include your time costs to update it, backup it, monitoring it, etc. is it really cheaper ?</p>
  <p>All this is very company specific and need to take into account the human cost, does a staging environment down block 1 or 80 devs ? Are the devs junior or senior ? The cost per hour of outage change a lot from these simple two metrics.</p>
  <p>At the end of the day, that's a judgement on accepted risk of outage and capacity to restart versus administration time to avoid the outage for which there's no magical mathematics formula.</p>
  
Answers: CC BY-SA 4.0
Answers: 2021-03-12T20:03:23.413Z
Answers: 2021-03-12T20:03:23.413Z
Answers: Tensibai
Answers: <blockquote>
  <p>Managed DBs - I totally get their advantages and I'm a huge fan. But they are expensive. How many instances should be deployed? Let's assume that I have 5 independent projects and each project has dev/staging/prod environments. Should I have 15 DB servers (instances) running? Or can I perhaps run one DB instance and serve dev/staging environments from there and keep prod instances seperate? Important: I mean database server instances, not databases.</p>
  </blockquote>
  <p>I agree, this would give you too much overhead and it will be expensive. I would go for a single regional database server instance per environment. It would be good if a DBA could maintain it and setup proper backup and disaster recovery.</p>
  <p>Remember, <em>microservices</em> should all have their own database. But this is <em>logical database</em>, e.g. typically a <em>schema</em> or <em>logical database</em> inside the instance. Each <em>microservice</em> should probably has its own dedicated <em>database user</em> as well.</p>
  
Answers: CC BY-SA 4.0
Answers: 2021-03-12T22:05:25.577Z
Answers: 2021-03-12T22:05:25.577Z
Answers: Jonas
Body: <p>I'm looking for some insights into cloud management. I won't go into much detail, I just need some general information/resources that I can follow, about these topics:</p>
  <ol>
  <li>When to use container services like Fargate, ACI, App Service? If the project isn't big enough, is it worth to migrate from more traditional approach (so VM instances with docker-compose running inside)?</li>
  <li>Managed DBs - I totally get their advantages and I'm a huge fan. But
  they are expensive. How many instances should be deployed? Let's
  assume that I have 5 independent projects and each project has
  dev/staging/prod environments. Should I have 15 DB servers
  (instances) running? Or can I perhaps run one DB instance and serve
  dev/staging environments from there and keep prod instances
  seperate? Important: I mean database server instances, not
  databases.</li>
  </ol>
  <p>I've been trying to find some info online but most docs don't go into that much detail. Could you give me some more insight on how to run this type of infra? Mind you, the projects are not big, the databases are 1-2 GB in size (dev/staging DBs much less than that). What approach would you choose and why?</p>
  
Tags: <docker><azure><databases><infrastructure-as-code>
Title: How many DB instances to use? When to switch to container services?
UserDisplayName: dywan666
ThreadText: # How many DB instances to use? When to switch to container services?
  
  (Asked by: username_0 on 2021-03-12)
  
  I'm looking for some insights into cloud management. I won't go into much detail, I just need some general information/resources that I can follow, about these topics:
  
  1. When to use container services like Fargate, ACI, App Service? If the project isn't big enough, is it worth to migrate from more traditional approach (so VM instances with docker-compose running inside)?
  2. Managed DBs - I totally get their advantages and I'm a huge fan. But
     they are expensive. How many instances should be deployed? Let's
     assume that I have 5 independent projects and each project has
     dev/staging/prod environments. Should I have 15 DB servers
     (instances) running? Or can I perhaps run one DB instance and serve
     dev/staging environments from there and keep prod instances
     seperate? Important: I mean database server instances, not
     databases.
  
  I've been trying to find some info online but most docs don't go into that much detail. Could you give me some more insight on how to run this type of infra? Mind you, the projects are not big, the databases are 1-2 GB in size (dev/staging DBs much less than that). What approach would you choose and why?
  
  **Tags:** docker, azure, databases, infrastructure-as-code
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2021-03-12. Score: 1
  
  The choice of the approach is a risk assessment, if one of the DB client (application) goes wild and bring your server instance down, what is the cost in term of human hours lost during the outage ?
  
  If you run the DB yourself instead of managed you have to include your time costs to update it, backup it, monitoring it, etc. is it really cheaper ?
  
  All this is very company specific and need to take into account the human cost, does a staging environment down block 1 or 80 devs ? Are the devs junior or senior ? The cost per hour of outage change a lot from these simple two metrics.
  
  At the end of the day, that's a judgement on accepted risk of outage and capacity to restart versus administration time to avoid the outage for which there's no magical mathematics formula.
  
  
  ---
  
  ### Answer by username_2 on 2021-03-12. Score: 0
  
  > Managed DBs - I totally get their advantages and I'm a huge fan. But they are expensive. How many instances should be deployed? Let's assume that I have 5 independent projects and each project has dev/staging/prod environments. Should I have 15 DB servers (instances) running? Or can I perhaps run one DB instance and serve dev/staging environments from there and keep prod instances seperate? Important: I mean database server instances, not databases.
  
  I agree, this would give you too much overhead and it will be expensive. I would go for a single regional database server instance per environment. It would be good if a DBA could maintain it and setup proper backup and disaster recovery.
  
  Remember, *microservices* should all have their own database. But this is *logical database*, e.g. typically a *schema* or *logical database* inside the instance. Each *microservice* should probably has its own dedicated *database user* as well.
  
  
  ---
  
  