Voice of the DBA

Tag: DevOps

  • Do What Hurts

    A long time ago I heard a manager at a company say that if something is hard, we ought to practice it more and find ways to make it easy. Barring that, we ought to at least be comfortable with the task. I’m not sure if this manager made this up or read it somewhere, but it’s the same thought expressed by Martin Fowler in this post: “if it hurts, do it more often.”

    I’m not sure that’s the advice I want to use with everything. When my shins hurt from running, or my shoulder aches after hitting a number of volleyballs, often I want to take a break. At the same time, I know that stopping isn’t always the productive thing. I can slow down and build up some strength and things will get better. My long running streak started with slow jogs for short distances, slowly building up the strength in my muscles and joints. Regularly hitting volleyballs and slowly increasing the number I hit allows me to get more done without hurting myself.

    At the same time, putting a hand on a hot stove doesn’t get better, no matter how slowly I increase the heat over time. There are some things that aren’t worth doing more often to get better, but building software is one where we can get better. Our practice does improve skill, quality, and ability if you practice well. We can decompose our problems easily, we can work in steps, and we can (relatively) easily alter our course of work if we need to do so. In fact, quite a few of the software methodologies adopted in the last 20 years are designed to improve the entire process be ensuring we adapt our work to the customer with regular pauses to evaluate our progress.

    When the pain of delays (procrastination) grows, we should find ways to reduce the hassles. Often the pain comes from difficulties, and when that is the case, we might do what Martin Fowler suggests: do it more frequently.

    It works well for databases, as he points out in his post, though I’d caution the data professionals to consider the details in his post. Decompose the problems and make the changes across multiple steps, not all at once. When you do that, make sure you plan for pauses in the various stages, not just stringing together multiple scripts into one transaction. That will help you evolve the database along with the application while ensuring your customers can continue working as you make changes.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Losing The Security Game

    It’s sad some weeks to see reports of security issues at large companies. It’s also discouraging some times when clients or friends will talk about security issues they’ve had in their organization. What’s mostly disappointing is how easy many of these issues would have been to prevent with a little effort.

    Joey D’Antoni made some fun of this with his Data Breach Game. It’s a bingo card you can print out and use the next time you hear about an issue. My guess is most of us could win this in about a week with the general state of security in most places. Some of you might win this in a day with inside knowledge.

    This is poking a little fun at the poor security practices of many places. There’s a wider article about 9 poor security practices you can read, with some notes about what you should be doing instead. When you read it, you’ll wonder why hasn’t someone just made these simple changes and dramatically improved security? I have asked myself that many times when I’ve seen some environments.

    Ultimately, no one wants bad security, but we (as a group) often make poor choices because we’re in a hurry. We can, and should to better. All of the items on this list can be avoided, and should be. Even the complexities of SQL Injection can be fixed with a little code refactoring. No time or that’s too hard? You should be building software in a Compliant Database DevOps manner.

    I like the list, though I wish ElasticSearch where on there in number 6 with MongoDB. Too many breaches this year from people dropping that server on their network without a password because they need full text searching of data. Don’t make that mistake. Always, always, always set a password on data resources. Developer or partner complaints aren’t worth the risk of losing data from an unsecured server.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • A #DevOps Discussion on Thursday with Abel Wang

    I’m hosting a webinar later this week with  Abel Wang, one of the talented members of the League of Extraordinary Cloud DevOps Advocates at Microsoft. This Thursday, October 10, 2019, at 3pm UTC we’ll be discussing DevOps, and how this can both transform your organization as well as improve your career.

    Microsoft has had an amazing transformation in the last few years, and I was fascinated by a few items recently when I watched Damian Brady (another League member) talk about the changes inside the company. I’m really looking forward to hearing what Abel has to say with all of his work with customers looking to build better software.

    Register today and join me Thursday, October 10.

  • Live and Learn

    I love this quote from Randolph West: ” Listen to people. Have strong opinions, but loosely held. If you are wrong, admit it and move on. Learn from those around you.”

    This is from his blog on diversity, which I support and agree with. He has some great thoughts and the post is worth reading. Maybe you appreciate diversity, maybe you don’t, maybe advocate for or against it, but in all those cases, I think his message is worth reading.

    I am not going to talk about minorities or ethnic groups here, but rather diversity of thought. That first quote could apply to software development in general, and certainly the idea of a DevOps process for building applications. It’s good to have strong opinions, and good to be able to debate and argue them, but it’s also good to keep those strong opinions loose. Many of us find as we get older and more experienced that we often have a huge gap in the things we don’t know that we don’t know.

    These are the unknown unknowns, as opposed to the known unknowns, which are things I know I don’t really understand. I’ve remarked to a few people that learn new things every week, and I feel stupider every week. Why? I learn things I never knew existed, so I constantly expand the knowledge of my own ignorance. It feels like I learn two things and then realize there are nine more new things I don’t know anything about.

    Today’s software requires a team. Maybe more importantly, today’s software requires a team of both application and database developers, as well as infrastructure staff, that can help put together an entire system. We need to work together, not independently with hopes of efficient integration of our ideas later. We want to shift left, and coordinate and communicate earlier. That needs strong opinions on how to best do a job, but a loose grasp on those as we might need to adapt to work with others.

    Read Randolph’s blog twice. Once thinking about the topic of human rights, and then once more thinking about teams and our opinions on building software. It’s thought provoking and worth a few minutes of your time.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.