Voice of the DBA

Tag: DevOps

  • Titles and DevOps Confusion

    Alex Yates has become quite the DevOps consultant in the last few years. I used to work with Alex at Redgate before he left to start his own consulting firm. I hear nothing but good things about his work, and if you are looking for someone to help guide your database development team, he’d be a good choice.

    He wrote a piece on the Octopus Deploy blog about the title of DevOps Engineer and why that doesn’t quite make sense. He essentially notes that this doesn’t really describe what a person does and it might not be a good title. I tend to agree, since DevOps isn’t a thing, per se, but rather a set of guiding principles. While this might include building software, or deploying it, there are titles for those things (build engineer or release engineer). It could include Infrastructure-as-code, but that’s the domain of sysadmins.

    There are any number of titles that have come about in this business, and likely more being created all the time. If you have a new job, often you can finagle your way around some pay structures because after all, if you invented the term, the HR department doesn’t have a pay scale to limit you. I suspect that’s part of the reason someone started calling themselves a DevOps Engineer in the first place and got someone to hire them under that title.

    I suspect titles used to be more descriptive and important in the past, when we had fewer of them and the work that each of us did was more tightly scoped. Throughout my career, I’ve started to see more people doing more types of work all the time. Especially in technology where we usually do the work that needs to be done, often crossing over the duties between job titles when something is broken. Getting a system working often takes precedence over any claims of some task being “my work” or “your work.”

    Titles ought to be somewhat consistent, if for no other reason than to easily allow us to compare the work we do in different organizations and allow us to easily promote ourselves to a new employer. If every organization had different titles, we’d waste a lot of time trying to decide if we wanted a position, as would hiring managers trying to decide if we could do the work. Certainly the we find that a DBA or a Developer moving organizations might have some different tasks, but we have a general idea of what work they should be able to complete.

    I’ve never been too concerned about my titles, though I have worked to become “senior” at different employers. That’s usually a function of proving you can do the work well, across a period of time. Of course, if you get work done effectively and efficiently, the title likely doesn’t matter. Someone, likely many someones, will want to hire you.

    Steve Jones

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

  • The Tech Blame Game

    Last year Solarwinds was hacked and blamed an intern for a security lapse. When Equifax was hacked, in testimony to the US Congress, the former CEO blamed a specific, though unnamed, person for not patching a system. British Airways blamed their USD$200+mm IT issue on an engineer that rebooted a system too quickly.

    I don’t know that any large company from my younger days, say before 1990, would have blamed a massive failure on a single person. While any single person can influence more systems in the age of technology, no one should have the power to cause such a massive failure. If they do, I think I’d look towards poor system design, rather than individuals.

    These aren’t the only examples of management trying to scapegoat an IT worker, and I suspect we’ll see more examples in the future. However, I hope that governments and shareholders start to demand better management from management. If you don’t understand how IT works, get auditors or consultants to evaluate things and explain them to you. If you don’t think that your systems are well put together without single points of failure, address that. If you worry about security, make that a priority. Microsoft did after the Slammer worm, and arguably they have a difficult job where most employees want to control their laptops and workstations entirely and run them in their individual manner. Microsoft built better controls into infrastructure and software development, and everyone else should as well. Management needs to own their responsibility for failures.

    We should expect mistakes in security, in design, in coding, and more. We should also be placing guardrails, tests, and limits inside our environments to ensure that we catch most of the issues. Software development and system design have improved dramatically the last decade to help us improve quality and security, but we have to embrace the knowledge that’s been gained, as well as ensure we have circuit breakers to prevent runaway failures. If a sysadmin can alter a Chef script to set the max memory in SQL Server to 1MB, this shouldn’t get deployed to all instances. Moreover, we ought to be testing for all sorts of potential changes that can cause issues.

    To me, this is the area that DevOps, GitOps, anything Ops, automated, or at scale, needs to mature. We need to allow for, expect, and assume mistakes and failures will happen and build in controls to our build and test systems. Once we start to better understand how someone can make simple mistakes, we can attach more checks and balances to ensure that we continue to improve quality, without sacrificing speed, or lowering security.

    Steve Jones

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

  • A Computer on Wheels

    I enjoy cars, and I’ve owned a lot in my life. In fact, I resurrected my list and I count 30 for my wife and I, with 1 motorcycle, 2 ATVs, 2 UTVs, and a tractor. Likely a new tractor or skid steer coming in the next few years as this one is 14 years old. I was hoping for a different car this year, but with two kids needing help, I’m going to have to delay my gratification for another year or so.

    For years, Glenn Berry has been trying to get me to look at a Tesla. He’s owned a few and has driven me around. I’ve never been thrilled with them from a design perspective, though they are quick. Recently I ran across this video (5 Features that didn’t exist when I purchased my Tesla model 3), and for some reason I watched it. It caught my eye (especially dog mode) in that Tesla is doing DevOps with their cars, introducing new features in a way that evolves the car into something new.

    Since then I’ve watched a few other videos, and the Model Y is intriguing. It’s got more range than the cars originally did and it’s not a crazy price. It’s expensive, and more than I want to spend, but it’s tempting because it’s a computer.

    The way that DevOps is changing software is moving beyond tech companies. As I study more about how some companies are building better software quicker, I see that this is finding its way into more and more types of industries. From finance to medicine to manufacturing to shipping to anything, there is tremendous investment in software developers and computing technology to transform industries.

    More and more we are going to depend on software, which means that quality, security, and more are going to become more important. They already are becoming issues, as different companies are realizing just how costly it can be to remediate software bugs for their customers.

    I don’t know if I’ll get a Tesla, but it’s on my mind. If I do, I’ll ping Glenn for a referral code, and then likely be reminded forever that he introduced me to the car.

    Steve Jones

    Update: My wife and I went to test drive a Y. She loved it and actually decided to sell her current, 1yr old car and use that money for a Model Y. So I’m getting a Tesla. Or half of one.

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

  • Tesla and DevOps

    That’s how someone described a Tesla recently, talking about how the software keeps changing. I had watched a few videos after I stumbled on this one:

    That got me thinking, and writing. I’ve got an editorial on this coming up, but really I was intrigued by the idea that the car would be upgraded, and not by unlocking features, but by adding them.

    I wrote before about BMW adding lots of things to the car and letting you unlock them. You could rent heated seats, for example, for a road trip, or a few months. Or rent them in your newly purchased secondhand car, when the previous owner never wanted them. That’s an interesting idea, but it’s simple. We know what’s available, and we pick from the menu of features.

    The Tesla thing is more interesting. They are upgrading the car. They have upgraded software to add more range to vehicles. They added sentry mode and dog mode. The change things, which sometimes is annoying for users when the UI moves, but it’s a neat idea.

    It’s DevOps in real time and in the real world. Not everything works, but not all changes in cars work. Plenty of mechanical designs find flaws and the last few decades, plenty of car software has had issues. I wish that more companies would adopt the upgradeable car, and make changes to improve things. Simple things, like letting me roll up windows remotely. My BMW had remote locking doors from an app, which I used when I got the airport, went inside and wasn’t sure I’d locked the car, but they stopped some of those features and turned off the wireless update (likely a security issue).

    I’m becoming more intrigued by Tesla, and I am considering one for the next car. I wouldn’t have thought that a few years ago, but for some reason the fans are convincing me.