 Hello again. So, we thought it'd be great. You know, everyone that we chatted with, as Toby mentioned, more than 50% of the folks are running things from the SMAC stacks. We really wanted to do a panel where we could focus on that. And I couldn't be more excited about having Neha from Confluent and Jonathan from DataStacks to join me today so they could come on up. Round of applause for them. So, you know, I think I'll start this just with that it's so fun to be on this panel with you guys. You know, it really is an honor for me. So, they're going to talk about themselves in just a second, but really quickly. Co-creator Cassandra and co-founder of DataStacks, co-creator of Kafka and co-founder of Confluent, that's pretty really impressive, guys. So, it's really, really fun to be on the panel with them. And co-creator Mezos, yeah, right here. Well, yeah. So, what we're going to do, oh, and all Apache projects, all Apache projects, yeah, which is great. What we're going to do to kick things off is, you know, this is a conference about Mezos and so maybe not everyone has as familiar about DataStacks and Cassandra and Kafka and Confluent. So, we're going to kick off first with Jonathan, oops, I failed. Let's try this again. Jonathan, first describing a bit more about Cassandra and DataStacks. Thanks, Ben. And yourself. So, just a quick correction, I didn't create Cassandra. So, I was part of a team of engineers at Facebook created Cassandra, and I was part of the team that got it into Apache and take it kind of the next generation of involvement with Cassandra. And I think that's one of the strengths of open source, by the way, you said, you know, we're all part of Apache, all part of open source, is it lets us, you know, kind of build on the shoulders of giants and we don't have to reinvent those wheels, but we can work together to do that. So, I think Cassandra is kind of an open source success story that it's gone from, you know, a corporate incubation to an open source success, even though those are two different teams making that happen. So, now a couple years after I started working on Cassandra, I founded DataStacks to commercialize it. And today, DataStacks is providing the S and the C in smack, but also graph and security and streaming analytics on top of that. So, I think early on, DataStacks had the reputation of, oh, you're just, you know, bolting Apache projects together, but it's come a long way since then. And just in terms of where we see this being used, in personalization, in fraud detection, customer 360 apps in particular are interested in the graph piece. And a couple of the verticals that are particularly interested, retail and logistics are really invested in this. Great. Thanks, Jonathan. All right. And you, Neha. Hi, everyone. I'm Neha. Thank you for the introduction. You know, one such giant that I was at, called LinkedIn, that's where Kafka took birth about eight years ago. And since then, Kafka has come a long way. I'm a co-founder and CTO at Confluent. We are the creators of Kafka and also the main backers of Kafka. So, let me just get a quick show of hands of people who have heard of Kafka, used Kafka, so I know the level of, okay, 90%. So, I'll just keep moving them. Okay. So, Kafka has come a long way. It started off as a messaging system, and today it's a distributed streaming platform, which means it allows you to publish and subscribe streams of data as in a messaging system. It allows you to store data in a, you know, replicated cluster and then it allows you to do stream processing, right? So, Kafka's claim to fame is that it's wicked fast, easy to use, horizontally scalable. And so, now it's used in thousands of companies worldwide to do all sorts of things, you know, from IoT applications, where it's used as, you know, sort of a messaging backbone for microservices to do streaming ETL. And now it's a basis for doing stream processing. And so, at Confluent, we provide an enterprise distribution of Kafka and a fully hosted service called Confluent Club. Awesome. Thank you. Thank you, guys. Yeah. So, you know, I think we got a great explanation of really where the M comes in, in SMAC when it comes to this world. I think both Michael from JPMC and Toby described that pretty well. You know, you think you all know what Mesos is, so I won't describe what that is. But really, I think what's more interesting is the glue that we're really seeing with this stack, with SMAC, and we didn't pull all the letters together, but we pulled the ones that we see the most that I see the most when I go out and chat with organizations, both open source users and enterprise. And I thought, you know, we'd kick off the panel with talking a bit more about those use cases. You know, you started to mention a couple of them. You know, what are the use cases you guys are seeing for SMAC? Go ahead. So, you know, one of the use cases I will talk about and then let Jonathan and Ben cover the others are, you know, use cases around interactive customer experiences and IoT. So, if I were to take an example of an interactive customer experience, Kafka, Mesos, Cassandra, a bunch of, you know, other systems are on cruise ships now so that you can go in and get a fully integrated experience of applying gambling credits and dinner reservations, offshore data centers, as well as on the ships. So, the hybrid nature of the deployment is one of the central aspects. My favorite IoT use cases around connected cars where, you know, they're trying to do these worldwide tracking of cars to detect problems earlier, learn about driver behavior, and so on. So, it's really, you know, around a span of different industries, also Fintech to do real-time credit card processing, and so on. This is always a question that I had trouble with, and especially early on when we were trying to raise funding for data stacks and the venture capitalists would say, well, what do people use Cassandra for and, you know, what are you better at than anyone else? And that was always a tough problem or a tough question for me because I've always seen it as a general purpose database, and you can build any kind of application you want. And so, kind of a way of framing the question that I think is more answerable is, what are the characteristics of those applications that make this kind of architecture compelling? And so, some of the characteristics are that they need to be always on. They need real-time responses. They need to be distributed, and they need to be scalable. And so, I think when you're looking at applications that require those things, I think all of us on stage are representing kind of that next generation that really that's what the SMAC stack is for, of that generation of cloud applications that your MySQL stacks aren't going to get you to. That's a perfect transition into the next set of questions. When you think about, again, where the M plays a huge role in the SMAC stack, it's providing that platform that can be the same wherever you are. If you're in the cloud, or if you're on a cruise ship, not a boat, don't ever call it a boat to a cruise ship company, or if you're in an edge container data center at an airport. And so, I'd love to hear from you guys the role that you guys really see of cloud in sort of the SMAC world for your particular projects and companies and for the greater SMAC as well. Yeah, so we see a lot of use cases where the SMAC stack is involved for two things, right, where the cloud comes into the picture. One is migration from on-prem to some kind of public cloud, which is really what I would call hybrid. And the other is fully public cloud deployments. And the things that people are looking for and the role that the SMAC stack plays in both of these deployments is a little bit different. For fully public cloud deployments, the thing people are looking for, as Michael mentioned earlier, is cloud neutrality. People are really scared of cloud lock-in. And so what they're trying to do with the SMAC stack is be able to just get cloud neutral and be able to move across different cloud deployments. The other aspect is, which I think is fascinating, is the migration aspect, right, particularly what DCOS does is give you sort of a layer in between the applications and your underlying infrastructure, so it really doesn't matter where you're deployed. And the other aspect where Kafka comes in is it kind of gives you this central nervous system. So be able to kind of sync data between data centers, whether it's on-prem or in the cloud, or one cloud to the other cloud. So earlier this year, we announced Confluent Cloud as a mechanism to sort of provide a fully hosted Kafka as a service in the public cloud and a Confluent Replicator to be able to sync data between clouds and on-prem on the cloud. I just add that in terms of the hybrid cloud, I think early on there was some excitement around, hey, I'll have a data center on-premise and I'll be able to burst into the cloud to provide additional capacity. And we're not seeing a whole lot of that kind of use case. But we are seeing a majority of our customers are in the public cloud, but very few of those are only in the public cloud. And they'll run part of their application on-premise and part of it in the public cloud, even though they're not necessarily part of the same Cassandra cluster. Yeah, it turns out that bursting thing can be a little bit harder when you have a data gravity, huh? It takes years and years. Yeah, yeah, exactly. Okay, great. So transition a little bit. What are you guys seeing? You know, is everyone starting with all a smack or just single parts? Or what are you guys seeing out there? And what are your recommendations for folks that maybe don't need all smack on pieces? So smack is interesting because it, as a term, it lets us kind of simplify the discussion and say, you know, here's, you know, I need to scale my application or I need to scale my data layer. I can go use Cassandra. I need to scale the complexity of my components. I can bring in Kafka. So it kind of has that framework of thinking about the problem space that's really useful. But, you know, from where I see it, I don't, I don't see people saying, I'm going to build a new application and it's going to be a smack application. And I'm going to use all of those tomorrow. But rather, I'm going to, you know, maybe, maybe my first data store is my sequel. And when I get tired of sharding that and it becomes more painful than I can tolerate, then I'll upgrade to Cassandra. And, you know, maybe I'll bring in Kafka to coordinate between my microservices. And these don't have to happen at the same time. So I see it more of an, as an incremental thing that people can adopt at different rates. And I think that's really healthy. Yeah, I'll add to that. I think I completely agree with Jonathan. That's how I've seen these technologies get adopted. I also think that it's easier to adopt the smack stack, whether you're doing it incrementally or not, because it's complementary to everything else that you have in your data center. So you can still continue to have your relational databases and your bat systems and your warehouse. And when you think about the world you end up with, there's a big chasm in the middle, right? You have the relational databases on one side, request response applications, and the warehouse on the other. And what the smack stack does is provide you sort of a, you know, good stack to come in with the chasm in the middle, which is asynchronous data processing applications. So, you know, the way I see this getting adopted is it's very much complementary in addition to all the things that you have for when you need fast data processing and data management. Yeah, yeah, yeah. Right, so I think the takeaway is don't just start with the whole thing. You can start with the pieces, but you'll probably converge as you go and add more of this functionality in. And smack is a great way to really talk about that entire architecture and all those pieces. I, you know, from our perspective, I think that's what we've seen as well. You know, we've seen some folks that have really started from the whole thing. Sometimes it's not just smack, it's smack or some of the other acronyms. But there's also lots of folks that start slowly and grow. So speaking of acronyms and smack and other ones, were you guys surprised that there ended up being a smack stack and acronym? And I think, you know, we need to give credit here. I believe to Alexi, I always mispronounce his name, Krabov, I believe is his last name, who I think was the first one that actually coined the term. Were you guys surprised that, you know, that there is a smack stack, that there was an acronym for it? So I'm not surprised that the smack stack exists, but I find the acronym very amusing. The other day, someone told me about the pancake stack. I won't go into the details over what that means. So I think, you know, the smack stack existed. It's been fascinating to see why it came along. In the last 10 years, the distributed systems have become a lot more practical. And I think in the whole world, like I mentioned before, right, you had databases and the warehouse and nothing in the middle. I think two trends really changed that, from my opinion, I think. One is digitization of the enterprise, right? So the need for creating data-oriented, you know, solutions, that's one. And the other is just the practicality of distributed systems in general. So these two things coming together led to explosion of data on one side and an explosion of distributed data systems that each solve one part of your data management problem really well. And to me, the smack stack is really a collection of the most well-adopted and, you know, most sort of prolific technologies that allow you to manage data. What I like about the smack stack is that, you know, if you look at some of the, you know, some of the stacks out there, they're an acronym looking for an excuse to exist. And I feel like with smack, people were building cloud applications and they needed that scale, they needed that real-time response rate. And so when I go to data stacks customers, I see a lot of Kafka, I see a lot of Mesosphere. So I feel like this was something that, whether someone was going to put an acronym on it or not, you know, these are some common patterns and common technologies that people are using to solve some of the biggest problems in the industry. Yeah, yeah. I like that as well. I think it's always better when the acronyms come later than there's some real usage, some real practitioners doing stuff and not just the marketing, nothing against the marketing, Peter. Marketing is really important. So, you know, one of the things we didn't really talk too much about, but I think really plays a role in this, especially with the growth of stack is open source. So, you know, how do you guys feel open source played a role in smack and has played a role in your projects and the companies? So I spoke to that a little bit early on. I think one of the things that's interesting thinking about the role of open source in the industry moving forward is the conditions that led to Cassandra 10 years ago and Kafka eight years ago, Mesos eight years ago, those conditions are changing. And in particular, companies today building new projects, they're looking for simplicity, they're looking to get everything in a box, they're looking for hosted solutions. And so, the public cloud vendors are playing a really a much more significant role than they were when our projects and our companies got started. So I'm not sure what that's going to look like for that next generation of infrastructure, whether that's going to be open source first or cloud first or something else. I'd really like to touch upon something you said earlier, Jonathan, about these technologies were born from these big giants. And I think that's a really important part of why the stack formed in the first place is because we got time to harden it in a real company for many years. So Kafka ran in production at LinkedIn still does for several years, which is why it became easy to use for everyone. But I think the role that open source played in how software gets bought and adopted in enterprises is really fascinating. Earlier, the decision of whether to use a Mesos or use a Cassandra or use a Kafka would have been a top down decision made by the sea levels. But today, I think due to open source, it's a very bottom up adoption model where the developer is actually the real buyer. You're the real decision maker of what technology to use, how it gets adopted, what problems it solves. Of course, later down the line, some enterprises do come in to sort of provide a full-fledged product. But to me, the just empowerment of the developers that is a real change that open source brought along that I'm very excited about. Yeah. I think it's very powerful the way open source has really empowered developers to be able to make the changes they want in their organizations. I think it's also really interesting to think about how the landscape has changed. And for a lot of these open source projects, sometimes some of their biggest competitors could be some of the big cloud providers that are taking those open source projects and turning them into products. It's one of the things that I've actually spoken about in the past at some of the open source summits. And it's one of the things that we're kind of definitely excited about trying to do at Mesosphere, which is make it so that you don't have to be locked into a single cloud, or you can have just as good of a SaaS-like experience for your projects and your products, even if you're the little guy, even if you're a small project or a small company, but you want to have the same flexibility of running at scale across multiple clouds simultaneously. So I think it's interesting how the landscape has evolved, and it'll be interesting to see how that continues to evolve in the future. Okay. I think from here, you would mention earlier a new acronym, Pancake. And I'm curious if you guys see a SMAC 2.0, is there a SMAC 2.0? We've got a 10-year-old project, 10, right? 10-year-old projects. We've got an 8-year-old project. We've got an 8-year-old project. Some might say that they're just getting to great maturity and scale. Some might say that that's a long time. Is there a 2.0? Does there need to be a 2.0? What do we think? You know, I think enterprise software is never rip and replace. So things that work well and are adopted, they're there to stay for decades. So I think one part of the evolution that is just inevitable is what I would call cloudification of every part of the SMAC stack. And what I mean by that is, you know, both capability-wise as well as operationalization of each of the components, right? Ben, you mentioned earlier multi-tenancy encoders. And that is what I would call, you know, capability-wise evolution of something like Mezzos. I see the same in Kafka. You know, security encoders is a big deal. If I were to take, you know, a couple steps for the look into the future, I might just say that it might, SPAC 2.0 might be called something else entirely. It's because of two things, I think consolidation on one side and proliferation on the other. You know, proliferation because each of the layers are solving problems that are extremely hard to date, right? Whether you talk about orchestration layers, and we just saw Kubernetes being deployed with DCOS. Or you talk about stream processing. I think there's this probably proliferation that's expected because these are large enough spaces and markets. And the other is consolidation. You know, if you just think about how Kafka was born, it was born in its messaging system today. It stores data that can be queried using SQL, and it allows you to write applications. So there's some overlap with both Spark and Aka, right? So I think it would be fascinating to watch how these things evolve, but I would expect it will be called something else. You know, if not pancake, maybe something else. I think SPAC is solving a distinct problem space in the industry for scalable cloud applications. And so I think what that does is it provides a foundation that you can build on top of. And so what I don't think is going to happen, I don't think people are going to look at that foundation and say, you know, I need to rip out this storage layer and put in a different piece there. But rather, I think what people are going to say is now that we've got a solid foundation, what can we build on top of it? And so you're starting to see this with things like deep learning for J, which provides machine learning for data in Cassandra analyzed using Spark. And so once you have that foundation, there's a lot of interesting stuff you can build. That's a perfect segue into one of my last questions, which is what do you see problems that we're going to be able to solve with SPAC that we hadn't been solving in the past? You see things that you either chat with organizations, you're like, I'm really excited to see people doing something like that in the future. Anything come to mind? I think one, I might take a stab at this is breaking down silos, right? I think earlier we saw the JPMC picture of all these risk management and all these different things. And in the old enterprise, those were just, you know, things that were locked up and in each in their own silo. I think the SMAC stack, it sort of, you know, provides or creates data as a first class citizen, as someone mentioned earlier. And I really believe that's like a big change that will really change how applications are built. You know, it's the same customer, no matter which loan you applied for, whether it was a car or home loan, if you're a risky user, you're a risky user across all those segments. So that's, I think, it's a big deal. I think, that's what I call event-driven, data-driven enterprise that's going to allow the brick-and-mortar enterprises to compete with the Amazons of the world. You know, just before Jonathan, just before you go, I just, what you got me thinking about is it goes both ways, right? I remember not too long ago I went to, I think I was getting a new parking pass in the city and they wouldn't let me buy that. I'm sorry to hear that. Yeah. And they wouldn't let me buy my parking pass because I had outstanding a speeding ticket. Was this a speeding ticket? No. I forget what it was. It was something. I said, but you guys are completely different organizations. They're like, oh, we've got this cool new thing smack and it lets us pull all the data together. They didn't actually say that part. But, you know, they were, and I just thought to myself, oh my gosh, what beast are we enabling? Because this is not good for me. I mean, it's great for the businesses. But I, you know, I had to pay a lot of money to get my parking. That's how I feel when I talk to the government agencies of what they're doing with Kafka. Just let's stop there. So, what about you, Jonathan? So you're saying smack can be used for evil as well as for good? Well, I mean, I guess I don't know if it's evil, but it's at least for making sure that we all pay our fines. So I think the technical problems that smack allows you to solve are pretty well understood at this point. I think maybe a more interesting question is what does smack do for your business as we move into this cloud first era of computing? And what smack does for your business is it allows you to maintain ownership of your data. And I think that's the crown jewel of any business. You don't want to be beholden to, you know, I'm sure the people at Google Cloud, we had on stage earlier, are very fine people. But you don't want Google owning your data. You don't want Amazon owning your data. You want to own that yourself. And that's what smack allows you to do. Yeah, great. Okay. So last one, totally off script, not thinking about what you guys do in your day to day lives. What's an interesting piece of technology that you guys are following that you think is really interesting that maybe the audience would find interesting too? To me, I think it's TensorFlow. The Google guys are here. They're going to be really happy. Android is losing, but TensorFlow is winning, guys. I just think it's fascinating. I mean, getting access to thousands of GPUs worth of compute and being able to use these algorithms that have been baked in for years and years at companies like Google. I think that's super fascinating. And thank you, Google, for outsourcing it. Jonathan, anything you can come to mind? I do think machine learning is in general, as embodied by TensorFlow is it's going to unlock a lot of new opportunities, both for entrepreneurs as well as for consumers. And I'm curious to see what, so the old joke is that AI is whatever we don't know, we don't understand how to do, right? So now that we kind of understand machine learning, that's its own space. It's not part of AI anymore. So I'm interested to see what the next kind of spin off from the AI world is. Yeah, I think it'll be really interesting, one of the things we often talk about within the MESIS community is how we can apply a lot of these kinds of things back to projects like MESIS. And I'm sure you guys think about those as well for your own projects. You know, ways in which the projects themselves, the technology itself can start to learn and be smarter and do things that humans would otherwise be doing. So I think that's a really bright and exciting future. Great. Okay, so let's wrap it up. Thank you guys so much for being part of this panel. It's been a lot of fun. Thanks again for being who you are and continuing to drive the industry forward. It's really a enjoyable time for me to be changing the world with you guys. So thank you. Thank you. Thank you for having me.