Screaming in the Cloud - The Redis Rebrand with Yiftach Shoolman

Episode Date: February 9, 2022

About YiftachYiftach is an experienced technologist, having held leadership engineering and product roles in diverse fields from application acceleration, cloud computing and software-as-a-service (SaaS), to broadband networks and metro networks. He was the founder, president and CTO of Crescendo Networks (acquired by F5, NASDAQ:FFIV), the vice president of software development at Native Networks (acquired by Alcatel, NASDAQ: ALU) and part of the founding team at ECI Telecom broadband division, where he served as vice president of software engineering.Yiftach holds a Bachelor of Science in Mathematics and Computer Science and has completed studies for Master of Science in Computer Science at Tel-Aviv University.Links:Redis, Inc.: https://redis.com/Redis open source project: https://redis.ioLinkedIn: https://www.linkedin.com/in/yiftachshoolman/Twitter: https://twitter.com/yiftachsh

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. This episode is sponsored in part by our friends at Rising Cloud, which I hadn't heard of before. But they're doing something vaguely interesting here.

They are using AI, which is usually where my eyes glaze over and I lose attention. But they're using it to help developers be more efficient by reducing repetitive tasks. So the idea being that you can run stateless things without having to worry about scaling, placement, etc. and the rest. They claim significant cost savings and they're able to wind up taking what you're running as it is in AWS with no changes and run it inside of their data centers that span multiple regions. I'm somewhat skeptical, but their customers seem to really like them. So that's one of those areas where I really have a hard time being too snarky about it because when you solve a customer's problem and they get out there in public and say, we're solving a

problem, it's very hard to snark about that. Multus Medical, Construx.ai, and Stacks have seen significant results by using them, and it's worth exploring. So if you're looking for a smarter, faster, cheaper alternative to EC2, Lambda, or Batch, consider checking them out. Visit risingcloud.com slash benefits. That's risingcloud.com slash benefits. And be sure to tell them that I sent you, because watching people wince when you mention my name is one of the guilty pleasures of listening

to this podcast. This episode is sponsored in part by our friends at Sysdig. Sysdig is the solution for securing DevOps. They have a blog post that went up recently about how an insecure AWS Lambda function could be used as a pivot point to get access into your environment. They've also gone deep in depth with a bunch of other approaches to how DevOps and security are inextricably linked. To learn more, visit sysdig.com and tell them I sent you. That's S-Y-S-D-I-G dot com. My thanks to them for their continued support of this ridiculous nonsense. Welcome to Screaming in the Cloud. I'm Corey Quinn.

This promoted episode is brought to us by a company that I would have had to introduce differently until toward the end of last year. Today, they're Redis, but for a while they've been Redis Labs. Here to talk with me about that and also much more is their co-founder and CTO, Yiftach Shulman. Yiftach, thank you for joining me. Hi, Corey. Nice to be a guest of yours. This is a very interesting podcast and I often happen to hear it. I'm always surprised when people tell me that they listen to this because unlike a newsletter or being obnoxious on twitter I don't wind up getting a whole lot of feedback from people via email or whatnot My operating theory has been that it's like when I send an email out people will get that

Oh an email I know how to send one of those and they'll fire something back But podcasts are almost like a radio show and well who calls into radio shows? Well lunatics generally and if I give feedback i'll feel like a radio show. And well, who calls into radio shows? Well, lunatics generally. And if I give feedback, I'll feel like a lunatic. So I get very little email response on stuff like this. But when I talk to people, they mention the show. It's, oh, right, good. I did remember to turn the microphone on.

People are out there listening. Thank you. So you, back in August of 2021, the company that formerly known as Redis Labs became known as Redis. What caused the name change? And sure, it is a small change as opposed to, you know, completely rebranding a company like Square to Block. But what was it that really drove that, I guess, rebrand? Yeah, great question. And by the way, if you look at our history, we started the company

under the name of Garantia Data, which is an Arabic name. And initially, what we wanted to do is to accelerate databases with both technologies like Memcached and Redis. Eventually, we built a solution for both, and we found out that Redis is much more used by people. That was back in 2011. So in 2021, we finally decided to say, let's unify the brand because, you know, as a contributor to Redis from day one, and the creator of Redis is also part of the company, Salvatore

