Voice of the DBA

Category: Editorial

  • Re-platforming

    Re-platforming is the process of moving a system to a new platform. Imagine taking an ASP.NET/SQL Server website and moving to Azure Functions on Azure SQL Database. Or maybe taking a Java client/server app with Oracle and moving it to a series of microservices against MongoDB. Those changes could be a net benefit to your organization in the end, but they aren’t quick or easy. They’re often fraught with various challenges that can cause a lot of stress while creeping over budget.

    There’s a post that talks about some of the things you might think about if you embark upon a re-platform. Often this takes place when an organization is looking to modernize their tech stack. Quite a few of the technology DevOps success stories take place when the older structures are not maintainable, but also not able to handle increased workloads or performance requirements.

    It’s often said that a complete rewrite rarely makes sense. I think that’s likely true, but that doesn’t mean it isn’t something you should do. It says that you should rarely do it, and you need to pick a good time when your old application, database, network, or some combination of these can no longer meet your anticipated future growth demands. This is likely a debate that your organization should have every year or two and ensure that continued investment in the current platform makes more sense than a new one.

    Once you decide to move forward, it will be a journey, which means understanding how new and old systems will interact becomes important. Compatibility, at least for some time, is very important. I’d say this is especially critical for how your data systems will work together and what options you have to replicate/ETL/etc. the data between systems.

    Even if you plan to make a cutover from one system to another, data migration is fraught with issues. Anyone trying to ensure data moves cleanly from one place to the next should have strong checks, usually with automated tests, that evaluate if your data is moving correctly. Row counts aren’t enough, or not the only metric. Random checks of individual rows, as well as checks for outliers, should be a regular part of any project that will migrate data. Learn where you struggle to correctly transform data because there will be places where this happens.

    I don’t believe that wholesale re-platforming often makes sense. Leaving SQL Server to go to another database platform, or even when you might try to change the paradigm with NoSQL or a Data Lakehouse, often costs a lot. Getting a return after staff training, migration costs, and even delays from inefficiencies during the process often equals many years of licensing. I think slow migrations are a better idea, perhaps adding something like ElasticSearch or Redis, experimenting with a small data lakehouse for a particular purpose, and replicating some data to Neo4J for complex hierarchy queries. These evolving mechanisms give you the chance to experiment and learn about the process. It will help you understand if there is a positive ROI if you continue.

    In many ways the world of technology changes slowly. We have lots of new shiny toys, but many of them don’t magically solve your problems. There are always tradeoffs and without strong domain knowledge, you may have more unknown unknowns that reduce your chances of success. Re-platforming can work, but make the decision carefully and proceed methodically, not with haste.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

  • Protecting Off Hours

    Legislation was introduced in Australia to allow employees to protect themselves from unreasonable calls and emails from work during off-hours. You can read more about it, but a bill was passed to allow employees to ignore calls and messages without repercussion  It is expected to pass, though I don’t expect this to do a lot for bad bosses. They’ll find ways to hint or imply that you need to respond, and might even remove your chances of advancement/promotion/raises. While you can sue, that rarely works out well for anyone.

    From the various reports I’ve seen, I’m not sure if this includes salaried workers or just hourly workers. I certainly think hourly workers ought to be paid if they’re called after hours. I’ve even been paid as a salaried worker if the calls outside of core hours exceeded a certain amount per week. That seemed fair to me, and in our team, there was always someone willing to work more for extra money, so I could trade on-call work if I didn’t want to do it.

    As a side note, my second time on call (for a week), I got paged over 40 times. It was a nice paycheck, but not worth it. I had toddlers in the house, and I slept with a vibrating pager on my chest to not wake my wife. It was not a good week and I traded away my on-call weeks to others, sometimes even sweetening the deal by buying them lunch.

    There are a lot of people working in technology who don’t like the job and don’t recommend a career in this business precisely because they are overworked. The US has a very poor work-life balance in general, and many people feel pressured to work lots of extra hours. My colleagues and friends overseas do lots of work, and seem just as productive, but don’t arrive early, leave late, or work weekends very often. Sometimes they do, but not often. In the US, many people work more than 40 hours regularly, with a commute, and think this is normal.

    There are times when extra work might be needed. However, with plenty of us working from home after the pandemic, it’s important to strike a balance of some sort and learn to get away from work. I’ve worked hard to reduce my hours from a regular 60 while owning and running SQL Server Central to something more reasonable now. I certainly have weeks I work more than 40, but I have weeks I work less.

    Balancing the workload in a day is something else I watch. I try hard to not set meetings or work too early or late, but the nature of my job means I work with people in the US, the EU, and Australia. As I write this, I started work at 8 am this morning with a meeting and I have an 8-9 pm webinar for the Australian region. However, I went to the gym at lunch and coached kids for a few hours in the late afternoon. I found a balance and while I might have worked 9 hours today, I don’t often do that. I will take 6 am calls, but not regularly.

    There is something satisfying about working hard to earn your paycheck each day. It gives one purpose and satisfaction for a job well done. At the same time, it’s important to get away from work, enjoy your family, friends, hobbies, faith, and more. In technology, where regular hours aren’t always part of the job, you must manage your life well. I don’t know that legislation would help in the US, but I am interested to see how this proceeds in Australia.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

  • Growing Skills at Work

    Redgate released the results of their State of Database Landscape recently, and I was part of a webinar where Beca Parker, Ryan Booz, and I discussed the results. As we were talking, one of the things that struck me was the high number of people who had picked skills as being a challenge for their organization. In a single environment, skillset requirements and training were the number one challenge, and it was listed as the number one obstacle to implementing a DevOps approach.

    While this industry is full of self-taught individuals who have spent time learning new technologies and tools, it’s somewhat amazing that training continues to be an issue. Many organizations limit their training budgets and time allocated to employees while continuing to expand the number of technologies and platforms they use. This is one reason why I think changing database platforms to avoid licensing costs is unlikely to save you money anytime soon. Retraining staff and developing competence takes time. Perhaps this is also one reason why many companies look to the cloud, thinking that they can reduce the amount of upskilling needed by their staff if the cloud vendor manages the systems.

    That might be true, but there is a lot of knowledge is still needed about how the underlying technologies work, especially if employees are to efficiently write code or make configuration changes in the system. The cloud can be more cost-effective, but it can easily be less cost-effective. Knowledgeable employees can make a difference.

    I do see plenty of organizations subscribe to online learning, but often I find these courses good for basics, but not necessarily helpful for specific situations and just-in-time knowledge requirements for projects. There more custom training, or at least, group support, is needed to ensure that your staff is learning efficiently. Far too many people can’t handle open-ended training from an online platform and complete more than one course.

    Training isn’t enough, as there also needs to be some practical application of new skills in your environment. Practicing katas as a group, coaching each other, and applying skills to actual projects while measuring results is important. It takes some commitment from both employees and organizations to get better. Far too often, I also see staff unmotivated to learn and grow, for a variety of reasons, but that’s a different problem that we have to work to solve together.

    The world of technology in business is growing increasingly complex. We find more and more organizations adding technologies, especially new database platforms, and we lack skilled people to work with them. That’s a constant challenge, but one that creates opportunities for you if you find ways to improve yourself.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

  • Navigating the Database Landscape

    The title of our keynote session at the Redgate Summit in Atlanta is Navigating the Database Landscape, and I’ll be delivering part of the talk, along with Grant Fritchey and Kathi Kellenberger today, Mar 13. This is based on the State of Database Landscape Survey results, as well as our experience working with customers and implementing DevOps solutions over the last decade. The talk was mostly written by others, but as I rehearsed the session, I found myself wondering about how I’d approach my job if we returned to being a DBA or developer.

    When working in technology today, there are many challenges outside of actually learning about any of the particular products, languages, platforms, etc. We have the politics of working with others, ongoing work, emergency requests outside of channels, random questions asked by others, code reviews, and probably a few other things I’m forgetting, all outside of learning any new skills. While I consider myself a lifelong learner, I know that finding time (and energy) to acquire the basics of any new technology is challenging.

    At the same time, while working in any size estate, it seems that someone always wants to add a new tool, platform, language, service, or database to the environment. It’s great we have choices, but it seems like sometimes every technologist wants to just use something new rather than work within the areas we have experience. Early in my career, it was rare to find more than 1 or 2 database platforms in a company. Now we have lots, often seemingly just added because one person watched a talk or video and thinks it would solve all our problems in this particular instance.

    Working in an enterprise of any size likely means there are multiple database platforms in use. While you might only be in charge of 1 or 2 today, who knows when someone will call you as the “database expert” and expect you to configure Redis or troubleshoot ElasticSearch. I’ve had friends in this position, and I’ve had people come ask me to figure out MySQL, DB2, BTrieve, Lucerne, and more in my career. It’s a challenge, and it’s also stressful because I want to do a good job, even if I don’t know what I’m doing. Fortunately Internet search, contacts among friends, and more have helped me usually solve an issue.

    The modern database landscape is likely to be more complex than ever, and with the advent of cloud services, we find there are lots of options that anyone in an organization might choose to use in production, and then ask you to support them. Our jobs are increasingly complex, both from the depth of things we need to know about a database to the breadth of different products and services that might enter our realm of responsibility. Navigating all this is a challenge, but if you rise to the occasion, there can be a lot of rewards.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.