Ep. #25, Data Stack Orchestration with Jonathan Ellis of DataStax

Grant Miller: All right, Jonathan. Thank you so much for joining us.

Jonathan Ellis: Thanks for having me on the show, Grant.

Grant: Great. So, I'd love to just jump right into it and hear a bit about your background and how you got into enterprise software.

Jonathan: It's actually been, I think, a bit of an atypical journey because the first half of my career was very startup oriented.

In the 10 years before I started DataStax, I was at nine different companies.

Grant: That's quite a lot.

Jonathan: Yeah, and it's even more, when my second job -- My tenure there was almost three years.

You pull that out and the average you get, it's pretty low. Some of those were because it just wasn't a good fit, and I said "OK, I'll find something else."

But more of them were, when you're doing super early stage startups, they run out of money.

My first one was a .com bust, or another one got acquired and I was redundant. That stuff tends to happen.

Grant: The first one was during the early 2000s, late '90s?

Jonathan: Yeah. I graduated from college in December of '99.

Grant: So, tell us about that. Did you join a startup right away?

Jonathan: I did, and it is funny. I have a friend named Gary Babich, and he recruited me to this job out of college and to my next job after that, and I returned the favor.

I recruited him to his next two jobs. It's good knowing the industry, there's a lot of change but it's good to have those friends that you work with for multiple years, even if it's across different companies.

But that first one was a little bit ahead of its time, it was trying to build content management systems on top of a dynamic HTML, which in early 2000 didn't really exist yet.

We didn't have XML HTTP requests yet, so the technology wasn't quite ready and the timing was definitely bad on the industry state.

Grant: Were any of these, would you consider them enterprise software companies? Is that something you would have classified them at the time?

Jonathan: Not really. They weren't really, the closest would have been the company I worked for that built newspaper publishing software.

That had some things in common with what I think of in terms of enterprise software today, but it was more of an ISB, I think.

Grant: OK. So, you were delivering software to these newspaper organizations.

That's funny, because it's like as the internet is disrupting everything to do with media news, you're building software for those teams.

Jonathan: Yeah. That was that was actually my second job, so that was 2001 to 2003. The writing was already on the wall.

A lot of people were in denial about it, but the writing is definitely on the wall in terms of "This is not a growth industry."

Grant: The rising tide is quite important, right?

Jonathan: Yeah.

Grant: Then you went to BYU, right?

Jonathan: I did, yes.

Grant: So, were you staying in Utah for these other jobs?

Jonathan: Yes. I was in Utah for the next 10 years after graduation.

I'll skip over some jobs that didn't go anywhere, but the first startup that I joined that had some success was a backup software provider called Mozy.

This gets into why I'm a big fan -- And I know I'm on the EnterpriseReady podcast, but I'm a big fan as a software developer of joining startups.

What that does is the startup, if it's like most startups, it literally can't afford to hire the talent that would let it say "I'm 100% certain that Jonathan can build my storage back in, because he's already done it three times at other companies."

Those people are really expensive, and so Mosi was willing to take a chance and say "Jonathan, on paper you're completely unqualified to do this. But we've interviewed you and we think you're smart, and we're going to take a chance."

It's like bi-directional risk, they're taking a chance on me and I'm taking a chance on them.

There's some powerful opportunities to accelerate your learning that you don't have otherwise. That actually happened with Mosi, they said, "We want you to build this storage backend."

I was basically building something similar in spirit to Amazon S3, except it is specialized for backups, meaning we don't care what the latency is to pull back a file. What we care mostly about is throughput on ingest, and then there's a footnote there that says "We also care about throughput on restore, but we definitely don't care about latency on reads."

That's scaled to multiple petabytes, it worked as advertised, and what happened on the way to building that--

What we built was a content addressable storage system based on ratio coding. Even in 2006, that was pretty understood how you build this system.

The problem we run into was we wanted to do single instant storage, meaning if you and I both upload the same MP3 or the same JPEG, the system only stores one copy and then it says "Jonathan and Grant all have copies of this file."

That takes it from just a simple content addressable store, to now I need to have these relationships and track ownership of these files I'm storing.

That was a really hard problem, because you couldn't just store your millions of users with billions of files and have relationships between them on any database on the market at the time.

We hacked it together using our own storage system, but it wasn't a great solution.

This set off a realization in my head that this class of problem was going to hit basically everyone building what we called at the time "Web 2.0" applications that the database technology was just not up to the task being demanded of them.

Grant: Interesting. OK, so that was where you first had the insight that state of the art databases weren't really going to scale and be as--

People were going to reach a lot of challenges with those as they emerged into Web 2.0 and web scale technologies.

Jonathan: Exactly. The primary challenge, I think, was around scale.

But then there's also the secondary one around availability, and "How do I build a database that never goes down, even when there's hardware failures and even when there's a power failure in the rack?" Or that kind of thing.

Grant: OK. So you had that insight while you were at Mozy , and just real quick, was Mozy targeted at consumer pro-sumer?

Or was it targeted at business and enterprise to buy licenses for their employees?

Jonathan: No, I think like any good startup the strategy changes over time, and we started targeting consumers.

There is actually a lot of interest from, "I like this idea. I want offsite backups for my company. Now, how do I as an IT administrator, how do I control these accounts and quotas and so forth?"

We started moving in that direction after a year or two.

Grant: OK, but you left there. Did the company keep going? Did you just decide to take off and do something different?

Jonathan: Yes. My timing was actually spectacularly poor, and I left within 30 days of EMC making an offer to acquire them.

So, I left before that. But basically what happened was Mozy was getting to 70ish employees, and I was reporting to a director who reported to a vice president who reported to the CEO, instead of reporting directly to the CEO.

