Leveraging Control Planes in Hybrid Cloud with Momento’s Khawaja Shams

This is Textron tv. Hey guys, thanks for the throw. We're here with Khawaja Shams, who?

CEO from Memento. It's a new startup company. They just raised 15 million and they're gonna make data infrastructure a whole lot more elastic than it's been in the past.

Kja, welcome to show. Thank you, Mike. I'm really excited to be here.

We've been talking about elastic resources in the cloud forever and, and a day, but what is it that we are missing here? Because it seems like, um, well, we're playing with more data than ever, but how do we make the whole infrastructure more elastic as the data increases in volume and or maybe decreases in ways that's just fundamentally more spiky than we're used to? I think the definition and the bar for elasticity has changed meaningfully since, since the cloud started.

So back in 2008 when I was at NASA building, you know, getting access to a set of elastic resources was, uh, really, really good for building the Mars data processing pipeline. But now, you know, just having access to the resource, uh, in an elastic manner is not good enough. Now people are building very large scale architectures faster than ever.

And the infrastructure, the orchestration of that infrastructure, the architecture around that infrastructure to be able to access, you know, to build a system that can do millions of transactions per second without worrying about the number of nodes, number of shards, replicas, all the orchestration that needs to disappear. So the DEF elasticity is just as important as ever, but the definition of elasticity and the bar for elasticity is very different. How do we accomplish that?

Because it's not like in, at least in my experience, that there's a control plane for all that stuff that lets me just dynamically shift data infrastructure resources as needed, or is that where you're headed and what's involved in that? Yeah, I'm so happy you brought up the word control plane because that's, um, you know, I think in the early days, cloud control planes were about getting access to compute resources. And what happened, you know, along the way was there was a bunch of services that got built that were essentially just compute specific control planes.

And you see that in services like relational database service or ElastiCache, they are mostly compute services that allow you to provision the compute resources. Then you see more data, specific control planes like what you have in OD db and in S3, these control planes are aware of your data topology. They know where your data is placed.

They are managing the background of the, you know, of the, the health of the data, the elasticity of the fleet, everything, all the care and feed that happens is happening magically by this data aware control plane. And when you have that, you don't have to worry about things like, you know, what is the instance type on your dynamo DB table or your F three bucket, or how many gigabytes of capacity do you have provision in your S3 bucket? Those things just disappear with a data aware control plane.

And this is what we're trying to do is, you know, building the same capability, the same data aware control plane for caching and messaging with the Memento platform Today, I still feel like I need to know what data is where, and the laws of physics are still applied, and um, in some ways it's a just a bigger version of, you know, trying to figure out what data to put where on a spindle, but now it's just in the cloud, but it's all over the cloud. Um, so how do I optimize where data is based on the application requirements? I mean, how smart is the control point?

Yeah, so you know, there's a, there's a variety of nuances that, that go into this. So in, in many cases, customers want, if you're in a particular region, you want access to the data really, really quickly within the region, and you need the cross availability zone resilience. So that's where you can say, Hey, I would like a cash or a message bus in a particular region.

There's other customers for whom, you know, the cross AZ cost is just too high or the, and that includes dollars, it includes the latency, it includes availability, and they might want to pin, you know, AZ specific swim lanes for, for their data. And, and the trick here with a dataware control plane is to make it really easy when customers have that business problem of, Hey, I need that, you know, AZ pinning done. They don't have to go invent the architecture to go make it happen.

They should be able to just make an API call and, and get that to, to occur. Um, similarly, if customers want to deploy in multiple regions, they should be able to pick the regions and then they can build their, you know, kinda the routing layer if you, uh, if you will, to, to route the, uh, appropriate customers accordingly. We don't do that today in terms of providing a global, you know, uh, cash.

But we are, we have a pretty nice footprint across multiple regions. So customers can just provision a highly scalable cash, which is available on a pay per use basis in any region that they want to be deployed in. You know, I'm reminded back in the day, maybe it was, you know, when the cloud first came along, we were all like obsessed about how are we gonna move data into the cloud?

