Daily Coping 22 Aug 2022

I started to add a daily coping tip to the SQLServerCentral newsletter and to the Community Circle, which is helping me deal with the issues in the world. I’m adding my responses for each day here. All my coping tips are under this tag.

Today’s tip is to make a thoughtful gift as a surprise for someone.

My daughter went back to school last week. That means it’s time to start some care packages. I usually need to send her something every month or two and I’ll include a few treats.

She forgot one bag on her trip, so I need to send that to her. I’m including a few chocolate treats as a surprise.

Posted in Blog | Tagged , , | Comments Off on Daily Coping 22 Aug 2022

The Case for Patching

Recently I was testing a feature in SQL Server on 2017 and 2019. There was supposed to be an improvement across versions, but I didn’t see it. Then I realized that I was on SQL Server 2019 CU 2 on my laptop, and the current CU is 17. I took a few minutes to download that and install it.

I have often been a lagging patcher in production environments, often looking to stay a CU or two behind, depending on my workload. SQL Server has been a very security -table platform, so that’s often worked well, though there are security updates at times. For those, I usually prioritize a patch getting applied.

Windows (Linux, MacOS, etc.) tends to get patched more often than other software, especially by administrators. At least on desktops. Servers sometimes lag a bit, which can be a problem. I saw this week that a lot of attacks in 2022 Q2 were for a vulnerability Microsoft patched in Sep 2021 but hadn’t gotten all their customers to apply the patch. That situation was a problem early in my career with many vulnerabilities, and it’s still apparently an issue now.

If you’re wondering how big a deal patching can be, remember the Equifax hack? This occurred because administrators hadn’t patched a system. Whether it’s a host OS, a database platform, or some other software system, it’s important that you keep somewhat current with patches. We never know when vulnerabilities will appear, and honestly, for most of us, we can’t spend the time tracking every piece of software and the various vendor disclosures.

We can, however, patch relatively quickly. While I don’t expect that most, or even many, people will patch within a month, I do think that delaying six months is probably a bit long. That being said, I need to check a few of my servers and make sure my admins are keeping them up to date.

Steve Jones

Posted in Editorial | Tagged , , | Comments Off on The Case for Patching

Proving Minimal Charge Loss for the Tesla

This is part of a series that covers my experience with a Tesla Model Y.

One of the reasons I have some data capture taking place on my own systems is in case some vendor I use has a DR event. That might cause me to lose some data, since I’d be depending on them to keep the data around. If I lose my system, I can always (hopefully) go get their copy again.

Maybe.

Who knows.

In any case, my wife and I spent the weekend in LA, coming back Monday. We got home from the airport and my wife said the Tesla was really low. The charge level was at 22%. She thought sitting parked at the airport from Fri-Mon drained a lot of charge. I countered that it hadn’t lost much of anything.

I had actually left home Tues morning and returned late Thur, so I hadn’t driven the car (or plugged it in) since Monday. My wife said she hadn’t driven much, so there should be more charge.

To settle the situation and understand, I turned to my Teslamate data logger. It’s been running in a container on my machine (Actually a few) and keeps the data backed up.

If you look at the charge level, you’ll see that I got up to the 76% level (the max setting for us) on Monday.

2022-08-17 13_39_55-Charge Level - Grafana — Mozilla Firefox

I was in Seattle at 12:50p Tuesday when someone started driving it around. The normal driving that day took the charge down to 59%. I’m guessing a few errands throughout the day.

2022-08-17 13_40_05-Charge Level - Grafana — Mozilla Firefox

Then this remained the state until Friday morning just before 9a. That’s when I left for yoga, and you can see I drained down some charge.

2022-08-17 13_41_40-Charge Level - Grafana — Mozilla Firefox

I got home and plugged it in, but because I have this set for overnight charging, nothing happened at first. I finally remembered to click “start charge”, but only added 2″%.

2022-08-17 13_42_15-Charge Level - Grafana — Mozilla Firefox

That’s what we took to the airport. The drive up drained the batter down to 41%, and I’m guessing another % went down with cabin overheat running. This runs for a bit of time after the car is locked (it was hot in DEN). The charge remained at 40 through the weekend until Monday morning.

2022-08-17 13_43_24-Charge Level - Grafana — Mozilla Firefox

Driving home was the dip down to the 22% where we ended up in the right side of the graph above.

Not that I wanted to win an argument, but more verify that what I told my wife was correct. We have sentry off and we should lose minimal charge from the car being parked.

Posted in Blog | Tagged , | 2 Comments

How Hard is Kubernetes?

We’ve run Kubernetes inside Redgate for some research projects (like Spawn) and we are building some skills running this orchestrator. At the same time, we’ve had no shortage of challenges in keeping the clusters up at times, patching, fixing issues, upgrading to new configurations, etc. Like any software, there is work involved with managing the orchestrator.

I’ve watched Andrew Pruski and Anthony Nocentino write about containers and Kubernetes and overall they’ve made me view the clusters like email. It’s useful and I want to use it, but I don’t want to manage or administer it. I’d want some service like AKS or EKS instead. Let someone else build expertise.

If you use containers, do you have an orchestrator running in your data center? Mercedes does, with over 900 clusters. They found value early on with container technologies and built in-house expertise within their research arm. I think a large organization like Mercedes likely can make this investment pay off, especially as they likely don’t depend on any one person to understand and manage Kubernetes. They can afford someone like Andrew or Anthony quitting and taking another position.

The rest of us can’t really do that, certainly not without our organization feeling containers and orchestration is a core competency.

The key for Mercedes is automation. They note that if they added 500 more clusters, they’d need just one more engineer. That’s a key for any of us that want to manage growing numbers of systems without spending a lot of our time reviewing resumes and hoping we can hire good staff. Hiring is hard, and finding good people even harder. When you find them, set them free codifying their knowledge using DevOps, scripting, automation, and more.

Then educate others and teach them what your talented engineer is doing. Mercedes notes that finding people is hard, and educating existing people is easier. DevOps, better coding, understanding APIs and declarative scripting are not hard skills, but they are something people need to practice to develop familiarity and skill. We want staffers to be able to easily pick up the work of another, understand it, and extend or improve it. We don’t want to depend on the person that wrote it.

The way Mercedes has attacked this technology is the way I’d have developers and administrators tackle DevOps. Take advantage of the power of modern software development and infrastructure tools and empower your staff to make things better. They are likely to enjoy their jobs more and remain employed, reducing your need to struggle with the vagaries of finding and hiring good people, a problem no one has solved well.

Steve Jones

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

Posted in Editorial | Tagged , , | Comments Off on How Hard is Kubernetes?