Voice of the DBA

Author: way0utwest

  • Audio Attacks

    There are running jokes about how Amazon Alexa and Google Home are susceptible to visitors in your home. It’s become a bit of test from some geeks who will walk in your house and call “Hey, Alexa” out loud to see if you have a device that’s available. I even had an accidental Siri activation while recording some content recently. I said something that started Siri listening on my phone and then a few people nearby kept trying to duplicate the effort. Fortunately Siri wouldn’t come on, so no one was able to cause too much trouble. I suspect that the speakers in the recording room weren’t positioned well enough to allow the control room based hacking.

    I know that will change. In fact, even if Apple and other companies manage to get digital assistants to recognize specific people’s voices (as rumored), technology marches on. People are already starting to fake audio data. The fidelity of digital recording and capabilities of speakers improve constantly. This is going to be a greater and greater issue over time, and I have no idea what security technique will prevent things. Maybe we need two factor authentication for audio commands? Won’t that defeat the purpose?

    As data professionals, we are going to be dealing with more and more types of data, and trying to process, analyze, and act on information. This is one reason that I think understanding data lakes and being able to import and combine many types and formats of data will be a valuable skill for all data professionals. Whether you use something like Azure Data Lake or another platform, I expect to be combining data in all sorts of ways and providing information to users.

    While speech recognition might not be something many of us worry about, will we want to extract information from audio or video and use it? Do we expect that audio files have more integrity than other sources? I worry that we give some types of data more veracity than others, when all types are subject to hacking. Some of us may get audio files as data, and it’s only a matter of time before we get hacked, perhaps with fake audio.

    One of the issues we have with some data is determining the source of record. If I record my voice as a sample, and you compare all future audio of me to that sample, you can verify my identity, right? What if someone can fake my voice with simple software? It sounds crazy, but those days are coming, especially if our systems are susceptible to a person stitching together words from different captures, such as some of Baracksdubs. What might be worse is when we find someone hacking a database and replacing the samples. What’s the source of record then?

    As I spend more time in this business, I become more convinced that auditing and monitoring are more important that security. We want them all, but I’d rather know I have an issue than assume my systems are protected because the security doesn’t appear to be broken.

    Steve Jones

     

  • Looking Back at Build–CosmosDB

    Part of a series looking back at Build 2017, going over the 20+ pages of notes I took.

    One of the big announcements at Build 2017 was the release of CosmosDB. This is a rebranding of DocumentDB, the document store in Azure, with some additional capabilities. You can also choose to store as

    • Column-family (columnar)
    • Key-Value
    • Graph

    The service is interesting in that it supports the MondoDB and Gremlin protocols for querying, which should allow some people to consider Azure instead of those platforms. The announcement was interesting from the data perspective. Microsoft focused a decent amount of time on this platform, and certainly people at the conference were very interested in the offering. Quite a few developers were thinking this would replace SQL Server, since it has some nice capabilities.

    One of the big ones is that CosmosDB offers < 10ms latency for reads and < 15ms for writes. They scale up to millions of transactions/sec, and also grow to PBs in size. There are some good guarantees for the database.

    They call it infinite, but that’s a marketing term. There’s a limit, and there certainly may be a limit you’re willing to store in the service. Jet.com was the featured customer and they talked about how much data they used and how they can scale the platform. I’m sure they went with DocumentDB and moved over, but they have their story in the keynote, if you want to watch. They get over 100 trillion, yes trillion, CosmosDB transactions/day. No matter what you do, a trillion of anything is a lot.

    Perhaps the more interesting thing is that Azure is offering five different consistency models in CosmosDB. They are

    • Strong
    • Bound Staleness
    • Session
    • Consistent Prefix
    • Eventual

    I don’t know how well these are supported in other platforms, but I like to see that developers have a choice. I’m not sure how many will understand the trade-offs and implications, and how many will get burned by choosing one over the others, but I’m glad the choice exists.

    They are also saying a money back guarantee. What that means, or how you get money back, is going to be something to see. I haven’t always been thrilled with the disclosure in billing for new parts of Azure services, but perhaps there is going to be some way to request credit, though I would hope that any telemetry that shows issues results in some credit.

    The other good thing is that the SLA is guaranteed across multiple dimensions: latency, throughput, availability, and consistency.

    Rimme Nehme, who demo’d the product, had an interesting quote. It was something like “developers can concentrate on the app, not the database.” Forgive me if I’ve slightly misquoted as I’m going from notes. While I cringe a bit as a data person, I do know that most developers don’t want to really work deep in the database, especially for many simple apps. If I were building some simple mobile app, I’d seriously look at CosmosDB, and I plan to learn a bit about it.

  • The History of the World, I Guess

    The lighter side. From my kids, and since there’s some science and it reminded me of the Big Bang Theory.

    Have fun.

  • Naming Conventions for the Cloud

    There are plenty of controversial topics in technology to write about. Today I want to combine two of them into one piece: the cloud and naming standards. I’ll leave tabs v spaces and language choices for another day.

    I like the cloud, and I especially like Azure. I’m not sure that it fits with most applications and organizations and at times I question the value for some parts of the platform, but overall, the ideas are great. I tend to work more in Azure because I’m an MS stack person, but I suspect AWS and the Google Cloud Platform are similar. Many of the cloud platforms, or even the various services from vendors like Rackspace offer lots of opportunity and an amazing set of platform services.

    However, as there are more and more options, tracking the various items and services that you are using becomes an issue. This isn’t a new problem, and I’ve faced the same issue in large Fortune companies. Inventory and management of any technology at scale is hard. This brings me to naming standards. Many of you have probably dealt with naming standards in development and perhaps argued about the choices that your team uses.

    There are also issues for infrastructure, which can be more complex and problematic in the cloud. Because we don’t have complete control over devices, we are limited to managing our objects through interfaces. At least in my data center I can fall back on labeling or connecting to a physical box to determine what services are running. Or even turning a system off to see who complains, something I’ve had to do in the past.

    In the cloud, the world gets confusing quickly because we have many more types of services. Not only items like VMs and databases, but we can have network interfaces, disks, storage accounts, load balancers, and more. In fact, the list in Azure has gotten extremely long. The addition of things like Azure Functions and Azure Logic Apps have me worried that we’ll start to lose control of our infrastructure. The one thing that I appreciate is Resource Groups, which allow me to put groups of items together.

    However, even with these tools, I sometimes find myself confused over what’s running. When I ran across John Paul Cook’s post on naming standards, I realized that I needed to get better organized with my resources. Having some sort of naming standard might help me quickly identify items and keep my portal organized. Even with the various icons, sometimes I get them confused because there are so many different possible icons and services. With a prefix and a resource group, maybe I’ll be better able to track which items I need to keep and which I don’t.

    As you grow the number of anything, the overhead for organization and management grows. It becomes more important to track what you have and use, especially when you’re being charged by the resource. I expect that many of us will be answering questions and reporting on not only usage and performance, but also cost for some part of our jobs as more applications move to the cloud.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 5MB) podcast or subscribe to the feed at iTunes and Libsyn.