Expanding GraphQL Federation at Netflix with Tejas Shikhare

Transcript

Intro [00:30]

Thomas Betts: GraphQL can be a great choice for client to server communication, but does require some investment to maximize its potential. Netflix operates a very large federated GraphQL platform. Like any distributed system, this has some benefits but also creates additional challenges. Today I'm joined by Tejas Shikhare, who will help explain some of the pros and cons you might want to consider if you try to follow their lead in scaling GraphQL adoption. Tejas is a senior software engineer at Netflix where he works on the API systems team. He has spent the last four years building Netflix's federated GraphQL platform and helped to migrate Netflix's consumer-facing APIs to GraphQL. Aside from GraphQL, he also enjoys working with distributed systems and has a passion for building developer tools and education. Tejas, welcome to the InfoQ podcast.

Tejas Shikhare: Thank you so much for having me, Thomas.

Quick overview of GraphQL

Thomas Betts: It's been a while since we've talked about GraphQL on the podcast. Our listeners are probably familiar with it, but let's do a quick overview of what it is and what scenarios it's useful for.

Tejas Shikhare: GraphQL has gained a lot of popularity over the last few years, and one of the most common scenarios that it's useful for is building out... If your company has UIs and clients that are product-heavy and they aggregate data from many different sources, GraphQL allows you to not only act as an aggregation layer but also query language for your APIs so that the client can write a single query to fetch all the data that it needs to render. And we can build this into a GraphQL server and then connect to all these different sources of data and get together and return them back to the client. That's the primary scenario with GraphQL, but at the end of the day it's just a API protocol similar to REST, GRPC, etc., with the added layer of being a deep query language.

Thomas Betts: Yeah, I think there's a couple of common scenarios. About a year ago we had the API Showdown on the podcast and we talked about REST versus GraphQL versus GRPC, and I remember over-fetching, and there's a couple different scenarios, like this is a clear case where GraphQL makes it easier than calling a bunch of different APIs.

Tejas Shikhare: Exactly, and I think what GraphQL gives you is the ability to fetch exactly the data you want, and not more, not less, because you can ask for what data, so you can ask for every single field you want and that's the only fields that server will give you back. And sometimes in REST, the way it works is you have an endpoint and it returns a set of data, and it might return more data than you need, and so you're sending those bytes over the wire when the client doesn't need them, so over-fetching is also another big problem that GraphQL solves.

Why Netflix adopted GraphQL [02:49]

Thomas Betts: What were some of the reasons Netflix decided to use it? I'm assuming you haven't always had GraphQL, this was an adoption, something you chose to do after you'd had traditional REST APIs.

Tejas Shikhare: We have a pretty rich history on graph APIs in general. GraphQL came out I think in 2014, 2015, was open-sourced and then it started gaining popularity. But even before that, Netflix has already started thinking about something like GraphQL, so we open-sourced our own technology called Falcor, and it's open source, you can find it on GitHub, but it's very similar to GraphQL in spirit. And really where these technologies came from, it's the problem space, and the problem space here lies around building rich UIs that collect data from many different sources and display them.

For us, it was the TV UI. When we started going into the TV streaming space and started building applications for the TV, that's when we realized there is so much different data that we can show there that something like GraphQL would become really powerful, and that's where Falcor came in. And we are still using Falcor in production, but GraphQL has gained so much popularity in the industry, it's community-supported, there's a lot of open source tooling, and that's really when we decided, "Okay, why should we maintain something internally when we can use GraphQL, which is getting much more broader support, and then we can get in all the fixes and move with the community?" That's the reason why we moved to GraphQL.

Benefits of GraphQL [04:10]

Thomas Betts: Gotcha. I like the idea that you had the problem and said, "We need a graph solution," built your own and then you evolved away from it because there's a better solution. It's always hard for companies to admit that what they're doing in-house isn't always the best, and sometimes it is better to go get a different... Well, you made Falcor open source, but a different open source solution. Has that made it easier to hire more engineers onto your team working on building out GraphQL or get people who know how to use it?

Tejas Shikhare: The benefits are a lot, because firstly, GraphQL engineers, all over the place that you know you can hire. A lot of people have experience now today with GraphQL, so that's great, but also the number of languages that support GraphQL. The framework itself has been implemented by the community in many different languages. We use GraphQL Java mostly, but then we also have a Node.js architecture internally that we could easily bring GraphQL onto, so that's a big advantage, so your technology stack broadens as well, hiring is easier, and really I think you can work with the community to improve GraphQL in the ways that you want to. And that's also another big win because we have members of our team who are actively involved in the GraphQL working group and advocating for features that we want in GraphQL in front of the open source community.

