Voice of the DBA

Category: Editorial

  • Republish: Idempotent

    Traveling today to Seattle and running around to Redmond as well. No time to look at anything, so you get a republish: Idempotent

    Enjoy and hope you learn something.

  • I Need a CS Degree. I Don’t Need a CS Degree

    For a long time I’ve felt that my recommendation for people wanting to enter technology wasn’t to go to college and get a degree, but rather start to learn on your own and get an entry level job (help desk, tech support, etc.) and start to work in the industry. That’s a good way to both experiment and understand what you’re considering undertaking as a career, as well as limiting your investment. It’s also nice to get paid to learn something.

    College is great, but it’s also expensive. I find that for many people, it can be hard to get a good ROI from college these days. The fast rising cost, not to mention the uncertain opportunities after college lead me not to recommend pursuing a CS degree, or really any degree, as a default view. There are exceptions, but for many people, I’d prefer to work and try to better understand where they should invest in education.

    However.

    Jerry Nixon has a great (long) post on Twitter on this topic, answering the question of whether someone should get a degree or not, mostly focused on developers and CS degrees. It’s a very nuanced view that you both should and shouldn’t get a degree. It really depends on what you want to do. There are cases where we might want someone to get a degree and deeply understand complex development. It’s one thing to build internal web apps or design a database used by internal sales teams. It’s quite another to design encryption for a military application or ensure a rocket can land on a floating platform.

    Both things can be true together. You should get a degree to be a developer and you should not get a degree to be a developer, but the more detailed answer depends on where you want to work and what you want to achieve. A nice optimistic view from Jerry is that some people want to achieve something bigger than a paycheck, bettering the world with software, not to earn more, but to make life better in some way. I wish more people felt that way.

    A great piece of advice from Jerry is to listen to those who you want to become, not the loudest people. I somewhat lament that so many of the very, very smart people I know or hear about are focused on tooling that generates revenue or income, and not necessarily pursuing improvements in the world. That’s their choice, and I can’t get upset about so many extremely capable technologists working in finance or FAANG rather than areas where they might change the world for the better. I can be though, and am, sad.

    Read the post, and think deeply about what this means to you. And if you want to be a great software or database engineer, then do great things. Work hard at your craft and constantly sharpen your saw.

    Steve Jones

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

    Note, podcasts are only available for a limited time online.

  • The Cloud Security Problem

    Your management gets a great demo from a cloud vendor and decides that the organization needs to implement the new service/application/etc. quickly. Your team tries to comply, furiously learning and experimenting with integrations, software changes, infrastructure configuration, and more. Things get deployed are working. Clients and management are happy with the new capabilities and you breathe a sigh of relief.

    After a bit of time there’s a security issue and all of a sudden there’s blame pouring down on everyone. The vendor takes a hit because it’s a public security problem, but the reality might be that your organization didn’t completely understand how to configure strong security. The public doesn’t blame your organization, but internally your team don’t know how to make changes to ensure future security.

    That’s a bit of what happened with the Snowflake customer hacks, and a good description of some of the issues is in this piece from Joey D’Antoni. Snowflake didn’t necessarily have bad security, but they allowed customers to have bad security and also limited the options for customers to implement stronger security.

    I think about this all the time as I look at the challenges of security that many organizations face. In my decades of working in different situations, the one thing I know is that pressure to move fast often creates security shortcuts. Much of the early security problems with SQL Server could easily be traced to a) allowing installs with no password, b) developers not understanding the security model and granting sysadmin (or using sa) in their applications, and c) management agreeing that this was OK because a deadline needed to be met.

    In all these situations, workers had the best of intentions to go fix things later, but there was rarely the time or energy to do so. As someone who forced apps to change away from sa in a large org, and required separate accounts and passwords for servers, I can tell you no one liked me and I got a lot of pressure to leave things alone. That is until I could explain the risks to managers with security people present. Even then there was no shortage of people who wanted me to assume the risk of apps using sa and let things be.

    Cloud security is pretty good from the major vendors. Most of the smaller co-location facilities I’ve worked with in the past also had good security. It was the clients that caused problems, often because of a lack of knowledge or the desire to hurry.

    Joey says Entra is a great system. I agree, and I love the SSO capabilities I’ve seen implemented. I also know that trying to set things up and configure them has been difficult for me, and I think I can be pretty sharp about lots of technology. Joey has patiently answered many of my ignorant questions because I didn’t understand how some part of Entra (AAD) works. I think lots of tech people don’t understand this and don’ t necessarily have a Joey to call on.

    Most of us working in technology need more security education, better habits, and the patience to implement strong security. That includes management. At the same time, I wish that the solutions out there were easier to understand, or maybe better explained for those of us who need to use some portion of the authorization and authentication systems in our software.

    Unfortunately, security software is still software and those vendors push out changes and updates quickly as well, leaving education and documentation to the user. This is a bad situation that continually arises with regular issues in many organizations.

    Steve Jones

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

    Note, podcasts are only available for a limited time online.

  • Databases for Executives

    There’s an article at Forbes about the Five Things Business Leaders Should Know about Databases. Disclosure, it’s by my boss, but I think it’s still a good read. These are points we’ve learned from research and work with customers and prospects at Redgate Software. These points come from you, as well as from executives with whom we work, but there are so many people in organizations who don’t think about the complexity of data, so it’s a good one to pass along.

    The five things are (if you don’t want to read): data is growing, getting more complex, there are multiple database platforms in most estates, teams struggle (duh), and data is a business issue. Most of us know about the fourth one, often because we may feel overloaded with work. We might also feel a lot of stress in trying to keep up with not only the workload but also trying to learn more to support the ever-growing variety of systems it seems our employer wants to put into production. I regularly talk with customers whose developers keep wanting to try out a new, shiny database platform in the cloud (or add new features from their existing platforms).

    Wait, not try out. They’ve already deployed some production data there and now want other developers or operations people to work with their system.  Often lots of the staff isn’t familiar with the platform or feature, even the people who decided to implement it. Is anyone familiar with that situation?

    The digital transformation and importance of software isn’t lost on most executives, but I find far too many that don’t place the same importance on the data that powers their software or the database platforms that support all software. Data is important, and ensuring it is available to software, protected, secured, and available is critical. That also means that the process of developing and managing the database portion of your software matters.

    I think Database DevOps is important, but it’s not a panacea to buy a product. I’d love to show you what Redgate Software can do here, but the main thing I stress to clients is that you need to get your database development into the modern era and match what software developers do. That means a smooth process, with version control, that ensures you deploy changes in a way that doesn’t impact customers.

    This doesn’t mean just go faster. This means bringing along data modeling, good architecture, and performance testing. Those are the same things we’ve been doing (or should have been doing) for decades, but we need to ensure these are still a part of whatever process we choose and included in any automation we implement.

    Pass the article along to your management, and be sure they understand that all these points are important. Particularly the fourth point because if your staff isn’t supported and trained, the rest of the business will suffer.

    Steve Jones

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

    Note, podcasts are only available for a limited time online.