Author: way0utwest

  • SQL in the City Summit comes to Brisbane on May 31

    SQL in the City comes to Brisbane on May 31. It’s a day before SQL Saturday #838 – Brisbane. If you’re anywhere close, which likely includes Sydney, take two days and get lots of Database DevOps and SQL Server training for a very low cost. I’m hoping for a good turnout and the chance to come back again next year.

    Register today for a full day of training and talks about DevOps and Redgate products on Friday, then come back to SQL Saturday 24 hours later.

    I’m excited for the event. We completed our London Summit this week and it went very well. I’m taking over the keynote from Kendra and also doing a Monitoring session as well as covering privacy and the panel.

    It’s going to be an exciting day, so if you want to improve your Database DevOps process, in a Compliant way, sign up and come on May 31.

    2019-05-02 11_33_08-Window_thumb[2]

  • Serverless

    About a year ago I kept hearing about serverless as the way to go for all new code. It seemed every conference, every cloud vendor, even many developers were discussing serverless as a technique for running small snippets of code. This technology seemed to burn very bright, but then dropped out of the media somewhat. It’s still being adopted, but seems less popular than a year ago, with containers and Kubernetes becoming more popular this year.
    Serverless computing is kind of a backend-as-a-service (BaaS) or a function-as-a-service (FaaS) architecture where you write and deploy functions on a cloud service that are called by your application as small chunks of functionality. The pricing is by the execution, with a very low cost for resources. Azure Functions cost US$0.20/million calls and US$0.000016 / GB-s. Strange metrics, but the result is a very low cost for most clients to use a functional part of a system. The key is that there are not infrastructure worries. The serverless platform provides the CPU and RAM needed to execute a function, with storage also available on the cloud provider’s platform.
    I ran across an interesting article that talks about serverless platforms on premises don’t quite make sense. The idea with serverless is that you most closely pay for what you use, not being charged for times when your code isn’t being executed. On premises, you would need some hardware running all the time that you are paying for, which is ready for when code is called to execute.
    I’d disagree slightly, especially with architectures like Azure Stack that blur the line between private and public cloud resources. With Azure Stack, you should (at some point) be able to write applications using serverless functions that execute in your data center. If you need more resources, you scale your data center up with Azure cloud resources, and pay for your usage. When the workload shrinks, you stop using cloud resources and just use your data center.
    Most of us won’t necessarily want to run an Azure Stack, so why would be use serverless on premises? To me there is one element of a cloud service I can’t control: what other people do on the platform. Cloud services are large and distributed and in use by lots of customers at a time. If I execute things in my data center, on some serverless platform, I have better control over how things work and likely more predictable performance. If my workload is well known, I also probably have lower costs.
    In many cases, we know the workloads of our databases, and we want predictable performance (however good or bad it is). Databases are potentially a good fit in the cloud, but often in a mature application, we would be better served by keeping the database on premises, especially if we’ve already invested in the hardware and other resources.
    Serverless is a very interesting idea, as is much of the cloud. It might suit your application, or it may not, but you have to think about the requirements for your situation. Knowledge of new options and technology is important for us to intelligently debate and discuss what works best for our organizations.
    Steve Jones
  • Republish: Are you a Data Scientist?

    Today I’m flying back from the UK, all day. Usually this is roughly a 20+ hour day for me to return home, so I’m not likely to do much work. You get to read a republish: Are you a Data Scientist?

  • Initialize-HgsServiceName Fails in VMWare

    A short one, but one that took some digging and debugging and help from others. Saving here, so I remember, as do others.

    I had a VMWare Workstation v12.x VM of SQL Server 2016 and was working with this tutorial on Always Encrypted with Secure Enclaves. In setting up the HGS server, I got to step 3 which has this code:

    Initialize-HgsAttestation -HgsServiceName 'hgs' -TrustHostKey

    When I ran this, I got an error:

    2019-04-24 07_52_51-Window

    That’s not good. In trying to find why this won’t run, eventually, I realized that my VMWare system needs the Microsoft Virtualization Based Security. This isn’t an option in my older VM, I believe because this is

    a) v12 and not v14+

    b) BIOS firmware

    You can see my settings here:

    2019-04-24 07_53_42-Window

    Fortunately I had an upgrade for VMWare available and updated to v15, and then build a new VM as a v14+ hardware version. This gave me UEFI and once the VM was shut down, I could check the VBS box.

    2019-04-24 07_53_26-Window

    After doing this, I could move forward with my secure enclave config.