Category: Editorial

  • All DevOps All Day

    There is no shortage of webinar events taking place for technology professionals. From our monthly Redgate DevOps webinars to the GroupBy conference to PASS Virtual chapters, there’s a huge set of online events that you can attend and learn from. It’s gotten to the point where you could have a full time job watching webinars if you could find someone to fund your efforts.

    Every year PASS does a 24 Hours of PASS, which is a neat event where 24 hour long sessions in a row are broadcast. It’s a lot of work to get this going, and certainly not many people want to watch 24 hours in a row, but it does seem to be fun. That same idea is being taken a step further tomorrow with All Day DevOps 2017.

    There’s still time to register and attend a few sessions, or even throw a party (or join one) with fellow technical professionals. Maybe this is a good way to take a break from work and still be productive. This might be one of the cheaper conferences you could attend this year. Maybe you can even convince the boss to get some t-shirts with the savings.

    As you might have guessed, I’m a part of this event. I submitted to DevOps East, a conference in Orlando next month, but they also picked me up for the online event, so I’ll be watching and speaking tomorrow. This is an interesting format as it’s not just 24 sessions. It’s over 100 sessions, with 2, 3, or 6 sessions going on at the same time. There are some long sessions, some short ones, all covering different aspects of what we call DevOps.

    Whether you think DevOps is a fad, the idea is silly, or are excited to start building software better and faster, I’d urge you to take a few minutes to scan the schedule and see if there is anything that catches your eye. You might learn a bit on how to change your culture, or improve security, or implement automation. There are even some testing sessions, which I’m looking forward to watching.

    Whether you’re a believer or a skeptic, learn a bit more about DevOps and have an informed opinion. Don’t just judge the movement on the media hype. Listen to some real technical people talk about the ways that they are trying to improve software.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Software Patents

    This editorial was originally published on Jan 30, 2014. It is being re-published as Steve is out of town.

    I highly dislike the current patent system in the US. I think awarding patents for an idea like “1-click purchasing” is a poor practice that discourages innovation. There are numerous problems with our patent system, not the least of which is that it can stifle new ideas and prevent small companies from building on similar ideas that are, well, what I’d all common sense. I don’t quite share Richard Stallman’s view of software patents, but I do think we have fundamental flaws in the way we handle this intellectual property.

    I do, however, think that software has value, and the work we do as software engineers deserves compensation, as noted in this post. We should have some patents, and we should reward those that create truly innovative, and not common sense, ideas in the digital world. How we define those, and how we measure innovation isn’t clear to me, but I do think that non-trivial ideas deserve protection.

    Our legal systems around the world are slow to catch up to the digital world, and may never do so. As quickly as we can debate patents, copyright, trademarks, and more, the digital world grows, expands, and changes to stretch and challenge our thinking of how the world works. It almost seems as though digital ideas and software defy analogies and explanations that we can relate to the real world.

    I don’t know how I’d change patents, but I don’t want them to go away completely. I do, however, know what I’d do with copyright. I’d change it back to the original system we had, granting 14 years exclusivity to creators, with a single option to renew for 14 years and that’s it. The world certainly changes too fast to wait 95 years to use someone else’s work.

  • The Cloud is Better In At Least One Way

    Many people don’t see the cloud platform as necessarily better run than what they do in their local data center. That might be true, and certainly the caliber of people, their experience, responsiveness, and more can make a big difference to the way in which any environment operates. One would like to think that AWS, Azure, Google Compute, etc. would all hire the best people and pay them more to operate a top notch system. I’m sure they have some of those people, but they also may have some average people that might not be better than your administrators.

    Corruption is something I’ve experienced a few times in my career, and it was incredibly scary each time. I’ve been on multi-day support calls, trying to recover data, exported out pages to reconstruct values, and had to have very difficult conversations with management and clients to let them know data is gone. I think the worst experiences for me were breaking the news to workers that would have to try and re-enter data. Many of them had lots of extra work to look forward to without extra pay.

    The Microsoft Azure team takes corruption seriously, and there’s a good description in this post of how they protect against and deal with corruption in Azure SQL Database. It’s quite comprehensive, and it’s a set of things that I wouldn’t expect most companies to implement. Even some of the better SQL Server people I know don’t necessarily get called in during off hours when a corruption alert fires. Plenty of people working with SQL Server might not have been through an Immersion event and understand how to even deal with corruption outside of calling Microsoft.

    The cloud is a vast array of service and settings, many of which we can manage ourselves. In those cases, certainly the cloud might not do a better job than we would. No one on a cloud vendor’s staff is going to manage your VM or help you ensure your database design is solid. However, in checking for corruption, ensuring disk level backups, watching for DDOS and other threat vectors, the cloud vendors certainly do a better job than most of us. And for corruption, Azure SQL Database seems better watched than most databases I’ve seen in my career.

    Steve Jones

    The Voice of the DBA Podcast

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

  • A Double Dose of Trouble

    It’s Friday the 13th, during the month of October. Halloween, a strange holiday associated with horrible events, and Friday the 13th, a bad luck day, are happening this month. Both are associated with horror movies, implying that this isn’t necessarily a good month for the world. It’s a double dose of bad luck, which is what Equifax would have you believe. I wrote about this yesterday, where the company would have you believe a single employee makes a mistake when a scanner fails, and hackers were ready to attack.

    I’ve, in general, had a lucky career. I’ve worked hard, and things have gone my way. That doesn’t mean I haven’t made mistakes or systems haven’t gone down, but overall things have gone well. As I think about Friday the 13th of October, I’m reminded about Murphy’s Law, where things that can go wrong, may just do so. I’ve tended to expect that some things will go wrong and prepare accordingly. In fact, in keeping with a corrollary that I’ve sometimes heard to Murphy’s law that if one thing goes wrong, I’d expect that something else will fail.

    On this double downer of a day, I’m wondering if you’ve experienced that. Have you had something bad happen at work, only to find that overshadowed by something worse? Hopefully you didn’t make a security mistake and then get hacked, but perhaps something else has broken?

    In my career, I’ve had this happen, though not directly to me. I consulted with a small company to make a little extra money and because I liked their business. I was rooting for them to succeed and wrote some database code to help speed up their application. One day they call me to say that a drive array failed with the database mdf on it. I wasn’t worried, and while in another state, I was ready to walk them through a restore process on the new array. Unfortunately, this was a default install, and the default backup path was on the old array. I hadn’t set this up, nor was I aware of their backup process.

    The lead developer was proud of himself. He’d made a backup the day before, using a file share on a network drive. He had the .bak file. I thought this would be a quick and easy call until he read the error message that not all media sets were provided. That’s when I realized that the developer, while making the backup in SSMS, hadn’t cleared the previous backup file from the dialog. He’d inadvertently created a striped backup.

    Eventually they managed to locate a backup that was many days old. I’m not sure how far back, but they angered a number of clients, who I’m sure all started looking for a new vendor. Eventually the company failed, and I moved on. There wasn’t much to be done in that situation, but it was a certainly double dose of things going wrong at the same time.

    I hope few of you have had double the bad luck in your career, but if you can share a story, we’re happy to commiserate with you.

    Steve Jones

    The Voice of the DBA Podcast

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