I was like, "There is too much red tape. At a 70 person company, this is huge." So I moved on to something smaller.

Grant: OK, so that was the reason. It was just not feeling a startup anymore.

Jonathan: Yeah, I think that's the short version. So now, skipping ahead 15 years, I started DataStax which is 500 employees. That's a little bit of irony for you.

Grant: Yeah, I get it though. If you're going to be in a bigger company, you want to be towards the top to figure out how to have a real impact. So, I get that desire.

How did you end up at Rackspace? That feels like where you really got deep on--

Obviously Mozy gave you some insight into building and understanding distributed large scale storage, but Rackspace feels like it's really where the seeds of DataStax were planted.

How did you end up there?

Jonathan: Right. I gave a talk at PyCon, in probably 2007, where I explained the work I'd done at Mozy.

Because the storage back end I wrote was actually in Python, which made sense in the sense that Python is pretty slow and inefficient, but when you're talking about storing files you care a lot more about disk.io than you care about CPU efficiency.

So, it sort of made sense. It turns out there's actually a bunch of reasons why Python wasn't ready for that system software, which turned into another talk I gave called What Python Can Learn From Java.

I've got pretty strong opinions about this, but the people at Rackspace saw the talk that I gave about the storage system I built, and they said "That looks really interesting, because we're building out cloud services and we want to compete with Amazon."

Again, Rackspace's strategy has changed since then, but at the time they wanted to compete head to head with Amazon and have a file storage system and DNS as a service, and all these things.

So they said , "You should come and work with us."

And I said "I'd be interested, but what I'm more interested in than re-creating this storage service is the next step of scalable databases. I think that's the big unsolved problem."

And they said, "You're right. We definitely need that at Rackspace for our customers, for our own internal services. We'll hire you to work on that."

That was in the fall of 2008, and that summer Facebook had open sourced Cassandra. It wasn't Apache Cassandra yet, it was Cassandra from Facebook.

I got to evaluate, when I got to Rackspace, I got to evaluate Cassandra. There were some systems you don't hear about anymore, but were recently open sourced at the time.

There was Voldemort from LinkedIn, there was Dynamite from Powerset, there was MongoDB, there was Hbase.

I got to evaluate these systems and say, " I think that, A, this space is super early. All of these technologies are super young, so rather than optimize for who's got the most complete solution right now, that's going to change in the next 12 months. So what I'm going to optimize for is who's got the best foundation, and I really felt that Cassandra's combination of a fully peer to peer scale out solution, combined with a big table style data model that gives you rows and columns, was the best foundation to start with." So, that's what I put my energy into.

Grant: Interesting, OK. You took a broad evaluation of all the various technologies that were emerging to solve this distributed database problem.

Were they calling it " Big Data" at that point, or was that a term?

Jonathan: My memory is fuzzy, but I think they were.

Grant: OK. So, this Big Data problem, and you just fell in love with Cassandra? Or, what happened there?

Jonathan: It was really the technical factors that caused my man crush, I guess. I would add a third factor, which is that it was remarkably simple for what it did.

I think at the time it was under 50,000 lines of code, compared to, for instance, Hbase was clocking in at around 250,000.

So I'm looking at that and saying, "I f these two are doing roughly the same thing and one of them is five times as complex, I think I can move the needle a lot faster on the simpler one."

Grant: So you took some type of involvement with getting Cassandra involved with Apache, or what happened?

How did that come about? How did it become Apache Cassandra?

Jonathan: Yeah. There was me, and there was one other guy, I think from--

I don't remember what company he was at the time, but he eventually joined Cloudera.

His name's Todd Lipscomb, he's really talented engineer.

We were both maintaining our own forks of Facebook's Cassandra , and the engineers at Facebook were taking an attitude of "If this is useful for you, then great.

But we're not looking to build a community, we're looking to solve problems we have at Facebook.

If our work turns out to be useful to other people, then great. But we're optimizing for our own problems."

Their nod towards this nascent Cassandra community was to contribute the code to Apache, and I became the first non-Apache committer to Cassandra-- Or, non-Facebook committer to Apache Cassandra.

Grant: OK, cool. Did they continue to use the upstream Apache version? Or did they maintain their own fork?

Jonathan: This is actually where I get to tell my story about the time I broke Facebook.

Not only were they running Apache Cassandra, but for the first few weeks they were running from Trunk and we were using subversions.

They were pulling from Trunk and building that and just pushing it into production, and so after I became a committer, I'm like "Cool. I'm going to commit stuff."

And I started committing some of the patches that I'd put together, and one of them broke something catastrophically.

Avinash Lakshman was instant messaging me, I think it was a late Friday night, like "What did you do? Everything is broken."

Grant: That's amazing. You were moving fast , so it's acceptable.

Jonathan: We had a discussion about branches and stable branches, and that kind of thing.

Grant: Avinash Lakshman was one of the creators of Cassandra at Facebook, correct?

Jonathan: That's right, yeah.

Grant: Got it. OK, so you were at Rackspace, really excited about Cassandra. I'm guessing that--Did Rackspace have Cassandra as a service offering, or what was going on there?

Jonathan: Yes. The first thing we were targeting at Rackspace was similar to what we had done at Mozy, where they had this file storage system and they wanted to track which users owned which files.

Before we got Cassandra to a stable enough point where that rolled out , they actually started over with a completely different architecture for their cloud file storage, and I'd left to start DataStax.

It ended up not ever going into production at Rackspace at the time, but several years later Rackspace became a DataStax customer. But that was a different era at that point.

Grant: All right, cool. Tell us more about how you were on this Apache Software Foundation, you helped get that going.

You were the first committer into Cassandra outside of Facebook, and what makes you decide "There's a big opportunity here? I should start a business around this?"

