(upbeat music) >> Welcome back to Supercloud 2 this is Dave Vellante. We're here exploring the intersection of data and analytics and the future of cloud. And in this segment, we're going to look at the evolution of cloud, and try to test some of the Supercloud concepts and assumptions with Brian Gracely, is the founder and co-host along with Aaron Delp of the popular Cloudcast program. Amazing series, if you're not already familiar with it. The Cloudcast is one of the best ways to keep up with so many things going on in our industry. Enterprise tech, platform engineering, business models, obviously, cloud developer trends, crypto, Web 3.0. Sorry Brian, I know that's a sore spot, but Brian, thanks for coming >> That's okay. >> on the program, really appreciate it. >> Yeah, great to be with you, Dave. Happy New Year, and great to be back with everybody with SiliconANGLE again this year. >> Yeah, we love having you on. We miss working with you day-to-day, but I want to start with Gracely's theorem, which basically says, I'm going to paraphrase. For the most part, nothing new gets introduced in the enterprise tech business, patterns repeat themselves, maybe get applied in new ways. And you know this industry well, when something comes out that's new, if you take virtualization, for example, been around forever with mainframes, but then VMware applied it, solve a real problem in the client service system. And then it's like, "Okay, this is awesome." We get really excited and then after a while we pushed the architecture, we break things, introduce new things to fix the things that are broken and start adding new features. And oftentimes you do that through acquisitions. So, you know, has the cloud become that sort of thing? And is Supercloud sort of same wine, new bottle, following Gracely's theorem? >> Yeah, I think there's some of both of it. I hate to be the sort of, it depends sort of answer but, I think to a certain extent, you know, obviously Cloud in and of itself was, kind of revolutionary in that, you know, it wasn't that you couldn't rent things in the past, it was just being able to do it at scale, being able to do it with such amazing self-service. And then, you know, kind of proliferation of like, look at how many services I can get from, from one cloud, whether it was Amazon or Azure or Google. And then, you know, we, we slip back into the things that we know, we go, "Oh, well, okay, now I can get computing on demand, but, now it's just computing." Or I can get database on demand and it's, you know, it's got some of the same limitations of, of say, of database, right? It's still, you know, I have to think about IOPS and I have to think about caching, and other stuff. So, I think we do go through that and then we, you know, we have these sort of next paradigms that come along. So, you know, serverless was another one of those where it was like, okay, it seems sort of new. I don't have to, again, it was another level of like, I don't have to think about anything. And I was able to do that because, you know, there was either greater bandwidth available to me, or compute got cheaper. And what's been interesting is not the sort of, that specific thing, serverless in and of itself is just another way of doing compute, but the fact that it now gets applied as, sort of a no-ops model to, you know, again, like how do I provision a database? How do I think about, you know, do I have to think about the location of a service? Does that just get taken care of for me? So I think the Supercloud concept, and I did a thing and, and you and I have talked about it, you know, behind the scenes that maybe the, maybe a better name is Super app for something like Snowflake or other, but I think we're, seeing these these sort of evolutions over and over again of what were the big bottlenecks? How do we, how do we solve those bottlenecks? And I think the big thing here is, it's never, it's very rarely that you can take the old paradigm of what the thing was, the concept was, and apply it to the new model. So, I'll just give you an example. So, you know, something like VMware, which we all know, wildly popular, wildly used, but when we apply like a Supercloud concept of VMware, the concept of VMware has always been around a cluster, right? It's some finite number of servers, you sort of manage it as a cluster. And when you apply that to the cloud and you say, okay, there's, you know, for example, VMware in the cloud, it's still the same concept of a cluster of VMware. But yet when you look at some of these other services that would fit more into the, you know, Supercloud kind of paradigm, whether it's a Snowflake or a MongoDB Atlas or maybe what CloudFlare is doing at the edge, those things get rid of some of those old paradigms. And I think that's where stuff, you start to go, "Oh, okay, this is very different than before." Yes, it's still computing or storage, or data access, but there's a whole nother level of something that we didn't carry forward from the previous days. And that really kind of breaks the paradigm. And so that's the way I think I've started to think about, are these things really brand new? Yes and no, but I think it's when you can see that big, that thing that you didn't leave behind isn't there anymore, you start to get some really interesting new innovation come out of it. >> Yeah. And that's why, you know, lift and shift is okay, when you talk to practitioners, they'll say, "You know, I really didn't change my operating model. And so I just kind of moved it into the cloud. there were some benefits, but it was maybe one zero not three zeros that I was looking for." >> Right. >> You know, we always talk about what's great about cloud, the agility, and all the other wonderful stuff that we know, what's not working in cloud, you know, tie it into multi-cloud, you know, in terms of, you hear people talk about multi-cloud by accident, okay, that's true. >> Yep. >> What's not great about cloud. And then I want to get into, you know, is multi-cloud really a problem or is it just sort of vendor hype? But, but what's not working in cloud? I mean, you mentioned serverless and serverless is kind of narrow, right, for a lot of stateless apps, right? But, what's not great about cloud? >> Well, I think there's a few things that if you ask most people they don't love about cloud. I think, we can argue whether or not sort of this consolidation around a few cloud providers has been a good thing or a bad thing. I think, regardless of that, you know, we are seeing, we are hearing more and more people that say, look, you know, the experience I used to have with cloud when I went to, for example, an Amazon and there was, you know, a dozen services, it was easy to figure out what was going on. It was easy to figure out what my billing looked like. You know, now they've become so widespread, the number of services they have, you know, the number of stories you just hear of people who went, "Oh, I started a service over in US West and I can't find it anymore 'cause it's on a different screen. And I, you know, I just got billed for it." Like, so I think the sprawl of some of the clouds has gotten, has created a user experience that a lot of people are frustrated with. I think that's one thing. And we, you know, we see people like Digital Ocean and we see others who are saying, "Hey, we're going to be that simplified version." So, there's always that yin and yang. I think people are super frustrated at network costs, right? So, you know, and that's kind of at a lot of, at the center of maybe why we do or don't see more of these Supercloud services is just, you know, in the data center as an application owner, I didn't have to think about, well where, where does this go to? Where are my users? Yes, somebody took care of it, but when those things become front and center, that's super frustrating. That's the one area that we've seen absolutely no cost savings, cost reduction. So I think that frustrates people a lot. And then I think the third piece is just, you know, we're, we went from super centralized IT organizations, which, you know, for decades was how it worked. It was part of the reason why the cloud expanded and became a thing, right? Sort of shadow IT and I can't get things done. And then, now what we've seen is sort of this proliferation of little pockets of groups that are your IT, for lack of a better thing, whether they're called platform engineering or SRE or DevOps. But we have this, expansion, explosion if you will, of groups that, if I'm an app dev team, I go, "Hey, you helped me make this stuff run, but then the team next to you has another group and they have another group." And so you see this explosion of, you know, we don't have any standards in the company anymore. And, so sort of self-service has created its own nightmare to a certain extent for a lot of larger companies. >> Yeah. Thank you for that. So, you know, I want, I want to explore this multi-cloud, you know, by accident thing and is a real problem. You hear that a lot from vendors and we've been talking about Supercloud as this unifying layer across cloud. You know, but when you talk to customers, a lot of them are saying, "Yes, we have multiple clouds in our organization, but my group, we have mono cloud, we know the security, edicts, we know how to, you know, deal with the primitives, whether it's, you know, S3 or Azure Blob or whatever it is. And we're very comfortable with this." It's, that's how we're simplifying. So, do you think this is really a problem? Does it have merit that we need that unifying layer across clouds, or is it just too early for that? >> I think, yeah, I think what you, what you've laid out is basically how the world has played out. People have picked a cloud for a specific application or a series of applications. Yeah, and I think if you talk to most companies, they would tell you, you know, holistically, yes, we're multi-cloud, not, maybe not necessarily on, I don't necessarily love the phrase where people say like, well it happened by accident. I think it happened on purpose, but we got to multi-cloud, not in the way that maybe that vendors, you know, perceived, you know, kind of laid out a map for. So it was, it was, well you will lay out this sort of Supercloud framework. We didn't call it that back then, we just called it sort of multi-cloud. Maybe it was Kubernetes or maybe it was whatever. And different groups, because central IT kind of got disbanded or got fragmented. It turned into, go pick the best cloud for your application, for what you need to do for the business. And then, you know, multiple years later it was like, "Oh, hold on, I've got 20% in Google and 50% in AWS and I've got 30% in Azure. And, you know, it's, yeah, it's been evolution. I don't know that it's, I don't know if it's a mistake. I think it's now groups trying to figure out like, should I make sense of it? You know, should I try and standardize and I backwards standardize some stuff? I think that's going to be a hard thing for, for companies to do. 'cause I think they feel okay with where the applications are. They just happen to be in multiple clouds. >> I want to run something by you, and you guys, you and Aaron have talked about this. You know, still depending on who, which keynote you listen to, small percentage of the workloads are actually in cloud. And when you were with us at Wikibon, I think we called it true private cloud, and we looked at things like Nutanix and there were a lot of other examples of companies that were trying to replicate the hyperscale experience on Prem. >> Yeah. >> And, we would evaluate that, you know, beyond virtualization, and so we sort of defined that and, but I think what's, maybe what's more interesting than Supercloud across clouds is if you include that, that on Prem estate, because that's where most of the work is being done, that's where a lot of the proprietary tools have been built, a lot of data, a lot of software. So maybe there's this concept of sending that true private cloud to true hybrid cloud. So I actually think hybrid cloud in some cases is the more interesting use case for so-called Supercloud. What are your thoughts on that? >> Yeah, I think there's a couple aspects too. I think, you know, if we were to go back five or six years even, maybe even a little further and look at like what a data center looked like, even if it was just, "Hey we're a data center that runs primarily on VMware. We use some of their automation". Versus what you can, even what you can do in your data center today. The, you know, the games that people have seen through new types of automation through Kubernetes, through get ops, and a number of these things, like they've gotten significantly further along in terms of I can provision stuff really well, I can do multi-tenancy, I can do self-service. Is it, you know, is it still hard? Yeah. Because those things are hard to do, but there's been significant progress there. I don't, you know, I still look for kind of that, that killer application, that sort of, you know, lighthouse use case of, hybrid applications, you know, between data center and between cloud. I think, you know, we see some stuff where, you know, backup is a part of it. So you use the cloud for storage, maybe you use the cloud for certain kinds of resiliency, especially on maybe front end load balancing and stuff. But I think, you know, I think what we get into is, this being hung up on hybrid cloud or multi-cloud as a term and go like, "Look, what are you trying to measure? Are you trying to measure, you know, efficiency of of of IT usage? Are you trying to measure how quickly can I give these business, you know, these application teams that are part of a line of business resources that they need?" I think if we start measuring that way, we would look at, you know, you'd go, "Wow, it used to be weeks and months. Now we got rid of these boards that have to review everything every time I want to do a change management type of thing." We've seen a lot more self-service. I think those are the things we want to measure on. And then to your point of, you know, where does, where do these Supercloud applications fit in? I think there are a bunch of instances where you go, "Look, I have a, you know, global application, I have a thing that has to span multiple regions." That's where the Supercloud concept really comes into play. We used to do it in the data center, right? We'd had all sorts of technologies to help with that, I think you can now start to do it in the cloud. >> You know, one of the other things, trying to understand, your thoughts on this, do you think that you, you again have talked about this, like I'm with you. It's like, how is it that Google's losing, you know, 3 billion dollars a year, whatever. I mean, because when you go back and look at Amazon, when they were at that level of revenue where Google is today, they were making money, you know, and they were actually growing faster, by the way. So it's kind of interesting what's happened with Google. But, the reason I bring that up is, trying to understand if you think the hyperscalers will ever be motivated to create standards across clouds, and that may be a play for Google. I mean, obviously with Kubernetes it was like a Hail Mary and kind of made them relevant. Where would Google be without Kubernetes? But then did it achieve the objectives? We could have that conversation some other time, but do you think the hyperscalers will actually say, "Okay, we're going to lean in and create these standards across clouds." Because customers would love that, I would think, but it would sub-optimize their competitive advantage. What are your thoughts? >> I think, you know, on the surface, I would say they, they probably aren't. I think if you asked 'em the question, they would say, "Well, you know, first and foremost, you know, we do deliver standards, so we deliver a, you know, standard SQL interface or a SQL you know, or a standard Kubernetes API or whatever. So, in that, from that perspective, you know, we're not locking you into, you know, an Amazon specific database, or a Google specific database." You, you can argue about that, but I think to a certain extent, like they've been very good about, "Hey, we're going to adopt the standards that people want." A lot of times the open source standards. I think the problem is, let's say they did come up with a standard for it. I think you still have the problem of the costs of migration and you know, the longer you've, I think their bet is basically the longer you've been in some cloud. And again, the more data you sort of compile there, the data gravity concept, there's just going to be a natural thing that says, okay, the hurdle to get over to say, "Look, we want to move this to another cloud", becomes so cost prohibitive that they don't really have to worry about, you know, oh, I'm going to get into a war of standards. And so far I think they sort of realize like that's the flywheel that the cloud creates. And you know, unless they want to get into a world where they just cut bandwidth costs, like it just kind of won't happen. You know, I think we've even seen, and you know, the one example I'll use, and I forget the name of it off the top of my head, but there's a, there's a Google service. I think it's like BigQuery external or something along those lines, that allows you to say, "Look, you can use BigQuery against like S3 buckets and against other stuff." And so I think the cloud providers have kind of figured out, I'm never going to get the application out of that other guy's cloud or you know, the other cloud. But maybe I'm going to have to figure out some interesting ways to sort of work with it. And, you know, it's a little bit, it's a little janky, but that might be, you know, a moderate step that sort of gets customers where they want to be. >> Yeah. Or you know, it'd be interesting if you ever see AWS for example, running its database in other clouds, you started, even Oracle is doing that with, with with Azure, which is a form of Supercloud. My last question for you is, I want to get you thinking about sort of how the future plays out. You know, think about some of the companies that we've put forth this Supercloud, and by the way, this has been a criticism of the concept. Charles Fitzer, "Everything is Supercloud!" Which if true would defeat the purpose of course. >> Right. >> And so right with the community effort, we really tried to put some guardrails down on the essential characteristics, the deployment models, you know, so for example, running across multiple clouds with a purpose build pass, creating a common experience, metadata intelligence that solves a specific problem. I mean, the example I often use is Snowflake's governed data sharing. But yeah, Snowflake, Databricks, CloudFlare, Cohesity, you know, I just mentioned Oracle and Azure, these and others, they certainly claim to have that common experience across clouds. But my question is, again, I come back to, do customers need this capability? You know, is Mono Cloud the way to solve that problem? What's your, what are your thoughts on how this plays out in the future of, I guess, PAs, apps and cloud? >> Yeah, I think a couple of things. So, from a technology perspective, I think, you know, the companies you name, the services you've named, have sort of proven that the concept is viable and it's viable at a reasonable size, right? These aren't completely niche businesses, right? They're multi-billion dollar businesses. So, I think there's a subset of applications that, you know, maybe a a bigger than a niche set of applications that are going to use these types of things. A lot of what you talked about is very data centric, and that's, that's fine. That's that layer is, figuring that out. I think we'll see messaging types of services, so like Derek Hallison's, Caya Company runs a, sort of a Supercloud for messaging applications. So I think there'll be places where it makes a ton of sense. I think, the thing that I'm not sure about, and because again, we've been now 10 plus years of sort of super low, you know, interest rates in terms of being able to do things, is a lot of these things come out of research that have been done previously. Then they get turned into maybe somewhat of an open source project, and then they can become something. You know, will we see as much investment into the next Snowflake if, you know, the interest rates are three or four times that they used to be, do we, do we see VCs doing it? So that's the part that worries me a little bit, is I think we've seen what's possible. I think, you know, we've seen companies like what those services are. I think I read yesterday Snowflake was saying like, their biggest customers are growing at 30, like 50 or 60%. Like the, value they get out of it is becoming exponential. And it's just a matter of like, will the economics allow the next big thing to happen? Because some of these things are pretty, pretty costly, you know, expensive to get started. So I'm bullish on the idea. I don't know that it becomes, I think it's okay that it's still sort of, you know, niche plus, plus in terms of the size of it. Because, you know, if we think about all of IT it's still, you know, even microservices is a small part of bigger things. But I'm still really bullish on the idea. I like that it's been proven. I'm a little wary, like a lot of people have the economics of, you know, what might slow things down a little bit. But yeah, I, think the future is going to involve Supercloud somewhere, whatever people end up calling it. And you and I discussed that. (laughs) But I don't, I don't think it goes away. I don't think it's, I don't think it's a fad. I think it is something that people see tremendous value and it's just, it's got to be, you know, for what you're trying to do, your application specific thing. >> You're making a great point on the funding of innovation and we're entering a new era of public policy as well. R and D tax credit is now is shifting. >> Yeah. >> You know, you're going to have to capitalize that over five years now. And that's something that goes back to the 1950s and many people would argue that's at least in part what has helped the United States be so, you know, competitive in tech. But Brian, always great to talk to you. Thanks so much for participating in the program. Great to see you. >> Thanks Dave, appreciate it. Good luck with the rest of the show. >> Thank you. All right, this is Dave Vellante for John Furrier, the entire Cube community. Stay tuned for more content from Supercloud2.

