Voice of the DBA

Author: way0utwest

  • DevOps and OSS Can Scale

    Microsoft has changed quite dramatically in the last decade, in many ways. One of the more surprising ways to me is their embracing of open source software, while still building products that customers want and use. This is quite a change from the Microsoft that I knew back in the early 90s when I started working with SQL Server. Open Source software was seen as a complete anathema to the Microsoft way.

    One of the very interesting ways that Microsoft works in the open is their use of GitHub as a VCS (version control system) for many projects. From .NET to Azure Data Studio to the new virtual kubelet code, thousands of Microsoft engineers are writing and committing code in a very transparent way. Not all their products are here, but there are more than I would have ever expected.

    Part of the challenge of using a (formerly) third party platform is the infrastructure and administration of users. Microsoft has a scale issue here that most us do not deal with. While we work with dozens or hundreds of developers, they deal with thousands. There’s a good blog post about how they’ve scaled up to ensure 25,000+ developers can work.

    The post has lots of information, both at a high, conceptual level as well as at a detailed, technical level in places. Some of the big themes I see in the post is that automation is important, and that there are tools that facilitate the collaboration of their developers by sharing information, triggering notices and reminders, and by enabling the discovery of others. Collaboration is a huge part of DevOps, and the more software can encourage this while reducing the burdens of tedious work, the better the system works.

    None of this works without a culture change. If Microsoft can do this with thousands of developers and thousands more non-technical staff, any of us can. Microsoft has grown in the recent years to be one of the more valuable companies on the planet. Many of our organizations can learn from this by adopting DevOps, but not just in name or at a technical level. The technical tools are easy, but to get your organization to perform better, you need to ensure culture grows with the Three Ways and a team environment. Let your management know that you can all do better, but only if they truly embrace all the concepts of DevOps, teamwork, feedback, and learning from our previous actions to drive continuous improvement.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Investigating Azure Databricks

    At SQL Saturday #884 – Pensacola, I dropped into Rodney Ladrum’s session on Azure Databricks (ADB) and the Traditional DBA. I had heard a bit about Databricks, and read a little, but I didn’t really know much more than a rough overview. I’ve heard quite a bit from Microsoft about running Databricks notebooks, but I didn’t necessarily know what that meant.

    I was hoping to learn a bit, and I did. This wasn’t really a Databricks session, but a look at how you might need to manage and work with Databricks as a DBA. This assumes that there are data scientists or other data engineers that need to work with and process data, choosing to do so with R, Python, or Scala, but wanting to use Databricks notebooks.

    I need to learn more, and stumbled on 30 days of Databricks. I can’t get to that right now, but I added a subscription to remind me to come back. Between Rodney’s session showing me the basics of working with this in Azure and the intro video, I know a tiny bit about the technology.

    Databricks is a company and a way of managing and running Spark analysis. Apache Spark is an open source project that implements an analytics engine. However, it’s complex to run, so Datarbricks (the platform) is used to make this easier. Azure Databricks is an implementation of what Databricks sells, under license I assume.

    I know a little more, as there are notebooks that can be executed under the Databricks engine, and the code in here can be bash, R, Python, Scala, probably something else.

    That’s my start. I’ll learn more over time. If I find time.

  • The Changing Nature of Data

    Are addresses sensitive or private information? It’s a good question to ask since many of us have address data in our databases. I asked this recently at a SQL in the City event and the room was split. I come down on the side of “no”, for addresses in and of themselves. After all, the domain of addresses is known. It’s public information in most every country.

    A few people pointed out that while the address isn’t private data, when it’s linked to a particular person, it is private. It’s not the address, but the linkage. To me this should give data modelers pause when trying to set up a schema, whether set in an RDBMS or a schema on read in some other type of data store. Separating the user from the address, and having a link that doesn’t necessarily disclose private information can reduce the surface area of sensitive data in your system.

    A second question: have you ever worried about your name being on a door or mailbox? I know some people in larger cities have, but that might be a minority. As I’ve visited friends, a name is often valuable to see on a mailbox, especially in my rural area where houses aren’t very visible from a road. That might change, or need to change. An article in the Washington Post notes that in Vienna names are being replaced with numbers. The linkage to an actual person is being removed in response to a complaint. It this overkill? I don’t know, but it is worth thinking about.

    Google Street View and similar services might be affected. The service blurs faces, but it might need to start blurring addresses or even houses. I’m not sure I think that the images are problematic from a privacy perspective, but I also know that the ability to harvest data remotely and create linkages occurs at a scale and with a creativity that I would never have imagined.

    Could a set of thieves search for people posting a vacation notice, image search for a house and then start correlating those images with Google Street View to find addresses? Sure, though arguably a search of public records for ownership might be easier. Many people rent, so maybe this is a bigger issue than I think? I’m not sure, and really, trying to determine how criminals might use data hurts my head.

    I do try not to be too paranoid, but I do get concerned about data privacy. The stories of abuse I hear in the world are truly stunning. The creativity of criminals is scary. I don’t know where to draw the lines, but I do think that we should neither be cavalier with data nor paranoid. There’s a balance to be found, but one that needs debate and deep thought, not casual dismissal or overreaching concern. I hope as a society that we move in the direction of careful consideration as we derive some framework for both the protection and use of personal data.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Learning more Kubernetes

    I’ve been slowly working my way through the 50 days of Kubernetes (K8s). As you might have guessed if you remember my first post, this has been more than 30 days. Life and work get in the way, but I’m working through the series of posts and videos.

    A couple of interesting things I’ve watched lately:

    Serverless Kubernetes and Serverless on Kubernetes – I worry about the idea of containers needing to spin up to meet serverless workloads, but maybe not. It’s a few ms for these containers to spin up, especially for small functional environments like Python or .NET. I suppose if there are issues, you can schedule more pods to be available or more replica sets to spread the load. This makes sense to me, and containers are often a perfect use for this on Kubernetes since you want to have lots of small items, but one large endpoint for people to hit things. I suspect this is how the FaaS implementations work on Azure and AWS.

    This video also talks about the need for a virtual kublet to allow the API to get things ready, without having underlying VMs, a prerequisite for scheduling items on the cloud. This is the serverless kubernetes concept. I’m not sure I completely understand this, but I get the idea here. We don’t have hardware provisioned, we’re running Kubernetes, and we want to push some of our load into the cloud. Since we don’t have a node assigned to us, we want to schedule on a virtual node that the cloud provider will actually spin up when we hit it.

    Fascinating and not something I’d have thought of before I saw this video.

    How the Kubernetes Scheduler Works –  This is interesting. Scheduling workloads and pods in different places is important. Flexibility while meeting demands matters. The idea of hard (required) and soft (optional or preferences) constraints for choosing where to run pods is fascinating. Another video by Brendon Burns. Most of us might care about these items since we may want some spreading assurances for instances or minimum resource requirements for our instances.

    For example, we might have a hard constraint that our pod (container) needs 128GB of RAM. This might limit the nodes that we want to run this pod on, and the scheduler takes this hard constraint into its decision making process.

    For soft constraints, we might prefer that a reporting instance not run on the same node as a OLTP instance, but if there are no nodes available, perhaps we’d live with this. That’s a soft constraint, and the scheduler tries to honor these, but it isn’t bound to prevent scheduling on those nodes.