Voice of the DBA

Category: Editorial

  • The Hybrid Cloud

    When various vendors started to push the idea of using the cloud for computing infrastructure, the focus was on moving all your systems to a hosted solution. It didn’t matter if you were interested in IaaS, SaaS, or PaaS solutions, there press from salespeople and even some technology professionals was for a complete migration. Put all your infrastructure in AWS, Azure, or some other place and your systems will run great.

    Over time we’ve started to realize that moving to the cloud isn’t as simple as just renting a new box or service and there may be plenty of work to get settled. Even then, there are some limitations or restrictions, either technical or otherwise that might make the cloud a poor choice. Security and compliance are often reasons to not move, but certainly there are also challenges with technology mismatches between on-premises and cloud platforms as well.

    One of the very interesting things that I saw demonstrated a few years ago was the idea of the Azure Stack. The idea behind this technology is that a hybrid cloud can be built, with a single management view. Both the Azure cloud and local resources are combined together and managed as a single entity, with the choice of whether to run workloads on the vendor’s infrastructure or your own on-premises machines. There are other versions of this, for example, with OpenStack working in conjunction with AWS.

    There are many advantages to this, including the ability to limit certain workloads from bursting or moving from one environment to the other. One reason for this might be compliance. An organization might be required to keep some resources off of public networks, for example, the need to ensure that certain data is domiciled in a particular country. The reverse could also be true, with the desire to use a secure public portion of the Azure stack as their system might be certified in ways that your local infrastructure may not be.

    I think the idea of cloud resources, managed, moved, and scaled as needed is a great one. It doesn’t matter if this is all in your data center, all in the cloud, or both. Working this way allows a much more flexible use of any resource, wherever its located. Cutting edge organizations already do a small portion of this with ESX or Hyper-V hypervisors, software configured storage networks, or other software configured resources that can be reallocated on demand. Azure Stack, OpenStack, and other frameworks are a great way to start to leverage the cloud, but in a controlled manner that continues to use any capital investments you’ve made.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Republish: I Feel Like a Magician

    I’m off in the UK and buried with other work, so a republish today.

    I Feel Like a Magician

  • We Don’t Have Perfect Information

    I was discussing the PASS Summit with someone and they were wondering about building their schedule. Actually, they wanted to pick sessions, but see the choices in a calendar format, but the schedule wasn’t out. My suggestion was to just build the schedule and then sort out conflicts later.
    A few people have mentioned over the years that they want to build a schedule and be ready for the event to maximize their experience and be efficient. I think that’s a common, normal, technical person thing to do. We’re Type-A, we like knowing and having a set schedule.
    The problem is that we don’t have perfect information. Even if the descriptions and abstracts included perfect information about the agendas, what is covered, and to what depth, including demos, we’d still not necessarily assimilate and recognize all that data. We’d think a session on database design covered fourth normal form, even when the text said third normal, or we’d expect that an SSIS data load talk included something on CSVs when the presenter described the talk as being with flag text files.
    We’re human, and that means we have flaws in how we deal with the world. This includes the ways in which we model and analyze data. While we can make mistakes in our analysis, we often may simplify our view of a problem to the point where our analysis is inherently flawed.
    I try to remember this when I write reports from systems that others will use. I won’t have every piece of information that might affect a system, but I try to ensure I have the most important, or significant, data. At least, the data I (and the users) feel is significant. The important thing to remember is that out data is always incomplete, and it’s entirely possible that we have missed a valuable piece of data.
    When that happens, we have to adapt and adjust our systems, just like our conference schedule. We’ll learn more across time and we can use that information to change our system. I know that my view of a conference like the PASS Summit today, or even a week before the event, will be different than what I know, and how I feel, at the event. I should have a plan, but be willing to flex as circumstances change.
    Steve Jones

  • Data Clarity

    There was an Associated Press (AP) report recently that noted Google applications track your location, even if you’re turned off Location History on your Android phone. The article has details about what the AP noted, as well as the report from some researchers that were testing the functionality. You can read the details, but the issue doesn’t seem to be as simple as the headline of the report.

    Google has responded to the claims, saying that they document and explain the various settings that need to be changed in the applications themselves to prevent any tracking. That might be the case in the eyes of the engineers that built the functionality, but I would tend to argue that the expectations, the descriptions, and explanations we use as technology professionals might not be clear enough for most users. We ought to be documenting, explaining, and even coding systems for users that aren’t as familiar as we are with the technology.

    This is an interesting issue. Not the location tracking, since I assume Apple, Google, government, and more can track my phone if they really want. To me, the issue is that we have data practices that are not clear to the end user. What Google documents, what they do with new services and features, and what the clients expect are not necessarily the same. That’s an issue, and I suspect it’s a similar issue for many companies.

    Most of us collect some level of detail from our software on how the user interacts with it. This might be a local log, or it might be some sort of telemetry, similar to what Microsoft collects from SQL Server. In either case, I think it’s important to spell out what data is being collected and to what extent this data is related to a specific individual or company. The changes to data handling as a result of the GDPR and other legislation might require that we do a better job of disclosing any data we collect, and in which specific circumstances.

    I know that data matters, but I also think that lots of the information that is collected doesn’t need to be related to a specific individual. Aggregates or tokenized data is often enough, though if you need to track a particular individual over time, such as the features they use in their install, be sure that you are very careful with any sensitive data, such as names, locations, etc. Most of us don’t have Google’s resources to combat legal action if customers find we are infringing on their privacy.

    Steve Jones

    The Voice of the DBA Podcast

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