← Marketecture: Get Smart. Fast.
Marketecture: Get Smart. Fast.
Inside AWS’s RTB Fabric: Sergio Serra on Reinventing Ad Tech Infrastructure
00:17:01
Loading summary
Transcript36 lines
- [00:10]
A
All right, welcome to marketecture, where you can get smart fast with in depth interviews of leading tech executives. I'm Ari Paparo, I'm joined today by Sergio Serra, who is the PM lead for RTB fabric at aws, Amazon aws. Thanks for being here, Sergio.
- [00:25]
B
Thanks for having me, Aria. Super exciting.
- [00:28]
A
So your colleagues were on stage at the recent Architecture Live just after you introduced this product. So a lot of people heard about it. But, but you're, you're where the buck stops. You're the product manager. So we want to hear firsthand. So what, what is RTP fabric?
- [00:45]
B
Absolutely. So RTP fabric is really a clear signal of AWS full commitment, I would say, to invest into our customers. Not just general proposed compute. We propose built infrastructure for the industry and for years SSPs, DSPs and all the ad tech customers in general had to stay in Colos or build custom private link networks just to meet their strict latency budgets. And so we set that to change and we came up with a purpose built network which again we refer to as the service RTB fabric, that is heavily optimized for RTB workloads and it allows to really communicate in a super fast, low latency and cost efficient way among different ad tech customers that we kind of abstracted away. So we have a concept of requester, which is really your SSP publisher or whoever sends a bid request. And then you have a concept of responder. Right, which is a DSP, but can also be another ssp. Right. Responding back to a resolved supply from another ssp. And so we didn't want to get into those nuances and rather have request and a responder.
- [02:00]
A
Right, Right. So you have these two parties and currently, let's talk about what it's like without fabric. So currently if I'm on, let's say I'm on aws, I just make an HTTP request to the other party and I have to pay egress fees, bandwidth fees, and also I'm not, I don't think, I'm sure it's in the same availability zone and things like that. Right, so is that a big part of what fabric improves?
- [02:27]
B
Yeah, absolutely. You're totally spot on. So I think you touched upon two important things. So one is the cost component. Today you are on AWS and you make a call to another AWS partner or even outside on the fabric Internet and that call costs you that egress. The other thing is if you are on the receiving side, you have a cost to bear on the load balancing. So you have exposed your endpoint as a DSP or as a bidder, and then that endpoint as to resolve into your actual fleet. And so that comes with another load balancing cost. RTB fabric allows you to really waive these two taxes. And I think I'm super excited about this as an adtech veteran too. So we were able to align cost on the unit economics of adtech. So we bill for per billion requests or billion transactions, where a transaction is a bid request sent from the requester and a transaction can also be a bid response for the responder side. Right. And so that is super cool in my mind. And the other thing you've touched upon is of course colocation. So today even if you are in the same AWS region, it's not a given that you will be automatically co located with your partner staying in the same region itself. So for instance, it's very often that customers will be deployed into multiple Availability zones. Availability zones are really clusters of data centers. Right. And so you can create your own workload in a specific Availability zone within a region, but your other partner might be whether either on that Availability zone or another one. Right. And so we try to automate that so that whenever you send a request we are AZ aware Availability Zone aware, so that latency can be improved.
- [04:11]
A
Right. So a real world example might be if you have redundant Availability zones, you have some servers in one, some servers in two, they're both in Virginia, but they're separate. So they have one goes down, the other one's still alive and then you're making requests to a DSP that has the same setup. You really want it to route correctly. And currently it's not an intelligence that many people would have as to how to route that.
- [04:36]
B
Exactly, you're absolutely right. And even though you are in same pre Availability zones within Virginia and your partner is in those exact Availability zones, it's not a given at all that we will resolve to the same Availability zone. You have a 33% probability. But with us with FTP, fabric becomes deterministic.
- [04:55]
A
So tell me about the load balancing. Like what is the advantage there? Don't I still need to load balance if I only have a certain number of servers?
- [05:03]
B
Well, yeah, I would say that at the end of the day, anybody today is using some shape and form load balancing. It could be another AWS or another hyperscalers managed load balancer, or it could be your own self managed load balancer like Haproxy and Gen X or the likes. And you do that because you need to do TLS termination You need to resolve to your specific fleet. And we actually do it in a very smart way and a very cost efficient way through DNS routing. So this means that you provide us, when you come to the service, subscribe to the service, you provide us your auto scale groups or your AKS cluster. And based on that we just figure out where to route the request directly from the requester side. Again, usually this comes with a cost. You have to manage all the cycles for taking down our machine deployment, taking it back up. And so all of this is non trivial and usually you rely on a load balance. Again, we do that included in the service. There is no extra cost. It just came, comes in the, in the cost per billion model.
- [06:07]
A
Right, got it. Okay. So and then in terms of like commercials, the, the customers still have to have business relationships with each other. Right? You're not, you're not facilitating that part.
- [06:19]
B
Yeah. So I think that's another important and key question. Right. So RTB fabric doesn't skip the foundational steps like legal contracts or API integration from a more OpenRTB perspective. Right. So those still have to happen between, you know, the ssp, the DSP and the various entities. Where we make the difference though is what comes next right after that. So today, once two parties are ready to exchange traffic, they have to decide how to connect. Right. And it could be through cross connect, like the very traditional collocation, or through something like AWS private link. But again it requires a lot of manual efforts and coordination. You just need 10 minutes in this case. Yeah.
- [06:56]
A
And now one of the things you talked about on stage or your colleagues did was about like the, I forget what you call them. They were basically containerized services models. Okay, why don't you talk about that?
- [07:08]
B
Yeah, yeah, absolutely. So I think that's another very novel approach we are introducing. Right. So on one hand we are trying to solve for cost efficiency and for latency, but on the other we are also trying to help move away our customers from monolithic applications. Right. And so going to this concept of modules and the idea actually allows you to be much faster when you deploy because you can kind of remove from your core stack non differential things, non differentiating functionalities like traffic shaping or very rudimental filtering. And the thing that is novel to me is that now you can run these models tweaking the link. So the link is the one on one relationship between your RTB gateway, which is what you create when you come on board with AWS RTB fabric and the RTB gateway of the customer. And so you just peer with each other. As I said, it takes like five to 10 minutes. And once that connection is completed, you can send away links and requests through that link. So what this means is that within the link now you can attach modules. So we have some built in modules, specifically three built in modules. One is Rate Linuker, which really allows you to protect your underlying fleet. I can tell you how many times, and I'm sure you have been there many times too, but how many times because of misconfiguration or some bad deployment, we ended up in my previous experience, bombarding the DSPs and so taking their fleet down. So now the DSP can just say, hey, I don't want to have more than 1 million QPs from this specific link. So from this specific SSP, anything that goes above that, we will throttle it for you. The second thing is an OpenRTB filter. So we allow you to dictate functions on the back of attributes, OpenRTB attributes, so you can declare any path. You don't want to have requests from a specific country or the one I have requests from a specific publisher format. Anything that is on the OpenRTB, we filter it for you. Now why is this great? Because you still have to deserialize the request, usually, right? Even if you don't care about that, you pay a cost for deserializing that. In our case, we do it for you and you have full control on the business logic. You tell us what to filter, we do that. And the last one is error masking. So that was really a requirement from our DSP customers. And the idea is sometimes you are deploying, pushing some code changes and so some of your VMs go down and retort. Service unavailable. Right. And we know that SSPs have circuit breakers and so they tend to penalize them. Even temporary VSPs don't want to have that. So we temporarily can mask that 500 to a 204, which is a no bid. Again, these are all services that come in on the network path with no additional cost. And they are super fast because they execute in the network.
- [09:58]
A
Right, that's super interesting. So in my experience, like the QPS spikes are a real problem because you might have, the engineers would call it elastic scaling, but it doesn't work when you're talking about this volume. You can't just add 20 servers in a second. It just doesn't do that. So having some guardrails would have been great. When I was running a DSP on the filtering side, I'd love to ask A little more follow up on that. Is it basically Boolean if it's country equals China, don't send it. Or is it, you know, percentages and how, how, how many can you layer rules on top of each other?
- [10:40]
B
Yeah, that's a great question again. And so the built in service we offer at the moment is just a match. Right. You can put together multiple rules like if the country is Russia and The format is 320 by 50, filter the request. Okay. But what we are doing, which is actually super exciting again when I go back to my BSP app, I would have loved to have this. So you can upload supp. So really segments based on attributes of the bid request and you can upload those in a shared cache and we take care of filtering the request for you based on a direct match and you can upload that as often as you want to, but this becomes very easily super granular. Right, right. So that's what DSPS do today as well. But they are still to deserialize as we say.
- [11:26]
A
Yeah, absolutely. Okay, so let's talk about the economics. So who pays? How much do they pay?
- [11:34]
B
Yeah, so that's again a great question. And as I mentioned, we are the first purpose built adtech service that also builds on ad tech unit economics. And what this means is that you pay per billion transactions. Again, a transaction in our case is a bid request as a requester or a bid response as a responder. There is also a nominal fee as a no bid. Right. Just to cover the cost of the service. So say that you receive 10 million QPS and you just respond back to the 10% you are charged for that 10% but also for the other 90% you are charged a very nominal price which I call like a tax. Right. Rather than a fee. So. Right, yeah.
- [12:15]
A
So the sender, the sender of the request is going to pay for every sent request and the responder will pay for every response plus a lower fee for non responses.
- [12:26]
B
Precisely, precisely. And we have multiple dimensions on pricing also based on internal transaction or external. So this where it gets interesting. Many people believes that RTB fabric, and that's a misconception of course, is a service only for AWS customers that communicate with other AWS customers. We actually allow RTB fabric to reach out to the public Internet. Of course most of these synergies and efficiencies we spoke about are really pertinent to the internal transaction because we can have more control on latency and colocation. But still, if you are sending a request to a Partner that is outside aws, you can do that and we classify that as an external transaction. Same thing if you are a DSP or a bidder responding to a request coming from outside AWS network, you can still do that. It comes with an increase in price, of course, and there is less efficiency when it comes in general to latency, but we totally cover that. And last thing I will mention Ari, is that we do have also a tier based pricing with two main tiers. So from 0 to 2 trillion transactions you pay X and then if you go above 2 trillion transactions from the incremental transactions you pay much less. And of course these two kind of help and incentivize customers to have higher volumes.
- [13:45]
A
Right, okay, that makes sense. And so just to be clear on the pricing, so if I was, if I'm currently, let's say I'm a seller and I'm sell, I'm currently sending a million bid requests to a buyer on aws. I'm currently paying for bandwidth, among other things. We switch to fabric. Does my bandwidth bill for those million requests go to zero and then I just pay the fabric fee? And is the, should I expect just on an apples to apples basis a lower total fee if I switch?
- [14:16]
B
Yeah, yeah. So that's again a very interesting topic. So the idea is this. We of course went back to the whiteboard, surveyed multiple customers and you know, based on our analysis, 2 kilobytes is pretty much the P95 of the OpenRTB requests and responses. So we cover that payload size for any definition of transaction if you still need more than that. Right. We do have a price per gigabyte which is still discounted compared to public pricing. But the idea is that you send a request via fabric, you don't pay anything else in terms of data transfer out data transfer inter regional and the like. So no hidden cost. It's all very mathematical and linear. So you can do the reputation very deterministically. And I think I would just close on that on my side saying something very interesting. RTB fabric really allows you to reduce cost, right. As far as networking is concerned by an order of magnitude. Again, that's huge when you compare to any other standard networking cost of hyperscalers. Yeah.
- [15:24]
A
And who are some of the launch partners?
- [15:27]
B
So we have many launch partners and of course people can find them in the official website. Some of them are Triple Lift, Viant, Ilmo and many more like Mobile Fuse. Of course we also work with Amazon ads, so APS and Amazon DSPs are also on board.
- [15:46]
A
Great.
- [15:47]
B
And many more are also coming, of course, and I will invite everybody to check out the website.
- [15:52]
A
Right, okay, great. So let's do a quick lightning round, some quick questions. You give me quick answers with regard to fabric. So what is the biggest challenge moving forward?
- [16:03]
B
I think really fighting the misconception that you can use fabric only within AWS backbone infrastructure, you can actually go outside very easily.
- [16:12]
A
What's the biggest competitive advantage?
- [16:15]
B
The size of AWS allows us to, of course, be very cost efficient.
- [16:21]
A
And if fabric was an animal, what animal would it be?
- [16:25]
B
Oh, that's a good question.
- [16:26]
A
That's always our last question.
- [16:28]
B
I would say it's a lion because it's gonna really break the industry on that extent. So I love to define it as a lion.
- [16:38]
A
Lion's a classic answer. We get a lot of tiger. More tiger than lion. All right, Sergio Serra, the PM lead for RTB Fabric, thank you so much for joining us.
- [16:48]
B
Thank you so much. Adding.