The history of GraphQL at Netflix [05:24]

Thomas Betts: You recently spoke at Qcon San Francisco and QCon Plus about GraphQL at Netflix. It was a follow-up to a presentation, I think about two years ago, of some of your coworkers. Is that when Netflix started using GraphQL, that was the advent of using federated GraphQL? What was happening then and what's been happening the last two years?

Tejas Shikhare: Let me go into a little bit of a history. In Netflix, we have three main domains in engineering. Obviously the Netflix product is a big domain of engineering, but in the last few years we've also started investing heavily in our studio ecosystem, so think about people who are working on set, working on making the movies, they need applications too, that are backed by the servers. There's so much complexity in that space. In fact, the data model is way more complex for the studio ecosystem than it is for the actual product, and that's fairly new, so that started about 2018 timeframe, the investments there. And GraphQL was already thriving at that time, and that's when we decided, "Okay, why don't we start using GraphQL for our studio ecosystem?" And a lot of different teams were pretty excited about it, and that's where GraphQL really got its grounding at Netflix and that's where it shined.

And we realized very quickly, even within our studio ecosystem, we had 100s of applications, over 100 services, and that's when we started thinking about we can't have one GraphQL team maintain the API for all of these applications, so that's where I think we started thinking about federated architecture, which allows you to break apart and distribute your GraphQL API to many different teams. That allowed us to scale, so really it picked up in our studio ecosystem, but then at the same time we paired up with the Netflix API team, which is responsible for the API for the product, which was still running in Falcor, as I mentioned, at the time. We started investigating how GraphQL could help in that area, and over time we started extending the federated architecture.

Two years ago when we first did the talk, we had mostly launched it for all of studio, but then over the last two years we started launching it for our Netflix product, so if you pull out iOS or Android phone that's using GraphQL, and our goal is to have a lot more canvases on GraphQL over time. And additionally, we are also using it for our internal tools. You might be familiar with all these applications like Spinnaker, which allows us to do deployments, and we have a lot of internal UI applications that developers use, customer support applications. We are starting to move those to GraphQL as well. Really just all across the company.

Federated GraphQL [07:49]

Thomas Betts: The keyword you keep coming back to is federated, and you said that the federated model allowed more people to work on it. And what's traditional GraphQL? Is it a monolith?

Tejas Shikhare: Traditionally, even when we first started, think of GraphQL as a BFF. It's providing a backend for front end where you can aggregate data from many different sources, so if you have a microservice architecture, you can aggregate data from many different sources, put it all together and so the client can build a query against it. Traditionally what we do is we write the schema and for each field in the schema we write data fetchers, and the data fetchers actually fetch the data from the clients and then we solve the n plus one problem with data loaders so that we don't have inefficient APIs.

That's how traditionally GraphQL is implemented, but what you quickly observe is if you have a very big company, big organization, you have a lot of data, you have a lot of APIs, and the schema starts to grow pretty rapidly, and the consumers of the schema are also, you probably have more than a handful of applications that the consumers of the schema also start to grow. The central team becomes a bottleneck, so every time you want to add a new feature, the backend teams will add it first to the backend, then it adds it to the GraphQL server, and then the client team consumes from it. That becomes like the waterfall model for creating those APIs.

And what federation allows you to do, essentially, is it allows you to split up the implementation. You still have this unified API, the one schema, but the schema is split across many different teams, and each of those teams then implement the data fetchers for their particular part of the schema.

And then these data fetchers essentially do the same thing, really talk to the database or talk to another service in the backend and get the data, but now you split them up across many services, so you split up the operational burden of those data fetchers, you split up the implementation. And also then as soon as one backend team implements it, it's directly available for the clients you use, so you don't have to go through another layer to build it up. That's where the federation gives you some of the advantages on top of doing the classic monolithic way.

Breaking up the API monolith [09:59]

Thomas Betts: It's somewhat similar to a move from a monolith to microservices architecture then, that you're saying. We're going to have a lot of services because this one monolith is too hard for all of our developers to work in one place. We aren't building new features fast enough, so we're going to spread it out. Is that kind of a good analogy?

