Voice of the DBA

Tag: software development

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
Building Quality In

I heard someone at the 2020 DevOps Enterprise Summit conference say that quality needs to be built in. That’s something that many, or hopefully most, of us believe. Everyone ought to do quality work and build it into their daily tasks. However, the person speaking went further and defined this in a way I like:

“Building quality in means we don’t pass quality issues along to others.”

That’s a much better definition for me. This implies that there are effects if I don’t do a good enough job. If I knowingly pass along an issue, that’s a problem. I haven’t done quality work. I’d likely say that if I don’t bother to test or evaluate my work in some way, I’m essentially doing the same thing.

We all write poor code, or do a job poorly at times. Often this comes because of ignorance, naivety, or just a lack of skill. That’s understandable, and we can forgive a person not being able or ready to do a job at the same level as a more experienced person.

However, that should be a learning and teaching moment. We don’t expect continuous quality issues, certainly not of the same type. A big part of the DevOps movement, and other modern software development methodologies is learning from our mistakes. Getting better. Improving the quality of our software.

Don’t just get work done. Don’t just close tickets or move a sticky note. Learn to do better each time you make a mistake. Learn to write better code or implement better processes. Learn to build in quality.

Steve Jones

October 29, 2020
The App Compatibility Promise

I was listening to one of the Ignite keynotes, and I heard an executive say something about “if your app doesn’t work, we’ll help you fix it at no additional cost, or fix Windows.” I had stop and rewind and check, and then go look around. Sure enough, there is an App Assure promise for Windows 10 and apps.

This isn’t just for commercial software, but it lists custom line-of-business apps, third party apps, and more. Now, this doesn’t appear to be for everyone. The eligibility for at last the FastTrack portion of this is 150 or more licenses of Windows, Office, etc. However, it is a guarantee that they will help you.

There’s also a note that there isn’t a requirement for ISVs building Windows 10 apps. To me, that means there’s no good reason why more companies don’t take advantage of it. I do think, however, that there’s a missing component here.

Big parts of the Ignite keynotes, and in Microsoft’s marketing and messaging, is about data. That should mean that SQL Server and CosmosDB ought to be included in this promise. If there are regressions or bad plans, I’d hope that Microsoft would help them fix things. Or maybe promise that the compatibility mode would insulate apps.

I know that execution plans regress, sometimes on the same version, and guaranteeing performance or a plan across versions isn’t likely possible. However, I do think that Microsoft could provide more guarantees, perhaps with some caveats that if they need you to change code you will.

We all know that we need to test, test, test to ensure we aren’t introducing regressions or other issues. This isn’t a panacea, but it also isn’t a project. It’s an ongoing part of building any software, including database software. Many of us do this, but it becomes harder and more complex for ISVs that often deal with many versions. However, we pay lots of money, and I’d expect that they at least are supporting patches to existing software. I think that’s part of an informal contract that they ought to believe in.

Listen to the podcast at Libsyn, Stitcher or iTunes.

October 13, 2020
Getting Started with Spawn

I’m excited that the Redgate Foundry is working on some cool projects. The Future of DevOps is one and part of that work is with Spawn. I’ve played with this a little, and I wanted to write about a few adventures I’ve had.

First, you need an account as Spawn is hosted and there is a login. The idea here is that the service (hosted now, but could be on premise) handles all of the complexity of databases in containers, spinning them up and managing them, with you just connecting to an endpoint to use the database. We can spin up SQL Server, PostgreSQL, MongoDB, MySQL, and Redis in this fashion. It’s truly a Database-as-a-Service (DBaaS).

Spawn on Windows

For once, this is easier, or I think it is. I downloaded the spawnctl.exe CLI and then put it in a folder in my path. For me, I have a “utilities” folder where I drop stuff and that’s where this lives. I can check this working with a version parameter.

So far, so good. Now we need to log in. I like integrated authentication schemes, and this one works well. I start with a “spawnctl auth” call from the command line.

This pauses and opens a web browser window. It’s here I need to log in. We support Github and Microsoft, but have mostly been using Github for our demo work.

Once I click that, since I have a Github session elsewhere, I’m logged in and I get a code back.

I paste that back in the cmdline and I am authenticated. From here, I can then see what images I have. As you can see, there are both MSSQL and PostgreSQL images for me.

I also have a few containers from my demo work.

Let’s make a new container and connect to it. I’ll use Azure Data Studio, since I can connect to both SQL Server and PostgreSQL.

Logging In

To get a database, I’ll use a CREATE verb and the DATA-CONTAINER noun, along with an image. When this runs, I get a note this container is being created, then I get a response with login information.

Let’s put that in ADS. I can copy/paste my credentials into a connection dialog and then hit Connect.

As you can see, I’m connected.

I see the demo database we’ve been using and the tables in there. How this works is worthy of more posts, but for now, this is pretty cool.

I can do the same thing with PostgreSQL. Create a container.

Then connect (need to specify the port in Advanced)

And query:

Pretty cool. Simple, easy, and I think about as fast and easy as any other cloud database. Here, though, I am spinning up a container from an image template. That’s valuable for dev work, and I’ll talk about that in the future.

July 1, 2019