In this RedMonk Conversation, James Governor of RedMonk interviews David Annez, VP of Product at loveholidays, to explore the company’s approach to adopting absolute cutting-edge technology while managing risk. The company relies heavily on Fastly’s edge network services to build its scalable, high-performance platform, supporting its rapid expansion and growing customer base, processing a booking every 40 seconds across the UK, Ireland and Germany.

This was a RedMonk video, sponsored by Fastly.

Rather listen to this conversation as a podcast?

Transcript

James Governor: Hi, I’m James from RedMonk, and we’re here to talk today about you don’t have to be afraid of the bleeding edge in technology adoption. I’m here with David Annez, VP of Product at loveholidays. And, yeah, I think that’s an interesting approach — the idea that experimentation and the bleeding edge are okay is interesting when so many people are worried about risk. So the first thing I’d like to know, shouldn’t really hone in on risk too much, but Love Holidays. Tell us a bit about the business, what it is you do, and then we’ll leap into why you do what you do.

David Annez: Yeah, sure. So I guess Love Holidays is a travel company. We sell package holidays in the UK, Germany and Ireland, currently third largest in the UK. And we process like a booking every 40 or so seconds. So, like, a lot of traffic, we get a lot of bookings. And we’ve been very successful leveraging bleeding edge technology to deliver the kind of search platform that we have today and primarily using Fastly for some of those systems. And so it’s been a really interesting journey over the last few years, getting to the stage where we’re at now, where we can experiment at scale and have built an incredibly performant platform that has let us now expand into Germany and start selling more package holidays.

James: Awesome. So, experimentation, for me, is interesting because basically, I talk a bit, or talk a lot, in fact, about this notion of what I call progressive delivery. So if we take the core concepts that really taken us forward as an industry with the ICD, there were a bunch of things that perhaps it wasn’t obvious how easy they would be. So if we think about the abundance that the cloud gives us and the ability to therefore experiment, because with abundance and automation, you know, why should I spin up one thing if I could spin up five things? We’re living in a different environment. And this progressive delivery notion, as I say, it’s interesting being able to talk to you. You take a view of experimentation. I mean, it’s not just A/B testing, it’s ABC… goes a lot further than simple two states, doesn’t it? Tell me a bit about, you know, how that works for you and why you take that approach.

David: Yes, I think we do multivariate testing and A/B testing as well. I think for us, trying to figure out n different like, options and then figuring out which one’s the most performant one is really important. It lets us do more granular tests and test a slightly different hypothesis of the same experience. Right. Rather than constantly running one A/B test and letting it run to significance, we try and run A/B/n tests to then figure out, well, actually one of these variations is the right one. So it gives us a little bit more flexibility in our experimentation platform. Now, naturally it can take a little bit longer to get to significance, but I think it gives us way more of an understanding and it lets us think a little bit wider than just experience A and experience B and then go on from the next one from there.

James: Okay, so performant is an interesting word because that can mean both. Something that’s really fast, but also something that works really well, or possibly both. I mean, you’ve got some interesting views on well, you know, performance. What do you mean by performance in that context?

David: Well, I guess there’s two sides of it. One of them is delivering a performant experience and being able to make a decision to show experiment a, b or c to the customer as quickly as possible. The other one of course, is the performance of the test itself, which is like, are you doing winning tests and more winning tests, talking a little bit about kind of performance to the customer and delivering like an experiment very quickly to the customer. That’s really important for us. I think historically A/B testing has been either client side or the server side version is very slow. And making that decision is really important to do it quickly. Cause if you’re global and maybe your services are not cached at the edge, then actually you’re going all the way to origin from the US to the UK and then you’re making a decision on experiment. It could take several seconds just to render a page. And that for us is just not good enough. Like for me, performance is really linked to scalability and also cost efficiency, right? If you focus on building performance websites, then a lot of the benefits come out on scalability and cost efficiency.

You’re delivering less bytes to the client and you’re probably making your service a lot more scalable because it can handle more load. And so that for me is part of the principles of how we think about performance at Love Holidays. And that means that when we were building the experimentation platform, that was like critical to it, which was we need to deliver a decision on a test in under a millisecond so that we can ensure that the experience to the customer is still perfect.

James: Okay, so another question, and I should have asked this before. What is your stack?

David: Well, currently, so we have Fastly as our content delivery network. We also use computer edge for our experimentation platform within that. And then into GCP and we have our own kind of Preact which is a variation of React web framework. And then we talk to multiple services through GraphQL. It’s relatively straightforward tech stack underneath the hood, but I think the magic really sits at the Fastly computer edge level where we can start making decisions and cache things more appropriately for our teams.

James: So bleeding edge for you doesn’t mean using a new JavaScript framework every week.

David: No, no, no. I think you should think carefully about when you reinvest in those areas. We are always looking for the next best thing to actually focus our time on. But I think that ultimately if you can get your engineers to deliver at pace good quality stuff that isn’t harming the customer experience. And that’s why we picked Preact over React, then like, you know, just pick the right tool for the right job, not the next new shiny thing.

James: And how many engineers do you have?

David: Currently there are about 68 engineers at Love Holidays.

James: Okay. Okay. Yeah. For business of that scale, that’s a good number.

David: Yeah. I think we pride ourselves on trying to like, scale scalably. We don’t want to just add hundreds of engineers. We think very thoughtfully about where we add them and the importance of where they add value. And I don’t think you need a thousand engineers to build a very successful business.