Tejas Shikhare: And that's what inspired it, moving to federation, using that kind of a thing. We already did this with our monolith 10 years ago, and realized now we have a new monolith, which is the API monolith because that's what we ended up building. And now federation allows us to split up the API monolith into smaller sub-graph services and that, but then you also run into the similar kind of challenges as you go from monolith to microservices. It's not all roses, there are challenges involved, so there are also similar set of challenges when you move from the monolith GraphQL to a federated one.

Thomas Betts: Yeah, let's dive into that. What's the first thing? You say, "Okay, we're going to take it from 1 team to 2 teams, and then 10 teams are going to be contributing to the one API," because you said there's still one graph, but now we're going to have multiple people contribute to that. How does that work when it's creating your first microservice? How do you create your first federated GraphQL instance?

Tejas Shikhare: In our case, our first federated GraphQL service was the monolith itself. In federated GraphQL... Our schema was exactly the same, so we exposed the monolith as the first sub-graph service in the federated ecosystem, so as far as the client is concerned, they can still make all of the same queries and do all that. Now we started to then reach out to a certain set of teams, so initially we bootstrapped this. Since we were maintaining the monolith initially, we went to the teams that would potentially own a sliver of the functionality of the monolith, went to their team and helped them build a sub-graph service. And basically the idea here is to not affect the clients at all, so clients can still make the same set of queries, and so we had this directive in GraphQL to make this kind of migration possible. It's an override directive which allows us to specify to the...

In the federated architecture we have a gateway, so let me step back a little bit, and then the gateway talks to the sub-graph services and the gateway is responsible for doing the query planning and execution. And as part of the query planning, it checks each field that was requested in your query and see which service it comes from, and then it looks at this child field and then sees which service it comes from, and then based on that it builds a query plan.

Now what we can do is we have this one monolith, GraphQL. Let's say we have three different domains within it, like movie, talent and production domain. This is our studio ecosystem. Now let's say I want to pull out the talent domain and make it into its own sub-graph service, so I'll identify the types that are specific to the talent and I'll mark them with the key directive that tells them that this particular type can be federated.

Now, I can redefine that type, I can extend that type in the sub-graph service using the same key directive, so that's something that they have to agree, and then I can slowly say, "Oh, these are the fields within, say the talent type." And I can start saying that now for these fields, go to my sub-graph service, the new talent sub-graph service, and you can mark those at override. That tells the gateway, the router, that, oh, for this particular field, we know that this original service can provide it, but also this new service can provide it. And then the future query plan takes into account that, okay, we are going to send it to this new service. That's how we started, so we did that for one service, the next service, and we slowly started pulling out until our monolith GraphQL became an empty shell and we got rid of it. It took about a whole year to do that because it had a lot of APIs in there, but that's how we started.

Thomas Betts: Yeah, it sounds like a strangler fig pattern. You can build a new thing and then you start moving it over, so it's again, following the patterns for how to move to microservices, the same thing for moving to federated. 

Moving to GraphQL from Falcor or REST [13:51]

Thomas Betts: Let's back all the way up though. I wanted to get into, you said that you were using Falcor for a while because you had the need for a graph, but then you had to switch to GraphQL. How is that different for we have a graph architecture for our APIs, versus somebody who doesn't have that in place and they're just getting started? You started in a different place than I think most people will be coming to GraphQL.

Tejas Shikhare: The example I described of migration earlier was all GraphQL in our studio ecosystem, because it was already GraphQL. In our consumer's ecosystem we had Falcor APIs and then we had to migrate them to GraphQL, which is I think what you alluded to. And then also, what would someone who has no GraphQL or no Falcor would do? I hit the first one already, so I'm going to hit the second one, which is how did we do from Falcor to GraphQL, real quickly? As far as Falcor is concerned, it has similar concepts as GraphQL, but really moving from Falcor to GraphQL is a lift. It's as good as moving from REST or GRPC to GraphQL because there's not really that much in common in how it works, but conceptually it's still similar, so it was a little bit easier, but not that easy.

