4

I have a STAGING and PROD environment, web apps, SQL databases, etc in Azure. Currently, the scale of the SQL db for PROD is much higher than STAGING - no surprises there.

I suppose there is some temptation to save money by pooling these SQL resources together with an SQL Elastic Pool. However I'm concerned that it will create a coupling between STAGING and PROD which everything inside me screams is a bad idea.

What are the legitimate drawbacks that could reasonably affect performance, reliability, security, etc?

Improve this question
2
  • Embrace the cloud, instead of thinking in multiple static tiers make sure you can spin up and environment fully automated when needed. This allows you first of all to shut them down when not needed, and much more importantly if you need multiple independent thinks (like qualifying the next release and a emergency configuration change) you can do both independently. – eckes Feb 20 '19 at 8:45
  • thanks @eckes but I'm not going to need n environments. I only need 2. – cottsak Feb 20 '19 at 15:43
5

The biggest push back for sharing Stage and Prod I get come from the Cyber side of the house. If you must demonstrate a clear line of delineation between Stage and Prod, you should not use an elastic pool for both. Other than that, there are not any real technical downsides, you can always mix and match single DBs with a pool. In most cases, an elastic pool is more cost effective but please note the following per our documentation.

There is no per-database charge for elastic pools. You are billed for each hour a pool exists at the highest eDTU or vCores, regardless of usage or whether the pool was active for less than an hour.

Improve this answer
1

If you have customer or contract requirements that require physical separation of N tiers then you cannot do this. From a security standpoint it's a very bad idea to combine the 2 environments. A great way to pour gasoline on the fire is that if management is pushing for the single pool because of cost then I counter that I'm shocked that the company isn't worth more than the cost of the second pool. I've seen execs try to shave off $5-10k on a project and I call them on it, sure they hate me but it's fact, not opinion. Getting hacked is the scenario of when it will happen, not if it will happen. You can only design that it will be more secure with the proper design. If this company couldn't be sold for $5-10k we have a problem. You should never skimp on security or why not just post all data publicaly so why try to secure it if that's their issue. If you haven't already, look at NIST 800-53 R4 to get a good understanding of a security framework. Also CIS-CAT and their nice scanner tool can help become more secure as well.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.