Voice of the DBA

Tag: DevOps

  • Defining DevOps

    DevOps has become somewhat mainstream in that many companies, perhaps most, are talking about it or trying to implement some of the principles behind this software development approach. However, even as I talk with people that practice DevOps, I find the idea of what DevOps actually includes can vary widely among developers, even inside the same company.

    There are lots of definitions, and this one caught my eye recently. It says, among other things, that there should be “increased collaboration among not only developers and operations staff but users.” I like that there is some emphasis on working together, which is often the hardest part of changing how we build software. I find that many customers struggle because they end up adopting the technology tools, but fail to change how they communicate with others. Culture change is hard, and DevOps requires a culture change.

    The article is high level, but it does highlight some of the complexities of DevOps, mainly that lots of stuff is happening at once. Good reporting, tracking, and management are important, and unfortunately, lots of managers don’t want to change their approaches to managing teams, which further complicates the process of building better software faster. Certainly, the need to have developers work with ops people, including supporting production systems, is important, but it never happens without management requiring and supporting this collaboration.

    The drawbacks to DevOps are many. Plenty of teams slap together code, getting the “faster” part but forget the “better” part, which means increasing and higher quality code over time. They embrace new tools, but they sometimes forget to run small experiments and change their approaches across time when they find better ways of building and operating code. Or they refuse to stick with current techniques or software because they crave change. Developers also find that some groups, like security and compliance departments, aren’t ready for the pace of change, which can be frustrating.

    Ultimately, DevOps is better collaboration, getting all teams on board working together. Like many people rowing a boat, every group needs to align their work with others to ensure a smooth and successful journey. Actually creating that alignment requires strong leadership and culture, two of the hardest, and rarest, things to build inside many organizations.

    Steve Jones

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

  • Data and DevOps Predictions for 2022

    All the Advocates at Redgate (Kathi, Grant, myself) got asked about some of the future predictions we might have, based on some of the data from The 2021 State of Database DevOps and The 2021 State of Database Monitoring. We each came up with a few things and then someone summarized them. Grant has an official blog post, but I thought I’d glance through the summary, see what the others wrote, and then come up with a few things.

    Side note: I hope to review this next January and see how I did.

    I didn’t do this last year, but I’m going to separate the DevOps and monitoring topics and give a few thoughts on each.

    DevOps

    DevOps continues to grow and really become almost a mainstream idea. I don’t know if I think the majority of companies are really adopting much of it, but many are adopting something. I rarely need to explain DevOps, though I do often need to define it for me and level set how I view it. It still seems everyone things about this differently.

    The main challenges for DevOps are adding automation, moving to the cloud (or hybrid) and writing better code. DevOps can help with all these things, but I think far too many organizations still want to tackle these are projects, not an ongoing habit.

    Well, all but the last one. It seems no one really prioritizing better code in most management I encounter.

    Automation is the easiest of these, and I find that more and more DBAs are embracing automation in different ways. Some still want to do everything manually, but more of them are starting to accept that a framework (like Flyway) or even a simple automated script runner can be used without them needing to connect with SSMS.

    I see this as a trend that will continue to increase, and eventually we’ll expect 95% of all deployment code to run with an automated process of some sort. Bt process I mean you aren’t connecting to a production server from your workstation.

    My prediction for 2022 is also that I won’t see anyone create new repos in a version system other than git. I do tend to work in the MS stack or the Flyway area, and I don’t expect to encounter any clients still trying to work with SVN, CVS, Vault, Perforce. or even TFVC. Any why should they?

    I also expect that we will see more cross platform work from everyone, which means that we will want a fairly consistent way of managing development, whether this is on SQL Server, Oracle, PostgreSQL, or MongoDB. I know that deploying code here means more chances for mistakes, so having a consistent high level process is important. This might mean that you use one type of framework for SQL Server and another for PostgreSQL, but the flow will be the same. Save code, run CI, deploy with automation. Hopefully testing in there somewhere.

    The cloud encourages automation, but not completely. The portals are complex, the offerings changing, and no one wants to worry about which version of a CLI you have on which machines. Still, I hope to see more GitOps or Infrastructure as Code used by clients.

    Monitoring

    I think two things here. First, people are going to rely more and more on monitoring systems to manage the disparate and ever-growing estates of data stores they have. This is going to come about with the problem for many people of not only managing different platforms, but also different monitoring tools.

    People already struggle with SQL Server and Oracle (or any other combination of platforms). I expect they will have AWS and Azure to contend with as well, though likely each organization will lean more heavily on one than the other. However, they’re also going to be dealing with different products for different platforms.

    I predict some stress, confusion, and anxiety about incidents and employees trying to decide how to find and use information.

    The second prediction is that we are going to see another security issue with a monitoring and/or management platform. We had a big one last year, but I bet hackers are working out how to attack other platforms, especially those that require sysadmin privileges and also allow the tools to change the remote systems.

    Security is always a problem and after last year’s incident, I expect other software to be targeted in this same way.

    Looking Forward

    If you are trying to find a new job, or improve your career, here’s what I suggest. First, learn to write and speak. However you can, but working with others, advocating your position, and improving your showing at interviews will matter.

    In terms of tech, get good at something but learn a bit of many things. Pick a cloud and learn how the general infrastructure of IaaS, PaaS, and SaaS work. Things will vary a bit from Azure to AWS to GCP, but the core remains the same. Learn how to spin up and work with a variety of technologies related to data. Be comfortable with version control, with repos, with CI, with CLI tools, with finding answers on how to accomplish tasks. Knowing a bit and how to find out more might be a good way to answer some of those interview questions.

  • The Complexity of Modern Systems

    I am a big advocate of version control and testing for your software. The main reason is that modern systems are incredibly complex, and capturing what has been done (and what is happening), along with looking for potential issues, is important. It might be critical for ensuring you have success in building software.

    Part of the reason is this post on software complexity. Now I don’t think the complexity is killing software developers. I do think it adds to developers’ stress, and in poorly managed environments, the complexity makes for a poor job experience for many.  While I do think most people are smart, and they find ways to overcome this, they just don’t enjoy the process.

    This is part of the reason, IMHO, that we are starting to see lots of people move to a new role, often in a new company. With remote work, there are more options, and for people with talent, they can easily leave. My recent job searches seem to show more remote job options and more demand for mid and senior level people. I think some of this is looking to get better talent in your company, and some are because experienced people are tired of poor work environments and poor code.

    Modern software is big, and I don’t think any system of consequence is built by individuals anymore. There are still good projects and applications being built by a person, but once they start to grow, a team of developers is needed. This means that we have to learn how to better work together. We need to adhere to standards. We need to communicate and collaborate both in code as developers and together as humans.

    While someone may understand how the entire system works, it’s unlikely that many of our staff does. If the system is large, it’s unlikely anyone completely understands, and then our ability to function as a team is incredibly important to be sure that we are building something that works well together.

    To me, the complexity of modern systems emphasizes the need for teamwork and collaboration, the thing that many companies adopting DevOps struggle to emphasize.

    Steve Jones

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

  • A Version Control Primer for Databases

    This is a talk for database people that might not be familiar with version control and how it can be used with database code.

    Abstract:

    With modern DevOps software development, there is a need for the database code to be tightly integrated with application code, and this requires the use of a version control system (VCS).

    This session will examine the basics of version control, the different types of systems, and how we can use them for database code. There is an emphasis on Git, as this is the most popular VCS in use today.

    Level: 100

    Slides: vcs_primer.zip