Season 2 · Episode 5
Cloud-Native, Open-Source, and Collaborative with Eric Brewer and Melody Meckfessel
What's the future of open source and distributed systems? Google Fellow & VP of Infrastructure Eric Brewer, Observable CEO Melody Meckfessel, and DataStax Chief Strategy Officer Sam Ramji explore the state of the art, the near future, and grand challenges for the next decade in cloud-native data.
Eric Brewer & Melody Meckfessel
Well, hello everyone. I am delighted to be hosting a conversation with Melody Meckfessel and Eric Brewer today about cloud-native data. So, we're gonna spend about 25 minutes exploring the state-of-the-art, the near future, and grand challenges for the next five to 10 years in cloud-native data. This is an awesome opportunity to talk with two of the people who have done more with cloud-native and DevOps than most folks in the industry.
Melody Meckfessel has spent 14 years at Google, where she built the infrastructure and led a thousand person engineering team that did all of Google DevOps, and then brought that to the public in the Google Cloud DevOps. About a year ago, Melody formed a new company. She became CEO of Observable, which focuses on data visualization as a high performing open source project, D3.js.
Eric Brewer is a Google fellow, the father of Kubernetes and author of Spanner and many other cloud native core capabilities. I learned a great deal in the last few years from Eric and his hard won experiences building distributed systems for search and for core infrastructure. Google is also ... Eric is also a professor emeritus at Berkeley in Computer Science. So good morning everybody.
So, Melody, I thought you might lead us out, and talk a little bit about what you're seeing in the structure of cloud-native data. You've had the brag book of what it means to do DevOps at high speed, relating that to data and what you're, what you're seeing in, in the world every day. I'd love to hear what you're seeing.
Thanks Sam. So, I think I am really interested in the human element, the folks that are actually writing the software and having to interact with the data. And we know that there are more people writing software than ever before. And we can call those folks developers. I like to call them creators because they come from a diverse, educational background and domain background.
And it's fascinating to look at, look at the rise of open source, right? We sort of take it for granted now. The open source way of developing is here to stay. And we know that today's software it's either open source or it's built on top of open source. So for humans, it means that we're more dependent on code written by other people, and we're also more likely to share code that we've written. These are sort of the social norms that we're in.
But there are a lot of challenges in that, right? There's a lot of duplication out there, there's a lot of tools, and DevOps really brought us this idea of, you know, how can we automate away the toil, and how can we bring in cultural practices that let us focus on that creation? Then we have to reconcile it with the fact that open source it's, it's, it's deep, it's, it's difficult to learn, and what can we do to make it easier? So, I really think there's a call to action here around improving how we understand and develop software and the applications that we're building.
But the interesting part to me is that we need to talk about the data as well when we're writing the software, so the complexity that we have to navigate with the data. So data distributed across multiple environments, across multiple formats, and I see a real risk and challenge that our understanding is starting to be connected, disconnected from that data. So I, when I, when I started looking into, well, how do we make developers productive? And how do we get them closer to understanding the data? Visualization was kind of an awakening for me. It is a powerful tool for thinking.
And if you look at the power of D3 and what it's done for humans in the world to use visualization to understand data, it's just a new way of, a new model of trying to come to a new understanding. And I think, you know, the visualization it's, it's not, it's not the end, it's the means to the end, it's the insight that it gives us. And it really, it taps into our human visual system so that it helps us think more effectively, and it exposes underlying data and code that allows us to question and explore and learn as we're building cloud-native apps, and as we're trying to manage this complex data environment that we're in.
So I really see a lot of power in visualization, bringing visualization to data, bringing visualization to software development and empowering not just what we call developers, but non-developers that wanna create and interact with data in powerful ways, and really build apps in a way that, you know, draws from a lot of the lessons of DevOps, but brings in this more intuitive way of interacting with data.
And, I think there's so much opportunity to move beyond looking at static text on a screen as we write code and we build the next generation of cloud-native apps. So those are some of the things that I'm, that I'm seeing out in the ecosystem and I'd love to hear more from, from Eric about his perspective.
Well, thank you, Melody. It's great to be here today even if at virtual. I was involved in the open source with Kubernetes and the reasoning behind that. And that certainly has gone well, I think it's fair to say. And when I think about why we did that and what we wanted to get out of it, I had a few things that stick out. The first of course is that, we wanted it to be a platform for everyone, and something that everyone could contribute to, and open source is by far the best way to do that.
But also we're trying to kinda change the whole industry, right? The goal here is to make the way you do development and the way you run applications be much more application centric, and much less based on the kind of the virtual machine you're using and the kind of model it, the virtual machine and OS and libraries that you historically have to deploy that really had nothing to do with your application per se, right?
So containers are a big part of that. Getting your container containerized structure for your application allows you to, to decouple some of this, but then Kubernetes is really more about how do you decouple arrays? How do you decouple the policy for running things? How do you decouple things like SLAs from the particular services? That's what a lot of Istio is about.
And so a lot of my focus now is on how do we do automation at the Kubernetes level and above, to make the experience better both for application writers but also application operators. How do you run a highly scalable service? How do you auto-scale? These are things that need to be done through automation, and when done that way are a great experience for developers. So they're, I think they're deeply tied together.
Second broad area I'm looking at this year in particular is open source supply chain security, which is really about how do you trust the software that you're importing, right? We are all now importing many different packages and not all of them are trustworthy. So how do you figure out which ones are? How do you tell when you're at risk? And the short answer is, we don't as an industry have a great answer to that yet. We don't even have good metadata about which versions are protected by a vulnerability.
And we're not even great at tracking vulnerabilities because it's a very human process today. You, you write in English what the vulnerability is, what version it affected, right. But that's not really the automation I'm seeking for all the rest of the platform. So we need to automate vulnerability tracking, automate dependency management, a lot of pieces here that actually make this whole experience significantly better. And in the past we didn't care because you kind of wrote your own software in house and you trust the code that your team wrote.
Now, most of your code isn't written by your team or even your company, and so why should you trust them? The answer is, well, it's open source and that's kind of a good answer, but we can make it better. Finally, I'll just add because of COVID, we ended up having a thousand interns that needed projects they could do from home, and now they're working on open source as well on all these projects, not just Kubernetes, but things like TensorFlow, Android, and Chrome, and Linux. And actually, we're hoping that they'll develop a lifelong love for open source as well. This is really a skill that I'd like every young developer to have.
That was awesome. A thousand Google open source internships this year. Thank you, Eric. You know, it's, it's always a funny thing to look back and say, “Who, who had the metaphors that helped us understand the world?” And I think Tim O'Reilly was one of the people who really helped so many of us get a sense of the world we are in. So he said “The internet architecture is small pieces loosely joined.”
And I think it spoke to construction of open source as well. It's hard to imagine being cloud-native without open source. So the thing that's been attracting my attention the most is the state of data in open source, the state of data in cloud-native, because as those small pieces start to move together more effectively, they can be joined loosely. You can have data that has many different opinions, you can have many different data infrastructures.
But the real transformation that I'm seeing in cloud-native data is, most databases were built in an era where they had nothing they could depend on, and they had to guarantee you awesome raw performance. So they tend to be more bare metal. And then it moved to virtualization. They still wanted to have a lot of control over the system under virtual environments. But the move to cloud-native is really fundamentally transformative.
So with Cassandra, what we found is, it's a good structure for our cloud-native database because it's able to refresh itself, replicate effectively, spread the nodes, and it uses eventual consistency to get global scale.
But it used to have to take care of all the lower layers by itself. So of course it did it in a slightly monolithic and quirky way. But being able to embrace that idea of, of small pieces loosely joined, letting go, kind of exhaling, trusting Kubernetes to take on, a bunch of that also lets us improve the lives of operators. So part of Melody's quotes in our Google DevOps days were, "No grumpy humans," right? And what makes grumpy humans is having to do the same routine work all the time.
What are the really cool things about Kubernetes is this operator pattern. So we've learned a lot in actually managing Cassandra on premises. We've been able to extract a lot of those things into a Kubernetes operator for Cassandra. So, you know, there are a lot of people who are working on cloud native data. I don't think any of us has the right solution.
But what we're trying to do is figure out, how do we, how do we take what happened in the 2000s, you know, where people like you know, Andy Bechtolsheim, and his company Arista and others created a networking infrastructure that could let us simultaneously address billions of devices.
The 2010s where, where this team, you know, Melody, and Eric, and others built a compute infrastructure that could scale to billions of nodes, right, billions of workloads. This next piece, where we bring data along for that ride, I find that really fascinating. So that's what gets my propeller hat spinning these days.
So let's talk for just a bit about sort of state-of-the-art what, what you're seeing Melody and Eric in the practices of, you know, operating data, sharing data. I think you've got two real different views, because Melody these days you're, you're focused very much on the, the, the end user experience and the author, right, the editor who's making the data consumable to people through visualization.
And Eric, you're looking at the ability to automate the production of data, right? Sort of the infrastructure for data pipelines among others. So I think you'll have real, real different points of view, I'd, I'd, I'd love to hear from, from both of you maybe starting with Melody.
Yeah. Thanks, Sam. There's, there's three areas that I would highlight around data and data exploration. So the first thing that I'm seeing just it builds on a lot of the lessons and evolution of DevOps. And that is that we want the exploration of data for developers and creators to be as real time, and as interactive as possible. And that means, you know one of the things that we're doing at Observable is you're working in this environment where there's no compiling required. It runs like a spreadsheet.
So when you're writing code and you're interacting with the data, you're getting that immediate real time feedback. And that ability to sort of learn and explore quickly through iteration is dramatically changing, you know what, what we think of as, as data science, right, in terms of the ability to model, explore, and analyze data, and really move beyond ... (laughs) make a joke about this, but here you're working towards some output and then you get to the thing that you're, the visualization, and then you make an image of it, and you put it in some other format like a slide deck. We need to change that.
And I think the reason why we need to change that is, we need to get folks across the organization connected to the data itself, and the logic, and the decision making that happens around that data. So, bringing an environment where everyone can explore and interact and make it as transparent as possible.
The second thing that I'm seeing is that, it's, you know ... In the open source community, there's thousands of examples out there. And so, one of the things we're trying to do is really harness and bring together communities like D3 and Vega-Lite, so that you don't have to start from a blank slate, right? You can find an example, you can fork it, you can bring in your data and you can immediately get up and running.
And that model is something that we're used to. We need to just bring the community around it, right? Importing code, so you don't have to write it yourself. And then you know, I would say the final thing that I'm seeing is just sharing and collaborating, right? We don't write software alone, especially in this clump, complex environment that we're navigating, and so the ability to collaborate and share what you know. I love the example from the internships that Google's enabling, where I think of all those folks that are now gonna be able to share and collaborate out in the open.
And I'm very inspired by our ability to break down the walls between the tools and the people. So data scientists and developers working more closely together and sharing information. Data analysts you know, data storytellers, and other types of creators, making it possible for them to come together, to do the exploration, to have examples to start from and to be able to share and collaborate. And you know, in, in my view of the world, I want everyone to be part data scientist, because we don't have any barriers around exploring the data and getting to the insight that we, that we, that we wanna find.
I love that quote, “Everyone is part data scientist.” I learned a lot from you when I got to work with you at Google as you were building out the SRE tooling. And I never really understood what an SRE did or what they were until I saw the tools. And I realized, "This is data science in operations." Right?
So that idea of, of the visualization shape in your cognition, and then using that collaborative toolset to be able to look at different visualizations and the group could think differently about why the system was down or you know, what were the issues that were that were showing up in production because that's where science is practiced, right? When your systems are down, (laughs) you need science 'cause the system is way too complicated to just kind of, you know, do it by logic.
That's right. Yeah.
And you said something else super interesting. You talked about forking data. So you and I haven't had a chance to talk about this a lot. Again, I've learned from you in your current role but maybe you could talk a little bit about the code experience 'cause I don't think most people think of data as something which you fork or code as something that you get to do a lot with data. People probably associate like R or Python with the
Yeah. So the motivation for me with what we're building in the platform is that writing databases, creating databases, it's, it's really challenging (laughs). You know, not only do you need to ... You have an idea and, or question that you wanna ask, but then you need to go to the data and you need to figure out how to bring the pieces together, and model, model what you're trying to, you know, to explore.
And then you need to apply the logic, right, and get to a visualization where you can interact. And that could be, you know, sales regions in a particular area, it could be what's the best algorithm for me to apply to the application that I'm building or the best configuration dashboard of what's happening with my service right now, and how I would visualize that.
It's difficult. Like those data pipeline steps are challenging. And the way most people work now is that the data scientists are in their own toolset, working in their environment, and when they have something interesting they throw it over the wall to the developer team to turn it into something that's interactive and can reach more folks within the organization or out in the world. And so if we start to make it easier for folks to get started in the same environment, you find an example of the database that you want. Maybe it's D3, maybe it's Vega-Lite.
And because it's reactive, you get to see those updates real time. And again, I think that immediacy and that level of interactivity around, "I don't have to, I don't have to start from like a blank slate you know, or like (laughs) some sort of blank terminal (laughs)." But I can take something like, "Oh, you know, this looks like it's close to what I'm trying to do. I'm gonna fork it." And then I'm gonna start to bring my own data in, and get to the outcome much faster, much more ... You know the velocity is higher, it's faster iteration and ultimately you know, it's, it's better, it's getting to that better decision and that better outcome.
And so I, I just think it's so powerful. And this, all of this forking came you know, came, came from, came from the open source community, this model. And we probably take it for granted, but it's so powerful. And I think we have the potential to reach many more folks to create that, or don't consider themselves
developers, right? They're data hackers or they're data storytellers or you know they have accessibility to code now because they're starting from an example and they can tweak it and learn much faster.
It sounds transformative when you said that the state-of-the-art was to throw it over the wall, that reminded me of the old bad days before DevOps.
So in some ways, this, like this, this sounds like a DevOps transformation for data pipelines and, you know, data, data understanding. Eric, you know, you've been, you've been at the forefront of cloud native data. You've seen it, you've, and built it at scale right? I think you're starting to see some, some changes in patterns from large blankets of distributed cloud-native data. I'd love to hear about that, and, and then maybe more pointedly, right, you've been pushing Kubernetes to do a better job of embracing statefulness, because it's kinda solved the stateless environments.
There's an architecture under, under statefulness, which is not just staple sets, it's what are you doing with data management and how are you doing storage. And you've got, I think a lot of, a lot of hard won thoughts about what needs to happen in Kubernetes for that.
Yeah. It's a super interesting space and there's a bunch of kind of large trends going on that are high indirectly, what Melody just said. And one phrase I think is, I've been using a lot internally is data transformation. And I distinguish that from the classic model data management, which is basically, "I have a database and I updated in place." And that's what most traditional applications do. They store their data, they make it change, they write over the previous data with new data.
And that ... It certainly starts to make sense if you had a limited amount of storage and you didn't have room to write it twice. But actually when you say the word fork, it actually implies that you're making a copy. And I actually think the velocity change we're seeing is exactly because of the copy. Right. When you transform data, you're really making a copy and then transforming it. And that gives you some wonderful freedom.
Particular, you and I have your own copy and you can muck with it however you like, right? Which means you get velocity, it means you get autonomy, you get independence on the things you want to do. And it's the ... In fact, the only way to do large scale collaboration is through this copy model, right? We can't actually give access control the database rows to all of the people in open source. It wouldn't work, right? In fact, get is the same thing. Get for code is basically a fork model where you make copies of things, maybe we can reintegrate your changes back in, but there are actually separate things and you work on them autonomously.
So, there's lots of reasons that transform model is actually better just fundamentally. So for example, think of all the fields of science. You're doing science, you have raw data from your experiments, you don't ever wanna change that data, right? You should never be writing over the raw experimental data, you should be transforming it as you learn, as you apply different pieces of statistics or machine learning to that data, you produce new things that are outputs.
So it's much more of a data pipeline model, like an Apache Beam, for example, and I see that model actually works quite well on Kubernetes. Because actually it's easier to do transformations and pipelines than it is to do live update in place database management. So we actually can take advantage of that.
It's a better fit for velocity, it's a better fit for collaboration, and it's a particularly a better fit when you don't wanna lose the original data.
Right. So lots of places will move to this model if they haven't already, and I think many have without realizing that it's actually a different model. Now we still need to do updates in place databases and manage accounts, and there's lots of reasons for additional transactions and Kubernetes needs to be better at that. And also, kind of state-of-the-art, will give you a node with a disc and you can manage it yourself, right? Make sure you get the same disc every time.
So if you could do logging, you have a place to do it. But that's not all that helpful. It's sufficient, but not super helpful. Whereas in the pipeline, in case it's much easier. Well, you can go back to some classic things like MapReduce, one reason it worked well is that, it's a transformation pipeline and it never messes with the original data. It just produces new data.
So doing it in parallel, doing it with fault tolerance is really easy 'cause if you screw it up, you can just start over, right? Literally you just rerun the partial transformation. So that's a nice model and I think people should adopt it more explicitly. I think many have, but we should actually talk about it as a separate thing from classic data management. And that'll, that'll I think give people some freedom to actually feel differently about how they wanna share things and even what they wanna share.
Yeah. You've said that DevOps is all about velocity, right? Doing more things on your own and not having to wait on others. So, I, I hear, I hear echoes of that in your comment.
Data transformation is the same thing for data velocity that decoupling developers from operators does for code velocity, right? If you can do a launch without having to do a launch calendar and a whole bunch of reviews because your infrastructure is kind of giving you guardrails that keep you safe. That's what gives you velocity for application deployment and development. I think data transformation has the same feel too. You can transform data without much risk to the original data, which means you have much more freedom to do so.
It also sounds like this is in keeping of your ... You're thinking on you know, having a larger number of smaller databases right against, against a common, you know, back plane or a fabric.
Yeah. I want everyone to have their own copy of the pieces they need to work on. It's good for lots of reasons, including basic availability. All right. If you have copies it's easy to keep one of them around (laughs). But I think more, it's more about the autonomy. Like, does your group have the ability to work with the data and transform it as needed on your own schedule with your own processes, right? That's what gives teams the feeling that they actually can make progress quickly. Right? It's that autonomy. So we want that for both data and for applications.
One of the things that we, we're also seeing is the ability to support all that stuff at a level of, of economic efficiency. So there's a pattern that I don't think has been used a lot, but it's starting to come up. We've just been developing this recently with Astra which is our Cassandra for Kubernetes, runs in GKE as well as in EKS is multitenancy.
So multitenant Cassandra gives us a chance to leverage so much what's great about Kubernetes, but also be able to say, “Hey, for, for these fast on fast off workloads for led experimental trial workloads, it's cheap and efficient to be able to start something get going, spin it up, spin it down.”
So those kinds of emergent pressures where you have to do this and you have to do it within the limits of our economic reality are pushing a bunch of technical innovation, right? Because we're all, we're all service providers now. It's not like the old days where we're like, "Throw your software over the wall and the TCO is the customer's problem." Right? Now, now, now (laughs) TCO is actually, that's about our margin. So we have to do a substantially better job there.
I guess I'd, I'd love to, I'd love to get your thoughts on the next, you know the next five to 10 years, right? Both of you are, are in the thick of it. You're, you're at the cutting edge again, another great quote William Gibson's, “The future is already here. It's just unevenly distributed.” I think you're both working in, in, in spaces and enrolls where you're, you're at the edge of the future. So from where you're, you can see even farther.
So the next five to 10 years, if you were to kind of lay out, what do you, what do you think is the grand challenge from, in your domain that, that is gonna be really hard to solve, really worth solving, right? Something that anybody listening can kind of sign up for and say like, “I wanna do more of that. I, I now see where the future is going.” I'd love to, I'd love to hear what's what's on your mind for grand challenges. Maybe we'll start with Eric and finish with Melody.
Sounds great. So I would say a few things that I think are long term issues. I already mentioned se, security one, which is really more about making it safe to do all this collaboration that we still have to do, and, we'll get there. It's solvable, but it's an industry problem that any single player can fix it.
But I think in terms of challenges that are, you know, worth thinking about quite a bit, I think there's plenty more to do on how do you do state management in something that Kubernetes. It's really quite challenging and I think, you know, the models we have are not quite right. So for example, within Google, there are storage teams. And basically if you're not a storage team, you don't get to do state management. That's because this view is very hard to do, and it is hard to do.
Conversely, if you're not in storage, then you don't have to do state management because you can do RPCs to the state management systems that someone else is running and life is good. Now that actually does increase the productivity for those teams. So I, I think that dichotomy has been useful to us. But again, that's something, the traditional model of data is in one database and it has a lot of access control, and is managed and updated in place and that we will remain important.
We need to do that better particularly at the low end in sense of if you want a million small databases, that's actually a hard problem today, much better at one big database in some sense. But we can, you know, invest our resources in, in kind of SREs and things like that to keep the one big database working well.
We need lots of databases to give the autonomy to teams that we wanna have, even if they're built out of fractions of larger databases. But I think this other model of data transformation, that's kinda easy to deal with the state management for... We don't quite have the right tools for it, we definitely don't have the right metadata for it. So, for example, if you wanna collaborate and pick up data from someone else, you need to know a lot about that data if you wanna use any automation at all.
And it's, you know, it doesn't need to have a full database schema but it needs to have enough metadata that automation is possible. You're kinda missing that layer today. And we're actually missing an open source as well for the code site. Like again, I can't really tell if I have a vulnerable version, which versions of libraries of the included are actually affected the vulnerability.
It's very hard to tell because it's done in comments and human texts not in metadata that enable automation. But the same thing's gonna be true for data, and you know, we're not there yet. Like so how, how do you label your data such that people can even know what the axes are, what the units are? Do you want to know the providence of the data, right?
[inaudible 00:30:04] The consequence of the transfer model is that all your inputs have a history, and you might need to know that history in order to interpret the data correctly. Right. And so we don't have a way to store that history again, other than in, in verbal description, if at all. And in fact, if previous transformations were done on the data that you've imported, you might like to see if they were done correctly.
I remember [inaudible 00:30:31] with a cooking stove invention and it improved the quality of cooking stoves which improved the environment, and had all these positive health effects. And we went to prove it, it's not my team, the team I helped, and they had this great chart showed it was working better than the old cooking stoves, but then we couldn't actually figure out how they created the chart, right? Because it was done with Perl scripts and various things and those had all been modified.
So the actual code used to generate the chart was not available. Right? Now that's a data scientist rookie air frankly, but the systems don't make it easy to get that right. And so that whole providence peice is also missing, that'll also affect the security of data, not just its quality.
Melody that sounds like the perfect segue to [crosstalk 00:31:21].
So I, I wanted, I wanna pop up a level which is so many companies across every vertical market, in every different domain, feel so much urgency around trying to wrangle and make sense out of the data to make better decisions, right? And you combine that with what's happening in the market, which is essentially a skilled crisis around data scientists. Their demand is far outpacing the supply.
And you can see something has to change. So good news, there's lots of developers. Developer community is growing, the diversity of the developer community is growing. And I, I really think the time is right to evaluate and understand how we increase data literacy in the world in the next five to 10 years. And that means, you know, means access to data ... Eric brings up a great point, like if more people are empowered and have autonomy to explore data and to ask those questions, there's some better outcomes that are gonna come out of that new workflow.
So you know, the next five to 10 years I, I, I believe is about how we bring access to the data and to Eric's point how we bring transparency to what's coming out of the data, which means that more people can see the underlying data, the constructs and can also see the logic that's being applied, and can understand, "This is the visualization piece that I'm passionate about," can more intuitively understand the data because it's in visual form. And the visualization allows more intuitive learning, right? More interactivity and exploration.
And that's extremely powerful because it just comes back to the core principles of DevOps, faster iteration, right? Faster understanding. You shift faster, you have happier users, right? You have a team, a collective team that's more informed about the data. They can see the code on the data combined together. So you know, that increase in data literacy opening up the toolset, and the skills, and the access increases the approachability of those tools to a diverse audience, right?
Bringing the data scientists, and the developers, and the data analysts, and the business analyst, and the financial analyst and you know, or the hobbyist who's working on a project together to be able to collaborate and share, is you know ... I think that's the journey for the next five to 10 years.
And it really is the crux of when people say the democratization of data, that's what that means. It means empowering humans of many different backgrounds to have access and to have that transparency to, to, to learn and to collaborate together. And so that's, you know that's what really inspires me for the next five to 10 years. And yeah, and I'm looking forward to the amazing things that people are gonna create in the visualization space.
That's so awesome. You know, literacy is the foundation of citizenship. And so as society continues to evolve faster than humans are, our ability to get people data literates to be part of a data driven society, right, as data citizens, whether you're a scientist ... my kids are, you know, studying Environmental Science and Nano engineering. You wouldn't think of them as a data scientist or a developer, but they need these tools and they need that literacy like at the, at the tip of their fingers, both to understand, also to inform, also to persuade.
Yeah, we've got, we've got an amazing decade ahead. I think that we can learn so many lessons from what hyperscalers like Google have done, right, invented things because they had to not for any theoretical purpose. And then I think this, this next decade the grand challenge that I see will be, how do you make everything data-driven in a pragmatic way?
How do you have infrastructure that you can just depend on that just scales up, and scales down, and just gives you the data that you want and it moves things where they need to be, it looks at the load balancers, it looks at the invocation sequences and you know, pre-caches data for you, warms it up, moves it where it needs to be? But all for the sake of understanding how we take data, and up-level to information, and up-level to knowledge.
How can companies who are trying to make sense of their domain, do a good job for their customers, good, do a good job therefore for their employees? How can they assemble all that into a graph of data where it's alive, and rich, and living, and they can interpret, right? There's a way faster than human speed of how all these small pieces of, of data and information come into the system and actually know what they mean, right? How do you have a dynamic active ontology that allows cognition to be augmented, right? Rather than artificial intelligence, looking more at augmented intelligence.
And how does the computer really become a great partner to the human? And I think that will take all of the work that both of you have done for decades and many others as we take you know cloud-native into the, into the next decade, which I think is gonna be awesome for open source, I think it's gonna be awesome for for computation, and awesome for collaboration.
So with that, I wanna thank you both so much for taking the time to be part of this conversation. I'm looking forward to many more in real life and hopefully a few more here in the virtual world before too much time passes.
Thank you so much.