(bright upbeat music) >> Welcome back, everyone, to the "Supercloud 22." I'm John Furrier, host of "The Cube." This is the Cloud-erati panel, the distinguished experts who have been there from day one, watching the cloud grow, from building clouds, and all open source stuff as well. Just great stuff. Good friends of "The Cube," and great to introduce back on "The Cube," Adrian Cockcroft, formerly with Netflix, formerly AWS, retired, now commentating here in "The Cube," as well as other events. Great to see you back out there, Adrian. Lori MacVittie, Cloud Evangelist with F5, also wrote a great blog post on supercloud, as well as Dave Vellante as well, setting up the supercloud conversation, which we're going to get into, and Chris Hoff, who's the CTO and CSO of LastPass who's been building clouds, and we know him from "The Cube" before with security and cloud commentary. Welcome, all, back to "The Cube" and supercloud. >> Thanks, John. >> Hi. >> All right, Lori, we'll start with you to get things going. I want to try to sit back, as you guys are awesome experts, and involved from building, and in the trenches, on the front lines, and Adrian's coming out of retirement, but Lori, you wrote the post setting the table on supercloud. Let's start with you. What is supercloud? What is it evolving into? What is the north star, from your perspective? >> Well, I don't think there's a north star yet. I think that's one of the reasons I wrote it, because I had a clear picture of this in my mind, but over the past, I don't know, three, four years, I keep seeing, in research, my own and others', complexity, multi-cloud. "We can't manage it. They're all different. "We have trouble. What's going on? "We can't do anything right." And so digging into it, you start looking into, "Well, what do you mean by complexity?" Well, security. Migration, visibility, performance. The same old problems we've always had. And so, supercloud is a concept that is supposed to overlay all of the clouds and normalize it. That's really what we're talking about, is yet another abstraction layer that would provide some consistency that would allow you to do the same security and monitor things correctly. Cornell University actually put out a definition way back in 2016. And they said, "It's an architecture that enables migration "across different zones or providers," and I think that's important, "and provides interfaces to everything, "makes it consistent, and normalizes the network," basically brings it all together, but it also extends to private clouds. Sometimes we forget about that piece of it, and I think that's important in this, so that all your clouds look the same. So supercloud, big layer on top, makes everything wonderful. It's unicorns again. >> It's interesting. We had multiple perspectives. (mumbles) was like Snowflake, who built on top of AWS. Jerry Chan, who we heard from earlier today, Greylock Penn's "Castles in the Cloud" saying, "Hey, you can have a moat, "you can build an advantage and have differentiation," so startups are starting to build on clouds, that's the native cloud view, and then, of course, they get success and they go to all the other clouds 'cause they got customers in the ecosystem, but it seems that all the cloud players, Chris, you commented before we came on today, is that they're all fighting for the customer's workloads on their infrastructure. "Come bring your stuff over to here, "and we'll make it run better." And all your developers are going to be good. Is there a problem? I mean, or is this something else happening here? Is there a real problem? >> Well, I think the north star's over there, by the way, Lori. (laughing) >> Oh, there it is. >> Right there. The supercloud north star. So indeed I think there are opportunities. Whether you call them problems or not, John, I think is to be determined. Most companies have, especially if they're a large enterprise, whether or not they've got an investment in private cloud or not, have spent time really trying to optimize their engineering and workload placement on a single cloud. And that, regardless of your choice, as we take the big three, whether it's Amazon, Google, or Microsoft, each of them have their pros and cons for various types of workloads. And so you'll see a lot of folks optimizing for a particular cloud, and it takes a huge effort up and down the stack to just get a single cloud right. That doesn't take into consideration integrations with software as a service, instantiated, oftentimes, on top of infrastructure of the service that you need to supplement where the obstruction layer ends in infrastructure of the service. You've seen most IS players starting to now move up-chain, as we predicted years ago, to platform as a service, but platforms of various types. So I definitely see it as an opportunity. Previous employers have had multiple clouds, but they were very specifically optimized for the types of workloads, for example, in, let's say, AWS versus GCP, based on the need for different types and optimized compute platforms that each of those providers ran. We never, in that particular case, thought about necessarily running the same workloads across both clouds, because they had different pricing models, different security models, et cetera. And so the challenge is really coming down to the fact that, what is the cost benefit analysis of thinking about multi-cloud when you can potentially engineer the resiliency or redundancy, all the in-season "ilities" that you might need to factor into your deployments on a single cloud, if they are investing at the pace in which they are? So I think it's an opportunity, and it's one that continues to evolve, but this just reminds me, your comments remind me, of when we were talking about OpenStack versus AWS. "Oh, if there were only APIs that existed "that everybody could use," and you saw how that went. So I think that the challenge there is, what is the impetus for a singular cloud provider, any of the big three, deciding that they're going to abstract to a single abstraction layer and not be able to differentiate from the competitors? >> Yeah, and that differentiation's going to be big. I mean, assume that the clouds aren't going to stay still like AWS and just not stop innovating. We see the devs are doing great, Adrian, open source is bigger and better than ever, but now that's been commercialized into enterprise. It's an ops problem. So to Chris's point, the cost benefit analysis is interesting, because do companies have to spin up multiple operations teams, each with specialized training and tooling for the clouds that they're using, and does that open up a can of worms, or is that a good thing? I mean, can you design for this? I mean, is there an architecture or taxonomy that makes it work, or is it just the cart before the horse, the solution before the problem? >> Yeah, well, I think that if you look at any large vendor... Sorry, large customer, they've got a bit of everything already. If you're big enough, you've bought something from everybody at some point. So then you're trying to rationalize that, and trying to make it make sense. And I think there's two ways of looking at multi-cloud or supercloud, and one is that the... And practically, people go best of breed. They say, "Okay, I'm going to get my email "from Google or Microsoft. "I'm going to run my applications on AWS. "Maybe I'm going to do some AI machine learning on Google, "'cause those are the strengths of the platforms." So people tend to go where the strength is. So that's multi-cloud, 'cause you're using multiple clouds, and you still have to move data and make sure they're all working together. But then what Lori's talking about is trying to make them all look the same and trying to get all the security architectures to be the same and put this magical layer, this unicorn magical layer that, "Let's make them all look the same." And this is something that the CIOs have wanted for years, and they keep trying to buy it, and you can sell it, but the trouble is it's really hard to deliver. And I think, when I go back to some old friends of ours at Enstratius who had... And back in the early days of cloud, said, "Well, we'll just do an API that abstracts "all the cloud APIs into one layer." Enstratius ended up being sold to Dell a few years ago, and the problem they had was that... They didn't have any problem selling it. The problem they had was, a year later, when it came up for renewal, the developers all done end runs around it were ignoring it, and the CIOs weren't seeing usage. So you can sell it, but can you actually implement it and make it work well enough that it actually becomes part of your core architecture without, from an operations point of view, without having the developers going directly to their favorite APIs around them? And I'm not sure that you can really lock an organization down enough to get them onto a layer like that. So that's the way I see it. >> You just defined- >> You just defined shadow shadow IT. (laughing) That's pretty- (crosstalk) >> Shadow shadow IT, yeah. >> Yeah, shadow shadow it. >> Yeah. >> Yeah. >> I mean, this brings up the question, I mean, is there really a problem? I mean, I guess we'll just jump to it. What is supercloud? If you can have the magic outcome, what is it? Enstratius rendered in with automation? The security issues? Kubernetes is hot. What is the supercloud dream? I guess that's the question. >> I think it's got easier than it was five, 10 years ago. Kubernetes gives you a bunch of APIs that are common across lots of different areas, things like Snowflake or MongoDB Atlas. There are SaaS-based services, which are across multiple clouds from vendors that you've picked. So it's easier to build things which are more portable, but I still don't think it's easy to build this magic API that makes them all look the same. And I think that you're going to have leaky abstractions and security being... Getting the security right's going to be really much more complex than people think. >> What about specialty superclouds, Chris? What's your view on that? >> Yeah, I think what Adrian is alluding to, those leaky abstractions, are interesting, especially from the security perspective, 'cause I think what you see is if you were to happen to be able to thin slice across a set of specific types of workloads, there is a high probability given today that, at least on two of the three major clouds, you could get SaaS providers that sit on those same infrastructure of the service clouds for you, string them together, and have a service that technically is abstracted enough from the things you care about to work on one, two, or three, maybe not all of them, but most SaaS providers in the security space, or identity space, data space, for example, coexist on at least Microsoft and AWS, if not all three, with Google. And so you could technically abstract a service to the point that you let that level of abstract... Like Lori said, no computer science problem could not be... So, no computer science problem can't be solved with more layers of abstraction or misdirection... Or redirection. And in that particular case, if you happen to pick the right vendors that run on all three clouds, you could possibly get close. But then what that really talks about is then, if you built your seven-layer dip model, then you really have specialty superclouds spanning across infrastructure of the service clouds. One for your identity apps, one for data and data layers, to normalize that, one for security, but at what cost? Because you're going to be charged not for that service as a whole, but based on compute resources, based on how these vendors charge across each cloud. So again, that cost-benefit ratio might start being something that is rather imposing from a budgetary perspective. >> Lori, weigh in on this, because the enterprise people love to solve complexity with more complexity. Here, we need to go the other way. It's a commodity. So there has to be a better way. >> I think I'm hearing two fundamental assumptions. One, that a supercloud would force the existing big three to implement some sort of equal API. Don't agree with that. There's no business case for that. There's no reason that could compel them to do that. Otherwise, we would've convinced them to do that, what? 10, 15 years ago when we said we need to be interoperable. So it's not going to happen there. They don't have a good reason to do that. There's no business justification for that. The other presumption, I think, is that we would... That it's more about the services, the differentiated services, that are offered by all of these particular providers, as opposed to treating the core IaaS as the commodity it is. It's compute, it's some storage, it's some networking. Look at that piece. Now, pull those together by... And it's not OpenStack. That's not the answer, it wasn't the answer, it's not the answer now, but something that can actually pull those together and abstract it at a different layer. So cloud providers don't have to change, 'cause they're not going to change, but if someone else were to build that architecture to say, "all right, I'm going to treat all of this compute "so you can run your workloads," as Chris pointed out, "in the best place possible. "And we'll help you do that "by being able to provide those cost benefit analysis, "'What's the best performance, what are you doing,' "And then provide that as a layer." So I think that's really where supercloud is going, 'cause I think that's what a lot of the market actually wants in terms of where they want to run their workloads, because we're seeing that they want to run workloads at the edge, "a lot closer to me," which is yet another factor that we have to consider, and how are you going to be moving individual workloads around? That's the holy grail. Let's move individual workloads to where they're the best performance, the security, cost optimized, and then one layer up. >> Yeah, I think so- >> John Considine, who ultimately ran CloudSwitch, that sold to Verizon, as well as Tom Gillis, who built Bracket, are both rolling in their graves, 'cause what you just described was exactly that. (Lori laughing) Well, they're not even dead yet, so I can't say they're rolling in their graves. Sorry, Tom. Sorry, John. >> Well, how do hyperscalers keep their advantage with all this? I mean, to that point. >> Native services and managed services on top of it. Look how many flavors of managed Kubernetes you have. So you have a choice. Roll your own, or go with a managed service, and then differentiate based on the ability to take away and simplify some of that complexity. Doesn't mean it's more secure necessarily, but I do think we're seeing opportunities where those guys are fighting tooth and nail to keep you on a singular cloud, even though, to Lori's point, I agree, I don't think it's about standardized APIs, 'cause I think that's never going to happen. I do think, though, that SaaS-y supercloud model that we were talking about, layering SaaS that happens to span all the three infrastructure of the service are probably more in line with what Lori was talking about. But I do think that portability of workload is given to you today within lots of ways. But again, how much do you manage, and how much performance do you give up by running additional abstraction layers? And how much security do you give up by having to roll your own and manage that? Because the whole point was, in many cases... Cloud is using other people's computers, so in many cases, I want to manage as little of it as I possibly can. >> I like this whole SaaS angle, because if you had the old days, you're on Amazon Web Services, hey, if you build a SaaS application that runs on Amazon, you're all great, you're born in the cloud, just like that generations of startups. Great. Now when you have this super pass layer, as Dave Vellante was riffing on his analysis, and Lori, you were getting into this pass layer that's kind of like SaaS-y, what's the SaaS equation look like? Because that, to me, sounds like a supercloud version of saying, "I have a workload that runs on all the clouds equally." I just don't think that's ever going to happen. I agree with you, Chris, on that one. But I do see that you can have an abstraction that says, "Hey, I don't really want to get in the weeds. "I don't want to spend a lot of ops time on this. "I just want it to run effectively, and magic happens," or, as you said, some layer there. How does that work? How do you see this super pass layer, if anything, enabling a different SaaS game? >> I think you hit on it there. The last like 10 or so years, we've been all focused on developers and developer productivity, and it's all about the developer experience, and it's got to be good for them, 'cause they're the kings. And I think the next 10 years are going to be very focused on operations, because once you start scaling out, it's not about developers. They can deliver fast or slow, it doesn't matter, but if you can't scale it out, then you've got a real problem. So I think that's an important part of it, is really, what is the ops experience, and what is the best way to get those costs down? And this would serve that purpose if it was done right, which, we can argue about whether that's possible or not, but I don't have to implement it, so I can say it's possible. >> Well, are we going to be getting into infrastructure as code moves into "everything is code," security, data, (laughs) applications is code? I mean, "blank" is code, fill in the blank. (Lori laughing) >> Yeah, we're seeing more of that with things like CDK and Pulumi, where you are actually coding up using a real language rather than the death by YAML or whatever. How much YAML can you take? But actually having a real language so you're not trying to do things in parsing languages. So I think that's an interesting trend. You're getting some interesting templates, and I like what... I mean, the counterexample is that if you just go deep on one vendor, then maybe you can go faster and it is simpler. And one of my favorite vendor... Favorite customers right now that I've been talking to is Liberty Mutual. Went very deep and serverless first on AWS. They're just doing everything there, and they're using CDK Patterns to do it, and they're going extremely fast. There's a book coming out called "The Value Flywheel" by Dave Anderson, it's coming out in a few months, to just detail what they're doing, but that's the counterargument. If you could pick one vendor, you can go faster, you can get that vendor to do more for you, and maybe get a bigger discount so you're not splitting your discounts across vendors. So that's one aspect of it. But I think, fundamentally, you're going to find the CIOs and the ops people generally don't like sitting on one vendor. And if that single vendor is a horizontal platform that's trying to make all the clouds look the same, now you're locked into whatever that platform was. You've still got a platform there. There's still something. So I think that's always going to be something that the CIOs want, but the developers are always going to just pick whatever the best tool for building the thing is. And a analogy here is that the developers are dating and getting married, and then the operations people are running the family and getting divorced. And all the bad parts of that cycle are in the divorce end of it. You're trying to get out of a vendor, there's lawyers, it's just a big mess. >> Who's the lawyer in this example? (crosstalk) >> Well... (laughing) >> Great example. (crosstalk) >> That's why ops people don't like lock-in, because they're the ones trying to unlock. They aren't the ones doing the lock-in. They're the ones unlocking, when developers, if you separate the two, are the ones who are going, picking, having the fun part of it, going, trying a new thing. So they're chasing a shiny object, and then the ops people are trying to untangle themselves from the remains of that shiny object a few years later. So- >> Aren't we- >> One way of fixing that is to push it all together and make it more DevOps-y. >> Yeah, that's right. >> But that's trying to put all the responsibilities in one place, like more continuous improvement, but... >> Chris, what's your reaction to that? Because you're- >> No, that's exactly what I was going to bring up, yeah, John. And 'cause we keep saying "devs," "dev," and "ops" and I've heard somewhere you can glue those two things together. Heck, you could even include "sec" in the middle of it, and "DevSecOps." So what's interesting about what Adrian's saying though, too, is I think this has a lot to do with how you structure your engineering teams and how you think about development versus operations and security. So I'm building out a team now that very much makes use of, thanks to my brilliant VP of Engineering, a "Team Topologies" approach, which is a very streamlined and product oriented way of thinking about, for example, in engineering, if you think about team structures, you might have people that build the front end, build the middle tier, and the back end, and then you have a product that needs to make use of all three components in some form. So just from getting stuff done, their ability then has to tie to three different groups, versus building a team that's streamlined that ends up having front end, middleware, and backend folks that understand and share standards but are able to uncork the velocity that's required to do that. So if you think about that, and not just from an engineering development perspective, but then you couple in operations as a foundational layer that services them with embedded capabilities, we're putting engineers and operations teams embedded in those streamlined teams so that they can run at the velocity that they need to, they can do continuous integration, they can do continuous deployment. And then we added CS, which is continuously secure, continuous security. So instead of having giant, centralized teams, we're thinking there's a core team, for example, a foundational team, that services platform, makes sure all the trains are running on time, that we're doing what we need to do foundationally to make the environments fully dev and operator and security people functional. But then ultimately, we don't have these big, monolithic teams that get into turf wars. So, to Adrian's point about, the operators don't like to be paned in, well, they actually have a say, ultimately, in how they architect, deploy, manage, plan, build, and operate those systems. But at the same point in time, we're all looking at that problem across those teams and go... Like if one streamline team says, "I really want to go run on Azure, "because I like their services better," the reality is the foundational team has a larger vote versus opinion on whether or not, functionally, we can satisfy all of the requirements of the other team. Now, they may make a fantastic business case and we play rock, paper, scissors, and we do that. Right now, that hasn't really happened. We look at the balance of AWS, we are picking SaaS-y, supercloud vendors that will, by the way, happen to run on three platforms, if we so choose to expand there. So we have a similar interface, similar capability, similar processes, but we've made the choice at LastPass to go all in on AWS currently, with respect to how we deliver our products, for all the reasons we just talked about. But I do think that operations model and how you build your teams is extremely important. >> Yeah, and to that point- >> And has the- (crosstalk) >> The vendors themselves need optionality to the customer, what you're saying. So, "I'm going to go fast, "but I need to have that optionality." I guess the question I have for you guys is, what is today's trade-off? So if the decision point today is... First of all, I love the go-fast model on one cloud. I think that's my favorite when I look at all this, and then with the option, knowing that I'm going to have the option to go to multiple clouds. But everybody wants lock-in on the vendor side. Is that scale, is that data advantage? I mean, so the lock-in's a good question, and then also the trade-offs. What do people have to do today to go on a supercloud journey to have an ideal architecture and taxonomy, and what's the right trade-offs today? >> I think that the- Sorry, just put a comment and then let Lori get a word in, but there's a lot of... A lot of the market here is you're building a product, and that product is a SaaS product, and it needs to run somewhere. And the customers that you're going to... To get the full market, you need to go across multiple suppliers, most people doing AWS and Azure, and then with Google occasionally for some people. But that, I think, has become the pattern that most of the large SaaS platforms that you'd want to build out of, 'cause that's the fast way of getting something that's going to be stable at scale, it's got functionality, you'd have to go invest in building it and running it. Those platforms are just multi-cloud platforms, they're running across them. So Snowflake, for example, has to figure out how to make their stuff work on more than one cloud. I mean, they started on one, but they're going across clouds. And I think that that is just the way it's going to be, because you're not going to get a broad enough view into the market, because there isn't a single... AWS doesn't have 100% of the market. It's maybe a bit more than them, but Azure has got a pretty solid set of markets where it is strong, and it's market by market. So in some areas, different people in some places in the world, and different vertical markets, you'll find different preferences. And if you want to be across all of them with your data product, or whatever your SaaS product is, you're just going to have to figure this out. So in some sense, the supercloud story plays best with those SaaS providers like the Snowflakes of this world, I think. >> Lori? >> Yeah, I think the SaaS product... Identity, whatever, you're going to have specialized. SaaS, superclouds. We already see that emerging. Identity is becoming like this big SaaS play that crosses all clouds. It's not just for one. So you get an evolution going on where, yes, I mean, every vendor who provides some kind of specific functionality is going to have to build out and be multi-cloud, as it were. It's got to work equally across them. And the challenge, then, for them is to make it simple for both operators and, if required, dev. And maybe that's the other lesson moving forward. You can build something that is heaven for ops, but if the developers won't use it, well, then you're not going to get it adopted. But if you make it heaven for the developers, the ops team may not be able to keep it secure, keep everything. So maybe we have to start focusing on both, make it friendly for both, at least. Maybe it won't be the perfect experience, but gee, at least make it usable for both sides of the equation so that everyone can actually work in concert, like Chris was saying. A more comprehensive, cohesive approach to delivery and deployment. >> All right, well, wrapping up here, I want to just get one final comment from you guys, if you don't mind. What does supercloud look like in five years? What's the Nirvana, what's the steady state of supercloud in five to 10 years? Or say 10 years, make it easier. (crosstalk) Five to 10 years. Chris, we'll start with you. >> Wow. >> Supercloud, what's it look like? >> Geez. A magic pane, a single pane of glass. (laughs) >> Yeah, I think- >> Single glass of pain. >> Yeah, a single glass of pain. Thank you. You stole my line. Well, not mine, but that's the one I was going to use. Yeah, I think what is really fascinating is ultimately, to answer that question, I would reflect on market consolidation and market dynamics that happens even in the SaaS space. So we will see SaaS companies combining in focal areas to be able to leverage the positions, let's say, in the identity space that somebody has built to provide a set of compelling services that help abstract that identity problem or that security problem or that instrumentation and observability problem. So take your favorite vendors today. I think what we'll end up seeing is more consolidation in SaaS offerings that run on top of infrastructure of the service offerings to where a supercloud might look like something I described before. You have the combination of your favorite interoperable identity, observability, security, orchestration platforms run across them. They're sold as a stack, whether it be co-branded by an enterprise vendor that sells all of that and manages it for you or not. But I do think that... You talked about, I think you said, "Is this an innovator's dilemma?" No, I think it's an integrator's dilemma, as it has always ultimately been. As soon as you get from Genesis to Bespoke Build to product to then commoditization, the cycle starts anew. And I think we've gotten past commoditization, and we're looking at niche areas. So I see just the evolution, not necessarily a revolution, of what we're dealing with today as we see more consolidation in the marketplace. >> Lori, what's your take? Five years, 10 years, what does supercloud look like? >> Part of me wants to take the pie in the sky unicorn approach. "No, it will be beautiful. "One button, and things will happen," but I've seen this cycle many times before, and that's not going to happen. And I think Chris has got it pretty close to what I see already evolving. Those different kinds of super services, basically. And that's really what we're talking about. We call them SaaS, but they're... X is a service. Everything is a service, and it's really a supercloud that can run anywhere, but it presents a different interface, because, well, it's easier. And I think that's where we're going to go, and that's just going to get more refined. And yes, a lot of consolidation, especially on the observability side, but that's also starting to consume the security side, which is really interesting to watch. So that could be a little different supercloud coming on there that's really focused on specific types of security, at least, that we'll layer across, and then we'll just hook them all together. It's an API first world, and it seems like that's going to be our standard for the next while of how we integrate everything. So superclouds or APIs. >> Awesome. Adrian... Adrian, take us home. >> Yeah, sure. >> What's your- I think, and just picking up on Lori's point that these are web services, meaning that you can just call them from anywhere, they don't have to run everything in one place, they can stitch it together, and that's really meant... It's somewhat composable. So in practice, people are going to be composable. Can they compose their applications on multiple platforms? But I think the interesting thing here is what the vendors do, and what I'm seeing is vendors running software on other vendors. So you have Google building platforms that, then, they will support on AWS and Azure and vice versa. You've got AWS's distro of Kubernetes, which they now give you as a distro so you can run it on another platform. So I think that trend's going to continue, and it's going to be, possibly, you pick, say, an AWS or a Google software stack, but you don't run it all on AWS, you run it in multiple places. Yeah, and then the other thing is the third tier, second, third tier vendors, like, I mean, what's IBM doing? I think in five years time, IBM is going to be a SaaS vendor running on the other clouds. I mean, they're already halfway there. To be a bit more controversial, I guess it's always fun to... Like I don't work for a corporate entity now. No one tells me what I can say. >> Bring it on. >> How long can Google keep losing a billion dollars a quarter? They've either got to figure out how to make money out of this thing, or they'll end up basically being a software stack on another cloud platform as their, likely, actual way they can make money on it. Because you've got to... And maybe Oracle, is that a viable cloud platform that... You've got to get to some level of viability. And I think the second, third tier of vendors in five, 10 years are going to be running on the primary platform. And I think, just the other final thing that's really driving this right now. If you try and place an order right now for a piece of equipment for your data center, key pieces of equipment are a year out. It's like trying to buy a new fridge from like Sub-Zero or something like that. And it's like, it's a year. You got to wait for these things. Any high quality piece of equipment. So you go to deploy in your data center, and it's like, "I can't get stuff in my data center. "Like, the key pieces I need, I can't deploy a whole system. "We didn't get bits and pieces of it." So people are going to be cobbling together, or they're going, "No, this is going to cloud, because the cloud vendors "have a much stronger supply chain to just be able "to give you the system you need. "They've got the capacity." So I think we're going to see some pandemic and supply chain induced forced cloud migrations, just because you can't build stuff anymore outside the- >> We got to accelerate supercloud, 'cause they have the supply. They are the chain. >> That's super smart. That's the benefit of going last. So I'm going to scoop in real quick. I can't believe we can call this "Web3 Supercloud," because none of us said "Web3." Don't forget DAO. (crosstalk) (indistinct) You have blockchain, blockchain superclouds. I mean, there's some very interesting distributed computing stuff there, but we'll have to do- >> (crosstalk) We're going to call that the "Cubeverse." The "Cubeverse" is coming. >> Oh, the "Cubeverse." All right. >> We will be... >> That's very meta. >> In the metaverse, Cubeverse soon. >> "Stupor cloud," perhaps. But anyway, great points, Adrian and Lori. Loved it. >> Chris, great to see you. Adrian, Lori, thanks for coming on. We've known each other for a long time. You guys are part of the cloud-erati, the group that has been in there from day one, and watched it evolve, and you get the scar tissue to prove it, and the experience. So thank you so much for sharing your commentary. We'll roll this up and make it open to everybody as additional content. We'll call this the "outtakes," the longer version. But really appreciate your time, thank you. >> Thank you. >> Thanks so much. >> Okay, we'll be back with more "Supercloud 22" right after this. (bright upbeat music)