Sanfilippe, we believe that we should not confuse the market with multiple messages about Redis. Redis is not just a cache, and we don't want people to differently interpret this. Redis is more than a cache. Actually, if you look at our customer, like 66% of them are using it as a real-time database. And we wanted to unify everyone around this name and to avoid different interpretation. So that was the motivation, maybe. It's interesting you talk about, I guess, the evolution of the use cases for Redis.

Back in 2011, I was using Redis in an AWS environment. And, ah, disk persistence, we're going to turn that on. And it didn't go so well back in those days because I found that the entire web app that we were using would periodically just slam to a halt for about three seconds whenever Redis wound up doing its disk persistence stuff, diving far deeper than I really had any right to be doing. I figured out this was a regression in the Xen hypervisor and Xen kernel

that AWS was using back then around the fork call, not Redis's fault, to be very clear. But I looked at this and figured, ah, I know how to fix this, and that's right. We badgered AWS into migrating to Nitro years later and not using Xen anymore, and that solved that particular problem. But this was early on in my technical career.

It sort of led to the impression of, oh, Redis, that's a cache. I should never try and use it as anything approaching a database. Today, that guidance no longer holds. You are positioning yourself as a data platform. What did that dawning awareness look like? How did you get to where you are from where Redis was once envisioned in the industry, primarily as a cache? Very good question. So I think we should look at this problem from the application perspective or from the user perspective. It sounds like a marketing term, but we all know we are in the age of real-time.

You expect everything to be instantly. You don't want to wait. No one wants to wait, especially after COVID and everything that it brought to the online services. And the expectation today from a real-time application is to be able to reply

less than 100 milliseconds in order to feel the real-time. And when I say 100 milliseconds, it's from the time you click the button until you get the first bite of the response. Now, if you do the button until you get the first bite of the response. Now, if you do the math, you can see that like 50% of this goes to the network and 50% of this goes to the data center.

And inside the data center, in order to complete the transaction in less than 50 milliseconds, you need a database that replies in no time, like less than a millisecond. And today, I must say only Redis can guarantee that. And if you use Redis as a cache, every transaction, or there is a potential at least, that not all the information will be in Redis when the transaction is happening. You need to bring it probably from the main database, and you need to process it, and you need to update Redis about it, and this takes a while. And eventually, it will hurt the end user experience. need to process it and you need to update Redis about it and this takes a while and eventually

it will hurt the end user experience and just to mention if you look at our support tickets like I would say the majority of them is why Redis replies why Redis latency grew from 0.25 millisecond to 0.5 millisecond because there is a multiplier effect for the end user. So I hope I managed to answer what are the new challenges that we see today in the market. Tell me a little bit more about the need for latency around things like that. Because as we look at modern web apps across the board, people are often accessing them through mobile devices, which, you know, we look at this spinning circle of regret as it winds up loading a site or whatnot. It takes a few seconds.

So the idea of, oh, the database call has to complete in a millisecond or less time seems a little odd viewed purely from a perspective of, really, because I spend a lot of time waiting for the web page to load. What drives that latency requirement? First of all, I agree with you. A lot of times, you know, applications were not built for real-time. What drives that latency requirement? avatar in more than two frames, like 60 milliseconds, the experience is very bad. And customers are not happy with this.

Or in a transaction scoring example, when you sweep the card, you want the card issuer to approve or not approve it immediately. You don't want to wait. Ad serving is another example. But in addition to that, there are systems like mobility as a service, like the Uber of the world, or the Airbnb of the world, or any e-commerce site. In order to be able to reply in a second, they need to process behind the scenes thousands and sometimes millions of operations per second in order to get to the right decision. You need to match between riders and drivers,

and you need to match between guests and free room in the hotel. And you need to see that the inventory is up to date with the shoppers. And all this takes a lot of transactions and a lot of processing behind the scenes in order just to reply in a consistent manner. And this is why Redis is useful in all these applications. And by the way, just a note, we recently looked at how many operations per second actually happening in our cloud environment. And I must tell you that I was

