Voice of the DBA

Tag: DevOps

  • The Heart of DevOps Webinar

    One of the things that I think about DevOps is that it’s really hard to focus on the hard things that create friction in your process. Most of us want to move faster, and tackle the easy things to automate, the easy things to fix. We want to trust developers to move quickly and pick those items that get in their way.

    They do, but they often stop before the database. Or they start to try and find ways to use a different database (ugh). Or they just start putting strange data into existing columns to get things done.

    The database matters, and I’ll be talking about why.

    Webinar social_Heart of DevOps

    I’m doing a webinar on Feb 6 for 30 minutes to talk about the database in DevOps. You can register here: https://attendee.gotowebinar.com/register/3005019550714731265?source=KB

  • Ensuring Designs have Flexibility

    One of the biggest complaints from developers about RDBMSs is that they are inflexible and hard to change. This has led to many developers in the past using existing fields for a variety of purposes, sometimes putting data from multiple places into one field. In more recent times, this has led to adding or migrating data to new data stores, with the idea that the system can adapt easily to changing requirements.

    I ran across a post on system flexibility that somewhat illustrates the issue. The writing is a little hard to understand, but the author is thinking about the process of ordering food and how a system might need to handle some of the exceptions or additional changes. While the employees in a store might deal with this in an ad hoc manner, those of us building software need to think through the possible issues and account for (at least) some of them in code.

    Software typically has much more flexibility than we do at the database level, since anyone building software is usually building on top of the database system. However, those of us that design schemas need to ensure that we take care to consider the different ways that our data store will serve the needs of the end user and design in the proper structures needed to support the data that will be stored.

    In my experience, it’s important for the database developer to question the requirements of the customer. Just as a software developer might try and tease out additional features and functions that are needed, the database developer needs to carefully query the customer to ensure that there won’t be additional data that the customer assumes is being captured. We need to be aware of relationships and cardinality between the data elements, in order to better design a system that meets the current, and potential future, needs.

    Building and designing a database isn’t that hard, but it does take some attention to detail and a meticulous nature to think through how some real world situation is modeled. While I think small, frequent DevOps releases are a way to move forward, I’d also like to ensure that we capture as much detail as early as possible to minimize disruptions. After all, refactoring and changing the schema is harder in a database system than in an application software class.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Lessons from the Phoenix Project–Leave Slack

    Not @Slack, but slack time, time when you aren’t buried on a particular project.

    In the book, The Phoenix Project, the Brent character is the jack of all trades, the one that everyone goes to to fix and solve problems. He gets tasked with important projects and work, which means he’s always busy. I’ve been in this position, and a few of you are likely depended upon like this at your job.

    Slowly, the other characters start to realize that if Brent is fire fighting, or he’s on a long project, then he can’t get other things done. He likes and wants to complete work, something most of us do, which means that unless he has windows to tackle new work, he never gets to new work.

    It’s important to break work down and work in small windows. It’s also important to ahve some free time available for anything that comes up. That way if there is something important, you can tackle it without subjecting that item to a long delay. If you also find that some work can be handled by others or isn’t important, you have a break to switch to something else and leave the less important project behind.

    This comes from flow of work and theory of constraints, outlined in The Goal, from manufacturing. Ensuring that some resource is always busy doesn’t make sense from an flow standpoint. This is discussed in the book, Slack, as well.

    If you haven’t read The Phoenix Project, it’s a quick and easy read. A little silly, somewhat exaggerated, but it makes a point that’s worth making in how we work in technology.

  • Take the State of DevOps Survey

    Kendra wrote a nice piece on this the other day, and I agree.

    Take the Survey

    The data that comes out of this helps to influence executives and managers. You can show them results, which might get them to help you change your job.

    This is also a way that we can share information with each other. Are others doing their jobs better than you? Can they actually get code tested and reliably deployed? Are most people using VCS?

    Or maybe not.

    Take the Survey

    Share some information and learn something back. The results will be available online, and you can use them however you like to convince your organization to make changes.

    We don’t manipulate the data, and we’ve hired a company that specializes in doing this, so we can try and get accurate accounting of the data.

    Take the Survey