>>Welcome back to NYC the Cube's coverage of Mongo DB 2022, a few thousand people here at least bigger than many people, perhaps expected, and a lot of buzz going on and we're gonna talk devs. I'm really excited to welcome back. Robbie Bellson who's the developer relations lead at Verizon and Ian Massingham. Who's the vice president of developer relations at Mongo DB Jens. Good to see you. Great >>To be here. >>Thanks having you. So Robbie, we just met a few weeks ago at the, the red hat summit in Boston and was blown away by what Verizon is doing in, in developer land. And of course, Ian, you know, Mongo it's rayon Detra is, is developers start there? Why is Mongo so developer friendly from your perspective? >>Well, it's been the ethos of MongoDB since day one. You know, back when we launched the first version of MongoDB back in 2009, we've always been about making developers lives easier. And then in 2016, we announced and released MongoDB Atlas, which is our cloud managed service for MongoDB, you know, starting with a small number of regions built on top of AWS and about 2,500 adoption events per week for MongoDB Atlas. After the first year today, MongoDB Atlas provides a managed service for MongoDB developers around the world. We're present in almost a hundred cloud regions across S DCP and Azure. And that adoption number is now running at about 25,000 developers a week. So, you know, the proof are in proof is really in the metrics. MongoDB is an incredibly popular platform for developers that wanna build data-centric applications. You just can't argue with the metrics really, >>You know, Ravi, sometimes there's an analyst who come up with these theories and one of the theories I've been spouting for a long time is that developers are gonna win the edge. And now to, to see you at Verizon building out this developer community was really exciting to me. So explain how you got this started with this journey. >>Absolutely. As you think about Verizon 5g edge or mobile edge computing portfolio, we knew from the start that developers would play a central role and not only consuming the service, but shaping the roadmap for what it means to build a 5g future. And so we started this journey back in late 20, 19 and fast forward to about a year ago with Mongo, we realized, well, wait a minute, you look at the core service offerings available at the edge. We didn't know really what to do with data. We wanted to figure it out. We wanted the vote of confidence from developers. So there I was in an apartment in Colorado racing, your open source Mongo against that in the region edge versus region, what would you see? And we saw tremendous performance improvements. It was so much faster. It's more than 40% faster for thousands and thousands of rights. And we said, well, wait a minute. There's something here. So what often starts is an organic developer, led intuition or hypothesis can really expand to a much broader go to market motion that really brings in the enterprise. And that's been our strategy from day one. Well, >>It's interesting. You talk about the performance. I, I just got off of a session talking about benchmarks in the financial services industry, you know, amazing numbers. And that's one of the hallmarks of, of Mongo is it can play in a lot of different places. So you guys both have developer relations in your title. Is that how you met some formal developer relations? >>We were a >>Program. >>Yeah, I would say that Verizon is one of the few customers that we also collaborate with on a developer relations effort. You know, it's in our mutual best interest to try to drive MongoDB consumption amongst developers using Verizon's 5g edge network and their platform. So of course we work together to help, to increase awareness of MongoDB amongst mobile developers that want to use that kind of technology. >>But so what's your story on this? >>I mean, as I, as I mentioned, everything starts with an organic developer discovery. It all started. I just cold messaged a developer advocate on Twitter and here we are at MongoDB world. It's amazing how things turn out. But one of the things that's really resonated with me as I was speaking with one of, one of your leads within your organization, they were mentioning that as Mongo DVIA developed over the years, the mantra really became, we wanna make software development easy. Yep. And that really stuck with me because from a network perspective, we wanna make networking easy. Developers are not gonna care about the internals of 5g network. In fact, they want us to abstract away those complexities so that they can focus on building their apps. So what better co-innovation opportunity than taking MongoDB, making software easy, and we make the network easy. >>So how do you think about the edge? How does you know variety? I mean, to me, you know, there's a lot of edge use cases, you know, think about the home Depot or lows. Okay, great. I can put like a little mini data center in there. That's cool. That's that's edge. Like, but when I think of Verizon, I mean, you got cell towers, you've got the far edge. How do you think about edge Robbie? >>Well, the edge is a, I believe a very ambiguous term by design. The edge is the device, the mobile device, an IOT device, right? It could be the radio towers that you mentioned. It could be in the Metro edge. The CDN, no one edge is better than the other. They're all just serving different use cases. So when we talk about the edge, we're focused on the mobile edge, which we believe is most conducive to B2B applications, a fleet of IOT devices that you can control a manufacturing plant, a fleet of ground and aerial robotics. And in doing so you can create a powerful compute mesh where you could have a private network and private mobile edge computing by way of say an AWS outpost and then public mobile edge computing by way of AWS wavelength. And why keep them separate. You could have a single compute mesh even with MongoDB. And this is something that we've been exploring. You can extend Atlas, take a cluster, leave it in the region and then use realm the mobile portfolio and spread it all across the edge. So you're creating that unified compute and data mesh together. >>So you're describing what we've been expecting is a new architecture emerging, and that's gonna probably bring new economics of new use cases, right? Where are we today in that first of all, is that a reasonable premise that this is a sort of a new architecture that's being built out and where are we in that build out? How, how do you think about the, the future of >>That? Absolutely. It's definitely early days. I think we're still trying to figure it out, but the architecture is definitely changing the idea to rip out a mobile device that was initially built and envisioned for the device and only for the device and say, well, wait a minute. Why can't it live at the edge? And ultimately become multi-tenant if that's the data volume that may be produced to each of those edge zones with hypothesis that was validated by developers that we continue to build out, but we recognize that we can't, we can't get that static. We gotta keep evolving. So one of our newest ideas as we think about, well, wait a minute, how can Mongo play in the 5g future? We started to get really clever with our 5g network APIs. And I, I think we talked about this briefly last time, 5g, programmability and network APIs have been talked about for a while, but developers haven't had a chance to really use them and our edge discovery service answering the question in this case of which database is the closest database, doesn't have to be invoked by the device anymore. You can take a thin client model and invoke it from the cloud using Atlas functions. So we're constantly permuting across the entire portfolio edge or otherwise for what it means to build at the edge. We've seen such tremendous results. >>So how does Mongo think about the edge and, and, and playing, you know, we've been wondering, okay, which database is actually gonna be positioned best for the edge? >>Well, I think if you've got an ultra low latency access network using data technology, that adds latency is probably not a great idea. So MongoDB since the very formative years of the company and product has been built with performance and scalability in mind, including things like in memory storage for the storage engine that we run as well. So really trying to match the performance characteristics of the data infrastructure with the evolution in the mobile network, I think is really fundamentally important. And that first principles build of MongoDB with performance and scalability in mind is actually really important here. >>So was that a lighter weight instance of, of Mongo or not >>Necessarily? No, not necessarily. No, no, not necessarily. We do have edge cashing with realm, the mobile databases Robbie's already mentioned, but the core database is designed from day one with those performance and scalability characteristics in mind, >>I've been playing around with this. This is kind of a, I get a lot of heat for this term, but super cloud. So super cloud, you might have data on Preem. You might have data in various clouds. You're gonna have data out at the edge. And, and you've got an abstraction that allows a developer to, to, to tap services without necessarily if, if he or she wants to go deep into the S great, but then there's a higher level of services that they can actually build for their customers. So is that a technical reality from a developer standpoint, in your view, >>We support that with the Mongo DB multi-cloud deployment model. So you can place Mongo DB, Atlas nodes in any one of the three hyperscalers that we mentioned, AWS, GCP or Azure, and you can distribute your data across nodes within a cluster that is spread across different cloud providers. So that kinds of an kind of answers the question about how you do data placement inside the MongoDB clustered environment that you run across the different providers. And then for the abstraction layer. When you say that I hear, you know, drivers ODMs the other intermediary software components that we provide to make developers more productive in manipulating data in MongoDB. This is one of the most interesting things about the technology. We're not forcing developers to learn a different dialect or language in order to interact with MongoDB. We meet them where they are by providing idiomatic interfaces to MongoDB in JavaScript in C sharp, in Python, in rust, in that in fact in 12 different pro programming languages that we support as a first party plus additional community contributed programming languages that the community have created drivers for ODMs for. So there's really that model that you've described in hypothesis exist in reality, using >>Those different Compli. It's not just a series of siloed instances in, >>In different it's the, it's the fabric essentially. Yeah. >>What, what does the Verizon developer look like? Where does that individual come from? We talked about this a little bit a few weeks ago, but I wonder if you could describe it. >>Absolutely. My view is that the Verizon or just mobile edge ecosystem in general for developers are present at this very conference. They're everywhere. They're building apps. And as Ian mentioned, those idiomatic interfaces, we need to take our network APIs, take the infrastructure that's being exposed and make sure that it's leveraging languages, frameworks, automation, tools, the likes of Terraform and beyond. We wanna meet developers where they are and build tools that are easy for them to use. And so you had talked about the super cloud. I often call it the cloud continuum. So we, we took it P abstraction by abstraction. We started with, will it work in one edge? Will it work in multiple edges, public and private? Will it work in all of the edges for a given region, public or private, will it work in multiple regions? Could it work in multi clouds? We've taken it piece by piece by piece and in doing so abstracting way, the complexity of the network, meaning developers, where they are providing those idiomatic interfaces to interact with our API. So think the edge discovery, but not in a silo within Atlas functions. So the way that we're able to converge portfolios, using tools that dev developers already use know and love just makes it that much easier. Do, >>Do you feel like I like the cloud continuum cause that's really what it is. The super cloud does the security model, how does the security model evolve with that? >>At least in the context of the mobile edge, the attack surface is a lot smaller because it's only for mobile traffic not to say that there couldn't be various configuration and human error that could be entertained by a given application experience, but it is a much more secure and also reliable environment from a failure domain perspective, there's more edge zones. So it's less conducive to a regionwide failure because there's so many more availability zones. And that goes hand in hand with security. Mm. >>Thoughts on security from your perspective, I mean, you added, you've made some announcements this week, the, the, the encryption component that you guys announced. >>Yeah. We, we issued a press release this morning about a capability called queryable encryption, which actually as we record this Mark Porter, our CTO is talking about in his keynote, and this is really the next generation of security for data stored within databases. So the trade off within field level encryption within databases has always been very hard, very, very rigid. Either you have keys stored within your database, which means that your memory, so your data is decrypted while it's resident in memory on your database engine. This allow, of course, allows you to perform query operations on that data. Or you have keys that are managed and stored in the client, which means the data is permanently OBS from the engine. And therefore you can't offload query capabilities to your data platform. You've gotta do everything in the client. So if you want 10 records, but you've got a million encrypted records, you have to pull a million encrypted records to the client, decrypt them all and see performance hit in there. Big performance hit what we've got with queryable encryption, which we announced today is the ability to keep data encrypted in memory in the engine, in the database, in the data platform, issue queries from the client, but use a technology called structural encryption to allow the database engine, to make decisions, operate queries, and find data without ever being able to see it without it ever being decrypted in the memory of the engine. So it's groundbreaking technology based on research in the field of structured encryption with a first commercial database provided to bring this to market. >>So how does the mobile edge developer think about that? I mean, you hear a lot about shifting left and not bolting on security. I mean, is this, is this an example of that? >>It certainly could be, but I think the mobile edge developer still stuck with how does this stuff even work? And I think we need to, we need to be mindful of that as we build out learning journeys. So one of my favorite moments with Mongo was an immersion day. We had hosted earlier last year where we, our, from an enterprise perspective, we're focused on BW BS, but there's nothing stopping us. You're building a B2C app based on the theme of the winner Olympics. At the time, you could take a picture of Sean White or of Nathan Chen and see that it was in fact that athlete and then overlaid on that web app was the number of medals they accrued with the little trumpeteer congratulating you for selecting that athlete. So I think it's important to build trust and drive education with developers with a more simple experience and then rapidly evolve overlaying the features that Ian just mentioned over time. >>I think one of the keys with cryptography is back to the familiar messaging for the cloud offloading heavy lifting. You actually need to make it difficult to impossible for developers to get this wrong, and you wanna make it as easy as possible for developers to deal with cryptography. And that of course is what we're trying to do with our driver technology combined with structure encryption, with query encryption. >>But Robbie, your point is lots of opportunity for education. I mean, I have to say the developers that I work with, it's, I'm, I'm in awe of how they solve problems and I, and the way they solve problems, if they don't know the answer, they figure out how to go get it. So how, how are your two communities and other communities, you know, how are they coming together to, to solve such problems and share whether it's best practices or how do I do this? >>Well, I'm not gonna lie in person. Events are a bunch of fun. And one of the easiest domain knowledge exchange opportunities, when you're all in person, you can ideate, you can whiteboard, you can brainstorm. And often those conversations are what leads to that infrastructure module that an immersion day features. And it's just amazing what in person events can do, but community groups of interest, whether it's a Twitch stream, whether it's a particular code sample, we rely heavily on digital means today to upscale the developer community, but also build on by, by means of a simple port request, introduce new features that maybe you weren't even thinking of before. >>Yeah. You know, that's a really important point because when you meet people face to face, you build a connection. And so if you ask a question, you're more likely perhaps to get an answer, or if one doesn't exist in a, in a search, you know, you, oh, Hey, we met at the, at the conference and let's collaborate on this guys. Congratulations on, on this brave new world. You're in a really interesting spot. You know, developers, developers, developers, as Steve bomber says screamed. And I was glad to see Dave was not screaming and jumping up and down on the stage like that, but, but the message still resonates. So thank you, definitely appreciate. All right, keep it right there. This is Dave ante for the cubes coverage of Mago DB world 2022 from New York city. We'll be right back.