surprised to see that we have over 1,000 clusters or databases with the speed of between 1 million to 10 million operations per second. And over 150 databases with over 10 million operations per second, which is huge. And if you ask yourself, how come? This is exactly the reason. This is exactly the reason.

For every user interaction, usually you need to do a lot of interaction with your data. That kind of transaction volume, it would never occur to me to try and get that on a single database. All right, let's talk about sharding for days and trying to break things out. But it's odd because a lot of the constraints that I was used to in my formative years back when I was building software badly are very much no longer the case. The orders of magnitude are different. And things that used to require incredibly expensive dedicated hardware now just require, oh yeah, you can click the button, get one of those things in the cloud, and it's dirt cheap.

And it's been a very strange journey. Speaking of clicking buttons and getting things available in the cloud, Redis has been a thing, and its rise has almost perfectly tracked the rise of the cloud itself. There's, of course, the Redis open source project, which has been around for ages and is what you're based on top of. And then, obviously, AWS wound up launching, ah, we're going to wind up collaborating, and the quotes should be visible from Orbit on that, with Redis by launching ElastiCache for Redis. And they say, oh, no, no, it's not competition. It's validating your market. And then last year, they looked at you folks again, like, ah, we're launching a second service,

MemoryDB in this case. It's like Redis, except bad. And they look at this, and I figure, what is their story this time? It's like, oh, we're going to validate the shit out of your market now. On some level, you should be flattered having multiple services launched trying to compete slash offer the same types of things. Yet, Redis is not losing money year over year. By all accounts, you folks are absolutely killing it in the market. What is it like to work both in cloud environments

and with the cloud vendors themselves? This is a very good question. And we use the term frenemy, like they're our friend, but sometimes they're our enemy. We try to collaborate and compete them fairly. And, you know, AWS is just one example. I think that the other cloud took a different approach. Like with GCP, we are fully integrated in the console,

what is called third-party, first-class service. You click the button through the GCP console, and then you redirect it to our cloud, Redis Enterprise Cloud. With Azure, even we took one step further, and we provide a fully integrated solution, which is managed by Azure, Azure Cache for Redis, and we are the enterprise tier. But we are also cooperating with AWS. We're cooperating on the marketplace and we're cooperating in other activities, including the open source itself.

Now, to tell you that we do not have a competition in the market but competition is good and i think memory db is a validation of your first question like how can you use redis more than a cache and i encourage users to test the differences between these services and to decide what fits to the use case i promise promise you, from my perspective at least, that we provide a better solution. We believe that any real-time use case should eventually be served by Redis, and you don't need to create another database for that,

and you don't need to create another caching layer. You have everything in a single data platform, including all the popular models, data models, not only key value, but also JSON and search and graph and time series, and probably AI and vector embedding and other stuff. And this is our approach. Now, I know it's unpopular in AWS circles to point this out, but I have it on good authority

that they are not the only large-scale cloud provider on the planet. And in fact, if I go to the Google Cloud Console, they will sell me Redis as well, but it's through a partner affinity as a first-party offering in the console called Redis Enterprise. And it just seems like a very different interaction model, as in their approach is they're going to build their own databases that solve for a wide variety of problems, some of them common, some of them ridiculous. But if you want actual Redis or something that looks like Redis, their solution is,

oh, well, why don't we just give you Redis directly instead of making a crappy store brand equivalent of Redis? It just seems like a very different go-to-market approach. Have you seen significant uptake of Redis as a product through partnering with Google Cloud in that way? I would answer this politely and say that I can almost say that the big cloud momentum is only on AWS. We see a lot of momentum in other clouds in terms of growth. And I would challenge the AWS guys

to think differently about partnership with ISV. I'm not saying that they are not partnering with us, but I think the partnerships that we have with other clouds are more closer. It's like there is less friction. And it's up to them. It's up to any cloud vendor to decide what she wants to take in this market.

And it's good. It's a common any cloud vendor to decide what she wants to take in this market. And it's good. It's a common refrain that I hear is that AWS is where we see the 800-pound gorilla in the space. It's very hard to deny that. But it also has been very tricky to wind up working with them in a partnership sense. Partnering is not really a language that Amazon speaks super well, kind of like, you know, toddlers and sharing. Because today they aren't competing directly with you, but what about tomorrow? And it's such a large distributed company that in many cases, your account manager or your partner manager there doesn't realize that they're launching a competitor until 12

