Episode 1: You Can't Buy DevOps

In this inaugural episode of Data Company Podcast, Sanjeev Sharma and Robert Reeves dive into the world of modern software development, focusing on the data layer of DevOps.

Welcome to the first edition of Data Company Podcast. Your host, Sanjeev Sharma is joined by guest, Robert Reeves, CEO of Datical. In this inaugural episode of Data Company Podcast, Sanjeev Sharma and Robert Robert dive into the world of modern software development, focusing on the data layer of DevOps. They also explore the benefits and challenges of open source innovation, what it means to be good stewards of data, and ways to navigate a career in technology. Needless to say, it's a must-listen for data and DevOps professionals.

Sanjeev Sharma: Good morning. Good afternoon. Good evening, ladies and gentlemen. My name is Sanjeev Sharma and your host for the data company podcast. I'm extremely privileged today to introduce our first guest, Robert Reeves, CTO of Datical. Robert and I actually are great friends. We go back a long time. We started running across each other as you were working with clients and on the DevOps speaking circuit. It's a privilege to have him on, not just as somebody who is a true disruptor in the technology space, but also somebody I considered to be a friend. So, welcome Robert.

Robert Reeves: Well thank you. Yes, I am very much a disruptor. It is unfortunate for my management team, but wonderful for my customers.

Sanjeev Sharma: Excellent, excellent. Now you and I, Robert both work for companies which are handling the data aspect of DevOps, but I'm sure there are a lot of people on this podcast who might not have heard of Datical. So to kick it off before we start jumping deep into our conversation, why don't you take a couple of minutes to introduce to our listeners, what is Datical and what role Datical plays in disrupting the DevOps space?

Robert Reeves: Well, sure. My job when I first started out in tech was to get software bits out the door, and my focus has always been to automate myself out of a job. I took an approach that one, I wanted to be able to leave the office on time, and also I wanted to tackle bigger problems. Just always driven to what's that next hill because the tedious and manual processes of getting software out was a real pain. I started to realize that database scheme updates were

We were certainly automating a lot of things around the application. We saw the advent of J2EE application servers, certainly now with containers, we see it with cloud native applications and the move to the cloud, the adoption of DevOps. We're moving really fast when it comes to getting the application, lowercase A out the door, the compiled bits. But we are still updating database schemas manually. And so, that's what Datical does.

We take a tedious manual process and we automate it. We believe that there should not be a trade off between speed and safety. And that's what our focus is. We really want to have our database professionals focus on higher order tasks and not just making sure that developers are changing the schema correctly.

Sanjeev Sharma: Excellent. And I think this whole focus on the data layer of DevOps is the next nut to crack, right? If we look at DevOps as being a three layered cake, right? So to speak, for lack of a better analogy. The first layer most people attack and address is infrastructure and environment provisioning, “how quickly can I get my environments provisioned and configured?” And then the next one becomes, “how quickly can I get that compiled bits of code,” which you just mentioned, compiled, integrated and delivered to the next lower environment all the way out to production. And in most scenarios data gets ignored, right? Both the schema and actually the test and QA data one needs during that process, so I think it's a very critical area which we are seeing more and more relevance as DevOps matures. And most importantly is scales and data becomes the biggest inhibitor in that whole process.

Robert Reeves: Well, it's a spectrum. It really is. Understand this, you can't buy DevOps. You can't go to the DevOps store, “_I would like seven DevOpses, pleas_e.” That's not how it works. DevOps is an algorithm. It is a way of evaluating how we work and identifying areas for improvement. Now, the first area has been the application because it's been very manual. We compile the bits, we move them to the next environment up until the point where we have automated the application deployment. The database, the data component doesn't seem to be an issue. It doesn't seem to be one of those things where we really care about because you know, as humans we have a tendency to kill the alligators that are closest to the boat. There's no reason to go after the alligators that are a mile away.

All right, we need to take care of the ones that are right in front of us. But as companies mature, as they adopt DevOps, as they realize that DevOps is a way of increasing value for their customers and value of the company. They realize that, "Hey, we need you address this data problem," and that is the next mile. I think you saw this year with DevOps' Research Assessment stated DevOps report. This was the first year that Dr. Forsgren had asked about the database, and she found that companies that address the data tier as part of their software delivery have positive outcomes. Wow.