(upbeat music) >> Welcome back to New York City everybody. You're watching theCUBE's coverage of MongoDB World 2022. My name is Dave Vellante. Pretty good attendance here. I'd say over 3000 people, great buzz, a lot of really technical sessions. There's an executive session going on. There's a financial analyst session. So a lot of diversity in this attendee base. Vadim Supitskiy is here. He's the CTO of Forbes and Abdul Razack is the vice president of Solution Engineering at Google. Gents, thanks for coming on theCUBE. >> Thanks Dave. >> Happy to be here. >> So, Forbes, very interesting business. I'm interested in what occurred during the pandemic for you guys. Right? Everybody went digital. Obviously you guys have a tremendous brand. We all, in the business world reaped from it, but what happened during the isolation era? What happened to your business? >> Yeah, so we've been innovating and going through digital transformation for years, since we launched our website probably 25 years ago. >> But during the pandemic, because of our coverage, our foresight to create a breaking news team, our audiences and readership really skyrocketed. >> Really? >> Yeah, and at that point, we were very happy and really lucky to be in Google Cloud and MongoDB Atlas. So when the audiences went up, we didn't feel any impact, right? Our environments auto-scaled and our users didn't experience any issues at all. So we were able to focus on innovation, our users loyalty and really building cool products. So we were very lucky and happy to be in Google Cloud and MongoDB Atlas. >> So Abdul, the solution and the title you provided, obviously worked. How did you guys end up getting together? What was that like? >> Yeah, I mean, like Vadim said, maybe there's a little bit of the right place at the right time in this case, but you can see the need for digital transformation and the pandemic really accelerated that. And like Vadim said, primarily Forbes wanted to focus on innovation and customer loyalty and the way that comes to bear, is that you have a technology platform that can serve those needs. Right? Whether it is through unique applications that can be delivered, the ability for developers to build those applications quickly and seamlessly and then remove the intangibles of scalability, performance, latency, and things of that nature. So, you can see this all coming together in this scenario. >> So as consumers, we see the website, we read online, maybe sometimes in the laptop, mostly on mobile. What is it that we don't see? I mean, the apps that Abdul talked about, community. What else is there? Paint a picture of that for us. >> Yeah. There is a lot going on behind the scene. Right? So focusing on audience, building communities, but also what it allowed us to do while everything was working well, we were scaling up. Right? We were able to focus on a lot of innovation. And one of those was first-party data platform that we built. We call it Forbes One. And that's in the center of everything that we do at Forbes right now. Right? So it allows us, one, to connect our partners, advertising partners with the audiences that they're looking to engage and to connect with. And then we are growing our consumer business as well and what that allows us to do is target the right products at the right time, to the right people, on the web website and our domain. So, that's just one of the examples that we've built our full first-party data platform on these technologies and we now know our customers so well that we are able to provide them with what they want. >> So the first-party data platform is what? A self-serve for advertiser, so they can identify? >> Not just advertisers. So it's in the center of everything. So advertiser comes in, we provide the segments and users that they want to reach. Now, we are creating products as well, building cool, innovative products and offering our journalism and everything there to our readers and we are able to connect them to the right audiences at the right time, as well as personalization. Right? You come onto the website, you want to read what you want to read. So we able to create that as well, using machine learning and AI. >> So a product, it might be a data product or it might be a content product? >> It could be a data product. It could be like just personalization or something like that. It could be newsletter. Right? It could be a stand-alone product, like investing product. So, there is a lot going on there, but we want to offer the right ones at the right time, to the right audiences and building that platform has allowed us to do that. >> Okay. Now Google's got great tech. What's the tech behind all this? >> Yeah. So when Vadim talked about segmenting to personalize something that is relevant to you and providing recommendations to you. Right? And all that is based on machine learning, AI technology. The fact that Vadim has all the data curated in a in a first-party data platform gives the ability to create a seamless profile. Right? You could be interested in a couple of products. Right? And then the underlying technology can tailor that to bring what is it that you're looking for at the right place at the right time. Right? So those are recommendations, things of that nature that's all powered by AI and machine learning technology. >> So it's running on Mongo, and then you're bringing in Google AI and machine intelligence tools? Can you double click on that? >> Yeah. It's basically a combination of both, using both platform to the deploy it and we embrace Cloud. Right? So we using all the Cloud native technologies. Right? We didn't want to just lift and shift. We wanted to make sure we do it right. And we focused on automation, even if we had to take a step back, we knew that automating things was a key for us. So yes, it's been really successful, but also really informative for us to use the right tools for the job. >> And you had prior experience with Mongo, or? >> We did. >> What's your journey been like there? >> Yeah, we actually were one of the first clients of Mongo. I think we were number 11 at that time. >> 10gen. >> Yes. It was. >> We remember. >> Many years ago it was MongoDB one, right? >> Yeah. >> And at that time we we introduced contributor network for us and our audiences were scaling as well. And we used Out-of-the-Box WordPress as our publishing platform, which couldn't scale. So we had to rethink and figure out, "Alright, so what do we do?" We compared couple of no SQL databases and Mongo was a winner because they checked all the boxes and developers loved it right away. Right? They're like, "All right, this is so much faster to develop on. It's just a great tool for the job going from SQL to, to no SQL". And we scaled and we never looked back. And then obviously Atlas came, so there are kind of two inflection points here. One switch into no SQL and two going away from managing databases. Like we don't want to be in that business. Right? Updates, patches, all of that, that we had to do manually, over-provision in our environments and kind of wasteful. So being on Atlas, that was a second kind of inflection point for us, which opened it up for us to do even more innovation and move faster. >> Okay. And you're happy about this partnership, despite, I mean, you partner with Mongo obviously, Google has its own databases, that's just the nature of the world we live in, isn't it? >> No and fundamentally like that, we always believe that customer choice is the primary notion. Right? I mean, and Google Cloud platform is more of a platform and the ecosystem is critical to that. Right? It's imperative. So, like Vadim said, the combination of Google and Mongo provides a truly Cloud native platform that can serve the needs for years to come, rather than from looking at it from a legacy perspective. And that's the way we look at it. Right? I mean, there is choices all the time and sometimes it's competition. >> Yeah. Yeah. And you're still selling a lot of compute and storage and machine intelligence, so machine learning. This morning in the keynotes, we heard a lot about a lot of different capabilities. We've certainly watched Mongo evolve its platform over the last half a decade or more really. But you've mentioned the developers loved it. Right? As Mongo evolves its platform, is there trade off from a developer simplicity standpoint? Are they able to preserve that from your perspective? >> I think with Atlas, it actually makes it easier now. So when they need to create an environment, they can do it on the fly. When they need to test something, also things available to them right away. So it actually, in general, as the platform becomes more mature and more stable, which is very important, but at the same time, the flexibility remains for development and for creation of environments and things like that. So we've been pretty happy with how it transitioned, to being a more mature platform. >> Did the move to Google Cloud and Atlas change the way that you're able to deliver high availability versus what you were doing when you were self-managing? Can you talk about that a little bit? >> Yeah, absolutely. We were in a data center, so kind of one location and moving to MongoDB Atlas and Google Cloud, now we're multi region. Right? So we have a full DR strategy and we feel a lot more secure and we feel very confident that anything that happens, we can scale, we can fail over. So absolutely, this helps us a lot. And the feature that was introduced probably a few years ago to auto scale MongoDB environments as well, that has been really key for us, so we can sleep well. >> Meaning you can scale while you sleep. >> Right, exactly. Exactly. >> Yeah. Plus the other part is you don't size for peak. right? You size as you grow, and then you, you have that elasticity built in. Right? That it is the nature. And then Mongo is available on multiple Google Cloud regions. So as you expand, you don't worry about all the plumbing that you need to do and things of that nature. >> They asked us serverless this morning. >> Yeah. >> How does that affect what you guys are doing together and what are your thoughts from Google's perspective and then of course, from Forbes? >> And that's the trend that we see constantly. Right? Serverless really decouples the tie to the VMs. Right? And so it makes it much more easier to provide the elasticity and have function calls across. Right? Function as a service and things of that nature. Right? So we see a lot of promise in that. Right? We do that even within our own products and we see that giving the ability to decompose and recompose applications and would love to hear how you're leveraging that. Right? >> Yeah. We fully embrace serverless. So we use all the tools you provide, I think. If you look at our architectural diagrams, it's like all these pops-up, cloud functions, composer, app engine. So we use the full suite and we love it. >> Yeah, Yeah. Okay. And then you talked this morning about the eliminating, the trade-offs with serverless of having to either when you dial it down You have to restart, but you've solved that problem, or I guess Mongo's helped you solve that problem. Can you explain that a little bit from a technical standpoint? >> Yeah. From a technical standpoint, if you look at, like as a developer, right? If you're building an intelligent app, it has multiple components within it. Right? There is pops-up for messaging, there is cloud functions and things of that nature. So you don't worry about, when it's encompassed in a serverless architecture, you don't worry about a lot of the complexities that go on behind it and so that makes the abstraction much more easier. And it eliminates the friction that a developer goes through. I think they've talked about removing friction and that's the primary source of productivity loss, which is the friction. We used to come from a world where developers were more worried. 80% of the time they would spend on plumbing this thing and then only 20% writing code. Right? And then now this whole paradigm should flip that. Right? That's where we see the promise of it. >> Do you still do stuff on Prem or are you pretty much all in the Cloud? >> Fully in the Cloud. >> How long did that take? What was that like? >> It actually was really fast. We had a real aggressive timeline. It took us six months. >> Really? >> Yeah. Yeah. And it was aggressive, but I was happy that we did it in a short period of time. >> And what was the business impact that you saw moving to the Google Cloud? >> Yeah, so obviously after we moved to the Cloud, we wanted to measure, especially the first year, how it affected us and what were the positives out of it. And yeah, we've seen tremendous results. 58% increase in speed to market. We were releasing four times more often than when we were on Prem. We saw 73% increase in initiatives delivered and while our velocity was scaling up, we also saw 30% decreased in hot fixes and rollbacks. So it became more stable while we scaled up the velocity and obviously very happy with those results. >> Wow. Do you golf? >> I don't actually. >> Do you golf? >> No. I watch golf. >> I used to watch. Okay. Do you know what a mulligan is? >> Yeah. >> Okay. mulligan is like a do-over right. If you had a mulligan, would you do anything differently? >> You know, we learned a lot and one of the keys for me was definitely automate everything, make sure that you automate as much as possible, even if it slows you down because in the future that will help you so much and use the platform and the tools that available to you. So, serverless. Right? Use Cloud the way it's supposed to be, as much as possible and I think that's the advice I would give. >> Are there any cautions with regard to automation, either of you that you see? I mean because sometimes automation brings unintended consequences and "Oops" happens really fast. >> Yeah. It's a little bit of a process. Right? If you take a step back, right, and typically what people tend to do is, there is a standardization process and once it's standardized, the next step is you gain efficiencies by automation. Right? In this whole thing, what is underestimated is change management. And we see a lot of room for improvement around educating on change management, getting ahead of that so that you can see what is coming. So that the organization moves across that. I don't know if you saw that in your case, but we see this predominantly in other other cases. >> Yeah. I mean, for us, we wanted to make sure that all the testing was in place and things like that. So not just automation of deploying or anything like that, but make sure that there is something there to catch if something goes wrong and roll back and things like that. So you want to make sure that you protected in many areas. >> So square this circle for me, because especially with COVID, so many unknowns and one of the benefits of document database is you're not tied into a schema. You got a flexible schema. Okay. So you're changing, you can change things much more easily. So when you talk about standardization, you're talking about standardizing, what at the infrastructure layer, or where does that standardization occur? Where should it occur. >> I mean, you could have it at the business process level. >> Okay. >> You could have it at the infrastructure level. You could also have it on the administration aspect of it. So there are three areas where you could apply automation to. >> So is there an analog to flexible schema at the business process level? Is that kind of how to think about it, whereas I'm not locked into a business process schema? I have to build flexibility into that as I change my? >> No, I mean, you can apply it any which way. I mean, I don't think the schema matters so much. Right? Like, for example, if you take the Forbes US case. Right? There is content curation, for example. Right? >> Yeah, okay. >> You could take content curation. Content curation in the previous world, like in the WordPress world, was not very flexible. Right? Like that it wouldn't scale. And now you are in a world where you have a very flexible schema, but the process of curating the content can be standardized. Right? And then the next step of that is to automate that. Right? And so you could apply it in any manner if you will. >> So have you built a custom CMS? Is that what you've done there? >> Yeah. We built our own custom CMS. It's AI powered. We want to make our journalist lives easier. So we're constantly trying to figure out what can we give them to make their day-to-day job much easier. >> So the machines can curate and find the best content. >> We do recommend things. Yes, absolutely. We curate, we tell them what would be the best headline, for example, what would >> Prior to them publishing? >> Yeah. Yeah. What would be the better keywords to include and things like that, what images. Just recommendations. >> And you can automate the insertion of those WordPress to go every time they do, even though they're writing about the same topic. >> It's a recommendation process obviously, but >> There is a human intelligence to that at the end. Right? I mean, but you can create a much more informed view by curating and recommending content rather than a myopic view. >> And you're eliminating that mundane keystroke task. Wow. Amazing story guys. Thanks so much for sharing. >> Absolutely. >> All right. Keep it right there. We're live from MongoDB World 2022 in New York city. Be right back. (upbeat music)

