Voice of the DBA

Tag: software development

  • A Technology Collapse

    This past week the Arecibo radio telescope collapsed, with cables and instruments falling into the massive dish. You can see images of the devastation, which saddens me. I doubt this will be rebuilt, though one can keep hope alive. there were reports of failures a month or so ago, with the intent to shut down the telescope, remove instruments, and institute a controlled demolition.

    The facility was featured in a few movies, notably GoldenEye and Contact. The latter is one that first showed me the telescope, which I first thought was a movie magic trick. When I found out this was a real facility, I was amazed that humans could conceive and build such a structure. Even more amazing is that it was built in the 1960s.

    That’s quite a lifetime for a piece of technology. While I’m sure lots of wiring, electronics, computer systems, and more were added or upgraded, the core of this telescope remained the same. The ongoing engineering effort, fitting new capabilities around legacy systems and structures, was likely a study that many would find interesting.

    I don’t know many database systems that have survived that long, but certainly there are some long lived legacy applications. The Sabre reservation system for airlines is one that stands out to me. The history of this one is fascinating, especially as it’s a system I’ve depended on in my travels.

    Many of us that work with databases likely feel that everything we do is a legacy system. The dependencies our objects have on various applications, scripts, reports, and more can limit how much repair, improvement, or replacement we can make to schema.

    There are good techniques for modifying our objects, and helping to ensure we don’t break systems, but we often do need some cooperation and collaboration with application developers to implement those changes. Much of DevOps avoids talking about the database, but we shouldn’t. Instead, we ought to embrace database refactoring patterns, both at the database and application levels, ensuring that our systems can survive for as long as we need them while adapting to the changing requirements of our clients.

    Steve Jones

  • Rough Consensus

    The IETF has a document, RFC 7282, also called ” On Consensus and Humming in the IETF”, in which they describe how the body makes decisions. This is their philosophy:

    We reject: kings, presidents and voting. We believe in: rough consensus and running code.

    That is a process that I can get behind. Overall, I don’t like authoritative leaders. I don’t like to be one, though I do recognize as a manager there are times I need to make some decision. Overall, however, I like consensus.

    Someone was discussing how to choose approaches when developing software and brought my attention to that quote. With us being remote now, and unable to hum, this person talked about how to solve problems without humming.

    This individual talked about identifying solutions in a team, but not taking a vote, or rather, no immediate vote. Instead, they devised a rating system allowing everyone to look at all solutions and rate them from 5 (best solution ever) to 1 (this would be a terrible mistake). They then produce a histogram of the results for each solution.

    Once they’ve done this, they can then have people raise issues and debate them. I assume time limited, which is important, but often when we see different levels of support, we may rethink our rating or the merits/detractions of an approach. At some point, they re-rate the solutions and try to develop consensus.

    We won’t always agree completely with an approach, but I do think that we can often come to some decision we can support, especially with some rational arguments and reasoning. I’d like to think that I rarely had to overrule an entire group. Building a team means finding ways to discuss, debate, and decide together.

    Steve Jones

  • Markdown Links– Remembering the Basics

    For some reason, I can never remember how to do markdown links. I know to use the hash symbol (#) for headings. I know that asterisks do bold, or italics, though I can’t remember one or two without checking. This seems to work for me. Though when I check the markdownguide.org, I see I’ve forgotten underscores can be used.

    I know numbers and dashes for lists, that’s intuitive. I get that and use it all the time.

    But I can’t remember how to do links. I know parenthesis and brackets are involved, but I constantly seem to get it wrong.

    Writing help memory

    At least for me, writing actually helps my memory. so, I’m writing this on a piece of paper.

    [text](link)

    As a matter of fact, I’ll write it a couple times, and type it here.

    [text](link)

    [voice of the dba](http://www.voiceofthedba.com)

    while I’m at it.

    ![text](image)

    Maybe now I’ll remember this.

  • Building for Scale

    This year’s pandemic has moved a lot of business to the digital world. We see that with increased ecommerce from many companies, including lots of local business, like restaurants, that have embraced online ordering, pickup, and delivery. In many cases, the companies providing these services were able to scale and meet the additional load, which arguably wasn’t that high for any individual organization.

    However, some services aren’t able to handle the loads, especially government services. Recently the Florida voting registration website crashed under a larger than expected load. We’ve seen unemployment sites crash in the US, the contact tracking website in the UK, and plenty more.

    I can understand the challenges of government sites, many of which were built on older technology and rarely upgraded with budget restrictions. Investing in new technology is not only expensive, but it can be a huge challenge to ensure systems work through a transition, especially when many users are counting on services to be available.

    I do think that the future of much software development needs to be with a hybrid cloud architecture. There are great government secure options from AWS, Azure, and other providers. However, even if you build software that is intended to be in your data center (or a rented one), you ought to be thinking about how to scale it beyond the machines on which it exists, especially if you provide public facing access.

    Whether in government or private enterprises, we see the demand for systems grow and shrink rapidly. You can have incredible success, or face shrinking demand quickly. This isn’t like an investment in a large physical plant. The digital world allows us to easily scale up and down, using the cloud concepts and architectures developed over the last decade. Learn about the patterns, and ensure your systems can scale as needed.

    Steve Jones