hours before it launches. And that's, yeah, feels great. It just feels very odd. That said, you are a partner with AWS and you are seeing significant adoption via the AWS marketplace. And the reason I know that is because I see it in my own customer accounts on the consulting side. I'm starting to see more and more spend via the marketplace, partially due to offset spend commitments that they've made contractually with AWS. But also, privately, I tend to believe a lot of that is also an end run around their own internal procurement department. Oh, you want some Redis? Great. Give me nine months and then find three other vendors to give me competitive bids on it. And yeah, that's not how the world works anymore. Have you found that the marketplace is a discovery mechanism for customers to come to Redis, or are they mostly going into the marketplace saying, I need Redis, I want it to be Redis

Enterprise from Redis, but this is the way I'm going to procure it? My philosophy, and there are people that are seeing differently, is that marketplaces is out to be discovered through the marketplace. I still see it as a billing mechanism for us, right? I mean, AWS helping us in sell. I mean, their seller also sell a partner and we have quite a few deals with them and this mechanism works very nicely, I must say. And I know that all the marketplaces are trying to change it for years, that customer,

whenever they look at something, they will go through the marketplace and find it there. But it's hard for us to see the momentum there. First of all, we don't have the metrics on the marketplace. We cannot say it works, it doesn't work. What we do see that works is that when we own the customer and when the customer is hesitating how to pay through the credit card or through the wire, they usually prefer to pay through the commit from the cloud, whether it is AWS, GCP, or Azure. And for that, we help them to do the transaction seamlessly. So for me, the marketplace, the number one reason for that is to use your existing commit

with the cloud provider and to pay for our service. That said, I must say that with this regard, AWS should improve something because not the entire deal is committed. It's like 50% or 60% don't remember the exact number, but in other clouds, when ISPs are interacting with them, the entire deal is credited for the commit, which is a big difference. I do point out this is an increasing trend that I'm seeing across the board.

For those who are unaware, when you have a large-scale commitment to spend a certain dollar amount per year on AWS, marketplace spend counts at a 50% rate. So 50 cents of every dollar you spend through the marketplace counts toward your commit. And once upon a time, this was something that was advertised by AWS's enterprise sales teams as, ah, this is a benefit. And they're talking about moving things over that at the time were great. You can move that $10,000 a year thing there. You have a $50 million annual commit.

You're getting awfully excited about knocking $5,000 off of it. Now, as we see that pattern starting to gain momentum, we're talking millions a year toward a commit. And that is the game changer that they were talking about. It just looks ridiculous at a smaller scale. Yeah, I agree, I agree. But anyway, I think this initiative, and I'm sure that AWS will

change it one day because the other cloud, they decided not to play this game. They decided to give the entire, you know, whatever you pay for ISVs to be credited with your commit. We are all biased by our own experiences. So I have a certain point of view based upon what I see in my customer profile. But my customers don't necessarily look like the bulk of your customers. Your website talks a lot about Redis being available in all cloud providers, in on-prem environments, the hybrid and multi-cloud stories.

Do you see significant uptake of workloads that span multiple clouds, or are they individual workloads that are on multiple providers? For example, workload A lives on Azure, workload B lives on GCP, or is it just workload A is splattered across all four cloud providers? The majority of the workloads is splitted between applications, and each of them uses different clouds. But we started to see more and more use cases in which you want to use the same data sets across cloud and between hybrid and cloud. And we provide this solution as well. I don't want to promote myself so much because you worried

me at the beginning, but we create these products that is called Active-Active Redis that is based on CRDT, conflict-free replicated data type, but in a nutshell, it allows you to run across multiple clouds or multiple regions in the same cloud or hybrid environment with the speed of Redis, while guaranteeing that eventually all your write will be converged to the same value and while maintaining the speed of Redis, while guaranteeing that eventually all your write will be converged to the same value while maintaining the speed of Redis. So I would say quite a few customers found it very attractive for them

