Voice of the DBA

Tag: DevOps

  • Invisible Downtime

    This article has a concept I’ve never heard about: invisible downtime. This is the idea that there are problems in your application that the customer sees. Your servers are running, but the application doesn’t work correctly or is pausing with a delay that impacts customers. From an IT perspective, the SLA is being met and there aren’t any problems. From a customer viewpoint, they’re ready to start looking at a competitor’s offering.

    Lots of developers and operations people know there are issues in our systems. We know networks go down or connectivity to some service is delayed. We also know the database gets slow, or at least, slower than we’d like. We know there are poor-performing code and under-sized hardware, running with storage that doesn’t produce as many IOPs as our workload demands. We would also like time to fix these issues, but often we aren’t given any resources.

    The current buzzword among executives and senior IT leaders is observability. It’s the goal of looking at how our entire system, application, database, and network, are linked and performing with an eye on improving performance. Not because they want to spend time or money here, but because customers are becoming more fickle and quick to move to another offering. Leaders know that degraded application performance (another phrase for invisible downtime) can have real bottom-line impacts on revenue.

    There are a lot of products in this space, application performance monitoring (APM), designed to look at lines of code and determine how well each is performing. They can help you spot issues in application code, but they lack insight into database and network details, at least at a level that the experts need. As a result, digging into performance issues and root cause analysis of problems usually means pulling data from multiple sources and correlating log entries.

    This is likely an area where AI/ML technologies can help, especially across large estates, though I think in many cases, what we need is just a pointer to poor-performing code. C#, Java, SQL, whatever. We need to know where the bad code is and then we need to train developers to write more efficient code. That might be the best way to improve application and database performance.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.

  • The Ireland and UK DevOps Roadshow

    We’re taking the roadshow across the water. Hope the plane makes it.

    AUS02544

    The Redgate DevOps Roadshow comes to Ireland and the Northern UK in June. We’ll be in these cities on these dates:

    • June 11 – Dublin (Grant)
    • June 13 – Glasgow (Grant)
    • June 14 – Manchester (Steve)

    We’ll also have one of Redgate’s amazing Solution Engineers, Huxley Kendall. He’ll be there to answer in-depth questions on the products and solutions that Redgate offers.

    This is a great chance to get exposure to the solutions Redgate offers for building and managing your database code, as well as ask questions about the challenges you face and how we might tackle them.

    Register today and join us for a great day in one of these cities.

  • Redgate Summit Comes to the Windy City

    I love Chicago. I went to visit three times in 2023: a Redgate event, a volleyball tournament, and a wedding. Each time was a lot of fun and I look forward to coming back at the end of this month.

    The Redgate Summit is coming to Chicago on May 29. Three weeks from today! Register today and save your spot. If you get on the wait list, reach out to your account executive as they have their own tickets to give away.

    We’ve had two amazing Summits in Atlanta and London and we’re bringing the show to the Windy City. We’ll be covering a wide variety of topics related to databases, across three tracks.

    • New and Future Tech – leveling up skills about database DevOps and teams
    • Deep Dive Solutions – technical talks on innovative strategies for delivering software
    • Leadership – focused on strategic initiatives

    We have something for everyone. Technical people, managers, senior leadership, and others. Tell your colleagues and come as a group, taking in different tracks and then discussing them alter.

    I hope to see you there and register for the Redgate Summit in Chicago today.

  • Another View of DevOps

    Chocolatey Solutions Engineer Stephen Valdinger said, “DevOps isn’t something you do, but rather, it’s a way of doing things. What works for us here, may not work for you there, so you adjust.” He then went on to say that DevOps is a way of working that reduces time to introduce changes, while at the same time making changes traceable, accountable, and revertable.

    I’ve seen many companies try to copy what another company has done, especially with regards to DevOps and software development. I see companies copy the organization of teams from Amazon, Spotify, or others. Often quite a bit of time and effort is spent changing the way your development team works, and often without a lot of success.

    DevOps is a lot like my studies of martial arts, where you learn some techniques, but it is up to you to implement and use those techniques in your own way. While we may practice in patterns, the actual use of the skill is up to the user. That’s what DevOps really is, a goal and set of ideals you aim for, but the actual implementation varies from company to company.

    Most of us want to build better software, and most managers want better quality applications, but often we can’t get out of our own way because either too many people are resistant to change, or there isn’t any incentive to work in a better way. This might be from individual contributors or from management, but without both groups making an effort to improve the software development process and quality of code, we won’t achieve much.

    To get better at software development, whether C# or SQL, you need to read and learn about how to write better code. You need to learn how to automate the testing, compilation, and deployment of your code to downstream systems. And then you need to discuss and debate what works well, what doesn’t, and adjust how the team writes code. Not just you, but the team. We might also need to adjust how we store, package, test, and run code on other systems. We have to experiment in small ways, testing out new ideas, algorithms, designs, and more.

    In short, we need to be a team. I like the quote above, but I also hope most of you realize the “you” in that quote is not singular, but plural.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.