Voice of the DBA

Tag: DevOps

Delivering Patches Quickly

I love cars. In my life, I’ve owned and regularly driven well over 20 cars. If I count the ones I purchased for my kids and lightly drove, it’s over 30. Just writing this paragraph gets me a little itchy about looking for another car. Actually, I’m looking lightly now, as I expect two kids to move on next year and handle their own expenses. So, next year I’m hoping to add another vehicle.

Recently I saw a note that there was an exploit against Tesla cars, which are rarely stolen, but there have been a few issues. This one was against the fobs that communicate with the car. Tesla is working on a patch, which is interesting. They’ve not only devised their cars, but also their fobs to get firmware updates. Good, and bad, as this increases attack surface area,

Tesla can patch their cars in real time, and they do this fairly quickly. I have a 2012 BMW, and I have updated the firmware in it, but patches are rare, and most of them seem to be stuck in the “visit a dealer” paradigm. It seems many other makes of cars fall into the same paradigm, and aren’t built for regular updates.

In some sense, this reminds me of the way many people deal with the their SQL Server databases. We put code out there, in tables, functions, procs, etc., and often we struggle to update that code quickly. This becomes especially true with applications that use our objects. I often find that changes seem to come slower and slower over time, much like the traditional way that your car is updated by a dealer only.

Ideally, we’d be able to more quickly update code when there are issues. This is especially true if you have procs or other code that could potentially have security issues. DevOps asks us to move towards this type of flow, making changes, and adjusting quickly. There are certainly still challenges with changing code and adapting applications, but if front end developers and database developers worth together, we can deploy code quicker.

Our customers don’t care about our challenges we face with writing and deploying code. What they want are new features, functions, better performance, and meeting their needs. DevOps helps, but it’s not easy. You have to automate things, deploy code sooner AND be willing to fix your code mistakes. You not only need testing, but testing that improves over time.

It is, however, worth the effort.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.

November 30, 2020
How Do You Experiment?

One of the things that DevOps asks software developers to do is experiment. Try new ideas out, get feedback quickly, and then choose how to grow or stop your experiment. This is great for features, and it works well for application software.

The general flow for this is to talk to customers, and then decide what to build. In some sense, this can work, but as I heard at the DOES Summit recently, if Henry Ford had asked his early on customers what to build, they’d have asked for a faster horse.

Customers are limited by their current experience. This includes not only end users, but for us database pros, the developers that build software. When they want to experiment, they often need some backing from the database to store information and query it.

If we want to help enable experiments, and allow our software to evolve, there are two things we need to deal with in experiments. One is schema changes, either through new data buckets in tables, or programmable objects, such as views, functions, and procedures Adding these, or removing them when experiments aren’t useful, can be cumbersome and difficult. It’s amazing how quickly we create dependencies and how slow we are to remove them.

The other area is in ensuring that we properly or appropriately, handle resource usage. Do we go back and tune queries, or restructure the way that we’ve indexed items to ensure that our system works optimally? Some tuning can be done early, and should be, but some requires some feedback to understand query patterns or data loads.

Today, I’m wondering how, or if, you experiment in database work. What works for you, or what doesn’t? Or do you hate the idea of experiments in the database world and want more specification up front? Let me know with a comment.

Steve Jones

Note: Podcasts are suspended for a week as I deal with the PASS Summit.

November 13, 2020
All In to the Cloud

I was listening to the fall 2020 GroupBy conference recently and heard Gethyn Ellis note that he wasn’t aware of any companies that were over some age (a decade?), and that had made a 100% move to the cloud. The comment caught my eye, not because I haven’t felt the same way, but because I’d just heard from a company that surprised me.

During the DevOps Enterprise Summit recently, one of the keynotes was from Capital One. They are a 26 year old company that is focused on financial services, and they said that this year they are 100% in the cloud. They recently shut down their last data center. For a highly regulated company, and one that’s not a startup, that is impressive.

Almost all customers that I talk with are looking at the cloud in some sense. They might not be looking to move their biggest or most important applications, or even a majority, but they are often looking to hedge their bets, while they continue depreciating or using their on-premises assets for some period of time.

Not so with Capital One. They have heavily embraced DevOps, flexibility and rapid change in a way that had them open their 8th data center in 2014, only to pivot and look to eliminate that part of their infrastructure. They believe there is sufficient capability, reliability, and perhaps most importantly, security, in the cloud providers. They’ve embraced cloud-first, after an initial lift-and-shift approach for their thousands of systems.

I don’t know that most companies need to move in this direction, but this does show it is possible, and no matter what your concerns are, there are models of enterprises that have found ways to take advantage of the cloud and that you can look to emulate..

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.

November 3, 2020
Azure DevOps–Using Variable Groups

I was in a webinar recently and saw a note about variable groups. That looked interesting, as I’ve started to find that I may have lots of variables in some pipelines, and I thought this would keep me organized. However, these are better than that.

When I go to the variable screen for a pipeline, I see this my variables, but on the left side, I see “Variable groups”. If I click this, I see some info.:

The top link takes me to a doc page, where I see this sentence: “Use a variable group to store values that you want to control and make available across multiple pipelines.”

Now that is interesting. I have been thinking about different pipelines, so having variables that work across them is good.

To create a variable group, I need to go to the Library, which is another menu item under the Pipelines area. I get a list of groups, of which I have none right now.

When I click the blue button, I get a form with the group properties, and then a variables section below.

I add a couple variables and add some group info. In this case, I want some secret values that are useful across different pipelines.

You do need to click Save at the end of this.

In my pipeline, I see I have some variables. On the left, again, is a Variable groups item.

When I click that, I don’t see any, but I haven’t linked any. Here I need to link my group.

When I click this, I get a blade on the right. I can then see my group(s), and I can set a scope. I do need to click the group and then I can click link at the bottom.

Now I see the variables available in my pipeline.

That’s pretty cool, especially as I am starting to see separate pipelines for different downstream environments becoming more popular.

November 2, 2020