Voice of the DBA

Category: Editorial

  • A Data Controversy

    Quite a bit has changed since this article about airlines and the US government.  Since very few people are flying, or even can fly, perhaps this disagreement is moot, but I bet it comes up again. Now, separate from the idea of the actual disagreement here, there is an interesting discussion about the data involved here. In short, the US government wants airlines to collect data about passengers to help track the COVID-19 virus. Airline executives say they can’t easily get this data, other than on paper, without spending a few months on development.

    Certainly having a way to gather additional information in a digital form can require some development work. There are all sorts of software decisions to be made about when, where, and how users might input information. We have mobile devices, kiosks, laptops, and more, all of which might require separate interfaces for software changes. There is also the testing, validation, and verification we want to ensure the software works well and doesn’t introduce instability.

    In today’s world, with growing legislation, there is also a question of privacy. These requests may or may not conflict with other laws that airlines are bound by. There is likely to be more conflict here as the world changes and laws are slow to change and converge in some type of consistency. Rapidly changing requirements, as have been pushed during the COVID-19 pandemic, can potentially put us technical people in a difficult position. We have to balance the urgency of meeting requirements with the potential liability of violating privacy. I’d hope we could find some balance there, especially in a crisis.

    We do need to be flexible and ready to adapt to changing requirements. If regulations change, our organizations ought to be able to prioritize these changes and rapidly deploy them. In today’s world, where many high performing DevOps companies can get new software out in hours or days, governments may expect large companies to be prepared to follow suit. In that case, especially where new data is needed, having a software development process that includes the database is critical.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • The Challenge of Contracting

    For most of my career I’ve been a full time employee (W-2 in the US) or worked for myself with my own business. I’ve rarely been a consultant or contract (1099) employee, and what experience I had with those situations didn’t suit me. I don’t like the lack of security and certainly don’t like being responsible for the sales portion of finding work.

    Many people like contracting, and in fact, some make a career of it. There are companies that help you find work, and many large companies employ people for years as contract workers. There’s an interesting article on the impact of this at Ars Technica. It looks more at hotels and other service work, but this is common for technology workers as well, especially at many of the large, common names. If you look through the comments, you’ll find a few examples.

    I do think this is starting to be something that workers have to contend with, and it’s been obvious how hard this is over the last month. This might be especially true as companies can find ways to better specify work and hire people for their expertise at less than full time hours. This does save them a lot of long term costs and commitment, which is a change from what I expected when graduating from university.

    I’ve said this in a few talks, but ultimately I believe that each of us should be treating all jobs as temporary, ensuring that you take care of yourself and plan for your future. While a company might provide benefits and some retirement help, you should ensure you are paying attention and saving where you can. In the US, healthcare is a mess and expensive for contract workers. Outside the US things are better in some places, but you should still ensure you plan to take care of yourself if the company doesn’t.

    It has always been hard for workers throughout history. Many companies exist to make profits for their management and owners, often at the expense of workers’ treatment. Despite that, there are some amazing companies out there that do a better job of existing as a partnership with workers than others. My employer, Redgate Software, is one of those, and I’m lucky to work there. We’re hiring, good luck if you apply, and tell them I sent you.

    I hope all of you reading this can find a good employer that treats you well and gives you work you enjoy doing each day. If you don’t  have that, invest in yourself, work on your tech and soft skills, apply for jobs, be diligent in your questioning of the hiring team, and cross your fingers. There are great employers out there, and best of luck in finding one for yourself.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • What’s the Cost of an Hour?

    In 2017, we had a number of high profile downtime outages from companies. The British Airways fiasco, United airlines being grounded, Starbucks, Amazon, and more. There was a survey that noted 98% of respondents said an hour of downtime cost their organization over US$100,000. A third put that figure over $1mm.

    This week, I’m wondering if you have any idea what downtime costs your company. If you do, and can let us know, drop a figure in the comments. Maybe you can give us a range, or maybe you can say it’s a large amount. If you don’t know, maybe let us know if it’s not important to your business.

    I haven’t often calculated this, but when most companies look at lost revenue from customers, lost ability to conduct business, and potential losses from employees sitting around, it’s probably a large number. Then again, many companies might just force employees to work extra to make up the work, so perhaps some companies don’t care.

    This certainly isn’t a simple answer. Modern systems are often distributed, with many moving parts, and complex network connections. With modern software development using caching, micro-services, and feature flags, it’s entirely that an application is down for some clients and not for others. Or perhaps, a portion of the application is broken while other parts work.

    Downtime can be disruptive and expensive, and it is something most system administrators plan for and work to avoid. If you know what it cost for either the loss of a system or in your preparations, it would be interesting to know today.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Don’t Lose Data Without a Hacker

    The GDPR has been law since 2016 and been enforced since mid 2018. California has the CCPA in law, but not being enforced. In any case, it’s 2020 and we have lots of tools and knowledge about securing systems. We aren’t perfect, and certainly Microsoft isn’t, but we should be avoiding simple mistakes.

    For those of us in the US, or outside CA, we might be less worried, but if you’re in the EU, you should be concerned. Here is a mistake by Virgin Media, with data exposed for months. Someone configured a database, likely set it up for access remotely, and didn’t do a good job.

    It does start to feel that we ought to have some sort of security smoke test in every organization that checks for exposed databases in our networks. Perhaps we even ought to have this for all subscriptions with vendors that host services for us in the cloud. That might be good for IT people, but what about shadow IT, or the average person that just wants to share data with co-workers?

    No one ought to be able to configure a file share, an S3 bucket, Azure BLOB Storage, or anything similar by clicking in some sort of control panel. Honestly, I get that vendors want to make things easy, but we need security over data in all organizations. There ought to be a “configured” click to share button that runs a series of scripts to ensure we have secure controls over resources. File shares might be hard, but for databases, there’s no excuse.

    I do know that for some people, it’s a pain when they can’t create databases. I deal with customers regularly that have this restriction on developers, and it’s problematic. However, we need better security, and really, we need less real data being shared so widely. As an industry, we need better dev data sets, and we need better security protocols over any production data.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.