Voice of the DBA

Tag: software development

  • Continuous Delivery

    At Red Gate Software, we have a product called Deployment Manager. Its aim is to smooth and ease the process of deploying changes in your software from environment to environment, database and application code. What I like about the product isn’t that it makes the overall software development process easier, though it does. It’s that the team behind the product is using their own tool and technique to . They’re practicing Continuous Delivery (CD), even as they work to help make it easier for you to practice CD.

    That’s pretty neat. Even if you don’t want to release software that often, you have to admit that’s cool. I once worked at a company that released changes every week for well over a year, and I have to say that the development team was very proud of what we accomplished every week when the deployment was complete.

    However we didn’t release every change every week, and as the Deployment Manager team as learned, some things take longer than a week. There are particular challenges to handling the partial release of software, and while you can overcome lots of them, at times you have to delay a release. However, I’d much rather delay my release a week or two than months. The latter has happened in many places I’ve worked when a large application is being built.

    At Red Gate we do think that continuous delivery is an important skill and valuable technique in software development. This idea gathers a lot of focus at Red Gate as we build tooling to help with the challenges of implementing CD. However the idea of CD doesn’t mean that you constantly update your own software for customers. It’s entirely plausible to practice CD internally, releasing changes to test and staging environments many many times before you release a change to production. The idea in CD is that you know how to, and practice, deploying software regularly. That way you’re assured you can actually perform a release when you need to.

    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.

  • 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.