Voice of the DBA

Tag: career

  • Redis University

    As if I don’t have enough to do, I started a data structures class at Redis University. Someone recommended this to me as another way a company has structured learning, so I decided to give it a try. There were some things they liked that we might use as Redgate University.

    I decided to start with the 101 course, since I have a rough idea of what Redis is, but now how it works. The class has a number of videos, with transcripts alongside that teach various concepts. One thing I like is that if I get lost, I can glance at the transcript, click it, and the video jumps back to that point. That’s handy, as life sometimes distracts me.

    The quizzes every video or two are nice, but I wish there was a bit more chance to practice things in the middle. I could certainly grab a Redis VM or container, but I have no real idea of how to access it, and I’d have another project. I would actually suggest some “launch lab” points after each set of videos with some practice tutorials or exercises.

    The class has two weeks, with a few chapters, each of which is about 6-7 videos. I don’t know about you, but that’s a lot in a week. If I could abandon some other things for an hour a night, maybe, but that can be tough to do consecutively. I’d really rather this was a 4 week class, with each of the items listed as a set of learning and practice for one week.

    Overall I learned some interesting things about how Redis works. With the power and speed of this memory based key-value system, I can see why some of our customers are using it. If you are thinking about it, or your app uses it and you want to know more, maybe check out their university.

  • Kubernetes Pipelines

    This post continues looking at some of the Kubernetes concepts I’ve been learning with the 50 days of Kubernetes (K8s). Specifically in this post, I’m writing and thinking about the flow of containers from code to a Kubernetes cluster.

    The video talks about pipelines, which is the way in which you get code running in a Kubernetes cluster. The start looks at the idea that we don’t want arbitrary containers running in the cluster, so we limit access to the cluster to somewhere like a container registry, like Azure Container Registry. This ensures that only those containers loaded into your space get onto the cluster. No pulling from Docker Hub or some arbitrary location.

    However, then we worry about developers loading containers into the registry that haven’t been checked. So, we don’t give them permission, we give it to some CI/CD pipeline, which means any code written by a developer that builds a container has to be checked in.

    Now, we have a pipeline flow that we can control. As Brendon mentioned, this isn’t simple, and really, I think you have a lot of work here before you want to trust things running on a production Kubernetes cluster. Really now you need these in your CI pipeline:

    • Unit tests
    • Vulnerability scanning
    • credential scanning ( I see this from MS for Github repos)
    • every other type of scanning you can do

    In this way, you ensure some quality level in your containers as far as security goes and code working. The big win here, at least for me, is that you can continue to raise the bar by adding more tests and scans, something that’s hard to do for developers without automation.

    Not a lot new here, but certainly the idea of putting access and control into the CI/CD flow makes sense.

  • Learning more Kubernetes

    I’ve been slowly working my way through the 50 days of Kubernetes (K8s). As you might have guessed if you remember my first post, this has been more than 30 days. Life and work get in the way, but I’m working through the series of posts and videos.

    A couple of interesting things I’ve watched lately:

    Serverless Kubernetes and Serverless on Kubernetes – I worry about the idea of containers needing to spin up to meet serverless workloads, but maybe not. It’s a few ms for these containers to spin up, especially for small functional environments like Python or .NET. I suppose if there are issues, you can schedule more pods to be available or more replica sets to spread the load. This makes sense to me, and containers are often a perfect use for this on Kubernetes since you want to have lots of small items, but one large endpoint for people to hit things. I suspect this is how the FaaS implementations work on Azure and AWS.

    This video also talks about the need for a virtual kublet to allow the API to get things ready, without having underlying VMs, a prerequisite for scheduling items on the cloud. This is the serverless kubernetes concept. I’m not sure I completely understand this, but I get the idea here. We don’t have hardware provisioned, we’re running Kubernetes, and we want to push some of our load into the cloud. Since we don’t have a node assigned to us, we want to schedule on a virtual node that the cloud provider will actually spin up when we hit it.

    Fascinating and not something I’d have thought of before I saw this video.

    How the Kubernetes Scheduler Works –  This is interesting. Scheduling workloads and pods in different places is important. Flexibility while meeting demands matters. The idea of hard (required) and soft (optional or preferences) constraints for choosing where to run pods is fascinating. Another video by Brendon Burns. Most of us might care about these items since we may want some spreading assurances for instances or minimum resource requirements for our instances.

    For example, we might have a hard constraint that our pod (container) needs 128GB of RAM. This might limit the nodes that we want to run this pod on, and the scheduler takes this hard constraint into its decision making process.

    For soft constraints, we might prefer that a reporting instance not run on the same node as a OLTP instance, but if there are no nodes available, perhaps we’d live with this. That’s a soft constraint, and the scheduler tries to honor these, but it isn’t bound to prevent scheduling on those nodes.

  • Learning to Stop Being a Hero

    A few weeks ago I re-published a piece on whether we might be giving too much of ourselves for our employers. At the time I was on holiday with my family and since this was a popular piece years ago, I decided to run it again. I was surprised at the response, with quite a few individuals writing about their experiences in their current positions.

    A good friend of mine read the editorial and then sent me a link to a post by Paul Cunningham that looks at the IT hero. This talks about some of the ways in which we put ourselves out as employees. It’s a good read, and it’s certainly something to think about when you look for a new job. When I talk about finding a dream job, I’m not talking about a specific job or career path, but rather, what’s the right fit for you. That might not be the job I want, or even that your friends want. It’s the job that you’d want.

    To find your job, you really need to think about more than the work, the company, the location, or benefits. Instead, think about everything and start to rate those items against each other. A friend always tries to scale everything to some monetary value to make it easy to compare jobs. You can put a value on a 5 minute commute v a 45 min commute by thinking of the cost of time. Same for other benefits. Perhaps you can even do this in terms of future opportunities. You certainly can do this in terms of expected work week, on call time, and more.

    What you don’t want to do is let an employer take advantage of you by asking for a lot more of your time than you feel comfortable giving for the salary. Most of us are happy to pitch in when extra work is needed. I’ve seen this in restaurants, lawn care, and IT. What we don’t want to do is get taken advantage of when extra work is required on a regular basis. You don’t need to be a hero to be successful.

    Perhaps the final caveat in all of this is that you can’t control how all employers treat or view employees. Sometimes you might take a job that isn’t a good fit because you need a job, or maybe because you’re trading a poor situation for some experience. Just be sure you know you’re making that trade.

    The other thing I’d note is that finding a dream job, or maybe just a job that fits your life well, means you need to be able to compete with the others wanting that job. Work on improving your technical and soft skills to ensure that when the time comes, you are in the best position to get that job.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.