>>Okay, welcome back everyone. Cube's coverage here. Live on the floor at AWS summit, 2022, an in person event in San Francisco. Of course, AWS summit, 2022 in New York city is coming up this summer. The cube will be there as well. Make sure you check us out then too, but we day two of coverage had a great guest here. I Han VP of developer relations, Mongo DB, formally of AWS. We've been known each other for a long time doing, uh, developer relations at Mongo DB. Welcome to the queue. Good to see >>You. Thank to be here. Thanks for inviting me, John. It's great >>To, so Mongo DB is, um, first of all, stocks' doing really well right now. Businesswise is good, but I still think it's undervalue. A lot of people think is, is a lot more going huge success with Atlas. So congratulations to the team over there. Um, what's the update? What's the relationship withs, you know, guys have been great partners for years. What's the new thing. Yeah. >>So MongoDB Atlas obviously runs on several different major cloud providers, but AWS is the largest partner that we work with in the public cloud. So the majority of our Atlas workloads for our customers are running on the AWS platform. And just earlier this year, we announced a new strategic collaboration agreement with AWS. That's gonna further strengthen and deepen that partnership that we have with them. >>What's the main product value right now on the scale on, on Atlas, what's the drive in the revenue momentum. >>So, I mean, you know, there's a huge trend in the industry towards cloud managed databases, right? You look back 10, 15 years ago when we first met, most customers were only and operating their own data infrastructure, either running it in their own data centers, or maybe if they were really early using the primitives that cloud providers like AWS offered to run their databases in the cloud when Amazon launched RDS back in 2009, I think it was, we started to see this trend towards cloud managed databases. We followed that with our own Atlas offering back in 2016. And as Andy jazzy from AWS would say very often it's offloading that UND differentiated, heavy lifting, allowing developers to focus on building applications. They don't have to win and operate the data infrastructure. We do it for them, and that has proven incredibly popular amongst our customers. You know, Atlas route right now is growing at 50, sorry, 85% car year on year growth. >>You know, um, I've been following MongoDB for a long, long time. I mean, going back to the lamp stack days, you know, and you think about what Mongo has done as a product because of the developer traction, you know, Mongo can't do this, just keeps getting better every year. And, and the, I think the stickiness with developers is a real big part of that. Can you your view there cuz you're in VE relations. I mean, developers all love Mongo. They're teaching in school. People are picking up a side hustles, they're coding on it, using it all everywhere. I mean it's well known. >>There's a few different reasons for that. I think the main one is the, the document orientated model that we use, the document data models that are used by Mongo DB, just a net way for developers to work with data. And then, uh, we've invested in creating 16 first party drivers that allow developers using various different programming languages, whether that's JavaScript or Python or rust to integrate MongoDB, natively and idiomatic with their software. So it's very, very easy for a developer to pick up MongoDB, grab one of these drivers from their package manager of their choice and then build applications that natively manipulate data inside MongoDB, whether that's MongoDB Atlas or our enterprise edition on their own premises. They get a very consistent and very easy to, I easy to use developer experience with our, with our platform. >>Talk about the go to market with AWS. You guys also have a tightly coupled relationships. There's been announcements there recently. Uh, what's changing most right now that people should pay attention to. Well, >>The first thing is there's a huge amount of technical integration between MongoDB and AWS services. And that's the basis for many of our customers choosing to run Mon Mongo DB on AWS. We're active in 23 AWS regions around the world. And there's many other integration points as well, like cryptographic protection of Mongo MongoDB, stored data using Amazon cryptographic services, for example, or building serverless applications with AWS Lambda and MongoDB servers. So there's a ton of technical integration. Yeah, but what we started to work on now is go to market integration with AWS as well. So you can buy Mongo DB Atlas through AWS's marketplace. You can use the payer, you go offering to pay for it with your AWS bill. And then we're collaborating with AWS on migrations and other joint go to market activities as well. That >>Means get incentives, the sales people at AWS. >>Of course our moreover I mean, it's just really easy for customers, really easy for developers to consume. Yeah, they don't need to contract with MongoDB. They can use their existing AWS contracting, their existing discounting relationships and pre purchasing arrangements with AWS to consume Atlas. >>It's the classic meet the customers where they >>Are exactly right. Meet the developer where they are and meet the customers where they are now with this new model as well. >>Yeah. I love marketplace. I think it's been great. You know, even with its kind of catalog and vibe, I think it's gonna get better and better, uh, over there teams doing good work. Um, and it's easy to consume. That's key. >>Yeah. Super easy. Reduce that friction and make it real easy for developers to adopt this. Right. >>Talk about some of the top customers that you guys share with AWS. What are some of the customers you guys have together and what the benefits of the >>Relationship joint references that we talk about? A lot, one of them is Shutterfly. So in the photographic products area, they built a eCommerce offering with MongoDB and AWS. The second is seven 11 with seven 11. We're doing a lot in the mobile space. So edge applications, we've got a feature in MongoDB Atlas that allows you to synchronize data with databases on mobile devices. Those can be phones point of sale devices or handheld devices that might be used in the parcel industry, for example. So seven 11 using us in that way. And then lastly with Pitney Bowes, we've got a big digital transformation project with Pitney Bowes where they've reimagined their, uh, postage and packaging services, delivering those to their customers, using MongoDB as a data store as well. >>I wanna get in some of the trends, you've got a great per you know, you know, Mongo from Amazon side and now you're there. Um, Mongo's, as you pointed out has, has been around for a long time. What are some of the stats? I mean, how many customers, how many countries? Well, it's pretty massive >>Mind. We've got almost quarter of a billion downloads today, 240 million MongoDB downloads since we launched the first product <laugh>, we've got 33,000 active customers that are using MongoDB Atlas today and we're running well over a million free tier clusters on MongoDB Atlas across all of the different providers where we operate the service as well. So these numbers are, you know, mind blowing in terms of scale. Uh, but of course at the core of that is operational excellence. Customers love Mongo DBS because they don't have to operate it themselves. They don't have to deal with fairly conditions. They don't have to deal with scaling. They don't have to deal with deployment. We all, we do all of those things as part of the service offering and customers get an endpoint that they can use with their applications to store and retrieve data reliably. And with consistently high perform, >>You know, it's, you know, in the media, something has to be dead. Someone's the death of the iPhone, the death of this, nothing that really dies. Mongo DB has always been kind of like talked about, well, it doesn't scale on the high end. Of course, Oracle was saying that, I mean, all the, all the big database vendors were kind of throwing darts at, at Mongo, uh, DB, uh, but it kept scaling. Atlas is a whole nother. Could you just unpack that a little bit more? Why is it so important? Because scale is just, I mean, it's, it's horizontal, but it's also performant. >>Exactly. Right. So with, uh, Mongo DB's document access model that I've described already, you break some of the limitations that exist inside traditional relational databases. So, you know, they don't scale well, if you've got high concurrent and see of data access, and they're typically difficult and expensive to scale because you need to share data. Once you grow beyond individual cluster nodes, and you'll know that all relational databases suffer from these same kinds of issues with non relational systems, no SQL systems like MongoDB, you have to think a little bit more about design at the beginning. So designing database to cater for the different access patterns that you have, but in return for that upfront preparation, that design work, you get near limitless, scalability and performance will scale nearly linearly with that scalability as well. So very much more high performance, very much more simplicity for the developer as their database gets larger and their cluster gets larger to support it. >>Yeah. You know, Amazon web service has always had an a and D jazz. We talk to us all the time, every interview I've done with Swami and Matt wood or whoever on the team and executive levels always said the same thing. There's not one database to rule the world, right? Obvious you're talking about Oracle, but even within AWS customers, they're mixing and matching databases based on use cases. So in distributed environment, they're all working together. So, um, you guys fit nicely into that. So how does that, >>I think strategy slightly counterbalances that so, you know, they would say use the specific tool for the specific task that you have in hand. Yeah. What we try to focus on is creating the simple and most effective developer experience that we can, and then supporting different facets to the product in order to allow developers to different use cases. A really good example with something like MongoDB Atlas search. So we integrated Apache Luine into MongoDB Atlas. Customers can very simply apply Apache Luine search indexes to the data that they've got in MongoDB. And then they can interact with that search data using the same drivers as an API. Yeah, yeah. That they use for regular queries. So if you want to run search on your application data, you don't need a separate open search or elastic search cluster, just turn on MongoDB Atlas search and use that, that search facet. So it's interest and we have other capabilities that it's >>Vertically integrating inside within Mongo, >>Correct? Yes. That's better. Yeah. With the guy, all of creating a really simple and effective developer experience, boosting developer productivity and helping developers get more done in less time. >>You mentioned serverless earlier, what's the serverless angle with AWS when Mongo, >>Is there one? Yeah. So we have MongoDB serverless currently in preview, uh, has the same kind of characteristics that you would, or the characteristics that you would expect from a serverless data base. So consumption based model, you provision an endpoint and that will scale elastically in accordance with your usage and you get billed by consumption units so much like the serverless paradigm that we've seen delivered by AWS, the same kind of model for Mongo, DB, Atlas serverless. >>What, what attracted you to Mongo DBS? So you knew them before, or you moved over there. Um, what's going on there? What's the culture like right now? Oh, >>The culture's great. I mean, it's a much smaller company than AWS where I was before, you know, it's a very large organization. And one of the things that I really like about MongoDB is, as I've said earlier, we can serve the different use cases that a developer might have with a single product, with different aspects, to it, different facets to it. Uh, and it's a really great conversation to have with a, with a developer, with a developer customer, to be able to offer one thing that helps them solve five or six different problems that have traditionally been quite hard for them to wrestle with quite difficult for them to, to deal with. And then we've got this focus on developer experience through these driver packages that we have as well. So it's really great to have as a developer relations pro have that kind of tooling in my kit bag that can help developers become more effective. >>Talk about tooling, cuz you know, I always have, uh, kind of moments where I waffle between more. I love platforms, tools are being over overused, too many tools tool with the tool, you know, the expressions, but we're seeing from developers, the ones that don't want to go into the hood, we serverless plays beautifully. Yep. They want tools. They do. And, and the, the new engineering developers that are coming outta college and universities, they love tools. >>Yeah. And we actually have quite a few of those built into Mongo, DB Atlas. So inside Mongo, DB Atlas, we've got things like an index optimizer, which will suggest the best way that you might index your data for better perform months inside MongoDB, running on Atlas, we've got a data Explorer, which is much like another product that we've got called MongoDB compass that allows you to see and manipulate the data that you have stored within your database natively within the Atlas interface. Uh, and then we also have, uh, whole slew of different metrics, monitoring capabilities built into the platform as well. So these are aspects of Atlas that developers can take advantage of. And then over on the client side, visual studio code plugins. Yeah. So you can manipulate and operate with data directly inside visual studio code, which is obviously the most common and popular IDE out there today, as well as integration with things like infrastructure is code tools. So we support cloud formation for provisioning. We have CDK constructs inside. Yeah. The CDK construct library. We also have a lot of customers using Terraform to provision MongoDB across both AWS and other providers. So having that developer tooling of course is super important. Yeah. Aspect of the developer experience, trying to >>Build out deploying observability is a big one. How does that fit in? Cuz you knew need to talk and not only measure everything here, but talk to other systems. >>Yeah. So we recently announced a provider for Prometheus and Grafana. So we can emit metrics into those providers. Obviously CNCF projects, very common and popular inside customers that are running on Kubernetes. We've got a Kubernetes operator for MongoDB Atlas as well. Good. So you can provision MongoDB Atlas from within Kubernetes as well as having our own native metrics directly within Atlas as well. >>Ian you're crushing it. You got all the, the data, the fingertips. Are you gonna be at Cuban this year? Uh, >>I will be, but some of our team members will definitely be there. >>Yeah, we'll be at, uh, EU. The cube will be there. Great. Thanks for coming on. Appreciate the insight final world. I'll give you the last word. Tell the audience what's going on. What's at Mongo DB. What should they pay attention to? If they've used Mongo and are aware of it? What's the update. What's >>The so you should come to MongoDB world actually in New York at the beginning of June, June 7th, the ninth in the Javit center in New York. Gonna have our own show there. And of course we'd love to see you there. >>Okay. Cube comes here day two of eight, us summit, 2020, this Cub I'm John for your host. Stay with us more. Our coverage as day two winds down. Great coverage.