Um, but today it seems like we've come full circle and much of the conversation is about moving compute to where the data is because well, there's too much data, so we can't always move it where we want to move it. Um, is there a balance to be struck there? Because sometimes, um, the compute is in the cloud, but the data might be on premise, but we need to move it because there's this thing called latency that sits in between, and then other times we want to apply compute resources to the data where it resides, but we don't want 'em to have them there permanently.

Can we have our cake and eat it too? I think so. I, I think there's a, there's architectural optimizations to be, to be made, and the cache is a really good way.

If you have your compute sitting in a cloud, having access to frequently access, uh, uh, data available locally in region where your compute is actually makes the, um, you know, the compute be more effective because it's not sitting idle waiting for data to show up. This applies if your resources are on premise. It also applies if your resources are sitting on, on S3.

So your AI models, your training jobs can run a lot faster with access to, you know, faster, uh, key value, uh, primitives that can move the hottest data into, into memory and make it available with very tight tail latencies. Um, so I think what we're gonna see is just, you know, better primitives that make it easy for customers to kind of build these types of optimizations right now, you know, if you wanna build, uh, these types of optimizations, in many cases you have to go architect an entire system. And what we're trying to do is to make parts of that system specifically related to fast data access and low leads notifications.

To be as simple as making an API call instead of going and provisioning a bunch of, you know, the friction with provisioning instances and sizing things and, you know, routing things and so forth. Personally, I kind of feel like these issues have been around forever and a day, but is AI now forcing everybody to reckon with them? It absolutely is because, you know, customers are, are, you know, going multi-cloud faster than ever because of the, they don't wanna be left out on the capabilities that any particular cloud provider has.

But for the customers that do have, you know, regardless of what cloud they're, they're running on, AI is accelerating the pace at which realtime data needs to be available, right? So the latency requirements are more rigorous and tighter than ever, and the amount of realtime data is, is exploding. So when people are, are building AI driven applications, they need the ability to have access to lots of data much faster without getting distracted with infrastructure nuances.

I was in charge of this these days because, I mean, way, way back in the day there were storage admins and then there were cloud architects, and now there's chief data officers, and it's not quite clear to me also, you know, data engineers for that matter in the AI realm, but who's kind of stepping up and taking ownership of the, um, not just the data storage and management, but the whole access to the right data when discussion? So this depends in different enterprises, we see all kinds of patterns. We see patterns where the developers are, you know, running wild.

We see enterprises where there is a coherent platform team that the, that is, you know, responsible for governance, for best practices, and for, you know, making sure that the availability and and costs are, are under control. And for these platform teams, um, you know, to that are already overworked. You know, having to the governance is really, really challenging because what's happening, you know, even before AI microservices were, were exploding.

And you'll get into a situation where the platform teams that are already overworked are dealing with, you know, data clusters or caching clusters for each microservice independently. And that makes governance really, really hard and intractable. It's really hard for these teams, or whether it's a data team or the platform team to ensure that there is a password and authentication required on, you know, each place that your data resides.

One of the biggest security gaps happens to be in the caches because people will provision these caching clusters by default. There's no transport layer security by default, there's no encryption, uh, at rest or in memory by default. There is, you know, um, you know, it's just available to anybody on your, on your VPC, whereas like you look at your database, there's usually a passwords.

It's, you know, you're usually doing some encrypted transactions. There's an audit log and, and so forth that you can get access to. So one of the things that we're excited about is to enable and empower that platform team to get governance, to have all of these best practices for security, availability, performance and cost kind of baked in, in a batteries included platform that makes it easy for them to, to have that governance, uh, on the data.

If I can manage that cache effectively, longer term, do I care less about what format the data's actually stored in? Because it could sit in relational, a document database or whatever it may be, but as long as I know what's hot and I can pull it into cache, um, the data itself becomes just, um, uh, a converged asset that I'm accessing as a developer and I might not care where it's actually stored. That's exactly right.

