Category: Editorial

  • Republish: Rogue Software Changes

    On site with a customer today, so busy all day. You get to read Rogue Software Changes while I’m working.

  • Contracting for Work

    Throughout my career, I’ve primarily been a full time employee for an organization. I have worked for myself, as well as for consulting companies. For the latter, I’ve been an employee as well as a contract worker. There’s a bit of difference between those, at least in the US, and it isn’t always easy to understand what that means for an individual.

    I thought about my various experiences while reading about Jon Shaulis’ T-SQL Tuesday post recently on changing his mind about contracting. He also has a section on T-SQL (bonus points for Jon), but the post is mostly about contracting and employment. Jon talks about some of the differences he’s seen between working for someone as a contractor and as an employee. His experiences are similar to mine, but I certainly wish I’d had a good list of these things when considering job offers in my 20s.

    There are lots of people in our #sqlfamily that have started consulting businesses, wanting to work for themselves and make more money. You can read various accounts of how well this works, but it certainly isn’t as smooth for everyone as it might seem. I like reading Brent Ozar’s yearly evaluations, and I’ve been following Eugene Meidinger’s journey as well. These aren’t about contracting too much, but they do give you an idea of what it’s  like to operate your own business, and as a contractor, you are your own business, though you have a little less of the “business” stuff to do since someone does the admin, selling, and marketing and just tells you what to do.

    I actually encourage everyone to consider themselves and contractor and don’t get too complacent with your job as an employee. You never know when you situation will change, and it’s good to be prepared. It might not even be you, as your spouse or partner might force you to make a change.

    Or your employer might.

    Just like a contractor might have one client for 10 years, I think it’s prudent to keep an eye on the environment and be prepared to find another client if some unforeseen event occurs. The days of single company employment for life are over for most of us. I have the best job, but I keep an eye on the market. One never knows when things might change for them.

    Deciding how to structure your employment is a decision each of us should make, but do so with an open mind and some understanding of the changes for work, benefits, savings, medical coverage, and more. While Jon has a good list, I’d love to see more people build and publish a structured checklist in terms of decisions and costs, even sample ones. This can help others get an idea of what the impact might be on their life when making a decision like this.

    No matter whether you choose to work for an organization or as a contractor, it’s not a final decision. You can change your mind anytime, though do so with some planning and consideration of the impact on you and your family. It’s not an easy decision, but you should be comfortable with your choice when you finally do make it.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Republish: Have a Think

    Traveling to London today for the SQL in the City Summit, so you get to Have a Think

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