Jonathan: I'm going to caveat this with "My crystal ball wasn't perfect," so if I did it over again I would have started DataStax much faster than I actually did.

What I actually did was, it was about a year and a half into working on Cassandra before I left to start DataStax.

That was time that set DataStax back versus where we could have been, just because when I went and got my Series A funding I staffed up to eight engineers working on Cassandra relatively quickly.

The most Rackspace had ever had on Cassandra was four.

So right away you're saying, "I could have gotten twice as much done for that time that I was at Rackspace versus at DataStax." I didn't do it quickly enough, in hindsight. But what actually pushed me over into starting the company, even though it was outside my comfort zone, was a sense of pride in what I was building.

We had a telecom company that was active on the Cassandra mailing list in late 2009, and I was really excited about this because this was Cassandra 0.5 or maybe 0.6.

It's super early still, but this is a really great use case that the company has. Then all of a sudden I didn't hear anything more from them for several weeks, and I reached out and asked what happened.

They said, "My boss said we needed to go use Riak from Basho, because we can get a commercial support contract, even though Cassandra is better technology for what we're doing."

I was like, " That really sucks. Somebody needs to start a company around Cassandra so that we can solve that bug," if you will.

Grant: That's funny. Like, "Someone should do that."

Jonathan: Right?

Grant: So you'd been an early engineer at a lot of different companies.

What gave you the confidence or desire to be like, "I'm going to go start that company?"

Jonathan: I think a couple of things did.

One is that the man who became our lead investor for our Series A, John Vrionis, had actually talked to me about six months earlier.

This was right around the time where you had Big Data, but then you also had NoSQL. One of my co-workers at Rackspace, Erik Evans, created the " NoSQL" term, something which he has mixed feelings about to this day.

So that was the touchpoint, I think, for some broader awareness that "This scalable database thing, this is a problem that needs to be solved."

John was one of the earliest investors to start looking at that, and somehow he tracked down my contact information and called me up.

We had a conversation about it and I believe he asked me specifically, "When are you going to start a company for Cassandra?"

And I said, "I'm not ready to do that yet."

Grant: Was he at a venture fund, or was he an angel?

Jonathan: Yeah, he was a venture capitalist from Lightspeed.

Grant: OK, cool. He's researching the industry, sees this project, sees that you're a contributor, you're not at Facebook, thinks that you might be the best person to actually go off.

You're probably the chairman of the foundation or something, so he thinks you're the best person to start this company.

Jonathan: Right. I was a chairman of the Apache Cassandra Project, which is distinct from the board of directors of the 200-odd projects at the Apache Software Foundation.

Grant: Right, but you're chairing that specific project. OK, that's great.

You have inbound investor interest from a reputable venture fund, that's helpful in terms of giving you some confidence that you might be able to start a company around this.

Jonathan: Exactly.

Grant: Then you decide to stop, and you maybe talk to someone else who is working on it with you and you bring them on as a co-founder. How did that happen?

Jonathan: I was leading the Cassandra technology effort, and there was another team led by a guy named Matt File that was more "We're going to deploy Cassandra for these different projects."

So, he was going to be running the Cassandra service. When I told Rackspace management that I was going to leave to start a company, Matt drove down.

He was in Austin, I was in San Antonio, and Matt drove down to talk me out of it. It ended up working the other way around where he decided to join me as our first CEO.

Grant: OK, very cool. Is he someone you had worked closely with while at Rackspace?

Jonathan: That's right, yeah. Since we were working on the two halves of the Cassandra service , yes.

Grant: That makes total sense. OK, did you raise right away? Is that when you went straight back to Lightspeed?

Jonathan: Yes. Effectively right away, so we ended up raising $2.5 million dollars Series A.

Which, another one of those hindsight moments, was not enough to do an infrastructure company. But that's what we did.

Grant: Now we would call that a "Seed to precede," right? That's just the way this works.

Jonathan: It's a different world.

Grant: Yeah, it totally is. Then you moved to Austin to start the company, or did you stay in San Antonio?

Jonathan: I stayed in San Antonio at first, and before we started recording I mentioned that hiring executives is one of the things that looks easy until you try it.

Our first VP of engineering was a disaster. Most of our engineers were in Austin at first, and so I've actually moved to Austin to do damage control.

Grant: OK, great. That's where your CEO was, that's where most of the team ended up being. Or, did you end up hiring pretty distributed?

Jonathan: For the first year, we did have a concentration in Austin and then our investors convinced us that we needed to have our headquarters in California.

Matt moved out to stand up that new office there. But on the engineering side, we did have a cluster in Austin and later on a cluster in California.

But one of the things that I wanted to preserve from my time working on open source first was that distributed engineering, and that sense that we can hire the best people no matter where they are.

Location shouldn't be an obstacle to writing code collaboratively.

Grant: T hat's the core open source ethos, is that you can do this from anywhere.

Jonathan: Yeah, and w hat that gives you is you do need to be able to work in a more asynchronous fashion.

Because instead of going over to the next cube and saying, "Gary, can you review this patch that I just wrote?"

And then going over it with him, it's more of a "I'm going to do a pull request and Gary will review it when it's convenient for him," which might be in a time zone six or twelve hours away.

I need to be able to task switch and work on something else in the meantime, so that's a little bit difficult for some people, but I think most engineers deal with that pretty well.

But in exchange for that you get a lot of benefits, and this is this is something that I'm pretty passionate about.

That as a manager in a traditional office environment, even if you're trying super hard to be objective, you can't help but be influenced by things like "Jonathan is the first one in the office and the last one to leave. He sure works hard."