Now, you and I, we knew this anecdotally. We've seen this with certainly all of our customers, but to have somebody that has done rigorous academic work, research to prove this out, I think that's the beginning of a realization from everybody that, "Hey, if we're not handling the data tier, well, we're really not solving the problem.” There needs to be a realization that, "Okay, we solved one problem. Now let's go to the next one.” That's the DevOps algorithm. And so, now, that companies are solving the application problem, lowercase a, it's time to address the data issue to get to the greater Application, the upper case A application.

Did you know that, and I just saw this on Twitter yesterday, that the patent for the toaster came out two years before sliced bread existed?

Sanjeev Sharma: Yep.

Robert Reeves: That's what really clever software companies do. They see the problem coming and they get ready for it. Some companies are going to realize that, "Hey, this is an issue." And those are going to be the ones that have outsize improvement because they went first. It's a warning to the folks that do not have a recognition of that problem. Their competitors have recognized this and do they want to maintain relevancy or did they want to go the way of Sears? It's up to them.

Sanjeev Sharma: Absolutely. That's the whole point of disruption, to be able to know where the proverbial hockey puck is going and be there before it gets there. And that's what makes some companies succeed over the others. And that's true, not just for starters, but that's true for any company, right? You need to know where the direction is going. Let me take a tangential look at a question by asking a question on another path. There's been a lot of conversation around this recently around open source versus other traditional business models. There's been a lot of angst in open source industry as some companies have misused open source path to relevancy to a commercial offering. This is one area where I believe you at Datical have been able to walk a very delicate line very successfully. Can you talk a little bit about what your contribution to open source has been and why you believe that is important?

Robert Reeves: Well, open source, it works. It helps us build better software, and at the end of the day, that's what we want. Now, I think there's been a lot of hand wringing about open source. A good example of that is over at Mongo. So MongoDB is open source and they are the primary, 99.9% of the commits come from Mongo for MongoDB. They certainly have some concerns about cloud providers taking their work and offering Mongo as a service. Certainly, the folks that work on the Linux kernel feel the same way and other companies. Now, we certainly have open source in our product.

Datical is open core and that open core is Liquibase and for us, we accept a lot of community contributions. There are a lot of patches that come, pull requests that come from the community that identify issues that we haven't seen yet or maybe on long tail data platforms that we don't have a lot of exposure to and we certainly accept those. Now, we're licensed Apache 2.0, meaning that anybody could take Liquibase and do what you want with it. The only issue is you can't call it Liquibase, you have to say based on Liquibase because the trademark, but we feel that it is better for the community, the greater software community, the user base to have a choice.

Okay, some people have more time than money and go ahead and use the open source, that's great. You're going to provide contributions back to the community, back to that project through bug reports, pull requests, requests for features. These are good things. And then there's some folks that have more money than time. They don't have the willingness to stand up a center of excellence or internal support, and that's where we come in. It takes a village, and I think there's a lot of value in those open source users. But there's also a positive correlation between the use of open source and positive software delivery outcomes.

That again comes from last year's State of DevOps Report, and it says that companies that adopt open source and use that are going to be better. The reason why is because open source is just cooler. It gets better features out to the market faster, and you can benefit from those features. Now, for larger organizations that might have SOX compliance concerns, those sorts of things, they want the ability to have a support, they want more features. Great, then the paid version is for you, that has those new fancy features. But other folks just use the open source, and we will all work together and get better. Everybody's providing value with open source whether you're paying or not because at some point, you're either paying in money or you're paying in time. So either way, there are contributions that you're making, open source won and we're a huge fan of it.

Sanjeev Sharma: Absolutely. I love your explanation between time and money as some of the decision making points between open source and paid versions. There is a place in the world for both, and I think that's where some of this angst and conversations which we see happening tend to not see the bigger picture. Now going back to our conversation regarding large enterprises, I want to talk about the statement you made earlier, which is what's the next hill, right? So, let's talk a little bit about the current hill.

There is a lot of noise and hype around what we can, what clients, customers, large enterprises can do with the data they have because there are massive amounts of data, right? They've been building data lakes, data warehouses, all these other capabilities to store and manage their data and try to make it more freely accessible to be able to gain insights from it to be able to predict. But it is still happening in fits, fits and jerks. What are you seeing there? When you go and talk to clients, what do you believe is the biggest inhibitor to them being able to maximize what they can or cannot do with their data?

Robert Reeves: Well, it is very much a cultural issue. For a very long time, we had our database professionals, our DBAs that would say, "Stay away. We've got this," because there was a realization that the database went down, everything went down. But now, there's a realization from these companies that the most valuable assets, second to the people, the most valuable non-person asset that a company has is the data. You're right. New business models from being able to glean insights into customer behavior and even offering that as a value add is amazing. But we have to free this data from behind lock and key.

