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.
11 Comments. Leave new
Was there a reason why azure functions were not a good fit?
Richard – yeah, they’re only in preview, not very well-documented, and weren’t documented at all when we started the project. https://serverless-developers.com/2016/06/the-pros-and-cons-of-serverless-architecture/
How about azure table storage?
Bobby – the provider decision (Azure vs AWS vs Google) was driven by the programming platform decision. We wanted to host the code using function-as-a-service hosting (aka serverless), which meant we had to choose between Azure Functions, AWS Lambda, and Google Compute Engine. Azure Functions wasn’t ready for prime time (and even now, it’s still in preview with no pricing), so Azure was out.
Interesting..always looking forward to ur thoughts and ideas on tech.
I have been tracking NoSQL databases since early 2012, collecting publicly available data on skills and vendors. The NoSQL market is still tiny. Considerations and summary of data in Section 2 of this very large slide deck: https://speakerdeck.com/abchaudhri/considerations-for-using-nosql-technology-on-your-next-it-project-1 Slides regularly updated with new data as I find it. Data last updated in August 2016. The presentation is quite tongue-in-cheek, so you might enjoy it.
Akmal – thanks, but you may want to think a little deeper about those updates. NoSQL has moved on to a very different place in the Gartner curve. The presentation doesn’t really speak for itself either – you probably want to do this as a video.
[…] is… interesting. Brent Ozar mentioned that he is using NoSQL for a new project. He picked Amazon DynamoDB over DocumentDB. I’m picking […]
SQL NOSQL by Brent Ozar. Dude I thoroughly appreciate your transparency. The “serverless” functional aspect of your project is a great choice. I’m going to go out on limb and predict that your free service will generate revenue, will be an excellent case study for AWS/Google function-as-a-service, and will eventually receive sponsored hosting from a vendor. GREAT STUFF!
Thanks!
[…] my community stuff has to be sustainable. I’ve written about what sustainable community initiatives mean to me, and I’ve been careful to build GroupBy in a way that I can sustain it. I don’t do the […]