Voice of the DBA

Category: Editorial

  • Data Orchestration

    We continue to deal with larger and larger data sets all the time. In fact, it seems that most people find themselves outgrowing the capabilities of some of their OLTP databases, often RDBMS stores, and need to upgrade hardware or re-architect software. It doesn’t matter if you have a 100GB database on a few cores or 10TB on dozens of cores, there is often a need to upgrade to meet our workload demands.

    In addition to the transactional needs, there is a growing demand for reporting and analysis workloads. Some people use a separate warehouse, and some want to just query data where it is. Certainly ETL processes and platforms have grown tremendously over the last few decades for those that want to implement the former process, but there is plenty of demand for the latter. In fact, I’m amazed how many customers have inquired if Redgate’s SQL Clone product will enable them to do this and spread their workload to other systems (it’s not designed for this).

    I’ve been thinking that with SQL Server 2019 we will start to access data where it lives, not move it to another place we want it. To me, this is more of what future data orchestration might involve. I ran across an article that takes a slightly different approach, thinking AI and other products will help better move data around, and perhaps that’s true, but I do think more and more we want to query data where it lives, and use larger, distributed compute platforms to do this.

    The scale out capabilities of SQL Server 2019, with the separation of compute and storage in Big Data Clusters, is a huge change that I think will be the future for many of us that look to meet reporting needs. The ability to grow hardware to match the workload needs is huge. This alone is a good reason to think about doing this in a hybrid or public cloud scenario.

    Of course this doesn’t come cheap, easy, or quick. There is work to be done to evolve systems, but it is an area I think is worth experimenting in during the coming year. I bet many companies would be interested in some PoC work here to determine how to better meet the reporting requirements of larger data sets. Perhaps this is something you suggest to someone in your organization.

    Steve Jones

  • Back from My Sabbatical

    It’s been six weeks away from work, but I’m back now. It was a great break, I’m refreshed, and I am ready to get back to writing, speaking, and working with the data platform again. I haven’t done much SQL Server work, but I have been busy. With this being my first day back, I did spend a few minutes looking back at what it was like to have a voluntary, extended break from work.

    The time away was very refreshing. I was able to spend days on my own personal growth in a few areas as well as tackle personal projects that my wife and I have wanted to do around the house. I avoided the computer for the most part, only using it for personal tasks, like watching guitar videos on YouTube. I used my hands often, rarely sitting at a desk.

    At the same time, this was an enlightening break. I realized I enjoy my job, and I enjoy technology. During a two day stretch near the end of my time away, I attended a conference and spoke. I engaged with other technologists and realized that I really enjoy working with and talking about databases and technology.

    I am ready to go back to work and looking forward to what 2020 brings to my career. I’ve missed Redgate, and I’ve missed interacting with many of you on a daily basis.

    Perhaps the best part of the sabbatical was that it have me a glimpse of retirement. I puttered around the house, did things I wanted to do, at my pace, without pressure. I handled it well, though I also think I do need a little more purpose or focus when I do retire.

    It was a good break for me, and I’m looking forward to the next sabbatical in a few years. In the meantime, I’m ready to get back to writing and speaking and SQLServerCentral.

    Thanks to Kathi, Kendra, Grant, and the others at Redgate for covering my work while I was away, and I hope everyone out there enjoyed their stewardship if the community.

    Steve Jones

     

  • Favorite Cars

    Ars Technica recently wrote about their favorite cars of 2019, which is an interesting list. They get to test a lot and I read their reviews to see what they glean. I love cars, and enjoy driving different vehicles, and I’ve owned a lot in my life. I think I’ve probably owned and regularly driven 30 cars since I started driving at 16. There was even a period of a few years in my life where I traded in my car for another used one every 11 months.

    I do get to drive or ride in a decent number of cars as I travel regularly and do rent cars at times. In the past year, I managed to rent eight or nine cars last year, all different, though not very exotic ones. Still, it’s always interesting to see how manufacturers change their designs and add technology. I’ve been surprised how much I enjoyed driving around a few cars, such as the Kia Soul.

    This week, I’m wondering what you fellow data professionals out there like to drive. Are there any cars or trucks that you have look forward to getting behind the wheel of and puttering around? I’ve got a long break coming up and perhaps I’ll take a few hours and go drive something around. Give me some ideas of what you like, new or old.

    In my car history, I’ve had quite a few cars I really enjoyed. I’ve had 3 Isuzu Troopers over the years, all of which I liked. The two Suburbans (1988, 2001) I owned were both some of the vehicles I liked taking on trips. An old VW Scirocco in college was a great beach vehicle for me. My 914 and 911s are two I slightly regret letting go, but it was a good decision at the time. I enjoyed our first Prius, mostly because of the MPG when gas was US$4/gal, but it’s not a car I look forward to driving. I would like to get behind the wheel of hybrid Toyota CH-R and see what that’s like. That’s not in the US, but I could try the ICE version.

    My wife likes the Tesla, and I’ve ridden in a few. Not sure it’s the car I want, but it’s very interesting to drive. The idea of electric vehicles makes sense to me, and I expect to see more and more over time. Not sure if we’re ready for one, but we will likely look to get another vehicle in the next 2-3 years, so maybe that will be on the short list. Let me know if you think that’s a good idea.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • A Problem with Cowboy Coding

    As we implement more automation and complexity in our systems, we increase the ability of every worker to accomplish more during their day. In many cases, this is a good thing, as many of us have no shortage of tasks to complete. Being able to do more is good. Some technology workers, and likely some managers, view these changes as opportunities to use less people to do the same work. That can be worrisome for many people, especially those concerned with job security. That’s a difficult situation to find one’s self in.

    I’m not sure if this worker was concerned about losing employment or just wanted to get more work, but a contractor put logic bombs in his project that would cause issues at various times. He would then be called to fix issues, getting paid for his efforts. Recently he was sentenced to prison time for his actions.

    Most workers make an effort to do good work and provide value for their time and knowledge. They may still make mistakes or cause problems, but it’s often unintentional, not malicious. We also don’t look to create future problems for others, though certainly we may accrue technical debt over time as we make trade-offs in our work.

    Whether intentional or accidental, we want to limit mistakes and issues in our code. This is one reason that modern development in a DevOps environment isn’t a wild west, cowboy style of work. We use code reviews and continuous improvement to help other developers learn to write better code. We use automated processes with instrumentation and logging to ensure we know what code is deployed when and by whom.

    We may move faster with DevOps, but it’s often safer, more secure, and more accountable than previous methods of building software. It doesn’t prevent mistakes, but every part of the process should be more transparent and auditable, which is good for everyone involved.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.