This idea that we're going to have bouncers like, "You can't get into the nightclub." That doesn't work. We cannot have these data clerics preventing us from accessing data. Other parts of the company need it. However, it needs to be done safely. It needs to be done in a way that we can protect PII, personally identifiable information. We need to be able to enforce compliance that we're not sharing this data with the wrong people, we're sharing it only with the right people. And there has been a bit of a Wild West approach to how are we supporting our analytics folks for ML. And in the past, it's been like, "Oh, do a database dump and just give it to them." Well, that's not cutting it. We need to be smarter about it, but we have one part of the company that is saying, "No, no, no, stay away because bad things can happen." So, it's an avoidance of pain. And then we have another part of the company which is like, "Well, no, but I want to do all these great, wonderful things and it's a drive to a better place."

So one is avoiding failure, and one is seeking out positive outcomes. There needs to be a balance between the two. There needs to be a carrot and a stick. There needs to be a recognition that other parts of the organization need access to this data. They should be able to make changes to that data to support their application releases and needs to be done in a way that we can satisfy both parties, both sides. And that's tough because a lot of the times, you know, when we go and talk to customers, there are some of the folks in the organization that say, "Nope, we've always done it this way, and we're never changing." And we certainly saw this with the advent of the automobile. We certainly saw this with the advent of word processing and those sorts of things. There are going to be people in the organization that just will not change because change is scary. It takes a lot of effort. It's tough. And so, we need to be able to help those people understand that it is in their best interests because it makes them more valuable to the organization. It makes the organization more valuable, but it's very much a cultural issue to balance those two competing interests.

Sanjeev Sharma: Absolutely. I think that whole concept is not changing, right. We've had some major scandals around data and data sharing. And quite frankly, in my opinion, the most successful advertising campaign I've seen or the most impactful, I should say, has been the one by Apple, where they talk about not the product but how they treat your data, right, saying we keep it, we encrypt it, it's end to end and we don't share it. And the Apple logo pops up with a lock icon on top of it at the end because essentially what they are saying, what they’ve recognized is that in today's world, becoming a custodian of your client's data is actually a business differentiator. It is something which can show that I am different from your competitor who might not treat your data the same way as a custodian of it the way I do. And that's brilliant in my opinion.

Robert Reeves: There is an opportunity for companies to be good stewards of data and use that as a competitive advantage against in the marketplace and it's working. Just look at their stock price.

Sanjeev Sharma: Absolutely. Absolutely. So we're coming up towards the end of our conversation here. So let's talk about what's next. So somebody young and eager, like you and I are, is looking for direction to say, “There are so many areas in technology today. There's disruption at every corner. I can turn left, I can turn right, I can go up, I can go down anywhere along this whole IT stack,” so to speak. Would you have a couple of words of wisdom?

Robert Reeves: Oh yes. More than one. I hear this a lot, “What should I be focused on? What language should I learn? What platform?” Yes, important, but I would say two things that that someone starting their career in technology should focus on. The first is to learn how to learn. My first language that I learned was Pearl, but I don't use Pearl today. I don't. We use other things, but I learned how to learn about a language. And so, it's important because as in technology, you're going to constantly be learning, so understanding the process by which you can quickly understand new concepts and master them, that's important. That's a skill.

But I think the most important thing is empathy. So, I'm a cofounder, I'm the CTO, but my job is not technical. My job is solving problems and understanding my coworkers, my fellow Daticals, the things that they're trying to accomplish to certainly understand my partners’ goals and my customers. To put myself in their position and really understand, “Well, what's in it for them? How can I help them meet their goals? How can I put myself in their position and deliver a more impactful experience, a more valuable product? How can I make their life better?” Because my personal view is that I don't sell software. What I sell is piano recitals, date nights, time with your significant other, all the things you want to do, but you are stuck dealing with the database. By understanding that there is another person on the end of that keyboard that comes across in the work that you do. It's something that is very lacking in our industry in technology. I think that if more people adopted that we would have better tech, and new people entering this industry, by having that skill set that sets them way apart from other people, they will be more successful to their customers and also to their employers.

Sanjeev Sharma: Excellent. Robert, could not have ended this podcast on a better high note. So thank you so much. It has been a privilege to have you on, Robert. Thank you so much for your time.

Robert Reeves: Oh, thank you. I enjoyed it. I really appreciate it, man.

Sanjeev Sharma: Excellent. This is Sanjeev Sharma signing off for the data company podcast.