In this DevOps Chat, our guest is Steve Jones of Redgate and SQL Server Central. Steve talks to us about DevOps and databases, as well as the latest from Redgate SQL Clone. More and more we are hearing from DevOps teams that the database is becoming a constraint. We must take DevOps to the database!
As usual, the streaming audio is directly below, followed by the transcript of our chat. There also is a link to a downloadable white paper from Redgate for your reading enjoyment.
Streaming Audio
Chat Transcript
Alan Shimel: Hey, everyone! Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. This episode of DevOps Chat features Steve Jones of Redgate. Steve, welcome to DevOps Chat.
Jones: Thank you, Alan. It’s good to be here.
Shimel: Thank you. So, Steve, you are in—well, you have sort of a dual role in that you’re an evangelist with Redgate, but you’re also the, I don’t know if you wanna call it the curator, the editor, the manager—
Jones: The founder. [Laughter]
Shimel: – founder of—
Jones: SQL Server Central.
Shimel: – SQL Server Central, exactly.
Jones: Yes.
Shimel: Before we jump into SQL Server Central, though, you know, I’m sure there are people out in our audience who may not be familiar with Redgate, so let’s give them, if you can, just a quick kind of elevator story pitch on who Redgate is and where they fit in in the DevOps world.
Jones: Okay. Well, Redgate has been around about 17 years, and really, we, our tagline kind of is, “We build ingeniously simple tools that help you build software.” So our goal is to help you build database software or .NET software in a more efficient manner. So that’s kinda the quick pitch on what Redgate does.
Shimel: Got it. And how—give us a little more background. How long has Redgate been around?
Jones: So, Redgate started right around 2001, and interestingly enough, SQL Server Central started at the same time. Myself and a couple partners put together this publishing area where we wanted to help people get better at their jobs and grow, and Redgate was actually our first customer and we sold advertising to them back in 2001.
Shimel: Oh, cool.
Jones: So I’ve known them almost since the beginning. And over the years, they’ve—Redgate has grown up. We’re now around 300 people or so. We have our main office in Cambridge in the UK, and then we have a sales office in Pasadena (California) as well, and we have a few people, then, like myself scattered around the world that do various jobs.
And so, across the years, Redgate has tried to help different groups build software better. You know, we sell to a lot of Fortune 100, Fortune 1000 companies all over the world, and over the last probably five or six years, we’ve tried to tackle the DevOps problem in the database world. So we’ve spent a lot of brain power, a lot of effort to build products to try to help people incorporate the database into a DevOps flow.
Shimel: Mm-hmm. So, you know, that kind of pre-empts my next question, Steve, which was, you know, obviously, when Redgate first started up here, there wasn’t people running around talking about DevOps, though people were still trying to do more faster and automate and all of these things.
But it’s been about four or five years, you think, where you guys have kinda consciously said, “Oh, we’re gonna, you know, try to hit the DevOps mindset,” if you will, or the DevOps [Cross talk]?
Jones: We are, yeah. You know, our founder—so, an interesting story. At the beginning, when he was looking for some additional money to get the company going, we had built our first product called SQL Compare, which compares the scheme of two different databases and gives you the differences and generates you a script so that you can do a deployment.
And, in trying to explain this to the laymen, to the managers, to the people that would be bankers or sign checks, it’s kind of a cumbersome process, right? The idea of a schema and comparing that is a fairly technical area; I think a lot of people don’t intuitively understand that. But he brought in two phone books to the customers and said, “Find me the differences between these two,” you know? And they’re like, “I don’t know how we do that,” right? [Laughter] “Like, we go page by page and we lick this out?” And he said, “This is what our product does—it finds the differences between two things and lets you know.”
And that’s where we’ve gone over the last 17 years. We’ve matured that product and then, five or six years ago, we decided to find ways to make it even better, and so we spent time looking at how people perform the deployments, some of the shortcomings sometimes of having somebody run a particular product to determine at this point in time what are the differences. And so we’ve built automation, we’ve built some of the other security ideas, some of the things you do in DevOps to produce a flow into various products so that we can ease the pain of deploying database changes.
Shimel: Makes sense, makes sense. So, Steve, you know, we’ve seen Redgate and a few others really kinda not attack, but really work hard to bring the database and the DBA into the DevOps environment, into the DevOps family, if you will, right? You know, we talk a lot about culture and so forth in DevOps and we try to bring—break down silos, bringing teams together, bringing dev together with ops, bringing QA into it, bringing security into it, and bringing the DBA and the database into it.
And, you know, I personally have seen this become a bigger and bigger piece of the DevOps puzzle. How—now, Redgate had a lot of success before that, right, and—
Jones: Yes, yes.
Shimel: – Yep, so my—I guess my question is, where are you seeing this uptake or, you know, DevOps—so your business was, it sounds like it was good before this. Is it really kinda hitting where—you know, or has it found that sweet spot with DevOps?
Jones: You know, it’s getting better. I gotta say, five years ago, when I started to try to talk about doing deployment—so, we started a product years ago to do deployments to try to help people do web deployments, and we wanted to include a database in that. And we found it was a much more difficult problem than we expected, and you know, one of the things that we found as we worked on this is that, you know, DBAs, I think—more than ops, more than J, more than security, more than any other group, we fundamentally have a challenge that they don’t have in that we have to maintain state between deployments.
In the ops world, right, they say that we wanna treat our servers like cattle—if one dies, we just pop another one up in its place and we go. Certainly we do that with containers, we do that with software, we can—you know, the QA people are used to doing that. But, you know, in the database world, we can’t do that, you know? If I could drop tables and recreate them every time I deployed software, my life would be so easy. [Laughter]
Shimel: [Laughter] [Cross talk]
Jones: Yeah. [Laughter] But you know, I think over the last decade, we’ve started to see in many industries, many businesses that the data is really, hugely important. You know, and as we see people moving to machine learning and AI and all these different things, the database fundamentally becomes even more important, because that data is required, you know? And whether you’re relational NoSQL or something else, you have to maintain that data as you make changes.
And so we have this fundamental issue that we have to find ways that we can make changes without disturbing the state of our system too much. And that’s a difficult process, right? If I deploy the wrong .dll or the wrong XT or the wrong .jar file, I drop it and I throw the last one I have up there and we’re good. If I deploy the wrong version of a database, if I make a fundamental change to a table and it’s the wrong change, maybe store, which could be hours, minutes out, you know, who knows—you’d have to substantially try to reverse a change, which means, if any data has been altered, I have to try to undo that, I’m gonna have to capture that statement and then go through some sort of ETL transform to put that data back.
It’s extremely risky and cumbersome, and you know, as a former DBA as part of my career, you’re risk averse. You don’t want to be in that place where you take the database down for substantial periods of time. So, you know, Redgate really, as we were trying to find new products to build and sell and try to enhance what we had, we realized this was a difficult process.
Shimel: Mm-hmm.
Jones: And so, five years ago, I talked to people, they thought it was done, they didn’t think it could be solved, and I’ve had a number of good friends that laughed at me three years ago, four years ago, and you know, in the last year, year and a half, they’ve been coming back to me and saying, “Alright, how do we actually get this database into a DevOps process and deployed?”
Shimel: Yeah, fair enough. So, Steve—well, first of all, what’s the latest news ? Anything with Redgate?
Jones: Absolutely. So today, actually—you know, we’re recording this from February 27th—Redgate has released SQL Clone, which is a product similar to some other ones in the marketplace, but it’s designed to provision copies of databases in seconds. So, what we essentially do is, we build an image file of your database, and then we can make real live copies of that in literally seconds.
So if you’ve got a 1 terabyte database, once I’ve provisioned that image, I can make 1 terabyte copies of a SQL Server database and have it appear on your instants in about 7 to 10 seconds. And every copy is independent, they all look the same, they all look like the original database. You can write to them, you can change things, and you can drop them and recreate them in seconds.
So, in the Dev/Test world, it’s a fantastic idea that I can provision a developer database in seconds, they can be on their own branch, they can make any changes they want structurally to the data to alter things. And if they decide they’ve made a mistake, as we often do in development where we experiment and we try something and if we want to undo it, they can drop that database, build another 1 terabyte database in seconds and continue with their development.
Shimel: Got it, got it. Steve, I wanted to spend a little time talking about your role as evangelist with Redgate.
Jones: Okay.
Shimel: So, you know, evangelist is not—what’s the word I’m looking for? It’s not an unheard position within the DevOps world, but can you give our audience a little bit of a flavor of what your role entails, especially in dealing with the DevOps marketplace?
Jones: Sure, sure. So, I—as an evangelist, what I end up doing is a lot of writing and speaking about Redgate and Redgate products, and certainly the DevOps world, but also just in general about good practices of software development and database administration.
I’ve been working with SQL Server for Microsoft for 25 years, so I’ve been—basically since Microsoft has had the product, I’ve worked with it as part of my career, and you know, the mission of SQL Server Central is really to help you get better at your job every day. And so I do a lot of writing and speaking to that effect, and you know, Redgate is essentially all over the world, so I get the chance to go to different conferences, different events, and provide information about general good database practices or Redgate products in particular.
Shimel: Excellent. Steve, we’re—as I mentioned here before, we got on, you know, live, the time here goes quickly. But I wanted to know if you can give our audience—well, first of all, where can they go to your SQL World blog? How can they find that?
Jones: Yeah, so SQLServerCentral.com—all one word, SQLServerCentral—that’s the site where I’m kinda the editor, I was the founder, and I run that right now. So we publish daily information to help you there.
I maintain my own blog at VoiceoftheDBA.com—so VoiceoftheDBA.com—and that’s where I write about a variety of topics related to data and databases and software in general. So, do that, and then on Voice of the DBA, I keep a speaking schedule, so I’m traveling all over. I head to Colorado Springs in about three weeks, and then SQLBits in England, and various places after that, so. [Laughter]
Shimel: Got it. What about—and what about Redgate? Any plans for conferences, shows, DevOps events where maybe our audience—you know, our audience is pretty worldwide, Steve, if I didn’t tell you before.
Jones: Okay.
Shimel: Places where they might see Redgate?
Jones: So, we’ll be—we go to a variety of DevOps conferences in the UK and the U.S. and elsewhere, so we will be at SQLBits in Telford in April, and then we’ll be at the Data Platforms Summit in Bangalore, and I’ll be there as well. And I don’t know all of our marketing presence where we’re gonna be beyond that, but you know, we have a good, active Twitter account at Redgate, and we post on there often where we’ll be with different events, so it’s a good place to find us.
Shimel: Excellent.
Jones: And of course, Redgate.com. [Laughter]
Shimel: Yeah, well, that makes sense. So, Steve, we’re almost at the end of our time here. I wanted to ask you one last question, it’s one I ask a lot of our guest, and it’s this—if you had to recommend one must-have book, one must-read book for our audience out there, maybe regarding DevOps and databases or something related, what would it be?
Jones: So, yeah, we talked about this briefly. I know probably everybody has thought about, talked about “The Phoenix Project,” which is great. If you haven’t read “The Goal,” which is kinda the precursor to “The Phoenix Project,” that’s good.
But the one I might recommend is “Database Refactorings” by Pramod Sadalage, and it’s interesting because there’s a domain of problems in the database world that are complex and they’re problematic. And so they are the types of problems where you can’t easily make a change and undo it, you know? If I had a column, then I could drop it very quickly—but there are certain problems that are difficult.
And in the “Database Refactoring” book, they’ve done a good job of laying out these problems and how you solve them across time, because most of these require you to make changes across maybe days, weeks, or months to actually complete them—so that might be the one I’d recommend.
Shimel: “Database Refactoring”—great. By the way, I loved “The Goal” as well. I read “The Goal” many, many years ago—way before “Phoenix Project.”
Jones: Yeah. Right—I did, too. That was the first one I read.
Shimel: Yeah, it was good stuff—but “Database Refactoring” sounds good.
Steve Jones, it was nice having you here. This is obviously your first time appearing on DevOps Chat, but we’d like to have you back in the future maybe again, and we can talk some more. And you know, I really do like to delve deeper into databases and DBAs and, you know, adopting and being adopted into the DevOps kinda methodology and work routine in many organizations. So maybe next time we could dive a little deeper.
But for now, I think we’re about out of time.
Jones: Okay. Thank you very much for having me, Alan.
Shimel: Steve, thank you for appearing. Steve Jones, evangelist for Redgate, and the founder of SQL Central—is that, did I say that right?
Jones: SQL Server Central.
Shimel: Excuse me—SQL Server Central. Steve, I apologize.
Jones: Yeah. No worries.
Shimel: Steve, until next time, then, we’ll have you on, and continued success with both SQL Server Central and Redgate.
Jones: Thank you very much. Great being here.
Shimel: Thank you. Hey, this is Alan Shimel for DevOps Chat, and we’ll see you on the next DevOps Chat.
— Alan Shimel
