Voice of the DBA

Tag: career

  • 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.

  • Balancing Hard and Soft Skills

    Many of us would prefer that the technology industry were a strict meritocracy. One where we get opportunities and are compensated according to our skills. We learn to code better, or manage more systems, and we’re seen as more valuable (and rewarded appropriately). Or maybe many of us would prefer that things stay the same, since we might worry that we’d be paid less because our skills aren’t as sharp as our co-workers or our competition for that next job.

    In any case, we don’t work in a strict meritocracy, but if we did, we might recognize that it’s not just your programming skills that are being measured. In this piece on hard and soft skills, the author notes that the importance of soft skills is both more and less serious than we might imagine. If that sounds contradictory, it is, but read the article and you’ll see that this is a complex issue.

    The main point from the author is one that we’ve realized at Redgate for some time, and it’s why we’re constantly refocusing our efforts on teamwork. Most modern systems are too complex to be built by one person, which means a group of people need to work together. DevOps asks us to build a culture of collaboration and communication, which are critical soft skills. It matters less and less if you’re an amazing developer that can’t work with others for some reason.

    I do think that the more you advance in your career, the more important these skills become as your job is not just code. It’s also helping shape the direction of software, teaching others, and sharing what you know. If you don’t have the skills to interact well with others, then I suspect your ceiling may be lower than you like. Or worse, your tenure shorter than you’d prefer.

    At Redgate, we do embed a lot of customer research, discussions, and more inside development teams.  At times, I think we do too much, but then I stop and think about the teams I’ve worked with that didn’t do this. They didn’t necessarily code quicker, certainly lacked understanding and empathy, and certainly didn’t make more customers happy. We’re trying to adopt more soft skills inside the company, while learning to build better software. We still value technical programming skills, but not necessarily above teamwork. More alongside teamwork.

    To build a team, we need to value those in the team, and work with them, not against them. Those are skills that can certainly help us in our career, as well as skills that help any organization learn to operate more smoothly, with more retention. At least, more retention of those that have strong soft skills.

    Steve Jones

    Listen to the podcast at Libsyn

  • Cloud Pace

    Recently, a user responded on SQLServerCentral to something I’d written on Azure, asking how do I keep up with all the changes. I wrote back: “Between the complexity and pace of change, I’m always learning something.”

    To be clear, I don’t really keep up. Even just trying to read all the Azure Announcements can be overwhelming, especially if you want to set up a quick demo on any of them. Even trying to get through the (free) e-book, The Developer’s Guide to Azure, was a chore. There were so many things I hadn’t heard of or barely knew about that I had to stop myself from logging in and trying something to get to the end.

    The Cloud isn’t really anything new. Not very new. All the IaaS stuff has been around for a long time, where you could rent a machine from some data center owner. The PaaS stuff is a little new in its implementation, but the idea is what many developers have dealt with in organizations where they didn’t have any administrative privileges. The database was just a database, no server involved.

    The biggest change I see with the “cloud” is the pace of change. Companies lose some of the overhead of dealing with different departments and getting resources provisioned. Because cloud vendors are working at scale, they’ve built tools that allow customers to spin up new VMs, databases, even clustered systems in minutes. Much of the tedious complexity has been removed, which allows users to just move forward with building systems.

    The move towards DevOps, with a focus on automation, means that vendors also build new platforms, capabilities, and options that we can use at a furious pace. The choices we have can be overwhelming at times, with no one person really able to keep up with the myriad of possibilities.

    To me, this means two things for your company. First, you always need to have some experiments running. No proof of concepts that will be turned into applications, but true developer or operational experiments where people try out an elastic pool or machine learning or a K8s replica set of Hello, World containers. Your staff needs to be learning and sharing with each other in small ways.

    The second thing is that you need to limit the technologies in use. While there are many amazing and useful new services, you can’t bounce between them and support an unlimited number of choices. Limit the number of technologies (languages, frameworks, platforms, services, whatever) to the few that get the job done, with a process to add new ones if a rational case can be made.

    The bottom line is that it is important to keep learning, evolving and using better technology over time, but we have to be sure that most of our time is spent working on the software we’re building, using the knowledge we already have. We’re paid to get work done and while learning is a part of that, it’s a small part. Mostly we need to be doing the other parts of our jobs.

    Steve Jones