Delivered 3 talks for this event. One on database devops, a lightning talk on the future of database development, and a talk on classifying data.
Wednesday schedule – Classify Data
Tag: DevOps
-
Speaking: SQL Saturday #962 Richmond
The first virtual SQL Saturday. I delivered Adopting a Compliant Database DevOps Process.
-
Never let a good crisis go to waste
There have been quite a few jobs in my life where my first day was complete chaos. Some were technical and some were not. I had a first day as a bartender (in more than one job) where someone was sick or the place was busy and I was left on my own to figure things out. Fortunately, I know my way around a keg and a bottle of liquor. I’ve also started at a couple tech jobs where we had a crisis in a system. I’ve been able to pitch in and help solve problems, or even get other work done on my own. In all these cases, the boss was impressed, and I often started out my tenure with quite a bit of credibility.
When we look to make changes, it can be hard to convince someone that the change is better for the organization. This might especially be true when working in software development and trying to convince someone to change their process or habit. I see this all the time as clients look to adopt DevOps, with no shortage of naysayers. There are always plenty of people that want to maintain the status quo.
I heard quote from a presentation by Comcast execs on DevOps: “never let a good crisis go to waste.” The quote has been attributed to others in history, but I think it’s an apt description of how to drive your processes forward when you know there are problems and issues and no one wants to spend time fixing them. Pain often allows an opening for a better solution to be considered.
Too often when there is no problem, no immediate pain, there is a lack of will from management to spend time improving things. Certainly there are some executives that believe in improvements, but far too many focus on adding something new rather than improving the underlying infrastructure of software development. When you see a problem, if you can’t make an improvement at the moment, keep an improvement or solution handy. You never know what a crisis might give you the opportunity to pitch a better way forward.
Steve Jones
Listen to the podcast at Libsyn, Stitcher or iTunes.
-
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