(upbeat music) >> Oracle continues to pursue a multi-mode converged database strategy. The premise of this all in one approach is to make life easier for practitioners and developers. And the most recent example is the Oracle database API for MongoDB, which was announced today. Now, Oracle, they're not the first to come out with a MongoDB compatible API, but Oracle hopes to use its autonomous database as a differentiator and further build a moat around OCI, Oracle Cloud Infrastructure. And with us to talk about Oracle's MongoDB compatible API is Gerald Venzl, who's a distinguished Product Manager at Oracle. Gerald was a guest along with Maria Colgan on the CUBE a while back, and we talked about Oracle's converge database and the kind of Swiss army knife strategy, I called it, of databases. This is dramatically different. It's an approach that we see at the opposite end of the the spectrum, for instance, from AWS, who, for example, goes after the world of developers with a different database for every use case. So, kind of picking up from there, Gerald, I wonder if you could talk about how this new MongoDB API adds to your converged model and the whole strategy there. Where does it fit? >> Yeah, thank you very much, Dave and, by the way, thanks for having me on the CUBE again. A pleasure to be here. So, essentially the MongoDB API to build the compatibility that we used with this API is a continuation of the converge database story, as you said before. Which is essentially bringing the many features of the many single purpose databases that people often like and use, together into one technology so that everybody can benefit from it. So as such, this is just a continuation that we have from so many other APIs or standards that we support. Since a long time, we already, of course to SQL because we are relational database from the get go. Also other standard like GraphQL, Sparkle, et cetera that we have. And the MongoDB API, is now essentially just the next step forward to give the developers this API that they've gotten to love and use. >> I wonder if you could talk about from the developer angle, what do they get out of it? Obviously you're appealing to the Mongo developers out there, but you've got this Mongo compatible API you're pouting the autonomous database on OCI. Why aren't they just going to use MongoDB Atlas on whatever cloud, Azure or AWS or Google Cloud platform? >> That's a very good question. We believe that the majority of developers want to just worry about their application, writing the application, and not so much about the database backend that they're using. And especially in cloud with cloud services, the reason why developers choose these services is so that they don't have to manage them. Now, autonomous database brings many topnotch advanced capabilities to database cloud services. We firmly believe that autonomous database is essentially the next generation of cloud services with all the self-driving features built in, and MongoDB developers writing applications against the MongoDB API, should not have to hold out on these capabilities either. It's like no developer likes to tune the database. No developer likes to take a downtime when they have to rescale their database to accommodate a bigger workload. And this is really where we see the benefit here, so for the developer, ideally nothing will change. You have MongoDB compatible API so they can keep on using their tools. They can build the applications the way that they do, but the benefit from the best cloud database service out there not having to worry about any of these package things anymore, that even MongoDB Atlas has a lot of shortcomings still today, as we find. >> Of cos, this is always a moving target The technology business, that's why we love it. So everybody's moving fast and investing and shaking and jiving. But, I want to ask you about, well, by the way, that's so you're hiding the underlying complexity, That's really the big takeaway there. So that's you huge for developers. But take, I was talking before about, the Amazon's approach, right tool for the right job. You got document DB, you got Microsoft with Cosmos, they compete with Mongo and they've been doing so for some time. How does Oracle's API for Mongo different from those offerings and how you going to attract their users to your JSON offering. >> So, you know, for first of all we have to kind of separate slightly document DB and AWS and Cosmos DB in Azure, they have slightly different approaches there. Document DB essentially is, a document store owned by and built by AWS, nothing different to Mongo DB, it's a head to head comparison. It's like use my document store versus the other document store. So you don't get any of the benefits of a converge database. If you ever want to do a different data model, run analytics over, etc. You still have to use the many other services that AWS provides you to. You cannot all do it into one database. Now Cosmos DB it's more in interesting because they claim to be a multi-model database. And I say claim because what we understand as multi-model database is different to what they understand as multimodel database. And also one of the reasons why we start differentiating with converge database. So what we mean is you should be able to regardless what data format you want to store in the database leverage all the functionality of the database over that data format, with no trade offs. Cosmos DB when you look at it, it essentially gives you mode of operation. When you connect as the application or the user, you have to decide at connection time, how you want, how this database should be treated. Should it be a document store? Should it be a graph store? Should it be a relational store? Once you make that choice, you are locked into that. As long as you establish that connection. So it's like, if you say, I want a document store, all you get is a document store. There's no way for you to crossly analyze with the relational data sitting in the same service. There's no for you to break these boundaries. If you ever want to add some graph data and graph analytics, you essentially have to disconnect and now treat it as a graph store. So you get multiple data models in it, but really you still get, one trick pony the moment you connect to it that you have to choose to. And that is where we see a huge differentiation again with our converge database, because we essentially say, look, one database cloud service on Oracle cloud, where it allows you to do anything, if you wish to do so. You can start as a document store if you wish to do so. If you want to write some SQL queries on top, you can do so. If you want to add some graph data, you can do so. But there's no way for you to have to rewrite your application, use different libraries and frameworks now to connect et cetera, et cetera. >> Got it. Thank you for that. Do you have any data when you talk to customers? Like I'm interested in the diversity of deployments, like for instance, how many customers are using more than one data model? Do for instance, do JSON users need support for other data types or are they happy to stay kind of in their own little sandbox? Do you have any data on that? >> So what we see from the majority of our customers, there is no such thing as one data model fits everything. So, and it's like, there again we have to differentiate the developer that builds a certain microservice, that makes happy to stay in the JSON world or relational world, or the company that's trying to derive value from the data. So it's like the relational model has not gone away since 40 years of it existence. It's still kicking strong. It's still really good at what it does. The JSON data model is really good in what it does. The graph model is really good at what it does. But all these models have been built for different purposes. Try to do graph analytics on relational or JSON data. It's like, it's really tricky, but that's why you use a graph model to begin with. Try to shield yourself from the organization of the data, how it's structured, that's really easy in the relational world, not so much when you get into a document store world. And so what we see about our customers is like as they accumulate more data, is they have many different applications to run their enterprises. The question always comes back, as we have predicted since about six, seven years now, where they say, hey, we have all this different data and different data formats. We want to bring it all together, analyze it together, get value out of the data together. We have seen a whole trend of big data emerge and disappear to answer the question and didn't quite do the trick. And we are basically now back to where we were in the early 2000's when XML databases have faded away, because everybody just allowed you to store XML in the database. >> Got it. So let's make this real for people. So maybe you could give us some examples. You got this new API from Mongo, you have your multi model database. How, take a, paint a picture of how customers are going to benefit in real world use cases. How does it kind of change the customer's world before and after if you will? >> Yeah, absolutely. So, you know the API essentially we are going to use it to accept before, you know, make the lives of the developers easier, but also of course to assist our customers with migrations from Mongo DB over to Oracle Autonomous Database. One customer that we have, for example, that would've benefited of the API several a couple of years ago, two, three years ago, it's one of the largest logistics company on the planet. They track every package that is being sent in JSON documents. So every track package is entries resembled in a JSON document, and they very early on came in with the next question of like, hey, we track all these packages and document in JSON documents. It will be really nice to know actually which packages are stuck, or anywhere where we have to intervene. It's like, can we do this? Can we analyze just how many packages get stuck, didn't get delivered on, the end of a day or whatever. And they found this struggle with this question a lot, they found this was really tricky to do back then, in that case in MongoDB. So they actually approached Oracle, they came over, they migrated over and they rewrote their applications to accommodate that. And there are happy JSON users in Oracle database, but if we were having this API already for them then they wouldn't have had to rewrite their applications or would we often see like worry about the rewriting the application later on. Usually migration use cases, we want to get kind of the migration done, get the data over be running, and then worry about everything else. So this would be one where they would've greatly benefited to shorten this migration time window. If we had already demo the Mongo API back then or this compatibility layer. >> That's a good use case. I mean, it's, one of the most prominent and painful, so anything you could do to help that is key. I remember like the early days of big data, NoSQL, of course was the big thing. There was a lot of confusion. No, people thought was none or not only SQL, which is kind of the more widely accepted interpretation today. But really, it's talking about data that's stored in a non-relational format. So, some people, again they thought that SQL was going to fade away, some people probably still believe that. And, we saw the rise of NoSQL and document databases, but if I understand it correctly, a premise for your Mongo DB API is you really see SQL as a main contributor over Mongo DB's document collections for analytics for example. Can you make, add some color here? Are you seeing, what are you seeing in terms of resurgence of SQL or the momentum in SQL? Has it ever really waned? What's your take? >> Yeah, no, it's a very good point. So I think there as well, we see to some extent history repeating itself from, this all has been tried beforehand with object databases, XML database, et cetera. But if we stay with the NoSQL databases, I think it speaks at length that every NoSQL database that as you write for the sensor you started with NoSQL, and then while actually we always meant, not only SQL, everybody has introduced a SQL like engine or interface. The last two actually join this family is MongoDB. Now they have just recently introduced a SQL compatibility for the aggregation pipelines, something where you can put in a SQL statement and that essentially will then work with aggregation pipeline. So they all acknowledge that SQL is powerful, for us this was always clear. SQL is a declarative language. Some argue it's the only true 4GL language out there. You don't have to code how to get the data, but you just ask the question and the rest is done for you. And, we think that as we, basically, has SQL ever diminished as you said before, if you look out there? SQL has always been a demand. Look at the various developer surveys, etc. The various top skills that are asked for SQL has never gone away. Everybody loves and likes and you wants to use SQL. And so, yeah, we don't think this has ever been, going away. It has maybe just been, put in the shadow by some hypes. But again, we had the same discussion in the 2000's with XML databases, with the same discussions in the 90's with object databases. And we have just frankly, all forgotten about it. >> I love when you guys come on and and let me do my thing and I can pretty much ask any question I want, because, I got to say, when Oracle starts talking about another company I know that company's doing well. So I like, I see Mongo in the marketplace and I love that you guys are calling it out and making some moves there. So here's the thing, you guys have a large install base and that can be an advantage, but it can also be a weight in your shoulder. These specialized cloud databases they don't have that legacy. So they can just kind of move freely about, less friction. Now, all the cloud database services they're going to have more and more automation. I mean, I think that's pretty clear and inevitable. And most if not all of the database vendors they're going to provide support for these kind of converged data models. However they choose to do that. They might do it through the ecosystem, like what Snowflake's trying to do, or bring it in the house themselves, like a watch maker that brings an in-house movement, if you will. But it's like death and taxes, you can't avoid it. It's got to happen. That's what customers want. So with all that being said, how do you see the capabilities that you have today with automation and converge capabilities, How do you see that, that playing out? What's, do you think it gives you enough of an advantage? And obviously it's an advantage, but is it enough of an advantage over the specialized cloud database vendors, where there's clearly a lot of momentum today? >> I mean, honestly yes, absolutely. I mean, we are with some of these databases 20 years ahead. And I give you concrete examples. It's like Oracle had transaction support asset transactions since forever. NoSQL players all said, oh, we don't need assets transactions, base transactions is fine. Yada, yada, yada. Mongo DB started introducing some transaction support. It comes with some limits, cannot be longer than 60 seconds, cannot touch more than a thousand documents as well, et cetera. They still will have to do some catching up there. I mean, it took us a while to get there, let's be honest. Glad We have been around for a long time. Same thing, now that happened with version five, is like we started some simple version of multi version concurrency control that comes along with asset transactions. The interesting part here is like, we've introduced this also an Oracle five, which was somewhere in the 80's before I even started using Oracle Database. So there's a lot of catching up to do. And then you look at the cloud services as well, there's actually certain, a lot of things that we kind of gotten take, we've kind of, we Oracle people have taken for granted and we kind of keep forgetting. For example, our elastic scale, you want to add one CPU, you add one CPU. Should you take downtime for that? Absolutely not. It's like, this is ridiculous. Why would you, you cannot take it downtime in a 24/7 backend system that runs the world. Take any of our customers. If you look at most of these cloud services or you want to reshape, you want to scale your cloud service, that's fine. It's just the VM under the covers, we just shut everything down, give you a VM with more CPU, and you boot it up again, downtown right there. So it's like, there's a lot of these things where we go like, well, we solved this frankly decades ago, that these cloud vendors will run into. And just to add one more point here, so it's like one thing that we see with all these migrations happening is exactly in that field. It's like people essentially started building on whether it's Mongo DB or other of these NoSQL databases or cloud databases. And eventually as these systems grow, as they ask more difficult questions, their use cases expand, they find shortcomings. Whether it's the scalability, whether it's the security aspects, the functionalities that we have, and this is essentially what drives them back to Oracle. And this is why we see essentially this popularity now of pendulum swimming towards our direction again, where people actually happily come over back and they come over to us, to get their workloads enterprise grade if you like. >> Well, It's true. I mean, I just reported on this recently, the momentum that you guys have in cloud because it is, 'cause you got the best mission critical database. You're all about maps. I got to tell you a quick story. I was at a vertical conference one time, I was on stage with Kurt Monash. I don't know if you know Kurt, but he knows this space really well. He's probably forgot and more about database than I'll ever know. But, and I was kind of busting his chops. He was talking about asset transactions. I'm like, well with NoSQL, who needs asset transactions, just to poke him. And he was like, "Are you out of your mind?" And, and he said, look it's everybody is going to head in this direction. It turned out, it's true. So I got to give him props for that. And so, my last question, if you had a message for, let's say there's a skeptical developer out there that's using Mongo DB and Atlas, what would you say to them? >> I would say go try it for yourself. If you don't believe us, we have an always free cloud tier out there. You just go to oracle.com/cloud/free. You sign up for an always free tier, spin up an autonomous database, go try it for yourself. See what's actually possible today. Don't just follow your trends on Hackernews and use a set study here or there. Go try it for yourself and see what's capable of >> All right, Gerald. Hey, thanks for coming into my firing line today. I really appreciate your time. >> Thank you for having me again. >> Good luck with the announcement. You're very welcome, and thank you for watching this CUBE conversation. This is Dave Vellante, We'll see you next time. (gentle music)

