It sounds like a trick question, but I’m serious.
If your company’s management is just now starting to consider the cloud in 2020, your reaction shouldn’t be to cast a shadow on cloud vendors. Instead, think of it as writing your own resume: what the capabilities that you and your team are really proud of?
What are you currently doing better than anybody else?
It’s a serious question with legitimate answers.
For example, at one of my clients with 10-20TB of data per server, the production DBA team works really hard on their restores. They have the whole process automated, and they regularly performance tune it so they can restore to a point-in-time as quickly as possible. In a matter of seconds, any DBA on their team can run a script that will:
- Put the soon-to-be-nuked database in a read-only state, keeping their application somewhat online in a degraded state
- Initiate the restore process onto the primary replica using a database with a different name
- Start communications with the affected teams (“your database restore has started” – “your database restore is now 25% complete” – “your database restore is now 50% complete – current status, seeding the AG secondaries” – and so forth)
- Rename the soon-to-be-nuked database (so that it’s still online for reads, but with a different name, so application owners can do some triage) and take it out of the Availability Group
- Rename the newly restored database to take the old one’s place
- Email the affected teams, stop the timers, and track their success metrics for their quarterly RPO/RTO service level agreement review meetings
(Don’t even get me started on why they need to do big restores so often and so quickly, but let’s just say that not everyone’s deployment processes can be done with an undo script.)
I think the time has come and gone for small businesses to even have this discussion. For small businesses, it just doesn’t make sense to try to run your own IT for new applications. However, for the kinds of readers I’ve got here – who tend to work in more specialized environments that have full time employees focused on the data – the question still has plenty of legitimate answers in the year 2020, despite what cloud vendor brochures say.
So I’m curious: what do you think you do better than the cloud?
31 Comments. Leave new
In all seriousness, we don’t do anything better than the cloud. My organization is moving all remaining production and test databases to cloud database-as-a-service.
I make an awesome gin and tonic. the cloud can’t get even close.
We have a medium size environment. 150+ servers and 10,000+ databases. A bunch of those databases are really small and get created automatically and dropped in a a couple of days.
I didn’t set this stuff up, the developers did this, I just have to support it.
I interrogate our SCCM server to find out what servers are running SQL
I then get a list of databases from those servers and store it in a central server. Most servers are ‘owned’ by one or two managers so they are the default stakeholder. If a long term database has a different stakeholder, we can change it.
If somebody needs access to a database for reporting/updating, they can request access through our portal.
Once the stakeholder grants the request through the portal, the central server automatically connects to the SQL server and grants the access.
After 90 days we revoke the access to keep in compliance with our SOP.
Let’s see the cloud do this.
They actually have all of that availability… granted, maybe not in the base server platform, but the supporting dev ops capability between pipeline functionality and rules and whatnot can definitely pull that off… It’s pretty amazing.
Sure, but it doesn’t matter where you run your stuff for devops. The tools you have on prem just usually work better and are more extensible
The cloud is just a platform. You’re still responsible for your applications and data, so in this aspect they’re about even.
When it comes to new technology and software such as Data Factory/Data lake its tough to build an equivalent on prem so here cloud (Azure) wins.
When it comes to performance – In my experience our local data center blows Azure out of the water. We did get close using P15 Azure SQL, but it was just too expensive to justify. MS is definitely going to stretch the useful life of old servers for VMs, so if you don’t mind crappy performance especially WRT to IO latency you’ll be just fine. For some of our IaaS SQL that is ok.
So far I find Azure SQL great where you need a basic relational DB with HA. Azure definitely shines for corruption checks and its backup/restore is solid though I do much prefer software like Rubrik with IaaS or on-prem SQL.
Looking into the future I believe that nearly all software will someday be sold as SaaS and there will rarely be discussion about platform or infrastructure will be niche at best. DBAs of today will likely transform into “Cloud data asset managers” or something like that. In that world it’ll be tough to justify anything other than cloud.
This is exactly my perspective of Microsoft Azure SQL DB. I don’t feel comfortable with the performance in comparison with our on-premises VMs. I wouldn’t use Azure SQL DB for a Data Warehouse. We have used it for small relational databases that require HA and DR.
I haven’t tried Azure Synapse yet. Is there someone that has run a Data Warehouse in Azure Synapse?
Until Azure Data Factory is developing it’s own ETL processes, I am feeling pretty good about that particular skill not being replaced by a robot.
(1) Capacityplanning is a drag on the cloud. Onprem you just buy some extra memory, license your VMhost and capacity is a few buttonclicks away. For the cloud (AWS i’m using) the RDS instance size needs to be as small as possible ($$). This requires constant resource usage monitoring and $$discussions if we need to increase the instance, but wait, we bought them for one year, we need to move to an other instance. etc.
(2) performance tuning: I see that the vCPU’s are overcommited and I am able to check and correct that on-prem, but in the cloud they will never admit this situations as this interferes with their revenue model. Systemvisibility is lower in the cloud, although this may come because the cloud is new to me and still hold many surprises.
(3) Database restores. In AWS you can restore an instance, not a database. PITR is difficult, as we don’t have access to the transactionlogs. We need to create a new instance, do a PITR for this, backup the troublesome DB and restore it on the main instance. Cumbersome.
(4) Some DB require to be onprem ( low latency, vendorsupport, extreme resource intensive etc).
For a lot of people, moving to the cloud, especially a managed system like AWS RDS, will be a god-send because they’re not doing anything really special with their SQL Servers.
For me, it would be a killer. Because it’s a managed system, all of your databases will be in the FULL recovery model and AWS RDS will automatically enforce that. You also can’t do things at the OS level and the list goes on. From what I understand, you also get your choice of either Express, Standard, or Enterprise editions… the Developer Edition is simply not made available. That means an instant and significant licensing cost increase for your Dev, Test, Staging, and other non-production environments.
If you go to AWS EC2, it’s basically just someone else’s hardware. But, even with that, if you’re doing backups (and you should), it’s a bit of a different ballgame. Imports and exports also change significantly. That means a whole lot of lost learning.
You also have to pay for performance. If you have on-premise servers that are 3GHz 24 by 48 CPUs, 384GB of RAM, and 10TB of some nasty-fast SSDs, you’ll find the cost of such servers on AWS to be rather on the steep side and certainly a whole lot more than people planned on because they don’t take the time to carefully research such things.
Don’t get me started on “computational miracles” like RedShift (which also requires very good knowledge of PostGre SQL and, no… SQL SQL here) and MapReduce. You’re not Google or AWS and the time you spend learning how to correctly use those things and then change all of your code and data structure to be to use them would be much better spent in fixing what you have on-premise and teaching people the right way to use SQL Server and T-SQL.
Ironically, I think too many people know too little about costs and paradigm shifts which make for some huge intangible but very real costs to just up and move. Like I said, if you’re not really doing much with SQL Server, then maybe it’ll help you save. If you doing something a lot more serious (regardless of database size), be really careful… it might cost you a whole lot more than you’d expect.
Don’t forget to check out things like RPO, RTO, cost for ad hoc restores, etc.
I fully agree with you, this is absolutely in line with my observations at my current employer.
Totally agree men.
The main caveats that I can think of about cloud based data repositories is… “who’s watching the watchmen?”
Other then that, bandwidth, availability a the required scale and Level of Detail, etc.
Once the user’s expectations are met there, can’t see much wrong with it, especially when leveraging AI/ML, automated management, etc…
I’m way cheaper than the cloud!
I tune the databases to go faster by learning from Brent Ozar which cloud can not do .
I have seen clients where they thought the performance would improve in cloud when they move there databases to cloud and after paying heavy bills they moved back to on perm.
Data security. Who and how many others have access to your “private data” in the cloud. These days, many corporations are paying $$$$$ for your data. Just look at free facebook and free google. Not to mention every other month, I am receiving an email that there is some class action suit against some well known bank or corporation that my private data was breached and I am entitled to $2.19 for my trouble. I will stay with on premise and deal with restoring my 10TB db.
I would say performance tune queries. Using Azure Managed Instances gives us options such as ‘automatic tuning’ which has caused our MIs to fail over more times than I can count.
I’m sure this feature will get refined in the future, but it’s not there yet.
1) Visibility. Even a normally neglected on-prem environment has more visibility than the cloud can have. you dont have 10-15 day support tickets you pay microsoft for, to learn that you were one of the unfortunate people that was a victim of a bad patch that was in sample testing on your stuff.
2) support calls. No waiting for hours to escalate to someone who is actually capable of resolving your problem, then spending days on the phone to fix something they don’t understand.
3) documentation. Even incomplete on-prem documentation is better than commonly non-existent or out-right wrong documentation that gets open-source developed on github now.
4) performance tuning. I can make egregious queries become bad queries and have performance come to an acceptable level, then move on. In the cloud, you have to be perfect in every query to make it even somewhat usable, and that is with significantly reduced visibility into what is going on in your DB.
5) Cost management. Make a plan on prem and run with it for 5 years. Make a plan in the cloud and you are revisiting it every 8-10 months and products come and go, pricing structures change and your friendly local microsoft cloud evangelist tells you that Azure can turn water into wine.
6) getting what I paid for. You always get what you pay for on prem. In azure, evidently you cross your fingers and hope MS hasn’t overprovisioned the failover site AGAIN.
Awesome. That’s pretty much what I’ve experienced in the past.
From my breaking down grammar, I was obviously getting angry again recalling these. I used to be far more excited about the cloud, but have been screwed over too many times by products completely failing to deliver on their most basic promises. Nevermind cost savings and imagined hindrances saved related to patching. stuff like servers not booting, servers bluescreening, minneapolis not having failover capacity for austin more than once, needing a month to configure an azure WAF because as the json config grows it takes over an hour to apply one rule change, ad nauseum.
Yes, all this happens on prem, but I have worked with some serious idiots and have been screwed over by them far fewer times and not as hard as I have been by microsoft’s cloud.
Ah… here’s one for ya. It falls under the category of “He who giveth, shall also take away”.
Anyone want to talk about what the impact was for them when MS removed CLR support for Azure SQL DB?
I don’t even like the word “Azure”… it sounds like a big time drunk trying to say “are you sure”? 😀
Nothing!
We use Azure SQL database only, and I really enjoy the “Always upgraded” (to the newest SQL version).
I could not do that On-Prem. Worth a lot of time&money to me.
Stronger together (but physically apart)
The only thing we deal better than the cloud is dealing with hundreds of databases with about 2k queries per second for way less $$$$ than if it was in the cloud. Working on reducing the queries the software team does to the database with caches and the broker, but it’s gonna take a long time before we reduce it to the point when we’ll be able to move to the cloud for a decent price.
For some of our applications, the cost for the bandwidth to move that data to the cloud from where it originates would be really high. Not to mention DW queries that pull a lot of data back would take for ever to run verses on prem.
Point and time restores don’t cost much more and it is just in more hardware where as you pay every month for the privilege in the cloud.
I do Performance better than the Cloud
Lindsey Allen from MS groks 480 Cores here in 2016 on-prem
https://channel9.msdn.com/events/Ignite/2015/BRK2558?term=sql%20lindsey&lang-en=true
Start at 14:30 in…
* More than 22.5mb/s log rate during ingestion
* Ratio of #Cores to RAM/TempDB
I had to chuckle out loud about that one. Nicely done.
Our on premise databases and applications still function when we have 3rd party host outages. Our local government cannot be held hostage by internet providers and cloud database hosts connectivity.
@Bob,
That’s actually one of my largest concerns with the cloud. While I appreciate their honesty and realism (because almost nothing, including on-perm stuff, is 100% online), I don’t hanker to other people’s schedules even when it comes to “necessary” down time.
That is exactly why we have not pulled the trigger and moved anything to the cloud. We just don’t see the potential benefits as outweighing the pitfalls.