James: So this question about performance, obviously it’s super important to you. That’s one reason why the edge makes sense. I think one of the questions I’m looking at in trying to understand the industry evolution is how much compute we do move to the edge. So obviously the nature of your business — start with cache. That’s something that you are always going to do. But how far does that go? At what point do you say, maybe we don’t need to run this service on Google Cloud, we could run it just on say, Fastly. How do you see the boundaries between caching and compute going forward?

David: I think that’s the thing that I’ve been thinking about a lot lately. And there’s a, rather than thinking about caching for a moment, I think it’s thinking about global availability as close to the customer as possible. So like removing caching from the concept for a moment, computer edge allows you to run basically a JavaScript application or an HTML application on Go or Rust anywhere in the world, right? As close to the customer as possible. So I think the thing that I’m thinking about there is if you are global and you are serving customers all around the world, which we are, and one of the interesting things with Love Holidays is yes, we are in the UK, Ireland and Germany only, so Europe mostly. But actually our customers travel all around the world, and so when they’re in the US they’re accessing an origin that’s in London…

James: You still want them to have a good experience.

David: Exactly, exactly. And so when you start thinking about running JavaScript app on the edge and it’s global, and you’re delivering that experience directly to the customer, it doesn’t necessarily need to be cached, as long as you’re fetching data from the same global pots which now Fastly enables you to do with the key value store, the config store, etcetera. And so we’re starting to think about what does that actually look like in practice? I don’t think it’s fully solved yet, given that we have a lot of runtime services that give us live prices and all of that. But I think for a lot of content that might not be as dynamic, you could essentially store it at the edge with a JavaScript application and give the same performance to everybody without necessarily going to the cash level at that point. I think there’s a very interesting comment from the original CTO of booking.com, which is like if you’ve added in cache in a layer, you’re doing it wrong, right? Building a really performant application is like your first port of call, and then caching is the next bit if you can’t make it fast enough.

And so my view is move everything to the edge and you build it fast enough, then you don’t necessarily need to cache everything as well. But it’s a cost saving then at that point when you’re doing that on Fastly.

James: Right. So I guess it sort of — and that was a future looking statement. But to sum up a bit, I mean, business that’s absolutely founded on this issue, we need to be able to experiment, experiment quickly, get stuff out to our end users. How do you see, I don’t know, like the evolution of this platform over the next couple of years, which is a very big question, but I feel like the need to offer better and better experiences, digital experiences, I mean, that’s just becoming ever more important. What do you see as some of the frontiers there? How far can you take that? It’s very open ended. But as a VP of Product, how do you see that product evolving in terms of customer adoption?

David: I think we’re already seeing it in certain areas. So working with a really large global retailer, because we’ve helped them craft their experimentation platform much like ours, they’re starting to use it quite extensively and using it similar to how I’ve described where they fetch data from origin, but then when the data gets fetched, they store it in the key value store, so then they have it at the pop, and so then they render their JavaScript engine there. And that’s been really, really good for them. And the developer experience in addition has been really easy, right? They can run it and test it just like it runs in Fastly. So I think that’s been really useful. I think a lot of businesses might not get there in the next few years. There’s a very large difference in, people that are very advanced and everyone is just running a normal e-commerce website. I think the biggest use cases that I see it at the moment are all of the things that you need to do at the edge that might help you make a decision or improve the customer experience. So two examples that I can think of are redirects at the edge. So making a decision and just being able to manage that at the edge with the key value store is super powerful. The second one that we’ve been toying the idea with, and I’d love to open source, what we’re going to be doing is the consent manager. Everyone loves a cookie banner, right?

James: And GDPR. Yes.

David: Yeah. But actually one of the really interesting things with this is the most frustrating thing for me with cookie banners is the fact that you load a page, you see the content, you’re really excited to scroll, and then all of a sudden this 600 kilobyte JavaScript bundle pops up with the 75 things that are about to track you, right? And that’s really frustrating. That small little jump up of something is just not a great user experience, and you can make that better while still being compliant. And so using computer edge, because the beauty of computer edge is you can actually manipulate an HTML response, right? And so the response that comes back from the origin, you can then add something into it. And so with computer edge you could basically say, well, if this customer hasn’t consented, let’s inject this actual HTML, not JavaScript, into the page to show them the model to give them the consent. But if they do, if they are consented, let’s not inject anything. Let’s not degrade the experience, because we have to load in the cookie banner and not show it. I think that’s a really great use case for something like this where — and you might not want to change your entire experience. It might still be at origin and GCP or AWS for Azure, but you might want to make some modifications or change a few things or make a decision like A/B testing. I think that’s where those encapsulated computer edge systems can really, really help you enhance the content delivery network experience that you’re giving to customers.

James: And I didn’t know I was going to ask this question, but I got to ask it now. Okay, so you do open source technology that you built?

David: Yeah, yeah, we absolutely do. We’ve open sourced a bunch of things over the last few years. I’m trying to remember one of them. We open sourced one that I think is really useful for companies at scale, which is it’s called Ripley, and it basically allows you to replay your logs on your systems so that you can actually then simulate six x ten x 20 x your traffic to see if your systems actually scale. And so we do that nightly to actually test. If all of a sudden everyone wants to book a holiday tomorrow. Can we actually handle it?

James: After watching this? They definitely [inaudible chatter]

David: Well, hopefully.

James: Hopefully. Okay, good. Thank you very much for that. Yeah, wanted to keep it short and sweet. That’s a RedMonk Conversation. David Annez from Love Holidays. Thanks a lot. And yeah, I mean, take a look at the Love Holidays site if you want to be traveling in Germany, Ireland or England. Yeah, I’m going to be checking it out myself.