The way we did the Falcor migration is we built a service on top of the Falcor service, a GraphQL monolithic service, a thin layer, and then we mapped the data fetchers for GraphQL data fetchers to call the Falcor routes, and that was additional engineering effort we had to put in, because that allowed us to convert. And then now that we had the GraphQL monolith service, then we applied the same pattern to move it to different services, which actually we haven't completed yet, so now we are at a stage where we've just move to GraphQL and there's only one service, but eventually our goal is to move it out to different services. Let's say if you don't have Falcor, it's more conceptually different, you have REST APIs in your ecosystem, and you're thinking about, "Oh, GraphQL is great for all of these things and I want to use it."

In that case, I would follow a similar pattern where I'll set up a new service, like a GraphQL service, and then start building the schema and implement the data fetcher so that it calls my existing REST endpoints. If you have a monolith, then maybe you can just build it within your monolithic service, so you have your REST API sitting alongside your GraphQL API, you can put it on a different port, and then have the GraphQL call into either your existing functions, your business logic. You still implement the data fetchers, but then they call into either your existing APIs or business logic. That's the way I would start, and then once you have this GraphQL API that works and clients start using it, then obviously if you're a big company, you want to start thinking about federation because you have a lot of services and you can grow and scale that GraphQL API, but really you want to see if that's working well, maybe just keep going with that for a while. And we did that too for almost a year and a half before we even considered federation.

Thomas Betts: Yeah, I like how you talked about we had Falcor, we couldn't just jump to GraphQL, we weren't going to do a full replacement. Again, it was almost that strangler pattern. We're going to put in an abstraction layer to help us with the transition rather than a big bang approach. You were able to make iterative things. 

Why use GraphQL Federation? [16:44]

Thomas Betts: And then let's go into what you were just saying about when do you get big enough that you say, "Hey, this is becoming hard to maintain." What are the pros and cons of moving to federation and why would somebody say, "Hey, it's worth the extra work that we have to do?" And what is the extra work when you get to federation? You don't get all that for free.

Tejas Shikhare: First, let's talk about the pros. Remember how I talked about earlier that the GraphQL service could become the central bottleneck? The first thing is you don't have to implement the feature in the backend service, in the GraphQL service before the client can use it, so that is one of the big problems that federation solves, so you can just have the owning team implement the feature and it's already available in the graph.

The second one, big pro is operational burden. You can split the operational burden instead of one central team being on call and the first line of support for all your APIs, you can kind of split that up and scale that a little bit better. We've seen that the more skill you have, you can see that part of the team, and I've known people who have worked on this team for a long time, that you can have some serious burnout on the engineering side. It's just hard to be on call for frontline services all the time, and it's stressful too. And you can hire more people to split up the on-call, but ultimately I think splitting up the support burden is very nice. That's another win from moving to federation.

And then the third benefit, I think it's a lot of companies, they'll have these legacy applications that you don't really develop actively, but you still have to maintain them, you have to expose those APIs, and what Federation allows you to do is you can convert those existing legacy applications into a sub-graph that you can contribute to the overall GraphQL API. It really allows you to modernize your legacy applications that you don't really maintain, but then expose it to the graph and then the clients can start using the GraphQL API, so that's a nice one. You can also do it in the monolith, but it's always falls behind. It's not like something a priority, but then the team owning it can modernize their own legacy application. I think it's a nice little win from federation.

Yeah, we covered the wins, but obviously it comes with some of the challenges, and I think that was your primary question, and the challenges are many too, because previously one of the big things is now everyone has to implement their GraphQL APIs. Everyone has to learn GraphQL, because you're federating the APIs, so each team is exposing a sub-graph service that's a GraphQL API, and GraphQL, although it has some complexity over REST or GRPC. REST or GRPC it's action handlers that you implement and then you call into your business logic. In GraphQL you get a query that can fetch multiple different kinds of data and then you learn how to use data fetchers, and then understand data loaders, so there is some complexity and learning curve there, which can be challenging if your entire company has to do it.

The second big challenge is I think the health of the API, like when we are designing an API, it's easier to collaborate when you're one team and building it by yourself, but it becomes very challenging when you have multiple teams, in our case 100s of them designing them in their own silo. And then does it combine together nicely to form a well-designed API that's actually useful to the client? Because ultimately you're building the API so that the client can consume from it, but if you just build something that's not what the client needs, then you're not really solving a problem, so that's a big challenge with federation and really those are the two things that we've been focusing on improving, making GraphQL developer education better, but also making schema development easy.

Tooling to help with federation [20:04]

