Voice of the DBA

Author: way0utwest

The K8s Overview

I’ve written some posts on Kubernetes (K8s) as I think this will be an important technology in the next decade for database systems. Actually, it’s not that I think Kubernetes is that important, but rather that the orchestration of containers that run database systems, along with the storage and networking, will be necessary. Kubernetes appears to be the most common and popular orchestrator, but that could change. There are other orchestrators out there.

Part of the reason that some technology gets adopted is that managers read about it and push it. Certainly technical staff have input, but managers have influence, and ultimately spend money on projects. While every manager wants to succeed and make their mark, no one wants to be left behind and have made a poor technology choice. As popular as containers and Kubernetes are, a little advocacy from management might get you moving in that direction. That’s if you want to implement containers.

If your manager knows nothing about Kubernetes, can they still recommend the platform? Sure, but you can also help them to understand how it works and what the impact of this choice might be. I ran across A Manager’s Guide to Kubernetes Adoption, which is a good read for a manager, perhaps tempering some of their enthusiasm to just install Kubernetes now. In fact, if you know nothing about containers and Kubernetes, you might give it a read as well.

I’ve changed my mind on database containers, and I do think Kubernetes has a future in the life of the data platform pro. It’s not simple, and may not be easy to run for some time, but I think that will change. I do think we’ll eventually just get a K8s service, or simple install, or use it in the cloud. I also think we may not need a lot more Kubernetes knowledge than is in the post, but we certainly will want to know what configuration items might affect our workloads, and certainly we’ll still need to think about, and set limits (high and low) for our database systems.

I don’t think that our world will change quickly, and certainly the more legacy applications you run, the longer your transition will be, but I do like the concept of Kubernetes as a platform where I deploy applications and services. I haven’t quite felt that way about AzureStack to date, nor OpenStack and other variants, but Kubernetes seems to be a better idea for what I’d want. It will take time to get there, and it’s not trivial effort to move to it, but once there, you should have reduced some of your infrastructure headaches.

As to whether your application will run better, look to your developers. All the hardware and well built platforms in the world won’t work well if you don’t write good code. Spend some effort there, and then think about moving to containers and orchestrators.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.

October 23, 2019
Do What Hurts

A long time ago I heard a manager at a company say that if something is hard, we ought to practice it more and find ways to make it easy. Barring that, we ought to at least be comfortable with the task. I’m not sure if this manager made this up or read it somewhere, but it’s the same thought expressed by Martin Fowler in this post: “if it hurts, do it more often.”

I’m not sure that’s the advice I want to use with everything. When my shins hurt from running, or my shoulder aches after hitting a number of volleyballs, often I want to take a break. At the same time, I know that stopping isn’t always the productive thing. I can slow down and build up some strength and things will get better. My long running streak started with slow jogs for short distances, slowly building up the strength in my muscles and joints. Regularly hitting volleyballs and slowly increasing the number I hit allows me to get more done without hurting myself.

At the same time, putting a hand on a hot stove doesn’t get better, no matter how slowly I increase the heat over time. There are some things that aren’t worth doing more often to get better, but building software is one where we can get better. Our practice does improve skill, quality, and ability if you practice well. We can decompose our problems easily, we can work in steps, and we can (relatively) easily alter our course of work if we need to do so. In fact, quite a few of the software methodologies adopted in the last 20 years are designed to improve the entire process be ensuring we adapt our work to the customer with regular pauses to evaluate our progress.

When the pain of delays (procrastination) grows, we should find ways to reduce the hassles. Often the pain comes from difficulties, and when that is the case, we might do what Martin Fowler suggests: do it more frequently.

It works well for databases, as he points out in his post, though I’d caution the data professionals to consider the details in his post. Decompose the problems and make the changes across multiple steps, not all at once. When you do that, make sure you plan for pauses in the various stages, not just stringing together multiple scripts into one transaction. That will help you evolve the database along with the application while ensuring your customers can continue working as you make changes.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.

October 22, 2019
Adding a License to GitHub

I’ve rarely thought about licensing my code, but it’s something to be aware of for your work. Most of us freely share code, though I have started to add a minor copyright and as is notation to some of my presentation scripts.

Recently a user opened an issue on the SQL Cop repository, noting that without a license, there is some ambiguity for how your code might be used. There’s a short read over at https://choosealicense.com/no-permission/ on this.

I pinged a few people at Redgate to decide what might be best and got pointed to the MIT license, which you can read here: https://choosealicense.com/licenses/mit/#suggest-this-license. After a brief discussion, we decided this would be fine. Actually, people gave me a couple options and said I should pick, so I did.

MIT License it is.

Adding a License

The easy way to do this is to add a file to the repo. If you have this downloaded, just create a new file and commit it. The name should be license.txt (or license). However, you can easily do this online as well.

There is a “Create a new File” in your GitHub repo. Click that.

This gives you an editor, with a name. Enter the filename.

I then pasted in the Mit license into this file. I edited the year and name for Redgate in here as well.

I then committed, this, adding a comment. However there is another way. Once you enter the name license.txt, a button appears on the right side of the page.

This says “Choose a license template”. If you click this, you get a page with other choices.

If you click the “which license” link on the right, you get taken to https://opensource.guide/legal/#which-open-source-license-is-appropriate-for-my-project, where you can read a bit about the differences. If you’re not sure, read this and try to decide what works for you.

In our case, we’re really hosting and sponsoring the project, so the MIT license makes sense. If I go back to the previous page and pick that, I see the license overview and the edits on the right. I changed this from my name to the company, but this defaults to you.

If I click this, I go back to the file page, with the edits filled in. Note the name changes to LICENSE.

I still need to add a commit message and commit this (or create a PR), but this is the meat of the process.

Add a license to your repo to be clear, but make sure it’s the right one for you.

October 21, 2019
Losing The Security Game

It’s sad some weeks to see reports of security issues at large companies. It’s also discouraging some times when clients or friends will talk about security issues they’ve had in their organization. What’s mostly disappointing is how easy many of these issues would have been to prevent with a little effort.

Joey D’Antoni made some fun of this with his Data Breach Game. It’s a bingo card you can print out and use the next time you hear about an issue. My guess is most of us could win this in about a week with the general state of security in most places. Some of you might win this in a day with inside knowledge.

This is poking a little fun at the poor security practices of many places. There’s a wider article about 9 poor security practices you can read, with some notes about what you should be doing instead. When you read it, you’ll wonder why hasn’t someone just made these simple changes and dramatically improved security? I have asked myself that many times when I’ve seen some environments.

Ultimately, no one wants bad security, but we (as a group) often make poor choices because we’re in a hurry. We can, and should to better. All of the items on this list can be avoided, and should be. Even the complexities of SQL Injection can be fixed with a little code refactoring. No time or that’s too hard? You should be building software in a Compliant Database DevOps manner.

I like the list, though I wish ElasticSearch where on there in number 6 with MongoDB. Too many breaches this year from people dropping that server on their network without a password because they need full text searching of data. Don’t make that mistake. Always, always, always set a password on data resources. Developer or partner complaints aren’t worth the risk of losing data from an unsecured server.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.

October 21, 2019