Voice of the DBA

Category: Blog

  • Production Kubernetes

    Still learning more about Kubernetes. I’ve been working through the 50 days of Kubernetes (K8s). Let’s keep exploring

    The API is the security boundary

    Everything happens with the Kubernetes API. Therefore, we want some RBAC here for the roles of individuals, as well as processes, like CI/CD pipelines. We want to ensure we have validation, security scans, etc..

    Things will go wrong

    In addition, we need some monitoring on the cluster. We need this on any system, but with scale and complexity of containers in Kubernetes, we need something in place.

    In addition, you want to test failover, which is likely between clusters. Containers do make this easier, but it’s something we want to ensure is a part of our process. This means practice. We know practice matters in most places, but we often don’t practice well in IT.

    Scaling

    There is planning to think about a large application, or maybe large for your environment means thinking about global access and ensuring that you have a way for your app to easily redirect across clusters or regions. There are also data challenges, as Brendon notes, with things like databases. It’s an opportunity to push CosmosDB, but in the relational world, we know how to handle this.

    Kubernetes will make AGs and HA easier.

  • Salaries in Job Ads

    Hiring at Basecamp is interesting. I caught this interview and think it’s a good look at a process most of us have gone through, but perhaps not thought about. Maybe we ought to try and not start out our relationship as employer/employee with a “I got one over on you”.

    Of course, many companies are not interested in treating employees well and just assume they’ll hire/fire/turnover often. Makes sense in some places (McDonalds type work), but less sense in our industry.

    I do think that we hide salaries too much in our industry. Certainly this aids in favoritism and entitlement for works with seniority. I’d really prefer to see salary ranges published for jobs, both internally and in the description. And not some huge range, but put something like a junior DBA from US$35,000-50,000. Or whatever range you think is appropriate.

    This would do a few things for me. First, it ensures that candidates that want to work for that range will apply. It also ensures you don’t waste time with a developer that wants to move to DBA work, but really needs $70,000 for their financial commitments. This also helps you determine if you’re range is correct for the market.

    I am a big proponent of disclosing more info up front and finding a good match between employer and employee.

  • T-SQL Tuesday #117 Invitation – When Have You Used MOT Tables?

    When Memory-Optimized Tables (MOT) were announced for SQL Server, there was a lot of excitement about the technology. After this was released on SQL Server 2014, feelings waned with a lot of restrictions and limitations for using the technology. I remember a panel at a conference years ago where most of the MVPs and experts recommended against using the technology for most users.

    Today there have been improvements (2017, 2016) in the MOT features, restrictions have been removed, and all editions can use MOT tables. That’s not to say that this is suitable for every table or situation where a DBA or developer suspects performance issues.

    This month I want to ask you about when you’ve made that decision. This can be to use MOT tables or NOT to use MOT tables. This could be a simple thought, a POC, or actual testing of the feature.

    Some ideas for you to write about:

    • Performance analysis of MOT tables that affected a decision
    • Reading the limitations and knowing this would prevent their use
    • A scenario where MOT tables improved performance
    • A successful implementation of MOT tables and what needed to change in your app
    • A failed attempt at trying MOT tables

    There might be other things that are related to MOT technology, but let us know this month what you think of the technology and how it has (or has not) impacted your application.

    The Rules

    Here are the rules as set out for the T-SQL Tuesday blog party.

    1. Your post should be published on Tuesday, Aug 13, 2019 between midnight UTC and 11:59:59 UTC.
    2. Include the T-SQL Tuesday logo in your post.
    3. Link back to this invitation.
    4. Include a comment on the invitation post or a trackback link.
    5. Enjoy the chance to be creative and share some knowledge.

  • Expose Multiple Docker Ports

    I was working with containers recently with Jenkins. I didn’t want the server process running on my machine all the time, but I did need to allow some communication. Jenkins uses 8080 by default, but agents need another port.

    I figured there was a way to do this, and I found it on Stack Overflow, which is the perfect forum for a question like this. The answer? Multiple –p parameters.

    Instead of 

    docker run –-name jenkinsci –p 8080:8080 jenkins/blueo

    I do this:

    docker run –-name jenkinsci –p 8080:8080 -p 50000:50000 jenkins/blueo

    That opens two ports from the host to the container, which is what I need.