When my team is completely distributed, then I'm forced to manage by, "Is Jonathan actually doing good work and is he doing it effectively?" I think it's a lot healthier and it's a lot more -- It's the world that engineers want to live in, which is "Good work gets rewarded and bad work doesn't, and politics doesn't play a role." There's still politics, but I think it is less of a factor in a distributed culture.

Grant: It's interesting, I think it's become obviously a pretty big trend in the last 10 years.

You started in Austin, opened up a headquarters in SF or in California, and I think you've seen the same trend happen.

A lot of people are based in SF or The Valley, and they are opening technical offices either in Austin or throughout the rest of the world in order to have access to more engineers, more distributed teams, without paying the huge tax on talent up in the Bay Area.

Jonathan: It's not just access to more engineers, but it's also access to more senior engineers.

The reason why I believe that is if you're in The Valley as a 20 something single person, t he cost of living super high but the salaries are also super high.

You can make that work. But when you start looking at, "I've got a serious relationship. We're starting to think about having kids."

That's a different era of life, and it's a lot harder to do that in Silicon Valley unless you've IPO'd or something and you're calling in rich.

So, we've had some of our early engineers who we hired in The Valley-- Because I mentioned we do have some engineers at our headquarters, and some of those have moved to Louisiana or to Texas.

That's fine, that's not an obstacle for us versus other companies that might be like, "You need to find a new job."

I think that not just being flexible about the place, but having that asynchronous decoupling of office hours from when you do the work, I think that's really healthy.

Because it gives you a chance to get a bit of that work/life balance, where the trend has always been work has been bleeding more and more into your personal life, but when you're working from home it's OK for your personal life to bleed a little bit into work .

I go pick up my kids, but that's OK because I'm going to be writing code after she goes to sleep.

Grant: It does definitely require a level of separation still, you have to be eit her doing one thing completely or another thing completely.

When you are picking up your kids, you're not trying to also write code.

Jonathan: Right.

Grant: There's a level of maturity and focus that's required in order to be successful as a remote distributed team, and I think that it's probably better for more senior folks anyway because they understand how work actually gets done.

Jonathan: I think that's a good word to use, the "Maturity" word.

I was talking with our director of culture, and I'm not sure if that's his formal title, but that's what he's doing.

He's new to the distributed engineering thing, and he said "So basically what you're saying is it's like attending a college class where the teacher says, "I'm not going to take attendance but I will grade you on your final."

Some students can deal with that, and other students are like "He's not taking attendance. I'm not going to show up," and then they fail.

Grant: It's definitely an important skill, I think, in this modern enterprise software, or just the software world, to be able to hire and recruit and then help onboard those folks into that remote environment.

Cool, so let's talk a bit more about DataStax in the early days.

You started this company, you get $2.5 million in funding and you hire on eight engineers, and we re you modeling the company and the go-to market after other database open core vendors?

Like Mongo, and these others that you mentioned? Or Basho and Riak, what were you--? What were the go-to market motions that you were emulating?

Jonathan: I think our peers were figuring this out at the same time as we were, so we weren't really looking to each other.

As in, "We're going to imitate what DataStax does or what Basho does," so much as the generation of infrastructure software just previous.

JBoss was one of the ones that we looked at and we said, "This open core model seems to work pretty well for JBoss."

Grant: I guess you didn't have a choice about it being open core, because your team didn't create the underlying technology that happened at Facebook.

They open sourced it, so you were open core . That wasn't a choice, right?

Jonathan: That's right. It turned out that I guess a lot of people came to similar conclusions that open core was probably the best way to build a company around open source, because even our peers-- We mentioned MongoDB, they owned their copyright.

It doesn't belong to Apache Software Foundation, so they could have done lots of different models, but they followed a pretty similar open core strategy.

Grant: When did you actually start working with customers? Like, right away or--? Like this telco, did you get a contract with them right away or did it take a while to start to get some amount of paying customers?

Jonathan: It was pretty quick. When we started the company, I believe officially in May, beginning of May-- W e announced our A round I think in July.

So in just those few months we already had customers before sending that A round, and I remember a couple of them don't exist anymore because that's the nature of the technology space. But yeah, we did have some customers by then.

Grant: Were those customer relationships purely support and training?

Jonathan: Yes. Support and services. The plan was, "We said 'Open core,' we're going to build stuff around this. We're going to sell a product."

But those super early customers, they're just straight up paying us for support.

Grant: Great. When did you offer the first enterprise product?

Jonathan: I'm struggling with my internal wayback machine here, but I think that was probably 2012.

Grant: OK. How did you differentiate that product? What was in that, that wasn't in the open core project?

Jonathan: The first thing we added was a Hadoop integration.

That was the hot Big Data thing at the time, and then we added search through basically a fork of Solar that we hacked up to run on top of Cassandra.

Then we started doing things around security.

Grant: What were the security things?

Jonathan: The audit logging is one, support for physical security modules, encryption at rest. T he standard things you'd expect, I think.

Grant: Sure, that makes sense. So encryption at rest wasn't a default feature, but I'm guessing maybe it is now?

Jonathan: It's a little bit messy, because Apache Cassandra in the Open Source Project provides support for encrypting what's called your SS Tables, but not for encrypting other things like the commit log or the index files.

It's a bit of a mixed bag, and so we said "We're going to solve that end to end and plug all the holes."

Grant: OK, interesting. Have you released some of the proprietary features around Cassandra back into the open source over time, as they've become more common in other contemporary databases and alternatives?

Jonathan: We haven't done a whole lot of that. What's more common is we'll look at something that we're working on, and sometimes this overlaps with things that other contributors are working on in the Apache world.

For instance, the upcoming Cassandra 4.0 includes an implementation of system views, where we present internal data about the system as views that you can select from with the Cassandra query language, instead of having to go over the Java management API that's Java only.