and very easy to migrate between clouds or between hybrid to the cloud because in this approach of Active-Active, you don't need a single cutoff. A single cutoff is a very complex process when you want to move a workload from one cloud to another. Think about it, it is not only data, you want to make sure that your entire application works. It's like it never works in one shot

and you need to return back. And if you don't have the data with you, you're stuck. So that mechanism really helps. But the bigger picture, like you mentioned, we see a lot of geo-distribution need, like to maintain the five lines of availability

and to be closer to the user to guarantee the real-time. Selling dataset deployment across multiple clouds and ivory, we see a growth there, but it is still not the mainstream, I would say. I think that my position on multi-cloud has been misconstrued in a variety of corners,

which is doubtless my fault for failing to explain it properly. My belief has been that when you're building something on day one, Greenfield, pick a provider, I don't care which one, go all in. But I also am not a big fan of potentially closing off strategic or theoretical changes down the road. Cosmos DB, and that is the core of your application, moving a workload from cloud A to cloud B is already very hard. If you have to redo the entire interface model for how it talks to its data store and the expectations built into that over a number of years, it becomes basically impossible. So I'm a believer in going all in, but only to a certain point in some cases and for some workloads. I mean, I've done a lot of

work with DynamoDB myself for my newsletter production pipeline, just because if I can't use AWS anymore, I don't really need to write last week in AWS. I have a hard time envisioning a scenario in which I need to go cross cloud, but still talk about the existing thing. But my use case is not other folks' use case. So I'm a big believer in the theoretical exodus, just because not doing that in many corporate environments becomes a lot less defensible. And Redis seems like a way to go in that direction. Yeah, I totally agree with you. I think that this is very important. And by the way, it is not to say that multi-cloud is wrong, but it allows you to migrate workload

from one cloud to another once you decide to do it. And it puts you in a position as a consumer. No one wants... Why no one likes Oracle? Because, you know, because of the pricing of Oracle, right? You don't want to repeat this story again with AWS and with any of them. So you want to provide enough choices

and in order to do that, you need to build your application on infrastructures that can be migrated from one cloud to another and will not be relying on a single cloud database that no one else has. I think it's clear.

This episode is sponsored in part by our friends at Vulture, spelled V-U-L-T-R, because they're all about helping save money, including on things like, you know, vowels. So what they do is they are a cloud provider that provides surprisingly high-performance cloud compute at a price that, well, sure,

they claim it is better than AWS's pricing. And when they say that, they mean that it's less money. Sure, I don't dispute that. But what I find interesting is that it's predictable. They tell you in advance on a monthly basis what it's going to cost. They have a bunch of advanced networking features. They have 19 global locations and scale things elastically, not to be confused with openly, which is apparently elastic and open. They can mean the same thing sometimes. They have had over a million users.

Deployments take less than 60 seconds across 12 pre-selected operating systems. Or if you're one of those nutters like me, you can bring your own ISO and install basically any operating system you want. Starting with pricing as low as $2.50 a month for Vulture Cloud Compute, they have plans for developers and businesses of all sizes, except maybe Amazon, who stubbornly insists on having something of the scale on their own. But you don't have to take my word for it with an exclusive offer for you. Sign up today for free and receive $100 in credits to kick the tires and see for yourself. Get started at vulture.com slash morningbrief.

That's v-u-l-t-r dot com slash morningbrief. Well, going to the Greenfield story of building something out today, I'm going to go back to my desk after this and go ahead and start building out a new application. And great. I want to use Redis because this has been a great conversation and it's been super compelling. I am probably not going to go to redis.com and sign up for an enterprise Redis agreement to start building out. It's much likelier that I would start down the open source path because it turns out that I believe Docker pull Redis is pretty close to a Docker run of Redis latest or whatever it is, or however it is you want to get Redis. I have no judgment here is going to get you the open source tool super well. What is the

nature of your relationship between the open source Redis and the enterprise Redis that runs on money? So first of all, we are like the number one contributor to the Redis open source. I would say 98% of the code of Redis is contributed by our team, including the creator of Redis, Salvatore Sanfilippe, who is part of our team. Salvatore stepped back in like, when was it, like one and a half, almost two years ago, because the project became like a monster. And he said, listen, this is too much. I worked like 10 years or 11 years. I want to rest a bit. And the way we built the core team around this, we said we will allocate free people from the company according to their contribution.