>> Announcer: Live from Las Vegas, it's theCUBE! Covering AWS re:Invent 2019. Brought to you by Amazon Web Services and Intel along with its eco-system partners. >> Hey, welcome back to theCUBE's coverage of AWS re:Invent '19. This is our third day in Vegas. That's a lot of Vegas. I am joined by my co-host Justin Warren, the founder and chief analyst at PivotNine, and Justin and I are welcoming back one of our CUBE alum. Joining us next from MongoDB is Sahir Azam, its chief product officer. Welcome back! >> Thank you so much, I'm happy to be here. >> So talk to us about what's going on at MongoDB, I know we've had you on the program before, we've had MongoDB, but what's sort of the latest and greatest? >> Yeah, so we're continuing to grow very fast, and especially our cloud product Atlas. We've got two million developers using the platform today, 13,000 customers, many of which are on the amazing AWS platform, and I think people are really embracing the idea of a multicloud database service and a data platform they can have the flexibility to work with no matter where they are. >> Talk about, sorry, Justin, about multicloud a little bit more because it is a symptom as one of our CEOs, Dave Vellante, calls it. A lot of companies have inherited it, it's more by whether it's organically, or it's by acquisition, or developer preference. It's a state in which a lot of businesses are operating, but it's challenging. >> Yes. >> What are some of the things that you're hearing with respect to customers? How can you help them deal better in that world? >> Sure. So, yeah we definitely see some of those exact trends, so, you know for large enterprises, many times, they have different use cases in different business units, where developers or application owners prefer different cloud providers. Oftentimes it's acquisition, but also at a strategic level, at the CTO, CIO, or even CEO level, you know, there is a forethought strategy that it's going to be a multicloud platform world, and now what we see is many customers are still very much focused on a single cloud provider to build-up the skills on, but with a close eye to a second or third tier provider in the architecture that they will scale and balance over time. So, I think it's early days, but the trend is definitely rising in what we're seeing. Now, one of the things that makes a multicloud strategy really hard to implement is the data. You know, especially transactional data that runs live applications that are serving real customers, that makes an application and a development team really stuck on a certain platform. So, what we're focused on at MongoDB is really de-coupling that data layer from the underlying cloud infrastructure providers such that if you want to leverage the benefits of the different services AWS has in their rich ecosystem, but then maybe plumb in something from another provider, we make that extremely easy to do with the click of a button, and move your data across those cloud providers. >> Yeah, so talk about the mechanism for doing that a little bit more, because that's really tricky to do, and that's one thing I think people have been concerned about the idea of multicloud, is that, well, are you actually running in multiple clouds simultaneously, or is it more that, well actually sometimes we just want to move a bit from here to there that we'll use for different applications? >> There's sort of three trends that we see you know, and we're a data platform player, so our use cases are sort of bounded around database technology, data analytics. So, the first is for customers who want high availability across multiple regions within a certain geography, so let's say you're dealing with personal information of German citizens in Germany, Amazon has a region in Germany, only one, and maybe you want Azure or GCP to be a second region for high availability, and you need to rely on a secondary provider, because there's only one from a particular cloud of choice in that geo, so that's sort of one high availability kind of use case. The second is leveraging the benefits of all these different services that the cloud providers themselves are releasing, so we hear a lot of customers that say, you know, Amazon's my preferred partner for operationalizing my app. We use their services, our database runs there, however, we may want to take some of that data, even if it's for a week, even for a few days, a month, and perhaps move it over to another provider to leverage some new analytic service or machine learning, or AI algorithm that they might have. Today, that's really challenging to do. It's the idea that you can click a button, and create that replica, and move that data over very easily is something that people are asking from us. And then the third is geographic reach. So, our database platform, Atlas runs in 70 global regions worldwide, across AWS, Azure, and GCP which makes it the most widely available databases service on the planet. And one of the interesting use cases for that is, let's say somebody is using a single cloud provider for 99% of their work load, but suddenly they see their app take off in Taiwan, you know, maybe another cloud provider has a region in Taiwan, just mix and match and add that region into the architecture very seamlessly. So, those kind of three categories, high availability within geos, the ability to leverage, you know, the rich service offerings and mix and match, and then the geographic reach, are the three things we see for multi plat at a strategic level, beyond the reactive angle of acquiring a company and learning how to have to manage multiple clouds that way. >> That does sound like it's a bit of a trend that we're hearing and particularly today, I think, Lisa, where enterprises want choice, and that customer choice, of being able to choose things that actually suit me, rather than necessarily which vendor I'm buying my infrastructure from. That sounds like something that we're hearing a lot. >> Yeah, and we've invested a lot of time, engineering effort, working with Amazon, working with Google, working with Microsoft, to unify that data layer across the three cloud providers, and I think that's something unique that Mongo's really focused on. >> But there were so many announcements that came out, in Andy Jassy's keynote a couple of days ago. I think I read 23 announcements just in the first 20 minutes, or something of his keynote. So much information, but I'm curious, did anything that they announced surprise you in terms of, hey, customers are living in this multicloud world, there's use cases, there's reasons for it? Any shift that Amazon is making or announced this week that you thought, yes, some of these things are becoming a reality? We have to go where the data is, and we have to deliver what's best for our customers. >> I mean, I think Amazon is a very customer-centric company. I don't think I heard any announcement that particularly acknowledged the fact that it's going to be a multicloud world, you know, I think they're still the market share leader, they have a rich set of offerings, and they're going to continue building on that which I think makes a lot of sense from the position that they're in. I think some of the announcements that are interesting to us, definitely the idea of having lower cost, higher performance ARM hardware and chips for our database vendor. If we can lower the price performance curve for customers on top of that infrastructure, that's exciting for us, and we always think it's interesting, in a AWS keynote that's two or three hours long that about a third or half of it is talk about data. We love data, so the more rich sets of services we can surround and integrate Mongo into, the better, so, exciting for us. >> Data seems to be like the next generation of cloud, data can become a huge asset for any business in any industry, whereas, there are companies and times where data was a risk, a vunerability. What is a great example, in your opinion, of a MongoDB customer who has done a great job of transforming to where data is now a huge asset, and a driver of business differentiation? >> So, one interesting customer example I really like is Axiom. They're a marketing data provider, data has been the heart of their business for a long time, but traditionally their business would be packaging up and shipping data sets to their end customers, in a very custom bespoke manner. What we worked with them on is leveraging our cloud platform Atlas, along with some API technologies that we have, and a product called Stitch, to make it very easy for them to create custom APIs to allow their end customers to access that data programmatically. And since we manage and run that on their behalf, their development team, their operations team don't have to worry about the plumbing and managing of all these API layers and all that, they just stamp out these custom APIs, we auto-scale them on top of the rich Mongo database on the back end, and so we've allowed them to really take the data business they were in, but really modernize it by exposing it directly to developers programmatically instead of just shipping data around which is expensive and cumbersome. So I think that's a really interesting example of a data company transforming itself, and kind of innovating in the cloud with some of the technologies we provide, obviously, on top of the Amazon platform. >> So, you mentioned transforming, that's definitely been a theme of the show. So MongoDB is a different way of actually managing data, so compared to traditional methods. A lot of enterprises still have a lot of investment in RDBMSs, more traditional kind of databases. What are you seeing when customers come to MongoDB and start using this different way of storing and managing data? What is that transition for them like? >> Sure, so I think the thing that MongoDB's inception 11 years ago through now, what drives our adoption, I should say, is really the fact that developers love our platform. The document model, the MongoDB API is just a much more flexible and natural way for developers to think about writing applications, so, you know, you're building an application, you might be managing a customer object, a product, an account. These are all sort of business objects that get represented in a developer's mind and then in an application, but then if you put that in a relational database, you're chopping that up into rows and tables, and then having to rejoin that back together just to make sense of the underlying information you're trying to represent. Mongo gets rid of all of that cognitive dissonance, and that's what really unlocks that developer productivity. Now, the interesting thing about MongoDB is as a non-relational database, we have looked at the legacy RDBMS providers and said, what are the things that are really strong about those platforms that we can bring forth and apply to this much more agile and natural data model? So things like data governance and schema, strong transactional guarantees, enterprise management functionality, enterprise security and encryption at a very deep level. These are things that large mission critical application developers and operators really need. And they don't typically find them in fast databases, scalable databases, like MongoDB. So what we've done is really merge the best of the legacy traditional databases, the things people expect in a rock-solid mission critical database, but brought it forward in a model that's much faster for developers to move quickly on, and so the way that represents itself in our business, roughly about a third of our business any given quarter, tends to come from legacy migrations off of some traditional relational database, and the driver for that is modernization. People want to move those apps to the cloud, they don't just want to lift and shift from one relational database to another necessarily, that might have certain cost benefits from one provider to another, but it doesn't unlock that developer agility, and that's why they're choosing MongoDB. >> So all in the spirit of transformation, the ability for MongoDB to unlock the developer productivity, one of the things Andy Jassy talked about on Tuesday was, one of the four essential pillars of transformation. It's got to come from the top down, it's got to come from that senior executive level, they've got to drive it down aggressively. As chief product officer, where are your conversations? Are you still, in terms of feedback and, you know, customer advisory information, are you still talking mostly to the developer folks who were the primary users, or are you also having those higher level-- >> Sahir: Both. >> Both, tell us a little bit about that. >> Now what's interesting about a data technology like Mongo is, it's not a top down sort of sell. No CIO, CTO, line-of-business executive is going to dictate down to their developers, thou shalt use this particular database technology, or what not. Every development team is going to choose a technology that allows them to move fast and meets their requirements. So, what we've really done is we've focused on engaging with our customers, our sales organization, our marketing organization, our developer relations organization, is merging a strategic top-down sort of model with those CIOs and business leaders about how MongoDB can transform their business as a data platform. Get that sponsorship, get that executive alignment, to be a strategic provider, but then at the same time, really fostering that community that MongoDB's always been known for bottoms up to make sure that more and more of these applications see the power and value of MongoDB. So we have to merge both those motions. If we were just bottoms up, then I think we wouldn't be as strategic as we are in many of these organizations in terms of how transformative as a vendor and a technology provider and partner we are. But at the same time, if we lost our roots with the developers, databases don't get chosen from the top down, they get introduced and put on the list, maybe, and sponsored into the account, but we've got to build and earn that trust with developers directly. >> Yeah, so you've had incredible success, incredible growth so far. >> Sahir: Thank you. >> What's next for Mongo? >> So, I think a big part of our journey for the last three or four years has been really, adding a second major growth engine to the company by building out our cloud business. So that was our MongoDB Atlas platform built on top of AWS, Azure, and GCP, and that is the fastest growing part of our business, and will clearly be, you know, the majority of our business in the future. The next year to two years, is really about transitioning from a single data product company to a data platform company. So earlier this year, we announced not just the core foundational database features we're always building on top of, but also a big step into analytics, with our Atlas Data Lake product, which allows development teams and analysts to run queries using the Mongo query language they love, but on top of S3, where they have mountains and mountains of data stored from all these different sources. And at the same time we've also added things like full text indexing, so instead of standing up a, search cluster next to your Mongo database, having to worry about copying data just to get full text search in your application, we merge that capability directly into the Atlas platform. So, a big part of our journey is saying, once we have so many customers on the platform, how can we add more value, and yet still merge that all in a very expressive developer experience with our query language? So they're not dealing with 13 different databases and four copies of their data and integrating and shuttling that all around, but is a very prescriptive experience for them. >> Wow, Sahir, thank you for sharing all the innovations that are going on at MongoDB with Justin and me on the program today. A lot going on. >> Yeah, thank you for having me. I really enjoyed the show and coming on theCUBE. >> Lisa: Good, we appreciate your time. >> Great. >> For my co-host Justin Warren, I'm Lisa Martin, and you've been watching theCUBE from Vegas, baby. AWS re:Invent '19. Thanks for watching. (electronic music)

