Show Notes
About Suphatra Rufo
Suphatra started her career at NPR and PBS stations around the country, and quickly found her way into technology. She worked on social good initiatives like Microsoft’s Imagine Cup, a competition for young inventors; We Day, working with Selena Gomez to advocate for more young women to learn how to code; and TEALS, a program that places industry engineers in high school classrooms to teach computer science.
She has deep product experience and led the effort to create a nonprofit SKU for Office 365 and Azure and bring cloud computing as an upsell to the social sector to 93+ markets and realize a new revenue stream for Microsoft. She was part of the original team that built Microsoft Teams and saw the product from Preview to GA, all the way to v2. She worked at the forefront of cloud computing at Amazon Web Services, managing their $6B database category's developer advocacy and customer storytelling efforts. Today, she heads up solutions marketing at Couchbase, a late-stage VC-backed cloud database startup in Silicon Valley valued at nearly half a billion dollars that develops open-source, NoSQL, multi-model, document-oriented and key value databases.
Transcript:
Jeremy: Hi, everyone. I'm Jeremy Daly and you're listening to Serverless Chats. This week I'm chatting with Suphatra Rufo. Hi, Suphatra. Thanks for joining me.
Suphatra: Hey, Jeremy. Thanks for having me.
Jeremy: You recently became the head of solutions marketing at Couchbase, so why don't you tell the listeners a little bit about yourself and what Couchbase does?
Suphatra: Hi, I'm Suphatra. I'm head of solutions marketing at Couchbase, which is a small start-up in Silicon Valley that develops open source NoSQL multi-model, document oriented and key value databases. We've raised $155 million in funding and we're valued at nearly half a billion dollars. As head of solutions marketing at Couchbase, I create the company's market strategy, sales plays across different industries and solutions, and I handle all of our compete scenarios. In my typical day to day, I'm usually looking at complex technical and business challenges and trying to diagnose how we can create solutions around that, and working with our engineering team to influence product road maps so that our solutions can be integrated in features and helping our business teams determine our next go-to-market investment areas.
Jeremy: Awesome. All right. You have a ton of experience and you have a very impressive resume on marketing cloud databases... Is maybe a good way to say it. I'd love to get some insight from you into how companies, especially enterprises, are looking at migrating data to the cloud and moving away from maybe more traditional on-prem type installations. I guess maybe the best place to start is, I think most people know what relational databases are, that's a pretty common thing. And I think people have a sense of what NoSQL is, people might be familiar with DynamoDB, MongoDB, Cassandra, those sort of things. But maybe you could just give us a little bit of background on what modern NoSQL looks like.
Suphatra: Yeah, yeah, like NoSQL 2.0, but I'll just start from the very beginning too, because I think a lot of people are confused NoSQL still, which is funny because it's been around for almost a decade at this point, but NoSQL is essentially a different kind of database that doesn't rows and columns. One good example is if you think about an application like Snapchat, on New Year's Eve, millions of people want to use Snapchat at the exact same time. So 11:59 PM, millions of people get on their phone to use Snapchat because they want to capture the exact same picture at that exact moment. So Snapchat, as an application, has to be built in a way to accommodate for a very sudden and huge surge in performance for a very brief moment of time, and then scale right back down... Because once people take that picture of them kissing their loved one when the bell rings, or the ball drops, I should say, then they stop using Snapchat, so then that goes straight down.
What NoSQL databases are great for is they can handle those types of really heavy spikes because they can scale up and down really easily because they aren't constrained by rows and columns like a typical relational database. That's what the NoSQL databases really offer. Since NoSQL databases were invented a decade ago, they've really branched out to lots of different types of NoSQL. Now you have document databases, you have adjacent documents, key value databases... Couchbase is cool because they do both of those things. When I was at AWS, I helped with stories about DynamoDB, which is specifically just key value database, which is also really strong database as well.
Jeremy: The thing that's interesting about NoSQL, and we're hearing more and more about it, there's a lot of different companies that are offering solutions for it. And more importantly, I think there are companies that are starting to adopt... And specifically for the workloads like you talked about, that New Year's Eve... Billions of records or billions of transactions in a very, very short amount of time, but is this something that you're seeing companies, maybe not just your start-ups and your Snapchats, but you're seeing other companies start to adopt?
Suphatra: Yeah, yeah. I think the way that consumers behave, the retail industry is a good example. You probably didn't know that Sears, Kmart, Barneys New York, Party City, I can name a dozen more retailers that just last year, either completely closed down or had to significantly reduce their number of stores, just last year. It's because retail isn't done the same way anymore. Those spikes are now a common part of life and people are having a hard time figuring out how to handle it. Tesco, which is the largest grocery chain store, I'm not sure in America or in the world, I'll have to check that... But they, in 2014, crashed on Black Friday because they couldn't handle the spike in the demands they were getting online. So they lost an entire day of business on Black Friday because they couldn't handle that workload. And then the year later, they went on a NoSQL database and now they can handle that load.
I think what people are seeing is that normal day to day business operations are fundamentally different. For example, the fashion industry used to have only four clothing seasons. Your mother probably remembers buying a new outfit every season... So winter, spring, summer, and fall. And so women's clothiers would go and create new clothes four times a year. Now the fashion industry has 52 seasons, so every week is a different season of women's clothing, which means there's a spike every week for every launch of every new clothing line. So that's another big database problem that's now just becoming a regular part of life. A decade after NoSQL databases are invented, it's really not a new invention anymore. Now this is just the way of business.
Jeremy: Wow. I can't imagine buying something new every week. I buy a new hoodie maybe once a year or twice a year or something like that. That's the extent of my fashion choices. I think that's really interesting. I think that's where everything is moving, is that just you have to become global now, right? You have to be able to handle these workloads that are just gigantic, and obviously there's some major players in this space. We have AWS and we know of things like DynamoDB and now some of the managed services they have. Google still has their big table and a few other things like that. Obviously, you have a bunch of these start-ups and I guess start-ups that are much further along like Couchbase, but what is the concern there? I mean data itself is a huge lock-in problem, right? As soon as you put data, and you got terabytes of data somewhere, you're kind of there. I mean, do you see vendor lock-in with some of these NoSQL players? Do you see that as a major concern?
Suphatra: Yeah. I think this is where things get really interesting. When I was at AWS, I worked almost exclusively on my creations off of Oracle and Azure at AWS. And a database migration is, by and large, the most difficult thing that you can do in cloud computing. It's really hard. You've got to do a lot of data modeling. You've got to do your schema conversions. I mean, it's really just a ton of work and what I have found is that when people are charged with, "All right. We got to migrate our database." We tend to do it in multiple phases and that will take multiple years, so oftentimes they'll first just re-host. Let's say they're on Oracle. They want to get off Oracle, but they don't want to be penalized. So they take their Oracle license and bring it to a different cloud provider. They keep all their data with Oracle still. They're just moving it. That takes six months to a year, then afterwards, they say, "Okay. Well, I think we're now going to replatform." And that's a whole nother workload and that's even more work, and even harder down the line is refactoring, which is where they might actually go from a relational database to a NoSQL database.
It's much more rare that you see people to a database migration where they go from a traditional relational database on one provider to a NoSQL database on a another provider because it's a really difficult piece of work. When people make the decision which database they want to move to, it's often a very permanent choice. One interesting thing that I've seen is people choosing not to go with public clouds which I think is a bit interesting and we see that with the hybrid solutions set Azure and AWS are coming out with with Outpost. I think that's a really interesting trend that I'm definitely keeping an eye out for in upcoming years.
I think that vendor lock-in is generally a problem that's going to be most relevant to really big enterprises. I think the smaller guys, I still find that they're pretty agile, smart and quick. They figure out how to do things pretty quickly. I think for the lock-in, my recommendation would be lots of NoSQL databases, Mongo, Couchbase, DynamoDB... They support a certain amount of data for free on their databases. So for most people, you can actually get that great performance completely for free as long as you have a small amount of data. And as you start to grow, that's when you might be more pressed to make a smart purchasing choice. Then you might say, "Okay. Do I want to do a data migration? Am I really comfortable with this database or now that that we have more needs, do I need to pay for it? What do I want to pay for?" But for the most part, I would say for the life of an organization, that free level is going to be totally fine.
And where the vendor lock-in happens is something... What I found was at AWS, it was like going to Target, where you go and you say, "Okay. I just need to buy a pillow," but then you see all the other cool stuff and Target and then by the time you've left the store, you've spent $300 dollars on towels and clothes and gadgets for you family. I think that's some of the stuff that happens with AWS. Take, for example, DocumentDB, which is a document database... It doesn't have Eventing. It doesn't have full tech search, so if you need those things, you need to purchase additional resources to get that, which means you think you're buying DocumentDB, but now you also buy X, Y, and Z. DocumentDB scales by storing its data on S3, so now you are also buying S3. What happens when you go with a provider that does a purpose-built database, is you have to be comfortable with buying a lot of different services. And Azure's a bit different where it's a little bit more all-in-one, right?
Microsoft's very good at the whole all-in-one thing. I worked there as well for a long time and they love just bundling stuff together. The downside of that is you never know what you're paying for it because you just get a lot. You get everything.
Jeremy: Yeah.
Suphatra: So that's different from Target, whereas Target you and you don't know what you end up buying. I liken Microsoft to the really nice seafood buffet restaurant in town where you're spending good money because the seafood's going to be good. It's not going to make you sick and you could have as much of it as you want... But after you've paid, you realize you didn't eat as much as you think you should have and there's that sense that you're not getting that price that you deserve, which is why Amazon has a good edge on Microsoft, because Amazon says, "Oh, we're going to cost because we let you choose. Pay as you go." Microsoft says, "Well, we're good on ease and convenience because you get everything you want all in one." So that's some ways to think about those two big providers.
Jeremy: Yeah, that's actually interesting way to think of it because I've always thought of AWS to be very additive, a lot of pick and choose the low level components that you need, and I like that about it... But when it comes to airlines where you pay that baseline ticket and then if you want to bring a bag or get a better seat, pay more money. That always drives me nuts there, but I do like that control. I think that's really interesting. You mentioned this idea of re-hosting, replatforming, and refactoring, right? The migration piece of somebody moving into a public cloud or moving into one of these other tools obviously is a long process, takes a while to do. And so when they get to that refactoring point and they're starting to get rid of Oracle, for example, or get rid of Microsoft, which AWS migrated everything off of Oracle... Do you see the role of Oracle and Microsoft SQL Server, things like that, do you see those starting to go away? Is that a dying market?
Suphatra: No, I don't think it's a dying market. I don't think people are migrating as fast as the hype makes you believe and you can kind of tell... At re:Invent last month, Andy sort of alluded to that. He was annoyed that people weren't migrating off of on-prem fast enough because it just takes time and people want to be smart and careful. And you would be surprised at how much both of those companies go through switchbacks, right?
Jeremy: Yeah.
Suphatra: And that's expensive, if you're a company that's like, "Oh, I want to do this," and then, "Whoops, my bad. We're going to actually go back." Yeah, I mean you can imagine that happens with Redshift and Snowflake.
Jeremy: Okay. Yep.
Suphatra: Yeah, right? It's an expensive process, so I would say that I think it's a dying market maybe for Oracle, and I don't know honestly if that's a technology reason. I think the reason for that is the business practices are ones that consumers are not willing to do anymore because the terms of the market have changed. When Oracle was the only player in town, they could treat you any way they wanted, right? It's like the Mafia, someone running your neighborhood, they can call whatever shots they want, but it's not like that anymore. Now there's multiple players.
And I spoke to so many customers at AWS when I was pursuing these stories about people migrating off of Oracle that would say, "We got audited and found out that we were using features that actually cost us money. We had no idea, so then we got the bill that is six or seven figures. And then they tell us, 'Hey, if you signed this contract, we'll alleviate this bill,'" and then you're locked in for further. Those types of business practices that worked in the past, when you're competitors are not doing that anymore or actually not doing that at all or ever have, and people say, "Well, I don't have to go through this," and go over here, it's just not going to work. So I do think tech in Oracle is not dying, it's just their business philosophy.
Jeremy: Yeah, and I think there's so many more options now, right? I mean, I remember way back when when the commercial databases that I licensed, early 2000s or late 1990s, we were licensing SQL Server, and you're paying for that license to use that and to install it on one server. And then if you need to grow, you have to buy a new license. You have to scale back or whatever... You're always paying more money in order to have all that extra licensing. And this model that... I'm sure not AWS who introduced it, but this idea of just paying per hour for a database, for example, and for the licensing that goes along with that, and you can turn as many on as you want or turn them off whenever you need to, is really a much different approach, obviously, like you said, to that mob boss mentality of Oracle maybe.
Suphatra: Yeah.
Jeremy: And not saying anything bad about Oracle, I mean I'm sure nobody ever says anything bad about Oracle, so we'll keep that level of decorum here as well. All right.
Suphatra: I did want to follow up on that too, because a lot of people say it's a dying market. They say, "Oh, well, Oracle and SQL Serve, people are leaving that." People love SQL. They love SQL.
Jeremy: Yes, they do.
Suphatra: And I was at the PASS conference last month and PASS has 30,000 members. Those are 30,000 SQL administrators. I mean that's a lot of people and that's just the people that are SQL administrators that have joined an organization about it. There's probably a bunch that they didn't capture.
Jeremy: Oh, yeah.
Suphatra: And they really love it, and I don't think obviously SQL is going anywhere. That was one thing I really liked about Couchbase, is that query and know SQL database can be really confusing and frustrating because sometimes people treat it like a data dump so it's hard to find information in there, and Couchbase has their own query language called N1QL, and it is essentially SQL for JSON. For example, if you were to use Mongo or DynamoDB and you wanted to query something, it would take you literally hundreds of lines of code, about 234, I believe... But on N1QL, it takes seven lines. I was like, "Wow, that's actually something different and new."
One thing I learned when I worked at Microsoft and at AWS, and when I was working on these stories about Oracle and these big companies, is I feel like I was often in this situation where I was seeing our teams build something that someone else had already built. We were just trying to build something again and compete against them. For example, the Amazon-managed Cassandra that came out last month to compete with DataStax and open source Cassandra and those sort of things, that I think I just start to feel like, "You know what? I think it's time for me and my career to go somewhere where the technology's net new. Someone invented it. It's brand new."
Jeremy: Yeah, yeah.
Suphatra: I do think it's a valuable business play and it's been done forever, to go and copycat something and compete with it in the market, but I also thought it'd be exciting to try some new technology as well. I think what I've seen with SQL and with the move over to NoSQL is it's not that people are abandoning SQL, the rate of SQL to NoSQL use is about 90/10, so obviously SQL had a huge advantage. But what's happening now is people are using SQL databases with NoSQL databases, so those numbers-
Jeremy: That hybrid approach, right?
Suphatra: Exactly. The hybrid approach, because they're saying, "Okay. Well, I don't really understand the NoSQL thing, but I want to venture into it, but I'm certainly not going start migrating all my stuff over." Like I mentioned, refactoring is very difficult, so they're just using both and I think that's really great because... One good example is Pokemon that I worked with at Amazon. They were using Aurora for their authentication and they're using DynamoDB for their botnet strategy, all-in-one, for their log-ins... Because DynamoDB, you can set a time to live. They were able to kill botnets within five minutes. They reduced their botnet issues, their bot log-ins, by 93%.
Jeremy: Wow.
Suphatra: And they have a really great video about it on Twitter, I think I tweeted it. I could also send it to you, but it's really funny. It explains how they defeated their botnets. And then they're also using Amazon Aurora relational database for the rest of their authentication process, so it's that kind of pairing of two databases of two different schema types, that make magic.
Jeremy: Yeah, and I actually think that is something where you just have to move to. And that's why I feel like some sort of really large commercial database like an Oracle or like a Microsoft SQL Server, is not needed at the scale it used to be needed at, right? You get Amazon, who is doing... I don't know, gajillion transactions per second or whatever they're doing, trying to run that on Oracle and it's basically starting to choke. They have to just keep making the clusters bigger and keep adding more servers and just keep scaling up and scaling up in order to handle that because of the complexity of the queries in a relational database. Whereas when you move to NoSQL, then the complexity of the queries stays the same regardless of how much information there is and as long as you understand your access patterns.
That's why I think that you're still going to need relational databases because you're still going to need to do analytics and you're still going to need to some of these other things, but as we are starting to talk about scale, where the growth is probably going to be in the market, I think that's going to be with NoSQL where those are the things that are going to be able to support this massive data from an operational standpoint. And then maybe you take that hybrid approach and use SQL Server or, I should say, a relational database as your reporting or some sort of data warehouse type thing to run analytics on, but certainly wouldn't need to run at the transaction scale as something like a NoSQL database would.
Suphatra: Yeah. No, I think you're exactly right, exactly right. Spot on. That's why I'm here. You're a smart guy, Jeremy.
Jeremy: That's why you're here because you're smart as well. I just wanted you to validate me, is basically what I wanted you to do.
Suphatra: Done. We can sign off now.
Jeremy: The thing you mentioned a little earlier too was about purpose-built databases and I think this is an interesting strategy that Amazon is doing. I mean, I get it. If you need a time series database, then use a time series database. If you need a Blockchain for some reason, then use a Blockchain, Quantum Ledger or something to that effect. What are your thoughts on these purpose-built databases?
Suphatra: Yeah. It's funny because I can't tell you how many times people come up to me and say, "What does that mean?"
Jeremy: Yeah, that's a good question.
Suphatra: It a weird word, it's not a real word, right? Yeah, it's good. I really liked it. The old way of database was you just set it up and you threw your data in there. A purpose-built is trying to get you to... You're using a database because you have an application and that's the database that's going to be used for it. Another way to think about it is when multiple databases are being put together for one application or purpose, like what I mentioned with Pokemon. I think that strategy is good.
I would recommend for folks... The only thing is there is a little bit of learning curve if you're going to be stitching multiple databases together. You got to figure out how to make them work together, and then also, your cost is going to go up oftentimes, so you got to figure that out. But I think the most likely situation is that only large enterprises are going to be using multiple databases. I think smaller companies will probably find one that is just suitable for their needs... Because I doubt that a lot of really large businesses are dealing with a 93% bot log-in reduction they need to deploy, right?
I would think if you are a small accounting business, one database is probably fine for your needs. If you are a small retail company selling quilts, you're probably not dealing with big spikes. For most cases, again, I think... What I said, SQL's not dying. I think it's going to still be really relevant. Examples I see most common are in travel and hospitality, retail, obviously... Retail's the easiest one, and finance. And those three, I would say, is where if you are in one of those three categories, then you need to be doing purpose-built databases... Definitely for sure NoSQL databases and you got to learn how to pair relational and non-relational together. One good example here, and travel and hospitality is a good one because... I'll give you an example of Carnival. Carnival is a customer of ours at Couchbase here. They run 20, 30 nodes with us and they really take advantage of our Eventing, and I know serverless, you guys love Eventing.
Jeremy: Yes, we do.
Suphatra: Eventing lets them do... I've actually never been on a cruise. Let me preface with I've never been on a cruise so I will explain something to you, an experience I've never had, but it sounds very exciting. The engineer was talking to me about this the other day because I was like, "Hey, man. I'm going to do this Serverless Podcast. I'm pretty sure they're going to want to talk about Eventing." He's our Eventing guy and he says, "Oh, I got a great Eventing example for you. Have you ever been on a cruise?" I was like, "I've never been on a cruise." He's like, "Oh, my god. You have no idea what you're missing. I take a cruise every winter."
So Carnival does these cruises, and apparently in the cruise, there's these different rooms for different activities, and he said that when you go from room to room, they put this wristband on you. It triggers our Couchbase database to say, "They're in this room now," so all this stuff pops up to you... Discounts on drinks if you happen to wander to the bar, if there's a ballroom, you can request a song. This is a combo of both field IOT and Eventing, which is great... And it's all in real time. What Carnival also does is... For example, if there's a show on the boat and a lot of people have crowded at the bar, not only does it trigger to the customer, "Hey, you're at the bar. Why don't I give you these special deals?" It triggers to Carnival so they can send more staff from one part of the boat to another. It's really helpful for their business.
Jeremy: Interesting.
Suphatra: I'm sorry, I went on a tangent, but I thought it was interesting with the cruise Eventing. Also, another exciting thing about a cruise, my husband refuses to do a cruise so I can only live vicariously through these technical case studies.
Jeremy: All right. Well, I have never been on a cruise either because 8,000 people stuck on a boat in the middle of the ocean does not sound like a good time to me, but anyways... But hey, listen, to each their own, and to each, their own purpose-built database if they need one. The other thing you mentioned, and this is something I'm really interested in because I think when you think of public cloud providers and you hear Andy Jassy's keynote and you hear some of these other keynotes even at Google Next and something Microsoft Ignite or any of these big tech conferences, and they're talking about where some of this stuff is going, there's a lot of focus on enterprises and I get it.
Enterprises have a lot of money. They spend a lot of money and it makes sense. That's where I think the vast majority of the cloud money is made, is with enterprise and even with government cloud and things like that now. I think one of the things I love about serverless in general, and again, something like DynamoDB or NoSQL database, is the ability for it to start really small and then get really big if it grows, right? So there's a lot of small companies, start-ups or small businesses, that can utilize this type of technology. What role does pricing and infrastructure play for these smaller companies?
Suphatra: Yeah, that's a really good question. There's a couple of things. If you're choosing a NoSQL database and you're concerned about pricing, you have to look at how the databases scale it... Because if it's going to scale up, then you're going to end up paying for expensive hardware than can handle scaling up. If it's scaling out, that'll be a lot better, so essentially if it can shard. If it can shard data, that's going to be more cost efficient. If you can get the NoSQL database, honestly, as software that you can install in your own server, that's probably the cheapest way.
I think my concern for the small guys is if they go to a public cloud provider, that they end up consuming features that they don't realize they're paying for as features... So that example I gave with DocumentDB where let's say you say, "Oh, I want to try some Eventing," DocumentDB, and then you do it, and then you find out later that you actually were consuming additional services. Those are some surprise bills that can happen. I think the benefit, though, of going with fully managed cloud is you don't have to worry about it, right? If you want to just pay that premium and you don't have to worry about it and that's worth the extra cost, then yeah, I think Azure and AWS is a good option. And one way to keep your costs down, is to make sure to keep your data really clean, which means you're just going have really good data hygiene. Does that answer your question?
Jeremy: Yeah, I think so. I mean I think what I'm trying to get at is there are... Obviously we've made a big shift from this idea of on-prem to even just, I guess, general hosting providers. I remember back... Late 90s, early 2000s, where it was always the hosting provider. You pay couple bucks per month and eventually that gets more expensive, but you would just upload some code into a server somewhere, maybe they installed MySQL or something like that for you, and it was sort of this very simple approach to that. As things become more complex though and companies start bringing in their own servers or try to do something on-prem, it gets more complicated. And even if you're a start-up, I mean I can't possibly imagine a start-up nowadays saying, "All right. Let's go buy $200,000 worth of Dell servers and rent a co-location for facilities somewhere and do this on-prem installation."
It seems crazy to me that they would do that and it also seems a little crazy to me for someone to say, "Well, we need a database so let's go ahead and install directly on a VM." They're going to use something like a managed RDS or whatever it's going to be, and I guess what I'm trying to get to is, these services that are built for these massive enterprises, I mean eventually these small companies might want to become enterprises, but is there a way for them to start small with these things? I mean, do you think it's a bad choice to go with DynamoDB or CouchBase if you're a small company? It seems like a good on ramp to me, I would think.
Suphatra: Yeah. I know it sounds crazy to just buy and install your own database and put it in with whatever cloud you're in, but honestly, for a small company, that's the best way to stay portable with your data because essentially you're buying something that you can put on AWS, on Azure, on GCP, whichever cloud you choose, and you can move that around if your costs start to overwhelm you. You can easily change your provider. So that was something that I personally had never considered because when I was at AWS, I only talked to large companies ever. We were only interested in storage from large customers so I didn't get to interface that much with those small companies. And when I was interviewing with I think every single database company in the world, back still a few months ago when I was interviewing, I got a lot more exposure to smaller companies. And what I found was they're really scared of vendor lock-in, what you talked about earlier, and they wanted that portability while they were growing because they weren't quite sure how their data was going to grow, so actually that is a really smart choice for them.
Couchbase, for example, does hybrid multi-cloud, bring your own cloud, put it on a server, then do literally anything you want, and that's something that's common if you were to go to any other small database as well. And I think that when you go to a fully managed cloud provider, you're saying, "This is it. I've made my decision, done deal." Once you're on Dynamo, you're on Dynamo. Like I said, database migration is very complex, very difficult. It'd be a significant investment to change it. If you're under 100 people, I would say that find one that is portable with you so it can grow as you change. You can always migrate to a bigger player later if you find that, "Hey, we're so big. We're going to go do that." I will say the nice thing about DynamoDB though, is that I believe 80% of DynamoDB's customers don't pay for it at all because they're on the free tier, which is a permanent level of free because the storage allowance is really big.
Jeremy: Yeah.
Suphatra: That is a nice thing about Dynamo, so if you say, "Hey, actually I want to go straight to Dynamo," that's an easy way to do it and feel pretty safe there for quite a while while you're growing as a company. And then Mongo has their community edition which is totally free, and then Atlas is paid, so you can take that route as well. That's what I'd recommend... I'm sorry. It's not declarative because I don't want to be like, "No, don't do this. Don't do that," but I guess I'm trying to think if I should be more brisk about it... What I think I find is hard is I feel like I meet people who are... I had an engineer over for dinner the other day because we moved recently, and he has been an engineer for a decade and he said, "Suphatra, should I go to NoSQL because I don't want to learn anything over again." And he's like, "Which is the best one to go to because we're on AWS so I guess I should just use that. That's probably just easiest."
And I think that's often the decision making that happens for people. It's like, "What are we already doing?" I think it's actually pretty rare that an engineer gets to be in a position where they're at the very beginning and they're like, "Okay. We don't have a single database yet at all, so I'm going to choose which one we are going to start on." Most of the time, what I find is people are talking about a database migration because they arrived after something's already been built and now they're choosing whether or not to stay or go somewhere else.
In that case, it's like, "Okay. Now you're factoring in the cost of the migration, the cost of the re-host, replatform, refactor." And then the burden of that choice feels heavy because you're hoping that it's going to be permanent. That's where I say, "Hey, be portable because you're probably going to be making a database migration choice later down the road if you're a small company." If you're a large company, pay the overhead, don't worry about it. I feel that way with my kids. Some things, you just go a little bit bigger on like nice doctors because you're like, "Screw it. Pay an extra 100 bucks. I avoid more [inaudible] in the future." It's totally fine.
Jeremy: I actually think that's really interesting advice, and I'll be honest, I don't know if I 100% agree with it just because of my... And it's always good. Whenever I never disagree with a guest, I always feel like, "Well, we're just talking. We're basically, again, reiterating what each other said." I do get what you're saying and I think depending on what it is that you're building, that portability may be important, especially if you're building something internal or things like that.
But I do think that if you're building something that is consumer facing, that choosing the lowest common denominator right out the gate just because you might need that portability later, might not always be... Especially if it adds complexity, I would say, or it adds additional cost that you might not need initially. For me, that seems like something that you would have to weigh to say, "Do we really think we're going to need to move this or is it something that we can get away with for a while, and then if we happen to hit some stride where we're having some success and we have to think about migration," maybe that's a problem that comes up. I don't know. I think it's probably one of those, "It depends," type answers.
Suphatra: Yeah, and it seems a bit unfair too, because here I am giving the advice from the side of being the provider of the database and not actually being a customer ever. I've never been in a situation where I've had to buy a database, so that seems totally unfair. I feel like it'd be a really interesting thing. I'd love if anyone that's listening to this has any opinions to tweet to me and Jeremy what you think because I would love to know too... Because I definitely see it both ways and I really care about this too because I feel the pain of every person that I talk to who's in the middle of a database migration.
Jeremy: And that's very true.
Suphatra: Because I'm so excited about databases, I want them to be excited too. And I think for people who are still trying to explore the NoSQL world, so maybe that is a net new choice for them, the nice thing is they're so many free trials out there now that they can do that with almost no penalty or no burden. Yeah.
Jeremy: Well, I think the other thing you're going to run into is no matter what database you choose, which technology you choose, whether it's managed or hosted, whatever, you got to discover all kinds of things that you never knew. You're going to discover... That are going to be either welcomed or they're going to be like, "Oh, my goodness. Why did we make this choice?" I think with any technology, there's going to be trade-offs and you're going to have to find the right path for your business.
But I think for me, if I was recommending to any small company that wanted to, say, build a product in the cloud, I would just say, "Choose the things that let you prove it out as fast as possible. Get 80% of the way there, and if you prove out that model, then you go ahead and you can start building custom things that may be more tailored to your solution," but I know that's super general advice and it's one of those things where it's like, "Yeah, in a perfect world that works, but you always run into little things where you end up with other problems." But certainly don't want to be spending months of engineers' time trying to set up servers or anything like that that would potentially slow you down.
Suphatra: Yeah. This is a key business quandary for us here at Couchbase. I mean that's why we created Couchbase Cloud.
Jeremy: Oh, that's right. This just came out, Couchbase Cloud.
Suphatra: Yeah. Yep. So just came out, Couchbase Cloud. It's a fully managed cloud database and it's everything that Couchbase 6.5 provides. You've got the Eventing, full tech search, the multi-dimensional scaling. We've got Couchbase mobile, asset transactions, role base access controls... Oh, my god. I'm going to keep going on and on, built-in ..., service side Eventing. We've got all this stuff, but I think this is part of that business question of just like, "Well, okay. We know people definitely want Couchbase server, which is where they can just go buy it and they can put it on any cloud that they want." They want multi-cloud. They want private and then they want hybrid. We also created the the fully managed. Now you have every possible way to deploy Couchbase and I think what I'm going to be really interested to see is how these numbers shift in participation in those areas. I think that will give an idea as to what are people moving to. I'm sure you see it too, but I see in the news all the time, people saying, "Okay. Well, now it's going to be a move over to hybrid instead of going full public cloud." But I'd love to know what you think about that, if you think there's going to be a shift over to hybrid.
Jeremy: Yeah, I mean, listen, every application that I've built probably in the last two years has incorporated some sort of hybrid database technology. A lot of the operational things live on NoSQL or on DynamoDB as that operational side of things that you don't have to worry about throughput, and that becomes that source of truth, but things are either replicated into something like Kinesis Data Firehose, they get dumped into S3, they can be queried by Athena... Or some of it goes into an Aurora database or something like that where you have the ability to then run aggregations and some of these other things that don't need to run at the same scale as the operational side of things. I think this is something that people have been doing for quite some time now. Maybe I think people that are developing in the cloud are ahead of the curve in a sense because they're understanding that the scale becomes a real problem when you start to get a bit of usage.
And just from a cost standpoint too, I mean the on-demand side of things is incredibly flexible from a pricing standpoint in the early days. I mean I think if you really hit scale with some of these things, you're going to start to realize some of it's expensive, but you're also not paying a team of engineers to manage servers for you either. So I do think that that is the trend, but I'm really interested to see whether or not you have massive enterprises that have spent billions of dollars building these complex custom Oracle systems and have paid these consultants to come in for a year and a half and sometimes walk away with maybe not a lot to show for it, if you're going to see NoSQL technologies start really getting into the enterprise at an internal level and using NoSQL to do more complex things that maybe aren't customer facing, but is starting to replace some of these large... I don't if we would call them legacy, but some of these older ways of storing data.
Suphatra: Yeah, that's interesting. Like I said, Jeremy, you're a very smart guy. No, I think you're totally right. I think you're totally right, totally spot on on that. Yeah, I think that's something I'd love to, in a year, come back and see if our predictions panned out. But yeah, there's some sort of shift happening, it's surprising how many people are doing switchbacks. To me, it's mind-boggling too, because it just seems like an expensive endeavor to take on, but you have to be [inaudible] pretty high level frustration to say, "Oh, hey, I'm going to go back to where I was before." And there must be a pressing business reason, which I think there's not enough investigative journalism and research into that. Instead you see other stuff like, "Oh, who's going to get the Pentagon contract?" or "How much I paid on Azure, AWS, was insane," those kinds of things. But what I'm really curious about is why do people make that change back? Because the business reason there has got to be affecting more people than we realize, so if I find out, I will definitely let you know, Jeremy.
Jeremy: Yeah, that's actually something that I'm curious about. I think you see these very big contracts for AWS that get signed and obviously you hear complaints sometimes that the costs get ridiculous. You know what I mean? That the cost of running maybe DynamoDB at scale or some of these other things... Now again, some of that has to do with optimizations and I think people don't necessarily use some of these things the way they were intended to and maybe that's a pricing issue, but what are you thoughts on... Does this get to a point where maybe cost is the reason why people start migrating back?
Suphatra: I hate to say it, but yeah... I mean I don't think it's the technology, right? Like I said with Oracle, it's not the technology, I don't think, at Oracle.
Jeremy: Right.
Suphatra: I don't hear people complaining about the tech, it's more the business practices and that's why I liken something like AWS to Target, which everyone loves Target. There's nothing wrong with Target. It's just that when you're in that environment, it encourages you to spend a little bit more than you should. And then I think with Azure, it's that opposite problem where you feel like you're paying more than you're spending. I don't know if there's going to be... There's no perfect answer, but I will say that I think the deals are really important here. With enterprises, they get their own dedicated sales teams, they're negotiating very specific deals... And then these guys are very aggressive. They're going head to head often so they're trying to undercut each other in those deals.
Jeremy: Right.
Suphatra: I'm sure that they can make compelling offers to do a switch or a switchback. Service is also really important, so if you've just signed a huge migration to one provider and then you're not getting the quality of service that you need to really maintain or improve on the infrastructure that you've built with them, then you might feel like, "You know what? We don't want to make a long term investment with you if you're not making a long term investment in us." That's another reason I think I've seen people move, is they say, "I don't think your service teams care about us." Another is competition. I think that is why some of the database companies have enjoyed a lot of growth is because a lot of... In the retail space, because a lot of retailers just will not work on AWS infrastructure, right?
Jeremy: Yeah, right.
Suphatra: Because they say, "Well, Amazon is just edging us out."
Jeremy: Well, they say they don't say that, but I think we know that they do.
Suphatra: Yeah, right? It makes sense. Amazon is completely edging out their business. They're not going to go and they know that AWS is paying for and supporting the rest of that business, so they're not going to go on that.
Jeremy: Right. Let me move on to one more thing. I think a lot of people are interested in what it's like to work for Microsoft and Google and AWS and some of these other big companies. Obviously, you have experience working with Microsoft. You were there for 10 years, I think, and you were with AWS for a bit of time. I don't know, maybe you could share just what was it like? What was it like working with those two different organizations?
Suphatra: Yeah, I feel so lucky and blessed to get that opportunity and just really great experiences at both. I have so many friends from both places and I would happily work at both of those places again... Really great experiences. And I think there's a lot of misconceptions about both of those places, especially Amazon, and it's unfortunate because I think that Amazon is a really special place to work. It's difficult in the sense where the people are incredibly smart. Anyone that you're working with at Amazon is just top-notch, really smart. Hiring process is very difficult, it's a very difficult filter to get through so you're really getting some of the best, smartest people in your industry in the world. There wasn't a day at Amazon where I didn't feel intellectually challenged and that's just really fun. And same with Microsoft, Microsoft has some of the smartest people in the world as well and Microsoft is more global in a sense, and so you're really working with the smartest people literally all over the world. But Amazon, they're smart in a different way. There's a saying at Microsoft that the loudest person in the room wins because Microsoft has a bit of a bullish culture where presentations are made with PowerPoints and people have big personalities. Bill Gates built his little empire there in a way where it was just traditional 80s, 90s business culture back then.
But Amazon's very different, it's a written culture, so to succeed at Amazon, you need to be a really good writer. The best writer in the room wins. Amazon has a very strict document culture, so you write these six-page documents which are one-inch margins, single space, no pictures, no graphs, with an appendix at the end, and it has to be just a business case of why you want to do the thing you want to do... And that's for anything. That's for a website change, that's for a new program, that's to add something. I mean you really spend a lot of your time writing these business proposals, business memos, and what that does, it causes you to really think very thoroughly how what you're proposing to do is going to benefit the customer. I would say what the retail side, Amazon.com, culture brought over to AWS is really beneficial, which is this customer first mentality... With a little bit of differences, AWS is obviously a little more competitor focused. You see a lot of focus on Oracle and Microsoft, more so than what you see the retail side does.
The downsides of working at Amazon is because it is a written culture, it's actually a very introverted culture, very quiet. It's funny because Microsoft's very gregarious, full of people, everyone's visiting and flying in and you go to fun parties. I remember my third week into Amazon and I was on LinkedIn and my old coworkers at Microsoft were literally posting selfies with Will Smith.
And I'm sitting in Amazon where it's just quiet. All you can hear are dogs because everyone brings their dog in and the dogs are making more noise than the people. We're all just working and typing up our memos, and here my buddies at Microsoft are just posing with Will Smith. So it's really a truly difference in culture and it's a very introverted culture. If anyone stayed for more than four years are likely a very serious written, introverted person... And that can be a little nerve-wracking for some folks. People do not like that. I've heard people say, "Oh, well, I've heard that Amazon makes you cry at your desk."
Jeremy: What?
Suphatra: You know that New York Times article that said people were crying at their desk all the time at Amazon and living in their cars?
Jeremy: Oh, yeah, yeah, yeah.
Suphatra: I never met someone living their car at Amazon or even sleeping in the office, I will say. And I thought that there was very good balance, people were able to get home to their families. The people are really passionate about the work, so I think it's a really, really great place. It's not for everyone. It is very difficult, so I would say that, but work can be difficult. And I will say it's funny because Amazon's known for being an entrepreneurial culture, but I would say that's the one thing I didn't find it to be. I did not find it to be very entrepreneurial actually. I found the very top management sort of allowed that kind of entrepreneurialism, but for the most part, if you're below those ranks, the work is very tight. Your swim lane is very narrow, so it is run very much like the retail side, which is almost like a supply chain where you have your role. You do your role. This is what you do. You have to excel at that and do it at max speed. It's very, very efficient.
Microsoft's different. You could come up with some sort of crazy idea. They'll give you a million dollars, you can go and do it. And they're like, "Hey, we should bring Will Smith in for the staff meeting." They'll do it. So it's really, really different. It's just different at Microsoft. Microsoft's just been around longer and it's all over the world and they've got big parts of their business that just print money, Windows, Office Suite-
Jeremy: Yeah, of course.
Suphatra: Prints money without really having to do too much for that, and most people don't know, but Microsoft's number one customer... I would love for you to guess, what do you think Microsoft's number one customer customer is?
Jeremy: Is it the U.S. government?
Suphatra: It is governments.
Jeremy: Governments in general.
Suphatra: Governments... It's not a consumer. It's not consumers and it's not businesses. It's governments and when you get a government contract, you are in that country for a decade or more.
Jeremy: Yeah.
Suphatra: I remember at Microsoft working on something that was for North Dakota. We are in every single kindergarten through graduate school... Is running Windows and Office for the next 12 years.
Jeremy: Wow.
Suphatra: I mean when you get contracts like that, like I said, Microsoft likes... You pay the premium, you get everything you want, but you pay for the full buffet. But the nice thing when you work there, it's a very different, lush culture and I think people at Amazon would say, "Oh, well, Microsoft's a country club." It's kind of true, a little true... But then people at Microsoft would say, "Well, everyone at Amazon's crying at their desk." Not totally true, but it's a very difficult work culture, so there's a lot of trade-off.
Jeremy: Well, I've always thought it was very generous of companies like Apple and Microsoft to donate computers and technology to schools, but then when you think about it, the more cynical side of you say, "Well, they're just educating consumers," right? They're just grooming consumers for when they graduate and go to work which devices they're going to choose. I know a lot of people who work at Amazon and I've heard similar things. I mean I think that people enjoy the work that they do like you said and they're very passionate about it, but I think the bottom line is if you like dogs, work at Amazon. If you like Will Smith, work at Microsoft. All right. We've been talking for a while so why don't we wrap this up? But listen, Suphatra, thank you so much for being here. If people want to find out more about you, how do they do that?
Suphatra: You can tweet me on Twitter. My Twitter is SKPRUFO. I'm really active over there. I would love to hear from you. I would love to hear what you thought about what I shared today. I love to hear your opinions and your thoughts because I'm always trying to get more information from customers and users and developers to help better inform my ideas and my opinions, so I'd really love to hear from you. Come and tweet, "Hi," to me.
Jeremy: And if you want to check out more about Couchbase and the new Couchbase Cloud, you just Couchbase.com, right?
Suphatra: Yes, Couchbase Cloud, we just launched it recently, so please go check it out. It's fully managed cloud database for your server folks. It's got all the service side Eventing you're going to ever want. And I really appreciate, Jeremy, the chance to talk with you. You're such a cool guy and I love this podcast.
Jeremy: Oh, thank you.
Suphatra: Everybody loves this podcast, so thank you so much.
Jeremy: Well, I appreciate that and the next time we bump into one another, we'll hit up the seafood buffet and we will continue this conversation.
Suphatra: Thanks. Thanks, Jeremy.