Voice of the DBA

Tag: software development

  • Always Canary

    Deploying software is hard. Despite decades of experience working to update software smoothly, it seems that many of us tasked with that responsibility find ourselves nervous about making changes. This is especially true for database changes, where we must not only update the schema and code, but we must preserve the data as well. If only we could drop and recreate the database during every deployment.

    One of the ways in which you can make changes in a live environment is to have a second system already in place and running. With a second system available, you can stop the secondary system from handling user requests, make changes, test them, and if things are working well, you can have users connect to the updated system while you take the one one offline and perform your updates there.

    This is the same process that many people use to patch clustered database servers, though the “rolling upgrades” are usually done for patches from Microsoft. It would be great if we could easily apply this same system for our schema upgrades. Deploy our changes to the passive node, have the application able to connect to this node through some switch, test the changes, and if things are working, switch users over. The problem is that our databases on the passive node aren’t live.

    Really the ability to deploy database changes to a live system and perform checks requires a strong architecture in both the database and application to support this. Your code must be able to handle additions to the database objects without breaking. The use of feature flags, turning functionality on and off with switches, allows certain users to test new features without most clients being aware of the changes.

    It’s a pattern that more and more software companies are using when they want to deploy changes rapidly to systems for limited numbers of users. However it’s not a design pattern that is widely used. I hope we get more sample applications and reference architectures in the future that will help developers and DBAs code more robust and resilient applications, allowing changes to be deployed live without affecting every user.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.5MB) podcast or subscribe to the feed at iTunes and LibSyn. feed

  • The Value of Code

    It seems that many businesses can operate with a large margin for error. Managers can make some poor decisions, processes can be a bit inefficient, and employees can be disengaged, yet companies can still turn a profit. Non-profits, and certainly government organizations, can run without optimizing their work, much to the chagrin of many. However I continue to find companies that look for ways to not only become more efficient, but also to fundamentally alter their business models by better understanding their particular market. They can turn profits (or operate efficiently) far in excess of the averages for their industry with one tool: software.

    There’s a belief in many of these highly optimized companies that data contains lots of value, but in order to understand and harness the information contained within data, an enterprise must be willing to invest in better software. That requires better software developers. In a forward looking enterprise, that means lots of opportunity for those of us that work with data and build software.

    Those of us that create technical solutions need to learn to better interpret data and find ways to help our clients find and understand the patterns revealed by our software. Those of us that primarily manage data, need to better understand how software renders and showcases information compiled in our databases. We truly have the ability to reshape the way organizations run with our technological skills.

    Computing power continues to grow, accessibility to information improves, and our enterprises become more dependent on our systems. Now is the beginning of an era where we will have tremendous influence in helping change the way business works. I’d urge all of you to continue to look for new ways to manipulate data and find ways that showcase the value that software can bring to your organization. Even if your current company doesn’t value your skills, I bet another one will sometime in the future.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.3MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • Encryption in Colorado Springs – Encrypting in the Application?

    Last night was my annual presentation at the Colorado Springs SQL Server User Group. I try to make sure I get down there at least once a year, and it’s been only once a year for the last few years. Far too busy, and I’m sorry for that, but I am glad I get invited to go down.

    I presented The Encryption Primer, and there were a few interesting questions asked. Always good to see people debating and asking questions.

    One interesting one from a developer – If I can perform encryption in the application, why would I do use something like TDE or column level encryption?

    To me, I prefer to do encryption as close to the source as possible. If I can do the encryption in the application front end, I’d do it there. It reduces the chances of having the data accidentally disclosed. I don’t have to worry about having data read across the wire, or in a backup tape, or anywhere else.

    However that takes time and effort. Developers are expensive, and they have to write good, solid, secure code in the application. They also have to write this encryption code in every application that accesses the database (reports, ETL, etc.).

    Something like TDE is much easier to setup and use. Column level encryption, while still coding, is centralized.

    It’s a balance, and one you need to consider carefully and thoroughly. It also helps to debate and discuss the decisions about what you protect, why, and what it costs.

  • Double Up During Trips

    Would you do this? Combine two calls, like an INSERT and then a SELECT, into the same batch sent from a ADO.NET client? It’s a proposal from Visual Studio Magazine to combine code into one batch instead instead of making two query calls (and two round trips).

    It’s an interesting idea, and for those programmers that are older, we probably unconsciously think about this all the time. We still remember when bandwidth was measured in kbps and processing power in MHz, and we often consider those resources to be valuable. We try not to waste them, precisely because they impact performance. Perhaps that’s why we recoil at some of the ORM frameworks and other programming structures that make development easier but are tremendously chatty in how they communicate with our servers.

    I know that programmer salaries are high, and that labor is one of the more expensive parts of building software. However rather than building inefficient applications that will create customer complaints, shouldn’t we be educating our developers more to ensure they write efficient applications? They can still use a framework or template of some sort, but they should do so in an efficient way. Along with training, using code reviews and keeping everyone on a central VCS where all code is visible can help spread knowledge throughout your staff.

    I realize that many managers are loathe to invest in developers’ knowledge when those developers might leave your company for another position, but imagine that a manager elsewhere is investing in his developer. It’s entirely possible those other developers then come to work for you. Ultimately we all benefit if we work to spread and build better software development practices throughout the industry.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.1MB) podcast or subscribe to the feed at iTunes and LibSyn.