We were working on that concurrently and we said, "OK. Let's join forces and combine these efforts."

Grant: OK , so occasionally there will be things that you have read mapped as potentially enterprise offering, but then the community maybe wants to pull in to the open core and you'll collaborate on building that together?

Jonathan: Right.

Grant: Then make it an open core feature , it sounds like.

As you've scaled out DataStax, it seems like the majority of your business has been the enterprise offering, are you taking a top down approach to that where you have enterprise sales reps who are going out into the world and engaging with folks who've used Cassandra?

Or are they approaching folks that have never heard of Cassandra? How do you approach that go-to market side?

Jonathan: When we introduced Data Stax enterprise, we pulled the plug on selling open source support contracts.

We said, "We're not a support company, we're a product company. We sell DataStax enterprise."

This is for solid reasons that you can probably guess at, that we wanted to be seen by the market as a product company and have the margins associated with that.

But at the same time, we did lose something from that in the sense that there are people out there who want support for Apache Cassandra, but don't necessarily want the enterprise features that we're selling.

Late last year, we added what we call DataStax Luna, which is a support offering for Apache Cassandra.

I guess that's a sign of the maturity of the company, that we're comfortable and that we've defined ourselves as that product company.

We can go ahead and sell support for Cassandra as well, without diluting that a great deal.

Grant: OK, interesting.

Jonathan: T hen you asked about the go-to market, and it's pretty much an enterprise sales manager GTM where we are primarily targeting Cassandra users, but also we have a fair sprinkling of customers who have gone straight from Oracle or even mainframes to DataStax without first stopping with Cassandra.

So, they're primarily the Cassandra market, but also people who have scale out problems in general.

Grant: OK, so that's more of a true top-down sale, where you're coming in and replacing existing technologies without them coming up and showing interest in the open source community.

Jonathan: Right.

Grant: Cool. It sounds like you also recently created a hosted version of this, I think you call it "Apollo."

Jonathan: Yes.

Grant: Is that targeted at the same type of user, or is that a little bit more mid-market oriented? Who's the targeted user for that? Tell us more about that product as well.

Jonathan: What we're trying to do with Apollo is really expand the Cassandra market. I think Cassandra has a reputation, justifiably, as extremely powerful.

It can solve problems nobody else can, but it's also difficult to manage and to run.

Our pitch with Apollo is we're going to deliver the power of Cassandra, but now it's just a couple of clicks to get up and running. You never have to manage it, it's a database as a service.

I think that Cassandra has been held back a little bit by the technical requirements and the knowledge of the team to run it. That's the problem we're trying to solve with Apollo.

Grant: OK, great. When did you launch Apollo?

Jonathan: We started our open data in October.

Grant: OK , so it's quite recent.

Jonathan: Yes.

Grant: Is it the same features and tooling as DataStax enterprise ? Or is it a lighter version of that?

Jonathan: It is a lighter version, it's a Cassandra-shaped version. We're providing Cassandra features, but we're not providing the search features or the analytic features from DataStax enterprise.

We are bringing in some of those security features to Apollo, and I think that's the right place to start in terms of "What are the enterprise features that are most well-suited for a ' Let's grow the Cassandra market' audience?"

Grant: OK, great. This fits really into that same idea of, we call it product assortment. Good, better, best.

Now there's the open source edition, there's the Apollo version that gives you the hosted version, plus a handful of other security features.

Then there's the Super Enterprise edition that you can run in your own environment. It has additional enterprise tooling and reporting and analytics, is that right?

Jonathan: Right. The plan is to merge the Apollo and the DSE feature sets over time, but that's a good description of where we're starting.

Grant: Cool. Just any new product is so hard to do, and it sounds like the go-to market effort here and making this-- Is it a self-serve sign up and get going workflow?

Jonathan: It is, yes. We offer a permanent free tier for people to use, and you get X amount of resources and that's free. It's not a free for 30 days, it's just free.

Grant: Cool. So targeting there, developers and trying to get more adoption of Cassandra more broadly, it sounds like?

Jonathan: Yes.

Grant: Part marketing, part funnel, part build a business around this "As a service" product over time.

Jonathan: Exactly. It's also about improving the user experience, because when you're controlling the platform you can do things like we've integrated what we call DataStax studio.

Which is a notebook interface to Cassandra that lets you start exploring your data and adding new data.

It's part of the web interface of Apollo itself, and not something separate that you have to download and configure.

Grant: So, are you still targeting developers? Or does it start to go into more, maybe a data scientist might use this to put data in?

Jonathan: I did blur that line a little bit when I started talking about studio, but we are targeting developers primarily at this point.

Grant: But studio gives this UI experience maybe for someone else at the company that developer might work with over time, and give them an experience to explore the data.

Jonathan: Yes.

Grant: Cool , that's really interesting. Will you have a separate go-to market and sales team around the Apollo offering, or will your enterprise reps still sell the same thing?

Jonathan: I don't think this is a case where there's a right answer and a wrong answer , but the answer we're going with right now is that we want our enterprise reps to focus on DSE, and Apollo will be a new motion with a different set of people.

Grant: Cool. That makes tons of sense.

OK, it's interesting because within the DataStax world, obviously Cassandra and a lot of your contemporaries w ere solving really interested distributed data and distributed storage and compute problems before the world of Kubernetes came around.

Now when you look at the ecosystem, obviously distributed systems have become incredibly popular and it's become this huge wave.

I think Kubernetes is at the helm has really driven a lot of that, and I know you have some Kubernetes offerings in you're moving more into that world.

But I'd love to hear your perspective on, one, the emergence of Kubernetes and how that's changed your business and how that's changed some of your offering in go-to market as well.

