Voice of the DBA

Tag: Microsoft

  • Three Days and a Notebook

    This is a short week of work for me, really just today before heading off to attend Microsoft Build 2017. I’ll spend the rest of the week watching Microsoft show off their latest tools, ideas, technology, and more at the developer’s conference. I’m not speaking (I think) and am looking forward to three days of learning, watching, and getting excited about building software that for the most part depends on data in some way. I’m not sure what will be presented, as the schedule hadn’t been posted as of the time I wrote this, but I’m sure there will be plenty of Azure and SQL to go with all the Windows and .NET sessions. I’m especially interested in ways that DevOps is making its way into the Microsoft stack and looking forward to seeing the creative solutions out there.

    I haven’t attended Build since it was the PDC many years ago. It’s been since the early 2000’s when I went to a few of these events as a software developer. I first saw Microsoft showcase XML tools in the late 90s and tablets a few years later.  I always enjoyed these shows and after a few years off was looking forward to going back. Then they cancelled the event before it was reborn as Build. I’ve been trying to schedule a trip for the last 4 years, but scheduling keeps getting in the way. I know, it’s a hard life, and I’m not complaining. It’s been disappointing for me.

    Last year I was actually offered the chance to go speak on behalf of Redgate at a session, and I did go, but with volleyball trips planned with my daughter, I was in San Francisco about 24 hours, saw 1/2 of the keynote and part of one session (besides my own) and then left. Not much of a Build event for me. I didn’t even have time to go through the HoloLens line and give it a try. However, I had a few days with my daughter, so I can’t complain at all.

    This year I didn’t have anything scheduled for May and got the chance to register early. I plan to try and leave my computer in the hotel room and work little. Instead, I’ll walk around with my notebook, jot down ideas, and just think a bit about software, my career, and where Microsoft is going. This will be my thinking time for the week. Actually, I haven’t had much thinking time this year, so I’m looking forward to the break.

    I rarely attend any events or training without having some sort of commitment or responsibility these days. I try to fit in a few sessions or a pre-con here and there, but training time and focused time on something other than work is rare. For the first time in many years, I’ll actually going as an attendee and doing the things many of you do at SQL Saturdays, SQL Bits, the Pass Summit, and other events. I’ll be learning, focusing, racing from session to session, networking, and hopefully overdosing on new technology.

    I’ll try to summarize notes in a few blogs, and maybe even give a short recap as an editorial one day, but this should be a fun technology week for me.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Syntactic Sugar

    There are all sort of features and enhancements that Microsoft can make to the SQL Server platform. If you look around Connect, you’ll see suggestions for improvements, such adding common checks, as well as additions like adding virtual tables. I’m sure many of you would like to see simple things, like Regex added to the T-SQL language. In fact, you might find that some of these small changes, which we can code around or build, should just be added. After all, if Dynamic Data Masking can be added, shouldn’t some other simple features be included, such as helping us solve the “string or binary data truncated” error?

    These handy, useful, simple changes to the platform are often called syntactic sugar. These are changes that are simple, many of us could easily code them, but they make development easier. Or even administration in the case of the SQL Server platform. These are not necessarily expanding the power or capability of the platform, but they can make working on the system more enjoyable.

    Should Microsoft create more syntactic sugar for SQL Server? Certainly they do at times, but perhaps not as much as many of us would like. The thing to keep in mind is that making changes to the SQL Server platform can be very difficult and time consuming. Adding small features that might be helpful, while enticing, can slow the evolution and development of more core product features. Or they can cause more problems than we might expect in other parts of the platform. Would you rather have something like DDM that makes obfuscating some data easier, or a more robust replication engine that recovers from more problems? Do you want stronger security features like Always Encrypted, or more robust Always On features, or is it more important to get Regex added? I think we might have differing opinions here.

    These can be really hard questions, and certainly I think our feedback can help influence Microsoft. After all, if there is a nagging issue that is constantly causing issues, then maybe it’s worth a syntactic sugar improvement, even if this takes resources away from some other area. The one thing I hear from Microsoft over and over is that specific business cases and issues are more important than complaints. Express the issues you have with the platform in terms of workarounds, developer time lost, or specific performance issues rather than just a “I don’t like this” or something “doesn’t work as expected.”

    Ultimately Microsoft is a business, and they do look to add new features regularly to the platform to increase sales. I get that, and I try to temper my requests and complaints. I like to see them focus a portion of resources on core improvements to systems that work, and while I think this does happen, I’d like to see a bit more improvement in existing features. Certainly our backup and log reading systems have improved over time. SSMS is decoupled and being updated regularly. There is more work to be done, and if lots of us provide specific feedback, I’m sure we will see even more core improvement over time.

    Steve Jones

    The Voice of the DBA Podcast

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

  • DevOps at Microsoft

    I’ve been watching Microsoft for quite a few years, with my career being tightly intertwined with the company for 25 years.  I’m amazed by the way the company has changed in the last five years. It’s probably been longer than that, but from the outside, the last 5 years have been surprising. Certainly the way Microsoft produces software is a process worth studying by almost any organization with developers. There are some scale advantages Microsoft has, and their mission is to reach and touch people at a level far beyond what many of us deal with, but there are lessons to be learned.

    There’s a great piece that shows some of the ways in which Microsoft is practicing DevOps in their own software development. I like that the focus isn’t just that developers do more, but that operations staff are involved in working closely with the development teams. In fact, there’s a quote I like that notes in addition to technology changes and habits, ” we found that the organizational changes and cultural shifts required to embrace these practices have been just as significant.”

    As I talk about smoothing the database development pipeline and creating efficiency in the process, I want people to be aware that cultural change is required. My employer, Redgate Software, can sell you tools that solve the technology challenges, but if you don’t change the way you build software in your culture, with your staff, the tools don’t help. At best they make a few tasks easier for developers, but you will still have issues releasing your software consistently on your schedule, whatever that may be.

    There is also the emphasis on developers deciding when to release. In Microsoft’s domain, this probably works, but not likely for many line of business applications in organizations. However, the focus should be getting changes to customers quickly after development. The sooner they see features, the sooner they can provide feedback on whether the software works as expected or changes are needed. This quick feedback also means that developers have the architecture and flow of the code in their recent memory. Always a recipe for smoother continued development and quicker bug fixes.

    Testing isn’t emphasized much, though I think as developers become more accountable, and they can get changes to customers quicker, they’ll start to want automated testing that allows them to check for regressions, as well as ensure requirements are being met. Microsoft has the advantage that many of their internal teams can actually use the end product, something that isn’t always easy for those of us in other industries.

    DevOps works. The principles are sound, and it doesn’t matter if you’ve followed the principles for decades (maybe under another name) or just started a new process by asking for more coordination and collaboration from your teams. Learn to build a coherent system with your developers and operations staff, throughout your software development process, and your whole organization will benefit.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Another Re-Release

    If you haven’t noticed, SQL Server Release Services dropped an updated CU6 for SQL Server 2014 SP1 this week. This replaces a previous CU6 that had a NOLOCK bug in it, and the old KB article (and patch) have been deprecated. You can install the new CU#6 on top of the old one, and you should. The old patch could cause you some issues, so if you’ve applied CU#6 previously (build 12.0.4449), go download the updated patch, test it, and apply it to your instances.

    However, there’s a couple issues with the process here. First, re-releasing a patch under the same name (with a different build) is confusing. I am sure there are going to be plenty of people, especially accidental DBAs, that think they’ve applied CU 6, and they don’t realize there has been a change. There will be others that apply the patch from an old download that’s shared on their file system. I’d much rather have fixed patches released as a new CU. What does it matter if CU #7 is released now instead of in a few months? There’s no limit I’m aware of for the number of CUs allowed for a particular version, so let’s just increment numbers.

    The second issue, for me, is that this eats up time. Releasing quickly is one of the problems with an agile approach, where you update software quite often. There isn’t necessarily enough time to completely test the the fixes, and as comprehensive as the Microsoft testing suite is, there will be things that are missed. I certainly think Microsoft deserves kudos for finding the issue and releasing a fix so quickly. However, will this patch be distributed as quickly as the original CU #6?

    If you are used to applying these CUs, are you going to notice there is a new version of this CU to apply? The blog entry title doesn’t note this is re-released. If you look for the latest patches and see CU #6, will you realize this fix has been updated? If you know there’s a new patch, will you have time to re-test the update and schedule another release? I know from experience in a large organization, re-applying Service Pack 3a for SQL Server 2000 was a chore, with limited time to re-deploy a patch among all the other work we had scheduled.

    One thing I’ve noticed is that more and more companies are depending on their databases more often, demanding higher uptime and fewer maintenance windows. The more patches we have, the more troublesome it can be to get permission to apply these patches, especially across a large server farm. Microsoft is building a better engineering process, that allowed for more comprehensive (internal) testing and quicker releases, but this process doesn’t necessarily prevent all mistakes. Those mistakes are not only bad press, but they reduce confidence in the entire process.

    I do think these CUs will start to take the place of Service Packs at some point, though I think the pace will become problematic for many organizations, especially those running third party software. I’m guessing that at some point, a good portion of the SQL Server community will start treating these patches like upgrades, and not applying every one. Many people will end up applying only every fourth or fifth patch, much like people seem to be upgrading many instances every 6 or 8 years.

    Steve Jones

    The Voice of the DBA Podcast

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