And I think one of the, the pieces of friction, so look, you're, you're absolutely right that if, if the cache is available, then you can take the data out of your relational database, your graph database, your document databases, and store it in the cache in, in a format that, that you, that you want so you can do the transformation and so forth as well. One of the pieces of friction that still exists and something that people pay less attention to is the web server that sits in the middle between the data and the, you know, the end user devices, right? And this is, you know, the reason why it's, it's important is now anytime I want to enable access to a specific piece of data that is sitting in my cache or in my database, I have to write code, I have to write web server code and logic, and I have to make sure, and you know, this adds delays because the code has to be written, it has to be deployed, and there's enough friction here that oftentimes the front end developers just, you know, they give up or, or they just sit there and wait.

And it really erodes the pace of iteration and innovation on the front end. One of the ways that we're trying to address this is through fine grain access control in the cache and in the messaging layer where you can connect the device directly to the cache. So now if your data is sitting in the cache and it's transformed the way you want it, and you want to enable a user to be able to access another attribute, it's just a change in the, um, in the fine grain access control.

You're not writing new code, you're not worrying about deploying a brand new web server for this microservice. You're just accessing the data directly from your front end. All you need is that access key, um, and some permissions that are, that are needed for it.

So this will, you know, going back to the AI revolution and how everybody's gonna need access to realtime data, more realtime data, and for it to be faster, it's not just the latency with which you get the data, it's the latency with which you can deliver the data into an experience on the front end application. All right. Do you think we're gonna have a, a new appreciation for data latency after all these years?

Because, you know, I seem to remember having these conversations two or three decades ago, and now I feel like, hey, data's cool again, my stuff's so old, it's new. You know, the vacuum cleaner was, um, you know, when, when it got invented in like the early 19 hundreds, uh, people thought, um, you know, the, the home made like portable one, not the ones that showed up in a horse carriage at your house. When it got invented and commoditized, everybody bought it.

People thought that this would reduce the amount of time that the average American household spends cleaning their house. And the opposite happened. People spent more time cleaning their houses than ever after the vacuum cleaner got generalized.

It's not because the vacuum cleaners were making the houses dirty. The standard of living got raised, the standard of cleanliness got raised and the standard of hygiene got raised. Data is just like that.

It's addictive. Consumer applications are always gonna wanna be more interactive. Consumers are gonna demand it.

And for businesses to remain relevant and alive, they're going to need to continue making their experiences more interactive and more real time. And the bar is just gonna keep going up. And that is what makes us super excited to be where we are today because I feel like we are on a mission to make interactive applications, you know, get out to market faster.

And to your point, I don't think many organizations that I know would get a good housekeeping seal of approval for the way they manage data. And, but if we give 'em the tools to do it well, to, it seems like the whole practice should be elevated. We just haven't really been willing to admit maybe how bad we are at data management.

I think it's, everybody has great intentions, but you know, in this market, everybody is super slumped, right? Like the, the, the, the needs from a developer from the platform teams are so high in terms of the pace of delivery that is expected out of them. And this is just the, the hygiene things are, are just getting, you know, it's, it's what kind of gets stuffed into under the rug and technical debt and operational debt and data governance debt just keeps kind of accumulating.

So this is why there's a need, I think, for better governed platforms that come, batteries included with the best practices around security, authentication, management capacity, all of those things. So like, I think this is like, you know, go back, going back to what we, where we started the conversation. This is why the world needs more data aware control planes.

It's, you know, the, the definition of elasticity is very different now. It's not just access to resources, it's access to capabilities. All right, folks, you heard in here the data hygiene standard is rising, it's timely filing may be meet it after all these years 'cause that which we used to accept this par for the course is no longer good enough.

Hey Kaja, thanks for being on the show. Thank you for having me, Mike. All right.

And back to you guys in the studio.