Jonathan: OK. I think the most important thing about Kubernetes is that it has become an industry standard for orchestration of container based infrastructure, and so if it hadn't been Kubernetes, if it had been Mesosphere for instance, I would have been OK with that outcome.

But now it turns out that Kubernetes is basically one, and that's the world we live in.

The database space is a little bit later than other infrastructure to move to Kubernetes, because Kubernetes has struggled with managing stateful applications for a while.

Recently, I would say in the last year, maybe if you're more optimistic you'd say the last two years.

It's turned the corner and it's a lot more ready to deal with stateful infrastructure now, but we're there now.

Apollo is built on top of Kubernetes and we're providing an operator for DataStax enterprise that's built on the Apollo one as well, so I think that's the industry standard.

Grant: OK , that's really interesting. I was wondering if Apollo would be running on top of Kubernetes, and it is. That's interesting.

And you mentioned your operator, so for those who aren't as familiar with the Kubernetes ecosystem, a very popular concept particularly around the stateful services is this idea of operators.

There are a couple different frameworks, one from Google called Queue Builder, one from RedHat that they call The Operator Framework.

I'd love to hear your perspective on this, but generally the way that I understand it's pitched is it's that same operational knowledge that you might use to create a service like Apollo.

You start to bake some of that into a scheduler, aware and smart manager that sits inside of the cluster, and then is managing the different instances of the service rate.

Is that how you think about it as well?

Jonathan: Yes. Some of the things that you'd want an operator to take care of in a Cassandra world are, "I want to add capacity, I want to add another node to my cluster, or I want to upgrade my cluster to a new version but I want to do that intelligently. Where first I upgrade one node, and when that's done, I upgrade another."

There's this rolling upgrade, rather than a big bang where we shut it down and restart it.

Basically, the idea is that you do automate and build in error handling. "What happens if I start adding a node to my cluster?"

But then the network connection dies, "What do I do at that point?"

Build those things into the operator instead of hoping that everyone does it correctly in ad-hoc on their own fashion.

Grant: Yeah , and you're actually using that same operator that - - Did you open source the operator?

Jonathan: It's not open source , no.

Grant: OK. But you have this operator, and you do offer it as part of DataStax enterprise then?

Jonathan: Yes.

Grant: OK , so you offer it as part of DataStax enterprise, and you're also using it as a foundational piece of operating the Apollo service?

Jonathan: That's right.

Grant: Great. One thing I'm always curious about, and this is maybe going to get really nerdy and technical for the Kubernetes world here.

But when I think about the opportunity for operators, and you describe some of the common tasks that it might perform, one thing that you didn't mention was around performance.

Is this an area that you think that operators can start to have a hand in, where maybe they're integrated with Prometheus or something else?

And you're getting some amount of feedback from how the system is performing, and then you're making automated tweaks based on that? Or is that just too far out?

Jonathan: I think we're really close to that world of research group at CMU under Andy Pavlo has built a machine learning based database tuning and optimization service, and it's called OtterTune.

Like the animal, "Otter" Tune. What it does is it says, "There's 125 configuration knobs for Cassandra and there's over 500 for MySQL. That's more than even the best human can reasonably deal with," so as a human I come in and I say "I'm going to make this Cassandra workload perform better."

I'm going to go to the half a dozen most important tuna bles, and that's probably where I stop because there just isn't time to deal with more.

But when you have an automated system, it's got all the time in the world and it can start going down that long tail of "Maybe this setting that's a little more obscure is actually going to move the needle for you,"so I think we get to a point where it's not just saving humans time, but it's doing better than humans can actually do.

Where Kubernetes comes in is, I think that the way it makes the most sense is for the optimization service to run above Kubernetes and to push out its recommendations through the Kubernetes operator, rather than building it into the operator itself.

But that's a level of detail that again, there's more than one right answer. But I think we're really close to where that becomes not just a research project, but ubiquitous in the industry.

Grant: I love that. I've actually been following OtterTune for a while as well, and I agree.

It's super fascinating, I think just from the talks Andy gives, he compares the idea of who can configure a Postgres database the best. OtterTune, RDS, or the best Facebook DBA.

Jonathan: Yes.

Grant: It was like, "Basically OtterTune is better than RDS, but the Facebook DBA made some tweak that was a business-level decision about a knob that you would tweak, that only if you knew this system that was happening would you get that advantage.

But generally the idea is that you can-- B ecause there are so many knobs and so many things that this system can intelligently test them out until it's created the most performant solution.

Jonathan: Yes.

Grant: I'm actually -- This is such a nerdy thrill, but I haven't talked to many people about OtterTune, and they did another project before that, Peloton.

Not to be confused with the bikes, but this is a really interesting and emerging area of technology where I think if we can get to true self-healing and self optimizing services, it creates a really amazing future for how we can run and operate services at scale without needing so much hand-holding and observation.

So, I'm really excited about that future.

Jonathan: Occasionally I have people ask me, "Isn't database a commodity now? Does it even matter if you're running Cassandra or MongoDB or MySQL versus PostgreSQL?"

I think when you look at things like this, there's a lot of scope for improvement still, and that's going to be really material to people.

I don't think we've tapped out the innovation in the database space, or the more broad infrastructure space at all.

Grant: There's so much opportunity.

I believe that we have made leaps and bounds in terms of what we've been able to do with creating these patterns and privateers for distributed systems in the last 15, 10, 5 years.

But the opportunity to continue to make bigger and bigger improvements, I think, is still directly in front of us.

Jonathan: Exactly.

Grant: It's interesting, you mentioned Mesos and this idea that obviously Kubernetes is one.

I guess Mesos, being part of the Apache Foundation, you probably had a deeper integration with it first.

I think Mesos is also generally thought of as having a better integration with stateful services five years ago, rather than the last two years.

