Category: Blog

  • The Foundry–Data Masking Research

    For most of the time I’ve been working for Redgate, we’ve had some sort of R&D group that tries out new ideas. Over the years we’ve done this in a few ways, evolving things over time. I had the chance recently to meet with The Foundry, which is formally investigating ideas for feasibility, interest, and general knowledge. Not all their ideas will move forward to actual pieces (or parts) of software, but it was interesting to meet with them.

    One of the areas they’re investigating is data masking, which is a much larger topic than you might think. I got the chance to review some of their research areas and thought a few of you might be interested in helping research and giving your thoughts.

    Data Masking Demos

    In looking at data masking, the group spent some time getting feedback from individuals, trying to understand the challenges and possible solutions, and then build some interactive demos. These aren’t really software, but they are a bit more than wireframes. you can see all the demos in the Data Masking Demo section of their site.

    Each of the items deals with a different aspect of data masking. The demos aren’t completely intuitive, which is both interesting and frustrating. It’s good that there is some open-ended-ness that gets me to think. Hard that I don’t always quite get the intention. I had the luxury of getting some time where someone would sit down and explain a scenario, but I’d be curious what some of you think.

    If you have a few minutes and want to play with potential areas of data masking research, try a demo and give some feedback. I particularly think the Manage Test Cases and Realistic Generation demos are things I’d like to see engineered, particularly together. I would really like the idea of some production-like data and some real test cases being moved into good, not-production, data sets that I can use for development and testing. I’ve given some feedback, but I’ll play more and leave notes here, and at foundry@red-gate.com .

    If you have a few minutes, maybe you want to do the same.

  • Good DevOps Books to Read

    I was interviewed recently at DevOps.com talking about the database as a part of DevOps. As part of the interview, Alan Shimel asked me for a book recommendation. After that, I decided I should recommend a few books that I’ve read and think have helped me to understand DevOps.

    Tl;Dr: The Phoenix Project, The DevOps Handbook, Continuous Delivery.

    The Phoenix Project

    I actually read The Goal first, which applies the principles of DevOps, grown out of the lean movement, to manufacturing. The Phoenix Project is based on the Goal, but looks at Information Technology.

    5170sr05QAL._AC_US327_QL65_

    The book is a good, light read. It felt like a repeat of The Goal, but it cemented some ideas, and I enjoyed it. The guru character is a little overdone, but certainly the “Brent”,  jack of all trades, the one everyone depends on rings a bell. I’ve been Brent in a few places, where I had to be involved in everything. While flattering, it’s tiring and annoying.

    This is a good, semi-satirical look at IT projects that helps you to realize the somewhat silly ways we build and deploy software sometimes. A nice overview for DevOps.

    The DevOps Handbook

    I read The DevOps Handbook the most recently of these three. After looking for more information on how DevOps is evolving, and following the research of Gene Kim in talks and articles, I decided to give this a try.

    51WMrr2knUL._AC_US327_QL65_

    The book is long, though if you read on the Kindle, you’re at the end around 70%. The rest of more details and additional material. It was interesting, using case studies and information from a variety of companies to explain the three ways that Gene Kim has postulated as the principles of DevOps. They are:

    • Systems Thinking
    • Amplify Feedback Loops
    • A Culture of Experimentation and Learning

    Those are discussed in chapters with examples of how companies implement these, along with the shift left and shift right concepts. I’d definitely recommend this one.

    Continuous Delivery

    I actually read this book first. Continuous Delivery was recommended to me when Redgate got serious about DevOps and DLM (Database Lifecycle Management). I was reading this as I attended FlowCon and had the chance to meet Jez Humble. That was a great conference, and I’d like to go back to another (or similar) one.

    51NbiDn81NL._AC_US327_QL65_

    This book talks mostly about how CI, automated testing, CD, automated deployments, and other specific parts of good software development and deployment practices that come under the umbrella of DevOps. When you look for specific things to implement as you adopt DevOps, this is a good book to give you ideas.

    Remember, DevOps isn’t a tool. It isn’t a think you buy or a specific way you do something. DevOps is an idea, a set of principles, by which you get better. If you have a way of doing that, no matter what you call it, others might call this DevOps.

    Conversely, if you aren’t getting better, if you struggle to get software changes to customer, have quality issues, or stressed staff that don’t collaborate, it’s not DevOps, no matter how much “stuff” you do.

  • Including Your Database in a DevOps CI/CD Process

    Abstract

    DevOps is changing today’s software development world by helping us build better software, faster. However many organizations struggle to include their database changes with their application deployment. In this session, we will examine how the concepts and principles of DevOps can be applied to database development by looking at both automated comparison analysis as well as migration script management. We will cover using branches and pull requests for database development while performing automated building, testing, and deployment of database changes to on premise and cloud databases.

    Level: 300

    I chose 300 because you’ll need some understanding of how software development proceeds, be very comfortable with producing code and executing it on different servers, using a variety of techniques.

    Downloads

  • Thoughts on PASS Summit Speaker Selection Changes

    Recently the PASS Blog released some changes to the speaker selection process that have generated some commentary and thoughts from various people. I read Joey D’Antoni’s thoughts, Andy Leonard’s thoughts as well as various tweets and comments. I talked with a few people, and wanted to put out a few comments for discussion. I’ll also give a few comments at the end about my experiences.

    If you want to join a PASS Board town gall, there are two on April 13.

    Pronouncements

    My biggest complaint with this, and really with most PASS changes, are the pronouncements. While I’m sure PASS spoke to some in the community, there is no general time for comments before a decision is pronounced.

    Please, stop doing this. Propose changes, give us a few days or a week to comment, and then make decisions. Don’t debate this in board meetings in a vacuum. Just propose, get comments, and then move on.

    More later.

    First Time Summit Speakers

    The pronouncement from PASS doesn’t mention first timers. I think this is a mistake, as my feelings are that it’s important and healthy for the organization to regularly grow beyond the pool of speakers available. We always have new people attempting to speak and some of them are really good presenters.

    On the flip side, we have experienced speakers that will get busy, get tired, and mail in their presentation. By that I mean they don’t prep well or polish their talks, or put in much effort to ensure the audience gets a good talk.

    Last year I was on the call when PASS noted that we had about 20% first time Summit speakers. I think that’s great, though perhaps a bit high. I wish they had published and pointed to these numbers. In fact, I’d like to see this as a category in review after the schedule is announced. Give me year over year first time Summit speaker percentages.

    Ideally I’d like to see PASS have a goal of some percentage of new speakers to the Summit. I think 10% is a good number, though this should vary year to year based on submissions. If it’s +/- a few percent that’s fine. Just list some reasons.

    Note that this is new to the Summit speakers, not new speakers. I am against anyone, including Microsoft speakers, giving their first outside-the-company talk at the PASS Summit. Anyone speaking at the Summit should have experience at multiple presentations. I’d say they ought to have at least 2 user group and 1 SQL Saturday (or equivalent) talks on their CV.

    Pre-Con Speakers

    Pre-conference slots are lucrative. Both for PASS as revenue, and for speakers as a way of funding their journey to PASS. This is one reason we often see the independent consultants delivering similar content they might provide in a training class to customers or paid attendees.

    Three things here. First, the content is often re-used and condensed from a multi-day class. I’m fine with that as long as the content is well structured and most attendees find it worth their $500. Training is training, and that’s what this is.

    Second, we need quality talks here, and like first time Summit speakers, I think anyone chosen here should have a record of multiple one (or more) day training classes delivered. In fact, I might say they ought to have delivered a full day of training at least five times, maybe ten,.

    Third, like speaking slots, we need growth. Some of the expert, very well known speakers have skipped delivering Summit pre-cons in the past. That means we should have at least one or two new pre-con speakers every year. If we lost the three or four most popular speakers in a year, revenue might precipitously decline.

    However, as in years past, I’d like to see a list of qualifications. Publish some bar of what you expect. Don’t make it really high, but publish something. Also, incorporate my next comments.

    Inviting Speakers

    There was a meeting at the last Summit (2016) between the program committee and a number of speakers. I was invited to attend and enjoyed the discussion. I gave feedback and one of the items I supported was inviting speakers. I think there are certain speakers, such as Mr. Ben-Gan, that should always be invited to speak and don’t need to submit a variety of talks in a general call.

    Even though PASS is a not for profit organization, the Summit is a commercial venture. The event needs to make money and support the rest of PASS. This is a fundraiser, and as such, it needs to be very profitable. That means that a certain amount of attention should be paid towards attracting lots of attendees. Content matters more than anything, but there are a few people can move the needle and grow registrations. I’m fine with extending a certain number of invitations.

    Again, be transparent and give us a percentage of invited sessions. I might limit this to 10-15%, understanding that the percentage may vary slightly year to year.

    Inviting Sessions

    On par with choosing people, I think there should be some effort to choose content. Ultimately the content matters, and given the nature of submissions, it is entirely possible that there are some areas that don’t get sessions, or perhaps there are areas we’d like to have more content.

    Rather than encourage everyone to submit 4, 5, 6 talks, I’d rather limit the talks, but have the program committee be allowed to go back to presenters and ask them to alter their sessions if need be.

    For example, if Mr. Hirt submits a range of FCI/AlwaysOn sessions for on-premise work, but the program committee would like to see an AG in Azure, I would hope they could approach Mr. Hirt and ask that he alter his session, or submit a new one, that meets some need.

    I don’t expect this to happen often, but I’d like some flexibility here. I would also expect transparency here so that we don’t have friends just picking and inviting friends to talk. Let’s just be open that we want a session on X and chose person Y. I don’t need a percentage of talks, just disclosure. We can debate in the future if this should be amended.

    Community Sessions

    There are always a few people or sessions that don’t get picked, but a number of people find interesting. A few years back there was a chance to vote in a few sessions. I’d like to see this again. Save 4, 5, 10, whatever number of slots for community talks. Pick from the list of sessions that were submitted and met speaker guidelines and take a vote. Give people 3 or 4 days and then put those into the program.

    It’s fun, and it’s a #sqlfamily community thing to do.

    Summary

    Here’s what I’d like PASS to do.

    • No pronouncements like this. Submit ideas, then take feedback, then decide.
    • List speaker statistics after the schedule is announced. Include the last 4-5 years for comparison.
    • Include percentage of invited speakers, community sessions, first time speakers.
    • Issue minimal guidelines for speakers, varying by type of session.

    This isn’t perfect or the best system, but it’s a start, and I think an improvment on what we’ve done.