Thomas Betts: It sounds like you've had to have a lot of people working on being able to scale the effort of federation, like you said, learning and coming up with the training tools. Do you also have tools that you're using to help monitor and learn what's in the graph and study that? How many people are working on the tooling and the platform compared to how many developers are now using it?

Tejas Shikhare: We've been working on a lot of different tools to make implementing federation a little bit better. I'm going to put that into a few different buckets. We have observability, which is an important aspect of any server-side development, and that's an important... We have a ton of tools that are federation-aware and GraphQL-aware that we've done. Then also the schema development and making the schema better, and then also feature development for the backend owners to make that easier. Roughly on the platform side, across these many buckets, my team focuses on GraphQL. We have about 6 or 7 people doing GraphQL-focused tooling, but then we work with say, the observability team, the Java platform team to make the Java platform easier, so maybe a total of 20 individuals from across all the different domains. And then I think on the developer side, we have over 1,000 at this point that are actually building and implementing sub-graphs, because we have the internal tools, the studio applications, the Netflix product API, the new games initiative, all of that we'll build with GraphQL.

On the observability side, we focused on making distributed tracing easier with GraphQL, so essentially you can track how each request is planned and where it's spending time. This is really good because it allows client developers to optimize their query by requesting fields that they feel like they need to render early versus render later, so they can see, but also allow backend developers to see where they might be introducing inefficiency in their system. That's really powerful, and it is aware of these data fetchers that I was talking about earlier that it can track that in the distributed trace.

Then we also have metrics, GraphQL-aware metrics. Normally if you have a REST API or GRPC API, you'd create the success scenario and then you'd have all these different kinds of errors, like 400 and all those kind... And then you send it to your metric server.

But GraphQL is a little bit tricky because in GraphQL you can have partial failures and responses, so we had to make GraphQL-aware metrics that we do, and we map them onto the existing metrics that we have so that you can create these charts when there's an outage to see, oh, what kind of error is happening? And you can track that up.

Really focusing on observability was important, and on top of that, for the schema development, one of the challenges I talked about is here. Observability just was stable stakes. It was something we had before and we needed to have almost the exact same experience with GraphQL and not anything harder.

But with schema design, it was one team doing it before and now we have multiple teams doing it, and firstly we needed a way to track schema health. We started tracking that, but then we realized people were doing too many things and it was impossible to do that, so we created the schema working group where people can come and ask for, showcase their schema, get a review done, and also discuss schema best practices.

And then once we had the schema best practices, we needed a way to enforce them. Enforce is a strong word, but really make people aware. We built this tool called Graph Doctor, which allows teams to get PR comments about what best practices they're not following in their schema design, so that would come directly on their pull request, and also a lot of sample code to how to do the things right way and then point them to that so that they can go look at it and then just start doing it. Those are the two things that help with schema design.

Then the last part is when you move to microservice, you have to make the development of the service easier with feature branches and things like that, so we had to do a similar thing with GraphQL where we have this overall API, but your team is responsible for this small part of the API, but you don't want to just push everything to production before... And you test in production, so you need a way to have your part of the graph merge with the rest of the graph in production and then give it to someone to test, so sort of like an isolated feature environment for people to use. That was another thing that we had to build, because previously the API team could just do it in the central monolith, but with this distributed ecosystem that was hard to do, and one of the big challenges. Those are the main key tools we focused on.

Schema-first development

Thomas Betts: My question was a little vague and you covered everything I wanted you to say. Going back, you said you've got maybe 20 people, but that's empowering 1,000 developers and that GraphQL, it's how you're doing work, but you basically have to treat it as a product that you manage internally and you're constantly getting, I'm sure feature requests and hey, how can we improve this? How can we improve this part of the developer experience? Your last bit about the schema and the schema working group, I think that's a whole nother conversation we could have. I believe in your QCon talk you'd said schema-first development was what you proposed. Can you describe what that is?

Tejas Shikhare: Another way to say it is API-first development, so starting with the API, so starting with the needs of the client, identifying the problem you're trying to solve, working with the product manager, working with the client developers, and coming up with an API together that works for everyone. Because what we often tend to do, and I've been a backend engineer and guilty of this many times, is we implement something and we create an API for it, and then we said, "Oh, here's the API, use it." And that's great if you've put a lot of thought into the API, you've thought of all the different use cases, but that's not always the case, and what makes that easier is having a schema-first approach or an API-first approach where... Or design-first approach, another way to say it, is you really understand the needs, product needs, client needs, and then working backwards from there and figuring out with the API.

