Voice of the DBA

Author: way0utwest

  • Are Windows Containers a Good Choice?

    I like containers. I think they’re the future of the SQL Server data platform. I also think this is likely on Linux, with Linux versions of SQL Server. You might disagree, and that’s fine, but that is where I see this moving over time.

    Why? I ran across a great post from Joey D’Antoni of DCAC that outlines one reason: Kubernetes. This is the way we will start to orchestrate SQL Server instances in the future, whether disparate or scaled-out, and this is really Linux technology. If you go Linux, with Kubernetes and containers, you’ll be able to easily move your systems as needed from your data center to developer machines (perhaps with SQL Provision from Redgate), to the Azure cloud, or over to the AWS cloud, a partner Kubernetes install, etc. It’s flexible.

    Windows Kubernetes will be less flexible. Inherently because less people use it, while more and more people are using, supporting and deploying Kubernetes on Linux.

    This won’t happen soon, as I think it’s 5-10 years before a good majority of SQL Server moves to 2019+ and containers become more mainstream for app and data work, but this shift is starting.

    This also doesn’t mean Windows goes away. I really like Windows. I’m comfortable with it, and I plan on having a Windows laptop for the forseeable future. What’s more, I can run Linux containers on Windows, thanks to the WSL. Even Microsoft sees containers with Linux as a future on Windows.

    Like Joey, I don’t want to dismiss or denigrate any work for Windows containers. I think it’s a good idea, and certainly some people will want to run their Windows apps in Windows containers. I just don’t think it’s the future for the data platform.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • The AI Manager

    One of the advantages of a computer is that it will handle repetitive tasks very well. That’s one reason the DevOps world pushes for automation of simple tasks, like compiling code or copying files between machines. We know the software will perform the task the same way every time, giving us a reliable, repeatable process. Even in many AI systems, the structure of the program ensures some level of reliability, though the actual actions or results may vary dramatically based on the inputs.

    For some tasks, this is great. If we have a system watching for a change in code to rebuild the application, that’s certainly a job for a computer rather than a human. If a sensor needs to be checked and an action taken if it exceeds a value, certainly the watching ought to be done by software, though the actions may or may not be something we want a system to do without human input.

    In some sense, I likewise think that the use of AI to manage workers is a bad idea. This was something I read about in Manna, which seemed exxagerated when I first perused the story. Now it seems that some of this is coming true in this story about workers in a call center being manager by an AI system. There is a software on their machines that tracks their activity, the way they interact with customers, and more. If there are potential problems, the software tries to give them messages about how to alter their behavior. Many employees aren’t bothered by this, but I wonder if that will be the case over time, especially if this software starts to affect employment and pay decisions.

    I think this is micromanagement at a level I’d never want to work under. I know that some of these jobs are akin to factory jobs that make widgets, with employees doing the same thing over and over again. However, there also is some creativity and thought required, otherwise I’d assume an AI could just do the whole job. That might be coming, and I wouldn’t be surprised to see it, but as long as humans are working here, there ought to be plenty of human oversight.

    Could you see this in our industry? Maybe AI reminders that you’re slow to close a ticket, or not committing enough, or even that you’re not doing enough testing. It’s crazy to think that there could be software that companies use to manage developers and other technology staff.  My guess is most of you think this would be a poor idea, but I could see this becoming used in help desks and infrastructure at some point. If it works there, who knows what types of AI software might be deployed by companies.

    Perhaps more worrisome for many is that if this becomes a trend, this might affect the middle management levels in companies more than workers. One manager might do the job of 10s,  or even 100s, which is its own societal implications if we use less people as supervisors. Maybe this would make for more efficient companies, and hopefully, less meetings. I don’t know if I think that’s a good evolution of software being used to manage a process.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • 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.