Building SQL ConstantCare®: Europeans, what do you want to see in a cloud-based monitoring product?

About a year ago, with GDPR enforcement looming, we decided to hit the brakes on EU sales because we weren’t confident enough in the third party app ecosystem’s compliance capabilities, or the EU’s ability to police the regulation effectively.

In the time since, it’s been interesting to see that:

  • Few folks requested their data or the right to be deleted
  • Among others, Google got hit with a GDPR fine
  • The compliance ecosystem has gotten marginally better, but still not great
  • Brexit (or maybe not, who knows)
  • The EU’s working on a new copyright filter law (Julia Reda’s writing on that has been phenomenal)

Looking at that list, it’s not that I’m suddenly filled with an overwhelming confidence that it’s easy and cost-effective to build a product with GDPR compliance, AND to defend a company against an EU country’s GDPR inquiry. However, I do think that it’s time to start looking at what it would take to sell SQL ConstantCare® in the EU. I specifically mean to sell it though – not just what it would take to be compliant, but have a cloud product that Europeans would open their wallets for. (And I’m not even sure that’s a possibility yet, thus the post.)

Brent Ozar at the Porsche Museum
I’d like to house the EU’s most prized possessions in a United States garage, specifically mine

As we go down that road, I’m curious about Europeans’ opinions to a few questions:

  • Would your company even be open to a solution like that?
  • What kinds of objections have your managers raised about cloud-based products?
  • Have you tried to implement a cloud-based product, and failed? Or succeeded?
  • Between Amazon’s regions (Frankfurt, Ireland, London, Paris, and Stockholm), is there one that your company absolutely insists that its data must be stored in? (Strictly speaking, EU data residency isn’t a technical requirement, but companies often have political requirements.)

Let me know what you think in the comments. I’m not making promises that we’ll sell to the EU by the end of the year – but it’s something that we’re starting to consider.

Previous Post
What should you do about memory dumps?
Next Post
There’s a bottleneck in Azure SQL DB storage throughput.