You mentioned Kubernetes, so is that an ecosystem that you were fairly invested in at some point at DataStax as well?

Jonathan: Now that you mention it, yeah.

We were pretty early partners with Mesosphere, and like you said they dealt with databases and stateful services at a time when Kubernetes didn't.

So yeah, it's an interesting alternate reality to picture where Mesos won , but here we are.

Grant: Not to put you on the spot, but d o you have any thoughts around why you think that Kubernetes actually ended up winning?

Jonathan: I think it's a couple of things. One is it did come out with the weight of Google behind it , and I think at a technical level it's that Kubernetes was really built for the container world, whereas Meso started I'm thinking in terms of VMs.

So there was some baggage that they had that Kubernetes didn't, but I don't think either of those are necessarily things that couldn't have been overcome again in some alternate reality.

Grant: The community nature of Kubernetes, I think, has been pretty impactful.

You saw RedHat and Google and Microsoft all get on, and get on pretty early, and I think that it just was more open, maybe. It just felt like there wasn't a single leader because Google had been involved but they weren't dominating the commercial offering space.

Jonathan: Could be.

Grant: Cool , and then another topic-- I look over at DataStax and parti cularly the leadership team that you've managed to pull together and recruit over the last few years, and there's this guy--

I've mentioned on the podcast before that just joined as your chief product officer, Ed Anuff, who I have a ton of respect for as an incredible product leader.

But I also know you recruited over Sam Ramji, who was at Cloud Foundry and Google for a while, and Chet is your CEO.

So when you think about scaling an organization and bringing on these executive hires who have done all of this before, you mentioned it's hard to get those when you're smaller.

But once you start to scale, how do you think about finding and recruiting and engaging such great executive talent in the way that you've done in the last few years?

Jonathan: I think this is a hard problem that I'm not very good at, and it's primarily the job of the CEO.

It's the job of the CEO to hire the executive team, and now I'm involved in the process but when I'm looking at hiring engineers I can do a technical interview--

We can go into what "Effective technical interviewing" means, but I can say with nearly 100% certainty this engineer can do the job.

Then you still have some false positives where Jonathan can do the job, but he's actually really bad at dealing -- Having that maturity to work in a distributed environment.

So there's still some hires that aren't going to work out, but in terms of "Can he do the job?"

I have a very clear signal on that. When it comes to hiring a VP of product or a chief marketing officer, it's way more difficult.

Part of it's just that at that level, everyone's good at selling themselves. Partly it's that you can't give someone a take home test and come back and say, "You know exactly how to run marketing for DataStax."

I'm really impressed with the job Chet's done recruiting quality talent. I think if he has a secret weapon, I think what it is that Chet is not selling something.

In the sense that when Chet recruits an executive, he says "Here's why I think DataStax is going to change the world," and he's completely honest about that.

You can tell, I think, when someone is trying to sell you versus telling you how they really feel. So, I think that his sense of mission and his excitement is contagious.

Grant: That's interesting, OK. But you helped bring Chet onboard in some way, right? Even just getting him to be engaged, he's been quite successful throughout his career.

He built and sold Apogee to Google, so did you have to do the same thing where you just shared your vision for why DataStax was so important in order to get him engaged?

Jonathan: I wouldn't have articulated it that way, but now that you say that I think that's exactly what happened.

Part of being successful as a startup is hard work, but that's not what makes or breaks you, because all of your peers are working just as hard.

Sometimes you just have to roll the dice and hope that it lands on sixes, and with our CEO hires first with Billy Bosworth and then with Chet, I think that's the kind of success that you can't really plan for and you can't get just by working hard.

The stars have to align and you have to get a bit lucky, and I think that's what happened.

Grant: But it takes building something interesting in a compelling space, and then also have a team that they're excited to work with.

It's one of these things that I'm thinking about more and more as I went to build out an exec team.

I'm trying to figure out how do I, one, find the folks that that really already believe some of the core things that we believe?

And then, two, are willing to take a risk on an earlier stage company because they see the opportunity to really scale?

It's just one of these interesting challenges that I think you have to do as you build a big company.

But it's something that most of us don't have much experience with, like I'm sure you had never recruited many senior executives to teams that you were at before.

Jonathan: Hopefully. This is where investors are actually really useful.

So when I was starting DataStax all the investors were like "We will be your partner and not just write you a check. "

I'm rolling my eyes and thinking, "That's great. But what I really want is the check."

But it's actually true that the non-financial contributions can actually be really meaningful, and one of the things that I've really enjoyed about working with John Vrionis is how he has been so involved at every stage of DataStax.

I don't want to spend too much time praising my investors, but stereotypically you've got early stage and late stage investors, and maybe somewhere in there you've got mid-stage specialists.

But John's been able to scale with us from that early stage to where we are today, and be meaningfully involved all along the way.

Hopefully your investors will be able to make introductions to the kinds of executives that you're looking to recruit.

Grant: H e's been on the board since that first $2.5 million dollar round?

Jonathan: Yes.

Grant: How big is the board right now? How many folks have not just observer, but true board seats?

Jonathan: I want to say seven, I'd have to go through the names in my head but I think it's seven.

Grant: Sure. And you're one of those, I assume?

Jonathan: I am, yes.

Grant: Boards are interesting as companies get larger and larger.

Jonathan: That's right.

Grant: Cool, and then one thing you said, which I actually would love to just get your perspective on , you said something about technical hiring and that interview process.

It sounds like you have a bit of a framework that you use, and I'd love to hear that.

I think that's often a challenge early on, is having a really clear idea of what a developer can come in and accomplish and fit well with your culture.

I'd love to hear how you think about that.

Jonathan: There's a dial you can adjust in terms of "How many false positives do I get versus how many false negatives?"