So the leaders are the number two after Salvatore in terms of contribution. I mean, significant contribution, not typo and stuff like this. And we also decided to make it like a community-driven project. And we invited people from other places, including AWS, Medling, and Zazu from Alibaba.

And this is based on the past contribution to Redis, not because they are from famous cloud providers. And I think it works very well. We have a committee which is driven by consensus. And this is how we agree what we put in the open source and what we do not. But in addition to the pure open source, we also invested a lot in what we call source available.

Source available is a new approach that I think we were the first who started it back in 2018 when we wanted to have a mechanism to be able to monetize the company. And what we did by then, we added all the modules, which are extensions to the Redis open source that allow you to do modern data model like JSON and search and graph and time series and AI and many others with Redis under source available license. That means you can use it like BSD.

You can change everything without copy left. You don't need to contribute back. But there is one restriction. You cannot create a service or a product that compete directly with us. And so far, it works very well and you can launch Docker containers with search and with JSON

or with all the modules combined. We are also having this and get the experience from day zero. We also made sure that all your clients are now working very well with these modules. And we even created the object mapping client for each of the major languages. So we can easily integrate it with Spring and Django

and Node.js platform, et cetera. This is called om.net, om.java, om.nodejs, om.python, etc. Very nicely, you don't need to know all the commands associated. We just speak higher level with Redis and get all the functionality. It's a hard problem to solve for. And whenever we start talking about license changes for things like this, it becomes a passionate conversation.

People with all sorts of different perspectives and assumptions baked in and a remembrance of yesteryear all have different thoughts on coulda, woulda, shoulda, et cetera, et cetera. But let's be very clear, running a business is hard. And building a business on top of an open source model is way harder. Now, if we were launching an open source company today in 2022, there are different things we would do. We would look at it very differently. But over a decade ago, it didn't work that way. If you were to be looking at how open source companies can continue to thrive in

a time of cloud, what guidance do you have for them? This is a great question and must say that every month or every few weeks, I have a discussion with a new team of founders that want to create an open source and they ask me what is my opinion here. And I would say today that we and other ISV built a system for you to decide what you want to freely open source and take into account that if this goes very well, the cloud provider will pick it up and will make a service out of it because this is the way they work.

And the way for you to protect yourself is to have different types of licenses like we did. Like you can decide about source available and restrict it to the minimum. By the way, I think that source available is much better than AGPL with the copyleft and everything that it provides. So AGPL is a pure open source,

but it has so many other implications that people just don't want to touch it. Source available, you can do whatever you want. You just cannot create a competing product. And of course, if there are some codes that you want to close, use closed source. So I would say think very seriously about your licensing model. This is my advice.

This is not to say that open source is not great. I truly believe that it helps you to get the adoption. There are a lot of other benefits that open source creates. Historically, it feels that open source was one of those things that people wanted the upside of the community and the adoption and getting people to work especially on a shoestring budget and people can go in and fix these things like that's the naive approach of oh it's just because we get a whole bunch of free unpaid labor okay fine whatever it also engenders trust and lets people iterate rapidly and build things to suit their use cases and you learn so much more about the use cases as you continue to grow. But on the other side of it, there's always the Docker

problem where they gave away the thing that added stupendous value. If they hadn't gone open source with Docker, it never would have gotten the adoption that it did. But by going open source, they wound up effectively being forced more or less into a, okay, we're going to give away this awesome thing and then sell services around it. And that's not really a venture scale business in most cases. It's a hard market. The gate should never be the cloud. Because people, like you mentioned, people don't start with the cloud.

They start to develop on the laptop or somewhere with Docker or whatever. And this is where source-available can shine because it allows you to do the same thing like open source. And be very clear. Please do not confuse your users. Tell them that this is source-available. They should know in advance. So they will be no surprise later on

