Voice of the DBA

Category: Editorial

  • The API Battle

    I think Oracle is a fine database platform, maybe too expensive, but it works. However, I’m not a fan of the company, and I find myself less enamored with them when I read about this case. This the Oracle v Google case, where Google is accused of violating copyright of Java APIs when it build Android.

    Essentially Oracle claims that the Java API, the packages, classes, methods, etc. are copyrighted and cannot be used in any other product. I assume this means that if I implemented the Java.SQL class, writing the code in C#, I’d be infringing on Oracle’s work.

    Even if I offered my software for free, this could be legal violation and I’d owe Oracle money. Or I’d need to license the API from Oracle. Any guesses on whether that would be inexpensive or prohibitive?

    In one sense, I do think that copyright and patent protection should exist. On the other hand, I think some of the applications of the original laws and ideas to the digital world don’t translate well. I certainly think that APIs shouldn’t be protected. These are essentially function names, and while I appreciate the need to copyright words, I don’t think it should go this far.

    I am hopeful that the Supreme Court will hear this case, and rule that this isn’t a violation. As someone that works for a software company, and has written software designed to inter-operate with other products, I think this would cause lots of chaos in our industry. I also think we have enough silly licensing and limiting practices in software, and I’d prefer to see less, not more.

    Steve Jones

  • What’s the Lunch Factor?

    A few weeks ago I wrote about the bus factor. This is the number of people that could cripple your organization if they got hit by a bus. Maybe a better way of looking at this is the lottery factor. If these people won a lottery and quit, would they cause problems? There were some interesting answers in the discussion.

    There is another factor that I heard about in a presentation that I found interesting: the Lunch Factor. This is the number of people that have to get involved for you to deploy changes to production. Today, I wonder what your lunch factor is? Leave a note in the discussion.

    This may be one set of people in your organization for things like patches, which are supposedly tested and approved by the various vendors you use. For software that you develop internally, likely there is a slightly different group of people, with some overlap. Usually the Operations staff is the same in both situations.

    In a true DevOps organization, the idea is that developers can actually release code to production. Maybe not every developer, or not every developer can release every type of change, but the idea is that developers can, and do, release code. They’re also responsible for this code. In my discussion with Donovan Brown and Abel Wang of Microsoft recently, this is how they view the world.

    They also would likely have most code released triggered and controlled by feature flags, which might ensure that customers can’t see the code right away, or that the code doesn’t break existing customer work. This also ensures that you can turn the feature off if there are problems. I’m a big fan of feature flags (or feature toggles) and think they are way too underutilized by many organizations.

    Allowing developers to release code is difficult for many managers, and even for Operations staff. There is always the worry that developers don’t have the expertise or accountability to make these decisions, and many orgs don’t have the capability built in to allow this, much less give the authority to a wide group of people.

    Microsoft does, as do lots of organizations trying to embrace DevOps and produce higher quality, more adaptable software. Many of these companies are bound by Sarbannes-Oxley and other regulatory rules, and they make it work. They grow, change, adapt, and most importantly, constantly improve their systems and process to allow this. For them, the lunch factor is 1, or maybe 0 if you consider that no one needs to get taken to lunch. What’s your factor? What staff, managers, even change control boards have to get involved? Let us know today and then think if you could reduce that number.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Pulling Together

    When the COVID-19 Pandemic grew rapidly in early 2020, medical supplies were in short supply. Different areas and organizations struggled with different types of issues, and one of the higher profile issues was with ventilators. In March, the projections were dire and quite a few hospitals were worried about the supplies of these devices. This was especially disconcerting given how many people were being placed on them and how long it takes to produce them.

    I met someone at that time that said getting a car company to produce these wasn’t possible. The factories were specialized and converting machinery and people wasn’t something that could be done in months. This was someone that claimed to have over 30 years of manufacturing experience.

    I had no basis to argue, though my instinct was that we have mobilized large industrial efforts in the past. When I read this article recently, it made me think about that conversation. Microsoft worked with a number of manufacturers to produce ventilators quickly, up to 400 a day in the UK. The story is interesting, and it shows that engineers at companies like Ford, McLaren, Unilever, Rolls-Royce, and more can not only work together, but also focus their efforts in a crisis. With the help of technology and data, they transformed a manufacturing process from the ground up to meet the needs of the UK.

    If you watch the video of the effort, it is amazing to see just how knowledge and data are brought together to ensure these devices can be built quickly, and at a very high level of quality. Certainly some PR is involved here, but the keys to success in producing something are the knowledge and skills being applied to a task. Products like dashboards and the Hololens help to move knowledge around where it is needed. In building software, tools like Live Share help to move knowledge from one person to another.

    The coordination of people working together, driving to a common goal, is critical as well. DevOps asks us to practice this, choosing to be a team, with the goal of increasing quality while we focus on delivering software to customers. This is a great story, but one that highlights things that many of us could strive for in our daily work.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • AI Data

    At the Microsoft Ignite conference recently, I saw a talk that mentioned the Microsoft Garage Project, Trove, which is designed to help people provide data for AI projects in a new way. You can read more about it and get the app for Android mobile devices.

    Trove is built to help AI researchers find images and use them in projects. However, the data they get is provided by users, who make the choice to include their data. This is different than many AI projects, where anyone doing AI work often just gets data from various sources, sometimes without permissions, but often without the individuals who own the data understanding where their data is being used or for what purposes.

    I like the idea here of people specifically giving permission for their data to be used. It’s a good way for volunteers to provide data, and have some control over how the information you provide might be used and where it is used. That doesn’t mean this is necessarily a good model for the future. First, I’m not sure we can easily verify that the images someone submits are their own. I could see that if there are payments made, I’m sure people will try to game this and earn more money by using images they don’t own. We already have problems with people publishing content they didn’t create. I’m sure we’ve have plenty more with something like Trove.

    The other issue, and likely the biggest one I think is a problem, is that trying to understand what data is collected and how it’s used by many companies is a challenge. Even when there is some disclosure, it can be difficult to understand what is being released. Even while reading this document on SQL Server data collection, I’m not sure what might be collected on my system that could be an issue.

    I don’t think this is malicious or deceitful on Microsoft’s part, I’m just not sure I can understand the implications. That is where I feel we, as a society, and certainly with regards to regulations, are woefully immature. We don’t have good controls, but I’m not sure we really know what we’d want.

    This is a thorny problem, and one I know we need to find better solutions to over time. Especially as we use more and more data for large scale research and applications in areas such as Artificial Intelligence and Machine Learning.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.