>> From the Aria resort in Las Vegas it's theCUBE. Covering AWS marketplace. Brought to you by Amazon web services. >> Hey everybody, Jeff Frick here with theCUBE. We are kicking off AWS re:Invent, I don't know how many people are here, I'm guessing 60, could be 70, I don't know, there's a lot of people here in Vegas and we're excited. We'll be here for nine days of continuous coverage spread out over three calendar days, and we're kicking it of tonight. We're at the AWS Marketplace and service catalog experience here at the Quad over at the Aria, so stop on by, there's a lot of cool things going on, and we're excited to have a CUBE alumni on to kick things off. He's Sahir Azam, the SVP of Cloud from MongoDB. It's great to see you. >> Thank you Jeff, great to be here, exciting week coming up at AWS re:Invent. >> Are you ready? >> I think I am ready. It's going to be a long week in Vegas, but it'll be a good week. >> All I could think was all those posts before we got started, said how to plan your time at re:Invent, >> They all say drink a lot of water. >> Drink a lot of water, stay hydrated. So we last caught up at Summit in New York City, I believe. >> Yeah AWS Summit in New York. >> So that was last summer, so how have things been going since then? >> Things have been great, obviously, the business is doing really well, especially our cloud products MongoDB Atlas, and MongoDB stitch have been an absolute rocket ship for the company and that's why we're here, is just really help the community, and drive even more adoption of our technologies in the market. >> So is that a big strategic, I mean obviously, it was a big strategic move for you guys inside, but I'm just curious some of the thought process behind, you know, offering a database as a service via a partner like Amazon. What were some of the things you were thinking about, and how's it kind of turned out based on what your expectations were? >> Sure, yeah, I mean I think, if you look at just overall adoption of MongoDB, obviously you know, we're one of the most widely adopted databases in the world, given we're open source, and really a pioneer in modern non-relational databases. >> Right. >> We've always been heavily used in AWS, even from the early days, nine or 10 years ago and in many ways we feel like we grew up in the cloud, as a company, given just our technology and adoption in that marketplace. Now, what's changed is I think probably, five years ago or so, we really started to hear customers say, you know we really want to get out of the business of operationalizing and securing, and managing these databases, and would rather you give us the same technology, the database we love but deliver it as a service on our cloud platform of choice. So we started on a project internally, to build MongoDB Atlas, which is now available in 15 plus regions on AWS, as well as other cloud platforms as a global database as a service, to help those customers move even faster >> Right >> with MongoDB. >> And it's been about a year right, since you since you released it? >> It's been about three years for MongoDB Atlas, but especially in the last year we've started actually selling out was through the AWS marketplace. >> Right, right. >> Which is really fantastic. >> So how does the marketplace change? I mean obviously, Amazon's got a great scale, and it's a nice sales force, sales presence for you to leverage so, how has that relationship gone? >> Yeah, it's gone really well actually, and especially in large enterprises. I mean, we have large automotives, we've got manufacturers, we've got you know telcos, that have sort of all procured our technolog6y through the AWS marketplace. And I think the benefit for us as a partner, really comes in two ways, first and foremost, its awareness, there are definitely some AWS customers that find their technologies by searching on it in the marketplace and when we pop up, and say okay great this is the databases service from the people behind MongoDB. That instantly just drives our awareness up, and then secondly, it drives really good alignment between our sales teams and Amazon sales team. So the AWS sales force is now aligned and incented to work with us on driving joint opportunity for MongoDB, and now Amazon customers. >> So is there a lot of joint, kind of opportunities that you guys are working together? >> Yup. >> I guess my perception would be that more the marketplace is, you know I find it, I order it, I install it, versus more kind of a joint enterprise sale, but maybe that's not. >> For us it's actually been really interesting on the joint enterprise sale, where it's been, you know they're really that high touch model because it's beneficial for customers to be able to buy their technology through the marketplace, and it's also beneficial for our go-to-market, and our sales teams to be aligned and not feel like we're competing but are actually driving an outcome together for the customer. >> Right, so partnering with Amazon's been a good experience, I know a lot of people are kind of afraid, do we to be partner with these guys, are they big, are they going to you know roll up our functionality? But you guys had a great experience. >> Yeah, I mean the reality is we there are definitely database technologies from Amazon that we compete with. But that's true of probably every technology vendor, and where there are places for us to work together, and deliver real customer value, I mean we're the most widely adopted modern, non-relational kind of database on the planet. >> Right, right. >> So Amazon probably sees that demand, and it's been a good working relationship through the marketplace team, especially at Amazon. >> Good, so I wonder if you can share some other trends you've seen in the marketplace, especially as you said you guys are doing a lot of joint customer activity, what are some of the things you're picking up on, what are you hearing out on the streets? >> Sure I definitely think server list continues to rise. Right, this past year with G8 MongoDB Stitch, which is our server list platform that makes it really easy to extend the power of the database all the way through mobile devices, client applications, and really have a data architecture and not just think of Mongo as something that's used on the backend, so we've been seeing quite a bit of adoption of that platform, and in particular for use cases where MongoDB Atlas is used with complimentary AWS services. So if you want to use AWS Lambda with a MongoDB database, the best way to do so is with Stitch. You want to tie you know Kinesis and streaming technologies into a database for MongoDB, Stitch makes those integrations natively in these other AWS services really easy. >> Right, so I'm curious get your perspective on kind of what percentage, don't share anything you're not supposed to share, of the sales on these things are, new kind of projects inside these enterprises, versus people doing migrations, because there's always this big debate right on legacy? You know you're going to lift and shift, and move it all, versus let that stuff just do what it does, and really the opportunities on Greenfield. >> Yeah, I think, it's probably hard to quantify, but we certainly see a few different patterns. First and foremost, there's like large enterprises that are lifting and shifting, and migrating those applications from on-premises data centers and into the cloud. And really what we see is an opportunity, not just to lift and shift, and manage things the same expensive slow way, but to actually modernize at time of migration, as well. So you can adopt the benefits of a platform as a service, or a database a service like ours, while you move into the cloud. So that helps customers move faster and operate in a much more economical way. So I think that's sort of one piece of it, and then of course there's all sorts of new modern applications, whether it be Connected Car or IOT platforms, modern mobile applications, we're seeing a fair share of like new, fancy applications being built, as well. We definitely see both, and I think for us, one of the things that's unique is given there's been so much MongoDB adoption in AWS, we're seeing a migration of customers that want to get out of the business of running the database, and want to have us manage it for them in the form of MongoDB Atlas. There's that third camp of people are already in Amazon, using MongoDB, but are now saying I want to move it into Atlas because it provides a much better way, and in fact, it's probably the best way to run MongoDB in the cloud. >> Right, right, it makes a ton of sense. I'm curious I'm the first one though, when you talk about modernizing while you're lifting and shifting, or while you're shifting over from legacy infrastructure, what are the key things without doing a complete rewrite, that people can do kind of a modernization of the application, 'cause that's kind of an interesting concept? >> I think it's two things, there are certain applications that people don't want to touch and change that much, and those are probably good candidates to lift and shift, and try to minimize the amount of change on. But frankly those are oftentimes not the most strategic applications anymore, they might be important to keep the lights on, but they're not the ones that are driving the customer experience or driving the revenue, you know new opportunities for businesses. Many of those applications are actually being kind of decomposed from monolithic old technology stacks and legacy tools to more modern micro services based architectures, and what we're seeing, is oftentimes the trigger for that modernization is a cloud migration. So in many ways what we're saying is, get off of a legacy relational database technology, move to the cloud, but don't now operate it the same way you always have, actually consume it as a service, and that's what's really going to unlock all that developer velocity, the elasticity, the cost savings people expect from the cloud. >> Right, so is the the database really the key piece for kind of a modernization effort, without rewriting the entire application? >> I think it's one of the most important pieces, for sure. I mean we like to say that the database, in many ways, is the heart of the application, because an application without data is really sort of generic and useless. So it is definitely one of the more complicated areas, and that's why we spend so much time with customers, building technology that makes it easier for them to modernize, leverage new capabilities, even if it's only new features in an application, versus a rewrite of the whole old model right with the block. >> Alright, Sahir, I think they open the doors, I think AWS is coming in. >> The rush is coming in. It's officially underway, so I know you got a busy week, I got a busy week. >> Likewise. >> Thanks for taking a few minutes of your time. >> Absolutely. >> And stopping by. >> Yeah great to see you. >> Alright, great to see you. >> Alright, thanks for stopping by. He's Sahir, I'm Jeff, you're watching theCUBE, we're at the AWS marketplace and service catalog experience, at the Aria, stop on by, see ya. (dance music)

(intense orchestral music) >> Hi I'm Peter Burris, and welcome to another CUBE Conversation. Got a great conversation with a CMO today, we're going to spend some time talking about some of the changes affecting the tech industry, and specifically affecting marketing in the tech industry, and we're gonna be having that conversation with Meagen Eisenberg who's the CMO of MongoDB, Meagen welcome to theCUBE. >> Thank you, thank you for having me. >> Well so, we're gonna spend some time talking about a number of different things but MongoDB is an especially interesting company in the context of this conversation, why don't we start by tell us a little bit about MongoDB. >> Sure, MongoDB is a leading modern general database platform, downloaded by 35 million developers, and is used by the hottest private companies like Coinbase to storied brands like HSBC. >> So if we think about it, the reason why I think this is especially interesting is because MongoDB is an opensource company and so that means that that has some specific marketing challenges it recently went through an IPO, and the marketing role in IPO is especially interesting, but very importantly here's where I wanna start, that in many respects the tech industry has always been set up to sell products, and the proposition was I know about my product as a seller, you don't know that much about it, user, so I'm gonna spend an enormous amount of time bashing you about why my product is better, that's changed a bit, as we move to this digital transformation and the role that data plays in helping companies transform it's less about what the vendor's doing and more how the company utilized the technology it's kinda this underlying from a product orientation to a services orientation it has a continuous relationship. >> Yes, that's right. >> Especially in the opensource world where you have a continuous relationship with your developers. Tell us a little bit about how, at least in your experience at MongoDB, that relationship, that from a product orientation to a service, ongoing service orientation, affects marketing. >> Sure, I mean we think a lot about how are user are using the product. You know, we wanna win the hearts and minds of developers, they're out there building new ideas, they're using it, when we enter a company through one developer we have the opportunity to spread to many others you know, if we think of all size businesses there's thousands if not 10s of thousands of databases and applications, so we wanna make sure they have a great experience that we're collecting data that's useful to help them, and that it spreads to others. >> Now lemme amplify wat you just said, because again, we could go back and think about other technology companies where the role was to explain what a relational database was and why it was better than something else, and what you just described is no, we wanna create a community of users that are constantly developing their own visibility their own insight and our job is to call the best of that and use that as part of the marketing experience, do I got that right? >> Yeah, that's right. Developers are actually quite social, and when they're out there building or they find something new, they're creating apps, they're creating new tools, they're sharing that knowledge and so, from a marketing standpoint, we do a lot of work with developer relations building apps, out there speaking to language communities, we're out there at conferences really showing what the technology can do. >> So the, many years ago I had a conversation with a CEO who's now worth billions of dollars, and I asked specifically, I thought that marketing had been essential to his success, and he said something very interesting, he said ah, marketing, that's what I put between my engineers and my sales people so they don't kill each other. (Meagen laughs) That can't be the role of marketing in a community-oriented company. Tell us about how marketing stands in a collaborative relationship between, with product and sales at MongoDB. >> Sure, so, I mean for myself personally as a CMO, I think the success of marketing is it's relationships not only with sales but with engineering, and that they're really, sales I see as a internal customer, understanding what they need to be successful, making sure that we're talking to the right persona that we're helping them build pipeline we're putting tools out there that are helping the user go through the experience, and from a engineering standpoint, that we're collaborating, that there's a feedback loop as people are using the product we want it to be a frictionless experience when they meet us out in the field or they come to our website, and that part's important as a registering for the product, as they come in, as they start to use the product and making sure we all have access to that data it helps sales better do their job, engineering build a better product, and marketing better really hook, hook the user in. >> So marketing helps sustain that journey, but also, also being, ensuring that sales is getting the appropriate information and insight on what customers are doing, but it's much more, it's multi-nodal today, I mean people talk about multi-channel all the time, talk a bit about how you anticipate the engagement model changing as more personas get involved, as technology gets more deeply embedded into the risk profile changes, and very importantly, especially for a company like MongoDB, as the number of use cases explodes. >> Yes, yeah I mean it's a good point, we are, from a marketing standpoint we're going directed developers who wanna do self serve with our MongoDB Atlas product, all the way to the CIO and CTO, who are trying to digitally transform their businesses, and that's, they're all different channels, it's not just email, it's social, it's your website, it's how you interact with them in the field, it's supporting your sales team, it's our developers that are out there working in the field and building the product. So you're right, at MongoDB we have 28 technologies in our Martec stack, and we've sunset seven, so we've experimented with 35, and the reason is because there's a lot of work around website, making a better experience, there's work around social media, how we design what we put out there, what we're doing in the field, making sure every experience, every form you fill out is is really optimized for that customer experience. >> Yeah, it's creating some sort of value with customers, not a distraction, not an annoyance. But if you think about it, another CMO once said, here on theCUBE, that they kinda summarize some of the new role marketing, is that marketing is creating the community, and marking is sustaining the community, where a community really is defined as people who are doing something in common. So your customers are trying to imply this technology that has enormous flexibility, I'm gonna ask you to explain a little bit about that in a second, we're not gonna get too deep, to a lot of new use cases, and that's what your users are trying to do bringing those together so they can share insights share experience, improve the quality tool, speed the process, the rate at which it all happens, there's gotta be a central feature of the marketing mission at MongoDB, is that right? >> Yes, definitely, I mean we're very focused on the developer, their experience, winning their hearts and minds, and creating advocates, people and developers that come and use the product and love it and build upon it and have, you know, things that they've learned that they wanna share, we have a pretty detailed documentation for new folks, we have a MongoDB university where we've had over 800 thousand developers take courses, it's definitely a highly engaged group that wants to innovate, and they wanna use the hottest technology, they don't wanna be on Legacy. You know, Legacy databases came out 40 years ago, the likes of Oracle, right, that was designed before cloud before mobile, before the volume and variety of data that we have today, and so if you want to build new apps you have to do it in a new, modern way, and MongoDB is a real alternative to those Legacy databases. >> Yeah, so one of the things I think is especially important as we think about some of this stuff, ultimately is, you said you wanna build that, the developer community, and make sure that engagement's strong while at the same time, obviously, sustaining relationships with other personas who are gonna write the checks, probably through your sales organization. >> Yes, yes. >> What is the role of diffusing knowledge through a service, I mean do you have a university or do ya, how does content get designed and instrumented at MongoDB to catalyze that community activity? >> Yes, I mean content's very important, all the way from our developer advocates at relations are building content to educate developers, to help them learn about the product, use the product, and then for the C level execs that are trying to transform their businesses, they're trying to learn about microservices, blockchain, there's a lot of content, and we see it like HubSpot really educated the marketing community around inbound marketing, we're doing a lot of work to educate and work with developers and create that digital watering hole so they can learn what they need to build their next app. >> Especially on the idea of complex, rich, natural data. >> Yes that's right, we believe that MongoDB is the natural way and the best way to work with data, and you can put it where you want intelligently as well as the freedom to run it anywere, our MongoDB Atlas runs on all three major clouds, with AWS GCP and Azure, and that ability to migrate, we're on 54 different regions, so really anywhere in the world you want to have your app running, we've got it set up for you. >> So MongoDB as a database company is trying to reduce the limitations of how well database can handle more complex data, the engineering is using an opensource approach trying to ensure that there's a high quality offering associated with that promise, >> Sure. >> You're deploying it on a lot of different platforms, cloud, not cloud, so that people don't face fundamental infrastructure complaints as to try to get advantage of that, that creates an enormous number of opportunities for someone to come in and try it, the whole try by motion, or land and expand as people like to talk about. How is MongoDB refining that notion of land and expand through its marketing mission? >> Sure, I mean well certainly we're making it frictionless for you to sign up, self serve, you can go put a credit card in, we've got a free tier where you can quickly experiment, try it out, as your application grows and becomes mission critical we've got the tools that you need to maintain it, we've got security and all the features you would need to run a modern application, and we're, we've set it in a way where no matter where you are in the world or who you wanna collaborate with, it's easy for you, it's very frictionless for the developer, it's a natural way to develop, and you're not, you know, you're not worried about the operational overload that comes with relational or Legacy databases. >> So we've talked a little bit about how MongoDB is working with developers, let's pivot a little bit and talk about how MongoDB worked with potential investors. I've been fascinated by the role that marketing plays within IPOs, you've got finance with a very very well defined role, sales typically has a very well defined role, but marketing's trying to straddle that fine line between driving new volume, but being very careful about what you say and how you say it to keep people feeling confident and comfortable from a financial standpoint. You got, you joined MongoDB three years ago. >> Yes, yes three years ago. >> You had an IPO about halfway in your tenure. >> Yes. >> Tell us a little bit about that. >> Sure, I mean, October 2017 the company went public it was a very exciting time, certainly the first time that I had been with the company and taken them public, I was fortunate enough, our CEO Dev Ittycheria had done it multiple times as a leader and as a board member, and so he brought a lot of knowledge around that, and as a marketer you're thinking how do you stay within the guidelines but make sure everyone's aware of what you're doing, certainly if you've been doing it in the past you can keep doing, you know, if you're not hyping the market, you can keep doing what you've been doing you can keep running your events you can talk about the product, the day of is a really big day to get in front of media, I was really impressed by what the team did to align media interviews I think we had 24 different interviews in one day, and we had over 50 or 60 stories break within the next week or so. So that was exciting just, you know, that timing, 'cause you can't line those up too soon, you've gotta make sure everything's a go, and, you know, it really worked out and now we're just excited about the future of the market, 60 billion dollar market by 2020 according to IDC, so we've got a massive opportunity in front of us, so what can we do, certainly from a marketing standpoint, what do I need to be doing to get on that and work through that. >> So MongoDB is a growth company, you know, good solid set of employees, tell us a little bit about how marketing's role is gonna change in the next couple years, as MongoDB tries to grab more of this 60 billion dollar opportunity. >> Yeah, I mean we definitely have a strong vision around where we're going with our products and solutions as a database platform, we're doing a lot of work with partners, we've got some great stuff going on with SA- SIs like Accenture and Infosys and Wipro who have modern, you know, they're modernizing the tech stack and working with really large companies, and we're part of that offering, so we'll be working heavily with that. We're very close with the cloud vendors, with AWS and Microsoft Azure and GCP, so a lot of good work going around that and we'll continue to grow our cloud offering itself, Atlas, MongoDB Atlas, it's only been around two years, it's already 14% of our business now has grown 400% over the last year, and so we're excited to see-- >> Congratulations! That's not bad. (laughing) >> Thank you, yeah, thank you. That's a, you know, really exciting part of the business and so much moving to the cloud it's the right place to be, I feel like we've done a great job really, you know, looking at where we need to be and then highlighting that in the markets. >> So last question Meagen would be Mongo is carving out an interesting spot for itself within the marketplace and as you focus on customers, customers are increasingly dictating how the market's gonna evolve, it's an interesting dynamic, especially that community approach, but there's always efforts to pull it back, especially from some of the entrenched database competitors. How are you guys trying to both keep the focus in what the customer needs, drive them to this modernization while at the same time acknowledging, recognizing, that they can't change everything on day one, that you have to coexist? >> Yeah, so, I mean MongoDB is doing a lot of work around migrations, making it very easy and frictionless. If you're gonna move to the cloud, this is the perfect time to move off Legacy databases, and we see it with our customers, they're struggling with 40 year old technology they need a more modern approach, they want a single view of their data, they're dealing with so much of it, and it's the right time when they move to the cloud. So we're making sure our product is on all the major clouds, which it is, and all the regions, that we've got the tools that they need, and that that process is really simple. >> Alright, Meagen Eisenberg, CMO of MongoDB, thank you very much for being on theCUBE. >> Thank you for having me. >> It's been a great conversation, and once again, you will see additional CUBE Conversations, until next time I'm Peter Burris, thank you very much for watching. (intense orchestral music)