when they move to the production state. And if they have some legal questions, for Redis, we are here to answer. And if they don't, they need to deal with the implication of this. And so far, we found it suitable to most of the users. Of course, there will be always open source gurus. If there's one thing people have on the internet, it's opinions. Yeah.

I challenge the open source gurus to change their mindset because the world has changed. We cannot treat the open source like we used to treat it in 2000 or early 90s. It is a different world and you want companies like Redis. You want people to invest in open source and we need to somehow

survive, right? We need to create a business. So I challenge these OSI committees to think differently. I hope they will one day. One last topic that I want to cover is the explosion of AI, artificial intelligence, or machine learning, or bias laundering, depending upon who you ask. It feels in many ways like a marketing slogan, and I viewed it as more or less selling pickaxes into a digital gold rush on the part of the cloud providers until somewhat recently, when I started encountering a bunch of

customers who are in fact using it for very interesting and very appropriate use cases. Now I'm seeing a bunch of databases that are touting their machine learning capabilities on top of the existing database offerings. What's Redis' story around that? Great question. Great question. So I think today I have two stories which are related to the real-time AI. Yeah, we are in the real-time world. One of them is what we call the online feature store. Just to explain to the audience what is a feature store, usually when you do inferencing you need to enhance the transaction with some data in order to get the right quality.

Where do you store this data? So for online transactions you usually want to store it in Redis because you don't want to delay your application whenever you do inferencing. So the way it works, you get a transaction, you bring the features, you combine them together, send them to inferencing, and then whatever you want to do with the results. One of the things that we did with Redis, we combined the AI inferencing inside Redis, and we allow you to do that in one API call, which makes the real-time much, much faster. You can decide to use Redis just as an online feature store.

This is also great. The other aspect of AI is vector embedding, just to make sure that we are all aligned with vector embedding terms. So vector embedding allows you to provide a context for your text, for your video, for your image, in just 128 bytes or floating point. It really depends on the quality of vector. And think about it that tomorrow, every profile in your database will have a vector that explains the context of the product,

the context of the user, everything, like in one single object in your profile. So Redis has it. So what can you do once you have it? For instance, you can search where are the similar vectors. This is called vector similarity search. For recommendation engines and for many, many, many others' implications. And you would like to combine it with metadata,

like not only bring me all the similar context, but also some information about the visitor, like the age, like the height, like where does the person live? So it's not only vector similarity search, it's search with vector similarity search. Now, the question could be asked, do you want to create a totally different database

just for this vector similarity search? And then how do you make it fast as that isis because you need everything to run in real time. And this is why I encourage people to look at what they have in Redis. And again, I don't want to be marketeering, but I don't think that a single feature deployment requires a new database. And we added this capability because we do think they need to support it in real time. I hope my answer was not too long.

No, no, it's the right answer because the story that you're telling about this is not about how smart you are. It's not about hype-driven stuff. You're talking about using this to meet actual customer needs. And if you tell me that, oh, we built this thing because we're smart, yeah, I can needle you to death on that and make fun of you until I am blue in the face. But when you say, I'm going to go ahead and do this because our customers have this pain, well, that's a lot harder for me to criticize. Because, yeah, you have to meet your customers where they are. That's the right thing to do. So this is the kind of story that is slowly but surely changing my view on the idea of

machine learning across the board. I'm happy that you like it. We like it as well. And we see a lot of traction today. Vector similarity search is becoming like a real thing and also features. I want to thank you so much for taking the time to speak with me today. If people want to learn more, Where can they find you? I think, first of all, you can go to redis.io or redis.com and look for our solution. And if I'm available on linking and Twitter, you can find me.

And we will, of course, put links to all of that in the show notes. Thank you so much for your time today. I appreciate it. Thank you, Corey. It was a very nice conversation. I really enjoyed it. Thank you very much. It was a very nice conversation. I really enjoyed it. Thank you very much.

Thank you. You as well. Iftar Shulman, CTO and co-founder at Redis. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you hated this podcast, please leave a five-star review on your podcast platform of choice, along with a long, rambling, angry comment about open-source licensing that no one is going to be bothered to read.

If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS. We tailor recommendations to your business, and we get to the point. Visit duckbillgroup.com to get started. This has been a HumblePod production. Stay humble.