Voice of the DBA

Category: Editorial

  • Up, Up, and Away

    I’m leaving tonight.

    Not forever, but for a couple of weeks. While that’s not a big deal for many people, I’ve rarely been away from home for more than a week. My longest business trips have been 11 days. Short, I know, but that’s the way I like things. Many of my colleagues think nothing of taking trips for multiple weeks, traveling the entire time. However, even during my six week sabbatical, I was at home the majority of the time. Perhaps that will change as my children get older since my wife likes to travel, but we’ll see. Certainly I’ve started to get used to living out of a suitcase, working on a laptop, and having minimal material things around. I expect the next few years will have me working out of our horse trailer as my wife teaches clients or participates in races.

    I’m looking forward to the trip, which will be a dichotomy of both relaxation and busy work times. I first start off with a week’s vacation in Scotland with my wife. She’s never been, and it’s been nearly 30 years for me, so we’ll take some time and wander around the Edinburgh area. I’m looking forward to the chance to wander around without an agenda and enjoy another culture. I’ve gotten a few ideas from friends on places to visit, and might even enhance the adventure by renting a car. I’ve driven (briefly) on the left side of the road, but it was a stressful experience.

    After a week of vacation, my wife and I will part at Heathrow airport, flying in opposite directions. While she returns to Denver, I’m going East, to Oslo for SQL Saturday #532. This is my first trip to Norway, and I’m looking forward to it. I arrive early Friday, so I have the chance to wander around a bit before the event Saturday. Then it’s back to the UK early Sunday since I’ll probably need to do laundry and get ready for a work week.

    My second week will be in the Redgate Software offices, but it’s a busy week. This is our Down Tools Week, with a number of projects that I’m interested in. I had hoped to be able to focus on one all week, but that won’t be the case. I’ve got SQL in the City preparations to begin, as well as a trip to London to deliver a talk on Tuesday at the London SQL Meetup. I suspect I’ll be doing something different each day, including some catchup with the great work our development teams are doing on various products.

    I finish off the trip at SQL Saturday #520 in Cambridge, where I’ll be giving a short, quick keynote to kick off the day. That’s exciting, and will make for a long day as I also have two more sessions to deliver. Then it’s back down to Heathrow that evening to begin my journey home.

    I am very fortunate to be able to travel around the world, speaking about SQL Server and meeting some amazing data professionals. It can be hard, but it’s always enjoyable and I look forward to shaking hands with many new and current friends on this journey.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Better Coding

    When the census was last taken in the US, it was still mostly a paper affair. My wife and I sat down with the form, filled it out, and mailed it back to the US government. While much of the data is publicly available, the process of gathering the data was primarily an analog process. That was in 2010, and governments are trying to do things differently. I suspect our 2020 census in the US will be mostly a digital effort, though I hope the companies setting up the applications learn from other countries’ issues.

    Australia had their census this year, 2016, and they planned on having most citizens complete the form online, with a requirement to opt-in to get the paper version. However, things didn’t go smoothly. There was a DDOS attack on the night the census was set to collect data. There were also concerns from many people over data privacy. All in all, not a great showing for the Australian Bureau of Statistics and their IT contractors. Things got worse in the weekend after the census was scheduled when a few university students built a website designed to handle a larger load than the government over a weekend for substantially less money.

    To be fair, the university students’ site wouldn’t necessarily meet all the requirements for privacy and data security. It also doesn’t seem to have the validation and verification that a website needs. Not to mention a database setup to keep the data for later analysis. Those things would certainly need to be added and tested, but this does show that sometimes there are better ways to develop software than the way that has been done in the past. Large government projects get bogged down, perhaps worse than many corporate projects, but I’m not sure. Perhaps we just need people that code better, and certainly, people that manage developers better.

    Certainly the cost of projects for the things like the census might not go down much. After all, I’m sure a fair amount of the cost charged by IBM goes back to the salespeople and engineers responsible for landing the contract. However, I also think that far too often there is too much overhead in large projects starts to obscure the most important part of any software system: it needs to work. I would prefer that even long term, large scale projects be developed in an agile fashion, and take on beta testers throughout (public or private). Let actual users play with the site in advance, report bugs, simulate a load, even watch the site develop in real time.

    And when you’re ready to deploy, from experience, I can tell you it’s not too hard to delete all that transactional data before you go live.

    Steve Jones

    The Voice of the DBA Podcast

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

  • The Future for Database Administrators

    I’ve been working in technology for over 25 years. As I look forward in time, I suspect I have less time left in a data professional career than I’ve already experienced. That’s fine, and while I don’t plan on retiring anytime soon, I know I likely will retire before another 25 years pass.

    While it might not be as much of an issue for me, I do think it’s important to think about where your career may go. I ran across this post on the future of IT Pros and thought, “this sounds familiar.” A friend I knew used to manage a 20,000+ Exchange system for a large company. In 2000, he was sure that the advances in email technology from Microsoft would mean that he wouldn’t have a job in five years. Within two he had moved on to another industry altogether, trying to establish a new career before he was made obsolete.

    Certainly if he had planned to still manage a 20,000 mailbox Exchange system the same way today, he’d be out of a job. However, if he evolved to either learn new skills along with Exchange, or added O365 administration, he might still be employed, and earning a very good salary in technology. Likely more than he makes now.

    I think about this regularly as I see the Microsoft stack world changing and the emergence of new database technologies like NoSQL, data lakes, and Azure SQL Databases/Azure Data Warehouses. Those technologies certainly might mean that less DBAs are needed to actually install, back up, manage, and care for on-premise database instances. However, I still think there are plenty of opportunities for the Database Administrator. High Availability and Disaster Recovery technologies are more in demand than ever, and there is a complexity in Availability Groups that ensures there are still good jobs. Increasing security and auditing requirements require humans, usually with knowledge about querying and understanding the data more than setting up the technology.

    The bar may be raising in terms of skills needed from database IT pros, but I still see lots of opportunity. Continue to work on your career, learn more, adapt, work hard, and you’ll have a job for a long time. Try to ride out the next few years on the same skills you’ve used for the last decade, and it’s entirely possible you’ll find yourself replaced by either a piece of software or another human that’s willing to learn a few new tricks.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Security Leaks from Websites

    One of the main issues with connecting databases to the Internet is that if a hacker finds a way to get access to the database with credentials, perhaps using a well known account (*cough* sa *cough*) and a weak password, they can get a lots of data. However, even if your database is not on a DMZ or addressable from the Internet, chances are some application that accesses your database is connected to the Internet. Websites are a perfect example of this.

    That means our data security is controlled by the security of the web application, and the security coding practices of our developers. That’s a scary in many cases, primarily because we, as an industry, don’t do a good job of actually sharing secure coding practices and habits widely. As much as people talk about and publish information about writing secure code, this doesn’t get spread around to many developers, who have years and years of bad habits. Even here at SQLServerCentral, we don’t have nearly enough information on SQL Injection, which is something I need to work on.

    However, even if you aren’t exposing your database server and aren’t vulnerable to SQL Injection, is your data secure? I read a rather sad article from Troy Hunt that looks at how personal data can be leaked. Far too many applications don’t follow secure information handling practices and unintentionally allow information to leak. Perhaps the most common item is verifying whether an account or email address actually exists or not in a login or password reset box. There are other examples, including not properly securing an entire page with SSL, allowing a simple thing like an order number to return user details, or even allowing someone to reset a password by guessing the answer to a security question.

    These seemingly benign issues often expose real vulnerabilities. I’m sure many managers and even developers would say that a hacker wouldn’t sit at a web page and try lots of email addresses. That’s probably true. However, does your web application have limits for how often someone can submit code? Extremely powerful scripting tools like Perl, Python, and PowerShell mean that a user could make submissions to your website in an automated fashion, retrieving the code and parsing it to find details.

    Most attacks on a system aren’t of the Hollywood movie variety. A hacker doesn’t find some hole and miraculously gain access to data in a few minutes or hours. Instead, a malicious user (outside or inside your organization), might make a series of attacks across days or weeks. They might try millions of emails or order numbers, gathering details and planning their future attacks that will actually reveal sensitive information. All those tools that make your job easier as a developer, or allow complex data analysis, can work just as well against your database as they do with your data.

    Steve Jones

    The Voice of the DBA Podcast

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