Simplify Microservice-Based Architectures With Redis Enterprise | Cloud Native Now 2023

Hello, welcome to my presentation. Today we're gonna be talking about simplifying microservices based architectures with Redis Enterprise. My name's Talon Miller.

I am a senior product marketing manager here at Redis on the technical side. And a little bit about me before we get started. I'm based in Salt Lake City, Utah.

Uh, it's my wife there in the middle picture. On the right is a picture of one of my favorite places on earth at Snowbird, uh, skiing Resort, where I spend a lot of my time in the wintertime up there as much as I can. And I actually have had snow up until recently.

Um, they just closed the resort just last weekend. So was snowing just last week or was skiing just last weekend. In regards to my background, I'm not a marketing person at all, even though I'm now in marketing and, and in product marketing.

Um, I started at Oracle long time ago, um, quite a few years ago, actually before Oracle Cloud was really quite a thing, so I worked a lot on Oracle db, got very familiar with that. And then what was there as Oracle Cloud was being launched. So that was pretty cool to see.

Um, I then went to Domo and if you don't know what Domo is, it's a business intelligence platform. I did mostly implementation there as well as some solution architecting. So, uh, I had a lot of fun there.

And then Redis called and Redis, uh, wanted me to come essentially bridge the gap from, you know, the technical capabilities and storytelling. So that's what I'm here to do now and I love it. It's been super fun.

So let's dive right into it. Um, in regards to microservices based architectures, it's been super popular over the years, right? Um, but it's been actually quite controversial recently on whether or not it's still a good architecture to have.

And, and it's because many businesses start with just one or two services and it starts out to be a very good thing, right? But then you fast forward, you know, a month or a year from then and then they're now supporting dozens if not hundreds of services that makes it feel like an ever going and never ending. Not to manage managing those hundreds or thousands of isolated services introduces many critical issues like increased latency as these services start to be supported on different servers and the risk of one failing service taking down the entire system.

And don't even get me started on the availability and consistency of data, especially as more and more of the services need to share the same data. And like I mentioned, it's actually been ki quite controversial recently. Uh, even though the popularity of this architecture is just through the roof, uh, as you can see, the date of this post was just, uh, last month.

So the swing of the momentum of this popularity or this, you know, to go to architecture might be swinging in the other way. Um, so this piece on, on LinkedIn talks about how Amazon Prime is ditching. This can be cumbersome architecture.

And look, I I'm not gonna sit here and tell you that you should completely drop microservices and go back to building a monolith cuz there are many ways to reduce the pains even significantly. We can simpl simplify microservices architecture with Redis Enterprise with more speed, scalability, and agility. In this presentation, it will cover four solutions that can help us tackle the pains of scaling out microservices.

We'll cover query caching, the C Q R S pattern, a p i gateway caching, and then finish with interservice communication. We'll review these solutions, discuss their architecture, and learn why and when we use them. So that has a ton of stuff to cover and we're gonna do it in less than 15 minutes, hopefully cross your fingers.

So let's dive in. I imagine that if you are familiar with microservices architecture, then you know, this next part will be boring, but let's just quickly get us all on the same page and cover some core points. Microservices based architecture is an approach that structures an application as a collection of small independent services that can be, be deployed, developed, and scaled independently.

It has become super popular, like I've said, due to mostly its ability to provide flexibility, scalability, and better resilience to applications. But it does come with some challenges. You probably noticed I said independent quite a lot when I when describing this architecture.

Well, independent services are a double-edged sword. Architectures will inevitably face increased complexity as each added service comes with its own deployment, maintenance, and monitoring requirements, maybe even its own database. In addition, the challenge of having a distributed architecture means that communication and the data shared between services becomes critical.

And that's where Redis Enterprise comes in. We can empower developers, DevOps, and architects with an optimized data platform for microservices deployments. Redis Enterprise enables agile, scalable microservices architectures that reduce complexity, deliver performant and resilient apps, and simplifies operations in hybrid and multi-cloud environments.

In each of the four solutions we'll be covering next, I'll make sure to add some insights on why Redis Enterprise is different when enabling these solutions. It's gonna look at our first solution query caching. Query caching is a very popular way to reduce latency and increase speed and performance In microservices architectures, it's actually pretty simple.