And once you do that, you might realize the stuff you have in the backend doesn't fit quite nicely into that, and that's when you've built a good API and you have to now start making the, or saying, "Oh, we maybe can provide this," and then you start taking things out of the API so that it fits with your backend. But then you've really done the homework, and that ultimately leads to better APIs, more leverage for the company because these APIs then become reusable for other product features. Yeah, so that's really what API-first design in my mind means.

Thomas Betts: One of my wonderings about GraphQL is that I could have all these APIs that were created and none of them met my needs as a consumer or the product manager, but I realize if I call three or four of them, I can get what I need, but now I have performance issues. Oh, in comes GraphQL, and it says, "Oh, I can just ask each of those for just the bit that I need and I've created this super API." But you're now talking about GraphQL as the primary way of doing things, and that that should influence the API development because people are writing those connecting layers and they're always thinking about the final use of their service, not just, well, we need something that is the talent database here, I'll just put all the data on one... Fetch one person by name or by id.

Tejas Shikhare: Yeah, exactly. I think that you nailed it there.

Thomas Betts: For non-GraphQL, when we just have REST APIs, one of the approaches is contract-driven development where you write the contract first, you write your open API spec or whatever it is, and then the consumer and the producer both agree to it, which is different than one side versus the other has to use it. There's different ways you can test this to say, "Hey, I as a producer meet the spec and I as a consumer expect the backend to do that." Is contract-driven development similar to the schema-first approach you're doing or is that a different scenario?

Tejas Shikhare: Yes, exactly. I think it's very similar. I think that's yet another way to just say the same thing, because ultimately you're building an API that works for the client and that the producer can provide, and schema is the contract in GraphQL, so oftentimes we refer to it as schema-first development, but really I think conceptually they're very similar.

The evolution of APIs at Netflix [27:44]

Thomas Betts: You've been doing this project for a few years, we talked about some of the migration challenges, and I like that you focused on it as a project that you had to migrate and it's still ongoing. Where are you at now in that evolution? When do you expect to be done, and what does done look like?

Tejas Shikhare: Where we are, I think we have a lot of people using GraphQL at Netflix for a lot of different things, and it's almost a little bit chaotic where we are trying to tame the chaos a little bit, and we are in the phase where we are taming the chaos, because people are so excited they started using it and we saw some of those issues and we're starting to tame the chaos. And really the next step is to migrate our core product APIs, because they experience a lot of scale challenges along with moving to a new kind of technology. It's almost akin to changing parts of a plane mid-air because we have so high RPS on our product APIs, and really we need to maintain all of the engagement and all that stuff, so I suspect that will take us about a year to two to really move a lot of the core components onto GraphQL, while also making our GraphQL APIs healthier and better, instilling all these best practices, making the developer tools, and one day everything is in place and people are just developing APIs in this ecosystem.

And that's when I think it'll be in a complete space. We have the nice collaboration workflow that I talked about, schema-first development between the client and the server, and there's all the platform tooling exists to enable that, and we have a lot of best practices built up that are enforced by the schema linting tool and things like that. I think we are probably around maybe a midway point in our journey, but probably still quite a bit of ways to go.

For more information [28:29]

Thomas Betts: Well, it sounds like you're definitely pushing the boundaries with what GraphQL can do, what you're using it. I'm sure there'll be a lot of interesting things to look for in the future. Where can people go if they want to know more about you or what Netflix is doing with GraphQL?

Tejas Shikhare: I think for me, you can reach out to me on Twitter. My handle is tejas26. I love reading about GraphQL and engaging with the community there, so definitely reach out to me if you have questions about GraphQL and where we are going with it at Netflix. We have tons of stuff that we've published. We have a series of blog posts. We have open source, the DGS framework, which is Spring Boot, which is a way to do GraphQL in Spring Boot Java, which is what we are using internally. We have a couple of QCon talks, and even GraphQL Summit talks from coworkers, so if you just search Netflix federated GraphQL in Google, some of these resources will come up.

Thomas Betts: Tejas, thank you again for joining me today.

Tejas Shikhare: Thank you so much Thomas.

Thomas Betts: And thank you for listening and subscribing to the show, and I hope you'll join us again soon for another episode of the InfoQ podcast.