You're Not Netflix

Ronald van Rijn at UXDX Community: Amsterdam. Video: https://www.youtube.com/watch?v=HOhU1Jr7uC8

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introduction: FUGA and copying the best without knowing why

[00:00:00] I am going to talk for the next 20 minutes about architecture and technology, and I notice that I'm the odd one out. Can I get a quick show of hands? People who consider themselves in UX. People who consider themselves product managers. Any engineers in the room? Okay, all right. I will try to keep it high level, and I'll try to explain the more technical jargon in there. If there is anything unclear, please let me know.

[00:00:52] My name is Ronald van Rijn, or Ronald van Rijn for Dutch people. I've worked at lots of companies you probably know, and one company you probably don't know about yet. My current company, where I work, is FUGA. They offer a digital supply chain for music. That's a very difficult way of saying we connect record labels with digital streaming platforms. A record label can upload all of their music into our content management system, and we will distribute it to all the digital streaming services out there, like Spotify, Apple Music, Google Music, anything like that. Then once the tracks are being played, we bring back all of the trends information, all of the analytics. We group that in a meaningful way and bring it back to our customers. And we can offer a full service portfolio where we also take care of royalties, or they can take care of all of that stuff themselves.

[00:02:04] About that title, You're Not Netflix. It's a sentence I've been using more and more. It could also have been Booking: you're not Booking. Or any other company. Netflix and Booking.com and so many other companies, like Spotify, for example, are amazing companies, and I think everyone should look at what they're doing and draw inspiration from that. But what I see happening more and more is that people start copying what they're doing without understanding why they started doing it in the first place.

[00:02:47] One area where I notice this a lot is in architecture, and more specifically microservices architecture. Companies start with a new architecture, and the first thing they say is: we need microservices. Look at all of these companies, they're doing microservices, we also need microservices. These guys are fast, we want to be fast.

A team of five running 30 microservices

[00:03:06] Not so long ago I got called by a technical director from a company I won't name, and they were struggling. He asked me to talk to his engineering team, because his engineering team was slow. They were not delivering what he wanted. They were making bugs and stupid mistakes, at least in his eyes, and he couldn't understand why. The whole thing didn't make sense. They were building something new, and a couple of months ago his architect had laid down this amazing architecture. He looked at the best companies in the world, took the best parts of them, and laid down a reference architecture for the team to follow. It was based on microservices, the newest AWS technologies and stuff like that.

[00:03:58] I started talking to the team, and I found a team of five engineers. They were talking about the application they were building: an application to capture orders and send them to SAP, for a user base of five people. And if they were successful, their user base would probably grow to fifteen people. Yet they were building everything based on this enormous reference architecture. The application was fully split up into microservices, 25 or 30 microservices. They had a separate front end, and basically all of their time was spent managing their architecture. They lost a lot of time because of that and couldn't implement a lot of features. This is one of those instances where you need to go back to people and say: look, I know the best in the world are doing this, but you're not Netflix.

The microservices premium

[00:05:00] What the team was experiencing is something that's been coined as the microservices premium. Microservices are used to manage very complicated infrastructure when we have very complicated problems. But they also bring complications with them. When you introduce this architecture, you need to manage complex situations.

[00:05:29] The first situation you will run into, and they immediately ran into it, is eventual consistency. When you start partitioning your software into multiple pieces and you want to remain highly available, which most systems want to be, you will run into a situation where you lose consistency. You could write something from process one to service A and service B, and this stuff goes across the wire and needs some time to process. When process two starts reading it, anything could happen. It could read something that was written by process one, it could read nothing that was written by process one, or either of the values. What you get is unpredictable, and you need to cater for that. There are many techniques to cater for that, but the important thing is that it costs time. Or sometimes, in the case of Marktplaats, for example, a company I worked for, eventual consistency was fine to show to our users.

[00:06:39] The other thing you need to take care of is intermittent failures. Once you start splitting up your software, and software doesn't talk to each other directly in the JVM, or whatever platform you use, and you start sending information over the network, you experience the same thing that happens when you make phone calls on a network, or when you're trying to watch Pantanal [?] on the network. Sometimes stuff drops, sometimes stuff fails. So in a microservices architecture you need to take care of failures much more than with direct process communication.

[00:07:20] And the other thing: these are just some extreme examples, Hailo [?] and Netflix and Twitter, because we have some information on how big these guys are, and this is already from a long time ago, so they're probably bigger. If you have this many different software components, there's no way you can manage that by hand. There's no way you can deploy this or bring it to production by hand. There's no way you can monitor this by hand. In your founding stages, or when you're just five developers, you might want to manually deploy the first versions of your software just to prove value. That's impossible when you start working at this scale.

Monolith first?

[00:08:12] This led some of the brighter minds in our industry to say: don't even think about microservices if you have a system that's so simple you can manage it as a monolith. A monolith, for people who are unaware, is just packaging all of your software together and deploying it as one package.

[00:08:43] When I start talking about monoliths, usually the first response I get is: yeah, but that's architecture from the past. That's exactly what we wanted to get away from. We had a monolith in our past, it was horrible, it was the worst experience we ever had. So this new thing we're going to build for sure needs to be microservices.

[00:09:04] I don't think this always holds true. I think there are very valid cases for starting with a monolithic application. Actually, two of the companies I've worked for, Marktplaats and FUGA, proved success this way. Marktplaats, I think it's 20 years ago already, built their application as a huge monolith. They still had to prove themselves. Similarly, FUGA had to prove themselves in the market. A monolith will allow you to quickly iterate and do a lot of stuff manually while you prove out your model.

[00:09:46] There is also a whole group of people that oppose Martin Fowler and say: don't start with a monolith when your end goal is to get to microservices. And I think there is some truth to that. When choosing your architecture, it always depends on different things.

Architecture is a spectrum

[00:10:11] I guess the most important thing here is that choosing your architecture is like choosing from a spectrum. On one end of the spectrum there is the one monolith, and on the other side there's the 500-microservice architecture that Netflix has. But there's a whole bunch of stuff in between. When we were at Marktplaats and started chipping away at our monolith, we went from one monolith to two monoliths, three monoliths. We started cutting out stuff, and over time it became microservices. So there are many, many things in between. The answer is not that black and white.

[00:11:01] But I will try to give you some tools to decide where to start if you need to build a new software project. The first thing is the size of your engineering team. If it's just Kevin, Bob, and what's the third guy's name, if you only have three rockstar engineers, definitely consider starting with a monolith. Three people can easily work together on a single codebase and deploy it. If you are the size of Booking.com, definitely consider splitting up your software. It will allow the teams to iterate very fast on their own piece of software and deploy to production. That's one thing to take into account.

[00:11:52] The second thing, I guess, is the stage of your product. Is it the flying car that you want to develop, or Marktplaats 20 years ago? Consider starting with the monolith. Make it easy for yourself and focus on proving the value of your product instead of focusing on your architecture. Are you building something that has been proven ten times over, and you know you're going to need microservices to do it? Let's say you're building Disney Plus, the rival to Netflix. You're pretty sure you're going to need some kind of microservices architecture. Go for it right away.

[00:12:35] Another important thing is the domain knowledge of your team. Do you have seasoned veterans, people who understand your domain through and through? Or do you have guys that are showing up on the scene for the first day and trying to understand the domain they're in? Domain knowledge is so important because once you start splitting up software, you need to put boundaries around elements of your domain. And if you put the boundaries wrong, the architecture will start working against you again.