We're caching a record needed for a single domain so that the data is always hot, serving the microservice much quicker than a R D B M S or this space, no SQL database. At the same time increasing the number of operations per second. We use a query cache when a single domain needs increased performance of operations and reduced latency.

So it's really for any microservice that has a slow database. What powers this solution? It's what we call the Redis Smart Cash.

We built this open source library to save time and costs by enabling developers to use a library to quickly deploy a and and standardize query cash and to provide insights into cash usage and analytics without needing to re-architect application code, which is pretty cool. The difference that Reddis Enterprise brings with this particular solution is our smart cash is obviously with speed, cash, uh, scale and, and resilience. Enabling the solution with real-time responses is exactly what an enterprise cash looks like.

Pair that with elastic scalability that will match the throughput you need when you need it. And best in class five Ds of high availability. The highest amount of availability for Redis anywhere on the market, and I can't emphasize this enough, it really does make a difference.

With five nines. You are looking at less than 30 seconds of downtime per month, which is incredible. I'm dropping that down to the industry standard of four nines of availability skyrockets the downtime from 26 seconds per month to 86,400 seconds a month, which equates to 24 hours of downtime per month.

Can your business afford one day a month of fail operations? With that said, let's move on to our next solution. The CQ r s pattern.

The cqs pattern for those who are not familiar is command query responsibility segregation. In this diagram where one microservice owns a system of record, the command database, while another requires fast read access or queries for a different business context. If that same database is used for both microservices, their deployment would, would be coupled breaking the isolation principle and could only optimize for either reads or rights.

But not both. The cqs pattern Decouples reads and writes, the command database is focused on high durability and consistency while the query is focused on performance and serving the data. The data.

The difference that Reddis Enterprise brings with this particular solution is latency, scalability, and ease of deploying, including the integrated change data capture capability that transforms the system of record and right optimization data structure like sql or read optimization data structure like hash while maintaining isolation. In addition, lightning fast queries, we can help lower T C O. Our typical customer saves up to two times DevOps resources due to automation and dev development efficiency with our integrated C D C solution with this CS pattern.

And more so onto our next solution, a p i gateway caching, which is caching globally shared data that must be accessed by all microservices at the API gateway level, Keeping that highly requested data hot so that operations happen at sub millisecond speed. Typically this data is session and authentication data for things like user IDs, preferences, authorization status and permissions. When do we use the solution when we need globally shared data serve to microservices to streamline user logins and add resilience to applications by reducing outages at the APAC a p I gateway, which can act as a single point of failure?

The difference that Reddi Enterprise brings with this particular solution is speed, scale and resilience, just like the query ca cash uh, solution. But it's also worth mentioning that Reddis Enterprise simplifies operations and of deployment through its supported operator for Kubernetes as it automates the deployment and management of Redis clusters. It also has pre-built integrations with Kong A leading a p i gateway management solution.

Redis, uh, rate limiting is also an option for API gateway using Redis Enterprise limiting the request to a particular service, uh, in the API gateway. So let's jump onto our final solution. Interservice communication.

We streamline interservice communication between microservices by using Redis Streams, a lightweight event driven message broker. I'll start with perhaps an obvious statement. Microservices need to communicate a lot of things all of the time, state events and a diverse variety of data.

In some cases without needing an an immediate response or asynchronously. It can be super complex time consuming to maintain and costly to implement this type of messaging. Redis Streams as the asynchronous message broker provides a published subscribe or pubs sub capability to populate the stream without having to add that logic into the microservice.

When do we use the solution? When storing transient data such as events and messages that need simple and fast write and read operations or simply because using a message broker instead of APIs for events and messages that need no response. The difference that Redis Enterprise brings with this particular solution is lightweight streams log data structure that is easier to deploy, develop and operate, and more cost effective than using Kafka plus sub millisecond latency on top of that simplicity.

So to close scaling out microservices in your architecture doesn't have to be a super painful process. Try Redis Enterprise for free today and see for yourself why it's the best Redis to supercharge your microservices architecture. Or if you wanna learn more, check out our solution brief on simplifying microservices architecture to dive deep into even more detail.

Lastly, just fyi, all of the solutions I've covered today. I have demos on, on YouTube using a simple application. So if you wanna learn more in regards to an actual visual element to the demo, uh, go check it out.

Thanks so much.