Voice of the DBA

Tag: software development

  • Downtime

    Most of us that work with technology hate downtime. We don’t want a system that we’re using to go down. We don’t want any software that we depend on to fail when we need it. Most of all, we don’t want our phones ringing because some system we’re responsible for has gone down. We do everything we can to keep our applications online. We avoid patches. We try to test as much as possible before deploying changes. We also may apply generous amounts of hope and prayer.

    However that’s not how all companies run their internal systems. Netflix has taken the opposite approach, actually creating downtime for some of their systems using what they call a “chaos monkey,” and they think it could help you. To be fair, Netflix doesn’t take their entire application offline, but they do cause failures in the hardware and software, specifically to see if their redundant and scaled-out architectures can limit the impact on users.

    It’s an interesting idea, though one that I’ve not seen many companies be willing to implement. Netflix thinks you could benefit from it, but they also run a series of services that are scaled our across many machines. Many companies I’ve worked with have services on one machine handling an application, and they accept the risk that a system might fail and users will experience problems. Given the quality of modern hardware, that might be a good bet to place these days.

    However more and more of us are running redundant systems for some applications. If you think the Chaos Monkey could help you, let us know.

    Steve Jones

    The Voice of the DBA Podcast

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

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • Caching

    How many of you have worked with a cache of data for your application? I would bet that the vast majority of you have never built a caching system. There’s not shame in this, as most of us don’t work with very high levels of concurrency in our applications. Even if we hit them, it’s rare enough that we wouldn’t bother with the extra coding when we designed the application because, well, it’s extra coding. It takes time, requires more testing, and our project managers might not be willing to invest in this “just in case” we hit some concurrency issue. Actually, most of us probably would view this as a “good problem”, one that would then be worth re-architecting the application.

    The problem is that often no one wants to re-architect a working application and potentially delay other, more exciting enhancements. Many highly visible web sites have gone through this, experienced growing pains, and only those that have a tremendous amount of resources to devote to the problem usually solve it.

    However it doesn’t have to be hard. Brent Ozar published a piece on caching results that uses a creative solution, scaling out to a new database and table that exists only to return results. In some sense, this is a great application of the KISS principle that doesn’t use replication or any other complex technology. It even employs a technique those NoSQL platforms often hawk: eventual consistency.

    That’s the idea behind caching. The data isn’t necessarily the most up to date, and it’s not dependent on being synced with your other data. Ideally you’d have some system that updates your cache when the base data changes, but even then there’s an “eventual consistency” delay at work. It might be tens, or hundreds, of ms, which is often what we find with distributed systems, but that’s usually fine. It’s very rare that a problem requires absolute synchronization of all data in the application.

    I’d urge you to consider thinking about  building some scaffolding into your application that can potentially be built out later to incorporate caching, or some other scaling technology, in the event that you find your system is more popular than anyone might expect. It shouldn’t be too hard, especially if you think about it early on.

    Steve Jones

    The Voice of the DBA Podcast

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

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • VMs for Development

    Here’s the scenario: you have gotten a few consulting jobs and have a couple clients. This could be your full time employment, or a side job that you perform away from another employer. You want to watch your budget, ensure you can work efficiently, and handle whatever requirements your clients may send your way. This week’s question is:

    How do you set up your virtual environment at home?

    I think the idea of using Virtual Machines (VM) is a given these days, but do you have one VM with all your tools in it? Do you use separate VMs for each client? What about licensing? Those can be complex questions for many people, especially if your employer does not provide you with multiple license keys.

    I hope that you are using VMs as having multiple computers isn’t practical these days, especially as the cost of power rises. A relatively small, inexpensive desktop computer can run 5, or even 10, VMs to simulate a variety of environments. I’ve seen some creative uses of hypervisors and other software to simulate clusters, SANs, and even multiple domains on one host.

    Let us know this week if you have some good tricks that can help someone get started with virtual machines, building a lab, choosing hardware, or easily configuring networking for their own learning efforts. Tell us what software you use, and if you don’t mind sharing cost data, I’m sure others would appreciate the information.

    Steve Jones

    The Voice of the DBA Podcast

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

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • What is Continuous Integration for Databases?

    I have a talk that I give on Automated Build and Test for databases. This was put together by one of the engineers at Red Gate Software, and I’ve presented it at a number of events. I enjoy it, and it’s one of those presentations that really gets people thinking. I enjoy getting people to think about software, and there are always good questions that come out of the session.

    The talk is essentially about how to set up continuous integration for databases. Continuous Integration is an extension of the daily build, which companies have been using for years to try and ensure some discipline in their software development practices. They want to limit the amount of code that can potentially break software.  The whole idea is to test changes developers commit to version control as quickly as possible and give feedback developers immediately so developers can fix issues while the issue is fresh in their minds.

    For databases, this can be a challenge. We have this stuff called data that has to be maintained between, during, and after builds. We can’t drop our structures and reload them as a developer does with an executable or DLL. As we work in a CI environment, we need to handle new objects, as well as alterations to existing structures. That means our scripts and code need to handle creation as well as upgrade scripts.

    This means that a CI process for databases must not only check out the DDL code from a Version Control System (VCS), but it must also handle the CREATE or ALTER code based on the state of the database. You can always build a database from scratch in your CI process, or you can restore a known version (usually the last version) and apply upgrade scripts. The way this happens depends on how you version your DDL code in a VCS and how your build process is structured.

    At Red Gate, we’ve built a number of scripts to help with this process for various CI servers. We have articles that discuss CI for Team City, Jenkins, Bamboo, and probably more by the time this piece appears. We’ve learned a lot about CI over the last few years and we are trying to share both our knowledge and code with you, as well as incorporate those ideas into our products.

    Whether you use our products or not, we do believe that you will build better software if you implement CI. We just know that we can make the process a lot smoother with our tools for developers and DBAs.

    Steve Jones

    The Voice of the DBA Podcast

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

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.