Voice of the DBA

Category: Editorial

  • Capture the Flag

    I’ve read a lot of science fiction in my life. Quite a few books talk about cyberspace and the interactions of humans and software. In Snowcrash there are AI systems defending systems. The Unincorporated Man series has AI systems that not only have sentience, they hide their capabilities from humans. Numerous other examples exist, including movies such as The Matrix, which popularized system programs independently able to evaluate and react to security issues.

    Science fiction is here, showcased recently at the DARPA Cyber Grand Challenge. You can watch a bit about the challenge or read a short article about what happened. Overall, it’s amazing. Seven systems ran various pieces of software that were targeted at finding vulnerabilities, patching their own and exploiting those of other systems. All without human intervention.

    In a visualization, I picture a team of Agent Smiths (from the Matrix) seeking out rogue programs that seek to wreck havoc inside of the operating environment. Or maybe a series of automated developers tracking down bugs, such as buffer overflows and correcting the code to remove the issue.

    Is this where static code analysis is heading? Automated repair, or maybe even real time repair? Could we actually have a software bot that might run through your Entity Framework (EF) application, tracking down SQL Injection vulnerabilities and correcting them? Even at a rudimentary level, I can imagine a bot that examines incorrectly parameterized queries and rewrites the code to properly manage the .NET code. Perhaps at some point we’ll even have bots that can understand queries from some application and build stored procedures on the fly that accept parameters, are called the next time a particular method is called, and can even grow to evolve with schema changes.

    I know the simplistic ways in which we might build this code would have their own sorts of issues, but I’m hopeful that at some point we’ll have semi-intelligent bots that can fix code to ensure it’s secure and reliable, while keeping the creativity originally built by the human developer.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Analyzing Data in Real Time

    A few years ago I was listening to a presentation from Microsoft where they touted a customer that had real time analytics with Analysis Services. Since my exposure had been that cubes needed to be processed, a resource intensive process, I was wondering what this meant. Imagine my surprise to hear that the cube was being updated within 5 seconds of the changes in the OLTP system. Talk about real time.

    Of course, the definition of real time isn’t really well known. We linked a piece in this week’s newsletter that looks at a survey of companies and their investment in real time, streaming, data movement pipelines. The definitions from companies about real time range from sub-second to 24 hours. I’m sure I think that 24 hours is real time, but if you’re used to processing cubes weekly, maybe that feels real time. I tend to see real time on the order of minutes, maybe a few tens of minutes. Once we get to hours, that feels more like batch processing, albeit fairly rapid batch work.

    I am sure there are systems that need real time analysis, especially in some areas where decisions must be made quickly. As we move to more and more machine learning algorithms and automated intelligence, there will certainly be more call for real-time data movement. Yet another opportunity for data professionals, especially those that work with ETL pipelines. There will be tough problems, not only with moving data, but tracking lineage, recovering from issues, even weeding out bad data quickly.

    However, that’s an opportunity for you, not me. I bet there are a few data professionals out there that feel the way I do. There are great challenges in solving real time problems, and building systems that can handle high volumes of data. The thing is, I value my sleep. I value not working all-nighters, I value a balance in my life. While I find the problems fascinating and the money involved tempting, I prefer to work on more pedestrian systems.

    I’m glad there are people that want to work on very difficult problems, and I wish you all the best in taking advantage of these opportunities. I hope you’re well paid, and you have a great time building these impressive systems. I also hope to read about some of the amazing things you do, so please, share the knowledge where you can. This is a great, exciting time to work with data, and it’s one that I continue to enjoy every day.

    Steve Jones

     

  • Are You a Tech Company?

    Are you a tech company. That’s an interesting question. I’m sure some of you might not think so, working for a commercial organization that has some physical product you sell or some service you provide. You might not consider yourself a tech company. However, your organization might be, at least according to this essay at Medium.

    I certainly think software has changed, and will continue to change the world. I think data becomes is an important part of our system, but in conjunction with software and the ease with which we can gather, process, extract, and analyze the information inside of our data. In order to do that, I do believe that we need ways to better build and deploy software, whether that’s database software or application software.

    To do that, can we be afraid of mistakes? I think not. The opening premise of the piece is looking at rapid delivery from two points of view. Can a system be secure if you change it multiple times a day? Or perhaps it can’t be secure if you don’t have the ability to change things. Either view could be true, and most of us lean one way or the other. My view is towards the latter, not because I want to release multiple times a day, but because if there are issues, bugs, or security holes, I need to be able to change my software that day. I can’t wait for weeks or months.

    That’s one of the problems I’ve seen with quite a few systems in the past. The time to release a new version, to patch an issue, is far, far too long when potentially hundreds, or thousands, of malicious attackers could take advantage of a flaw this week. Or our company could lose customers because a feature is broken for long periods of time. While I don’t think the cost of fixing mistakes is zero, I do think that the cost of not fixing issues is also more than zero. Certainly at times the cost of not fixing something might be much, much higher than our organization would tolerate.

    Mistakes will happen. However, the point the essay makes is valid. We should learn from mistakes, and not try to avoid them, but continually push forward to improve our software. Above all, we need to find ways to engage our employees and get them to believe they can produce better software and are empowered to do so.

    Steve Jones

    The Voice of the DBA Podcast

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

  • The 10X Programmer

    Is there such a thing as a 10x programmer? It’s an interesting idea, and one that is discussed from a few perspectives in this Q&A. There’s some talk about how to define “x” as well as the idea that the environment and project might make a big difference in productivity. Certainly the baseline of the staff measured makes a difference. If most of your programmers aren’t very productive, then a more talented developer might easily outperform the average by a factor of 10. Depending on how you measure productivity.

    I wonder, though, is there a 10x DBA or database developer? What would that look like? If we examined the effectiveness of a DBA managing systems, I have seen DBAs that managed 10x the absolute number of databases and instances. Working inefficiently, connecting the individual systems to apply updates or check statuses could easily make you ten times less efficient then the DBA making use of scripting and the ability to apply changes across many systems, not to mention managing them for issues.

    In terms of database development, if we have some programmers that can produce code using 10x less resources than others, I’d consider that a 10x programmer. Given the state of questions I see asked on SQLServerCentral and other sites, it definitely seems that there are plenty of developers being paid to produce poorly written T-SQL code. We don’t have great definitions of how we can measure productivity, but there is plenty of code posted that can be dramatically optimized. It’s the rare week that I don’t see someone noting they’ve reduced the runtime of some code from hours to minutes. Isn’t that 10x more productive?

    Ultimately one of the amazing things about software is that we aren’t bound to a particular structure once it’s created and used. We can quickly, and easily, change the way the code is built so that it works differently, does more, runs efficiently, or really anything we want. Of course, testing that the code produces the desired effects and deploying that to different environments in a way that minimally impacts clients is a challenge, but a challenge many in our industry work on constantly, seeking improvement.

    I think there are definitely 10x programmers, but that really depends on your situation and how you utilize the people working for you.

    Steve Jones

    The Voice of the DBA Podcast

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