In the sense that if my hiring process is super rigorous, then I'll be very confident that I'm not hiring someone incompetent.

On the other hand, a lot of senior talent will look at that and say, "I'm not spending four hours on a technical interview when I can go get a job with a conversation at other places."

So there's a bit of a dial there, and when I was running our Cassandra team up until fall of 2015, I had the dial pegged really hard towards "I will not have any false positives."

One of the tools that I used for that was actually taking advantage of the open source nature of Cassandra to actually give people, "Here is a ticket that someone has filed against Cassandra that represents either a legitimate bug or a legitimate feature we want to add ," and the tricky part is finding something that's meaningful enough that people can sink their teeth into a little bit, but not so meaningful that it's critical that we solve this for customers right away.

But we did a reasonable job of threading that needle, and so the state of the art of technical interviewing is you want to give the interview as much connection as possible to what someone will actually be doing on the job, so at the far end of completely useless is asking someone to write Quicksort on a whiteboard.

Nobody writes code on whiteboards, they have Google and they have StackOverflow, they have IntelliJ to do code completion.

You want it to be as real as possible, and then if you say "Here's a an actual ticket from the open source project that's not going to just require you to write code, but also to understand existing code," which I think is actually harder.

When you have a meaningful existing code base, then that's as realistic as you can get.

Grant: Yeah, that's great. We've been doing similar things.

I think being open source is really helpful there, because the ask of "Contribute to this open source project" is much different than "Write this. We're going to give you access to some repo. We've created some fake examples, spend eight hours doing this project and committing to open source to something that folks are interested in."

Then one thing that we do that I think is partially just because the industry seems to be--

There's a little bit of blowback around asking folks to do too much during an interview process, is we like to just give some amount of recognition for that contribution.

So, it could be a $250 Amazon gift card or something.

Jonathan: Yeah, we ran into that a little bit where people are like "You're trying to get me to provide free labor during the interview process."

And that wasn't the idea, we'd have a dozen candidates working on the same ticket.

Basically, we'd use the same ticket until somebody from the community went and fixed our ticket and committed it and then we couldn't use it anymore.

Grant: I love that idea around it , and I think it's good.

Actually, my thought is that it's better to actually not get free work but not have people do work that doesn't matter.

So there's this interesting mix, and that's why we say "We're going to recognize your contribution with a gift card,"because I don't want to spend the time to pay people and put them on some type of contractor thing.

But if we can say, "Here's a gift card for this effort," We don't expect free labor, so it is an interesting debate within the ecosystem.

We like our little solution, but the main challenge to your point is it's actually quite hard to find the right level of issue, or to give to someone to do.

You're like, "Is that one too complicated? Is that too easy?" You would want to reuse the same thing over and over, but one other thing you said that I'm interested to see how you think about it.

You said Chet and you would have to do at the same time when you were recruiting executives particularly, but explain why it's going to have such an impact on the world?

When you think about DataStax, I'd love to just hear you talk for a bit about why this is such an important company and technology, and how do you sell that larger vision?

What is that for DataStax?

Jonathan: When we were initially raising money, the reaction we got from a shocking number of investors was "This is cool technology, but there's a market for five companies in the world that need a scalable database more than they can get from Oracle."

I think in the 10 years since then, we've been thoroughly vindicated by the market that this actually is something that virtually all modern applications need to think about.

If I'm successful, I'm not going to fit on my MySQL box or my RDS VM. So the way to think about it is not, "How much of the existing market can you capture?"

But, "How big is the next market that the relational databases can't even address? How big is that market going to be?"

I think it's probably going to be at least twice the size of the relational market, so right now Gartner's estimate is a $5 billion dollar new SQL market, but that's going to be $15 in five years.

Grant: It's really just about painting the picture for why this becomes such an important part of the industry over time.

Jonathan: Yeah, I think it really comes back to the challenges I encountered as an engineer.

I know firsthand, this is something that we need to build effective applications, and it's just going to be part of the landscape the way relational databases are part of the landscape.

Grant: Yeah, I like that. One other thing that I think about just generally in terms of a bit more broader mission-oriented, which I think applies to basically every infrastructure software company.

It's actually based on this -- Zuck did some interview series and he was talking about how healthcare didn't really have much tool building, so it just didn't have some of the efficiency that you get from engineering, where we just focus so much on tool building.

The idea was that tool building just gives you this huge amount of leverage, so when you contribute to a company like DataStax or any developer tool company who's enabling a downstream developer to do something else, you're basically freeing up hundreds or millions of hours of effort that the community at large was all going to solve, each independently.

By you doing it upstream and then delivering it to those folks, they get to go do different things.

There's this huge amount of leverage that you get by building a tool company that's going to provide that level of effective and efficiency to all these different projects.

To me, that really ge ts me excited about the future of what we're able to do and the velocity at which we're able to keep moving.

I think it provides me with some really crystal clear value for what we're doing day in, day out.

Jonathan: No, that's a good point. If you look at 2001 up through roughly 2009 or so, that industry state of the art for solving the scale out data problem was to shard a relational database.

This was an ad-hoc solution that different companies approached differently, and it tended to not be very reusable from one project to another, even within a company.

Grant: Right.

Jonathan: Having a general purpose solution that just makes that something you don't have to think about very hard, I think that is super valuable.

Then the question is, "If I'm going to apply this to starting a company more generally, how big is the problem that I'm solving for people?"

Grant: Yeah. It doesn't seem like we have any lack of data and systems problems, there's a lot here.

I'm enthusiastic about the future of what you're building, and Jonathan, thank you so much for your time.

I really appreciate all the insights into building such an interesting infrastructure company. So, thank you again.

Jonathan: Thanks a lot, Grant. I appreciate it.