24 Comments. Leave new

  • Daniel Hutmacher
    February 25, 2019 7:55 am

    Most of my clients already use cloud platforms in one shape or other. And while not many of them host their actual databases or business-critical apps in the cloud, pretty much all of them use services like Jira, Trello, Power BI, Slack, Skype for Business, not to mention hosted e-mail services, etc. I mean, who in their right mind would set up a Jira server on prem? 🙂

    So eventhough monitoring software in the cloud may certainly contain sensitive information, that goes for all of the other platforms I mentioned, too.

    I think many buyers are uncertain about what the actual regulations with data residency are, so they will probably want to have their stuff in the EU. If you’re trying to sell a cloud solution, having the data in the same country is definitely a selling point, and many local cloud service providers market their services as “local” and “Swedish”, to attract customers who aren’t too comfortable shipping their proprietary data abroad.

    Public sector organizations are subject to more stringent rules with regards to data residency, but I don’t have detailed knowledge as to what those are.

  • We run a cloud based security scanning system, but because of client sensitivity the portal HAD to be in the EU at the very minimum, not on any US AWS region.

    Depending on Brexit we may see requirements to be UK only as well – certainly we’re seeing some traction in guaranteeing data sovereignty in these uncertain times – that might leave you with a headache setting up multiple regions, so you’d probably start with an EU based one as it’s the widest market.

    Cloud based services are becoming increasingly common, and if you can show you take security seriously by having data encrypted in transit and at rest, access with 2FA, etc. then I would think people would be OK with it.

    • John – ooo, wow, yeah, I bet with a security scanning service! I’m curious to see how Brexit goes with GDPR, too.

      • We have the UK Data Protection Act 2018, which is the GDPR in all but name only – so shouldn’t actually make any difference, and in our contracts we also state we comply with GDPR and have even been audited against it for our security clearances.
        Of course, if it ever happens……….

        • John – right, exactly, but read the post: I’m not talking about the bare minimum of what needs to be done legally, but also what the business actually wants, since the product would have to sell. (I’d be making real financial investments in this product – and at the expense of improvements we could be making for US companies – and honestly, I’m not getting a warm-and-fuzzy feeling about EU sales potential given the lack of replies on this post.)

          • I’m surprised you haven’t – seems a great service and frees up time for you to do the interesting stuff on SQL Server.

        • Yes – but it’s not quite as simple as carbon copy-ing the GDPR into UK legislation in 2018.

          Suppose brexit happens in 2019, and then in 2023 the EU decides to update their legislation for whatever reason – but the UK does not wish to make the same change (or vica versa).

          In such a situation the rules would become different in the UK and in the EU – so there is a problem. Just because the GDPR and UK Data Protection Act are aligned currently, we don’t know for certain that they will be forever. So does that mean that as a UK org, it’s safe/superior/inferior to store your data in the UK or the EU? Does it depend on your biz or the data subject? Most interpretations are increasingly vague on this point.

          Of course, some of these problems could (in theory) be mitigated with future deals between the UK and EU where both sides make commitments to maintain alignment – but we don’t have those yet. And then you run into questions about who gets to write the hypothetical future laws, the UK or the EU? And does either side get a veto? I’m sure that’s going to be politically toxic subject for years to come.

          • This is why we state we align with GDPR as well as DPA in our contracts, so if GDPR changes we’ll follow it. It’s more work but no more than a US firm would have to do to sell to the EU or even have EU users of its services.

  • At the end of last year I’d sold the idea of ConstantCare to my boss and he had his pen hovering over the cheque book before we realised we couldn’t buy it in the EU.

    We already use a cloud solution for our out-of-hours alerting.

    The business case for me around ConstantCare was that it gave you suggestions and advice around things to look at. Yes I could run sp_Blitz* across all our servers and get a massive To-do list but ConstantCare would give me a manageable and targeted list. That was the big win for me.

    • Robin Harmsen
      April 18, 2019 2:28 am

      I’m with Adrian here.

      Had it almost sold internally, when I realised it’s not available in the EU.
      Mostly due to the same reasons as to have a manabable and prioretized ‘to-do’

  • Companies are like people: some of them are not brain-dead; some of them are. I’m past weeping and cussing as yet another fellow IT person talks about the Cloud as though it were a soul-stealing zombie.

  • I’m going to agree with a lot of what Daniel said. I work in Financial Services with both private and government clients. The private clients mostly either don’t care or simply state EU depending on their client base. The government clients pretty much all state “local”. There is a second control however about remote access to that data from outside the EU. e.g. we have some US based support teams that we can’t grant access to our EU data servers for that very reason.

    Now we are looking to migrate a lot of our software to cloud based solutions and then sell that to those clients who are comfortable with that as a solution. We don’t expect to sell it to government clients for a few years as it always takes a little longer for those clients to agree that “this ‘ere new” technology meets their security requirements.

    Personally I’d bite your arm off to get your help, but then I’m not allowed anywhere near money 🙂

  • Oh, and back to the orignal question. Funcitonality :

    Exclude database list – Look, I know I’ve got databases that have problematic objects names (I’m looking at you data analysts), it’d be easier just to exclude those from the start.
    Ability to work with company specific file transfer software that can scan file contents before compression/encryption – It’s a security standard.
    Performance based cloud optimisation strategy advice – e.g. you’d be better to split/build/deploy it “this” way and here’s why (cost/performance/etc.)
    A page on what data you collect that doesn’t 404 🙂

    • Ooo, great questions!

      About the exclude list – that’s an interesting one. How would you handle query plans that cross databases?

      About the file transfer – ah, so rather than directly uploading to the cloud, you’d want to just save the files somewhere, have someone manually scan it, and then upload it later in a separate step? Would that be something you’d actually do manually, or in an automated way? How would you want to upload the files?

      About the data collection – sure, where are you seeing a 404 link from?

      • RE: file transfer. We use a file transfer gateway. So we have scheduled tasks that pick files up, check that and then either put them in a secured location in the DMZ where clients can log in from a whitelisted IP and retrieve them, or we can deliver them to a known location using e.g. sftp. The admins just prefer the client to retrieve rather than for us to deliver for monitoring and tracking purposes.

        Re; “local” by and large, its been in country, particularly for the UK. We have had agreements for certain 3rd party tools that have a DR server in a second EU country for geographical separation. TBH given all the potential problems with Brexit and the EU, I’d recommend avoiding govt clients for a year or two until everything settles down 🙂

        RE: Plans. Hmm, tricky. Our team is too small to do more than picking up just the disastrous queries, or offering advice to analysts and coders on good SQL writing. The analysts have their own sandbox databases that we would want to exclude, but finished work is promoted to other databases and has to meet our coding standards. All of this lives on our warehouse servers to minimise cost.

        404 – from there’s a link at the bottom

        • Gavin – gotcha. Yeah, “in country” is exactly what I was afraid of: it’s not financially practical for us to have data processing in every EU country. Fixed the 404 – thanks!

  • Anders Gregersen
    February 28, 2019 3:26 am

    Our main issue would be the sensitive data in the query cache and similarly places. It needs to be stored in the EU and we would most likely be required to have some sort of data handling contract with you if we were to use constantcare.

  • James ODoherty
    March 1, 2019 2:27 pm

    Yes please. No issues with cloud AWS or Azure. Best data residency is Ireland or Northern Europe. I have several clients who would subscribes to this without hesitation.

  • Hi Brent,
    we would subscribe for sure if you start selling your awesome tool here in Europe.

    For example, in our case, we are a medical company based in Switzerland handling with highly sensitive data and the only things we’re requesting is that the data collected by ConstantCare should not be send outside the EU territory. That means the “ConstantCare server”, who parse all the collected logs from any Europeean customers, should reside in any datacenter in Europe (even ours if you’re looking for a spot 😉


Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.