I really like building free stuff to make Microsoft SQL Server data professionals’ jobs easier and more enjoyable, and I’ve been picking up speed:
- 2011 – sp_Blitz®, easy free SQL Server health check script
- 2013 – DBAreactions.com, DBA life in animated GIF form
- 2015 – SQLServerUpdates.com, easy free way to find current patches
- 2016 – First Responder Kit, an open sourced set of scripts for health checks and performance tuning
We’re about to announce our first free online service, not just a web site or script, and that comes with some interesting design decisions and restrictions.
My free projects have to be sustainable.
Right now, here’s what that means to me:
- It has to be inexpensive to host. No hardware, no dedicated servers. As examples, DBAreactions, SQLServerUpdates, and the First Responder Kit all combined cost me under $50/month.
- It can’t be mission critical. If it goes down, your life has to go on. I don’t want to spend money on geographic or multi-cloud redundancy yet. (We don’t even have that for BrentOzar.com, although as we do more and more e-commerce, we’re approaching the point where it makes sense.)
- It can’t require interactive support. I can’t afford a live support team sitting around, which to me means I don’t want code running on your servers.
- It may require development time from me or others, but not too much. Some of my ideas would require a team of 5-10 developers, and I just can’t afford that right now.
These requirements led me away from Microsoft SQL Server.
From the outside, I bet you look at the project and think, “They should store the data in SQL Server. That way, when something goes wrong, they can use their own staff to troubleshoot the issues.” After all, we use our staff time to develop and support the First Responder Kit scripts – why not this too?
Thing is, when we hire consultants, one of our attractions is, “You’re not on call anymore.” We don’t offer on-call service level agreements for our clients (although I’m an email addict, and if someone emails after hours, I usually respond within minutes anyway, even if we’re not available.)
So self-managed SQL Server was out, although Azure SQL Database was still an option. I love that product – it’s a brilliant fit for a lot of ground-up new development projects like this – but we’re not storing relational data in this service.
These requirements led me to NoSQL.
Years ago, when I first heard the term NoSQL, I was mad as hell.
I’m a database guy, making my living with Microsoft SQL Server. I love it dearly, despite some faults here and there. Hearing the term “NoSQL” angered me because removing the SQL language wasn’t the solution to tough development problems.
At first, the NoSQL movement literally meant no SQL language: developers dumped all their data into key/value stores and did all joins in the application. Good for a laugh, but obviously that can’t last too long.
NoSQL later got translated into Not Only SQL, which makes more sense because bigger applications usually need a mix of relational data, key-value stores, cache layers, etc. A lot of stuff gets dumped into the NoSQL bucket, and I’m a big fan of it. After all, not everything belongs in a relational database.
Today, in 2016, I don’t take the term NoSQL to be a personal insult, or an arrow to the heart of the technology I know and love. It’s just a term – albeit a crappy one – to describe a lot of great ideas, like key/value stores, avoiding joins where you don’t need them, and the choice between consistency & availability when nodes of the cluster go down (the CAP theorem).
Our new service has more in common with your Facebook feed than it does your bank balance: if some of the data isn’t available temporarily, life goes on. If I can just make the service available and cheap, then I can make it work, and make your lives better.
I still love Microsoft SQL Server.
I still believe it’s a great platform to build your career on, and I’m still building free projects for SQL Server users.
It just so happens that this one is built using non-SQL tools, including Amazon DynamoDB. Why not Microsoft Azure DocumentDB? Well, that has to do with another one of the design decisions – using function-as-a-service, aka serverless architecture – and we’ll talk about that as we launch.