As software architects and developers, we live a distributed world. To simplify building distributed systems, we have to develop a sense of where value lies in the business we are in, so that we can understand where it’s reasonable to take risks and where it’s not. We should only tackle the problems that really need to be solved, Camille Fournier claimed when interviewed by Stefan Tilkov.
Fournier, formerly at Rent the Runway and Goldman Sachs, refers to Leslie Lamport for her favourite definition of a distributed system:
A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable.
For Fournier, Lamports’s definition really gets to the heart of distributed systems becoming more than just a minor thing that can fail, to something where you have so much complexity that it’s not possible to easily reason about it.
People often see systems as distributed just because there is a network in the flow, but a system consisting of just a server and a web browser, or a traditional three-tier architecture, is not what Fournier normally defines as a distributed system. She believes that it will only create an unnecessary complication; there is no need to worry about problems you don’t have yet. Even if you build a networked system with some complexity, that doesn’t necessarily mean you have to consider the whole world of distributed systems complexity to build it well and usable.
For Fournier, the threshold for when distribution becomes an issue and should be dealt with is when you really have many different systems you run across. Working in a services architecture, especially a microservices type architecture, starts to get some of the complexities but not necessarily all the complexities that can occur in large-scale distributed systems. She notes that distributed systems are as much of an engineering problem as they are a theory problem, which means you will have to apply as much theory as you need to solve the engineering problem, but no more.
Fournier believes that a services architecture, whether or not you call it microservices, is a very sane way to think about software at a certain scale, which does not need to be massive scale like Netflix. With tens of developers there can be a lot of value in thinking about the entities of a system that can operate independently and pull those into services, allowing for independent development and ownership of data. A monolith is not intrinsically wrong, but she notes that one reason for the increasing number of distributed system is not only that we really need it, it’s also because it’s so much easier to build such systems, because of the cloud.
State is when everything gets complicated. For Fournier, one of the important aspects to think about when building distributed systems is where you care about coherent and consistent state, parts where you don’t want to lose data or have people seeing different state. For these parts she generally favours using transactions and a traditional relational database. One example is order handling, in which you want to make sure that you will be able to fulfil all orders. In other parts you may care less about consistency and it’s not a problem if people see slightly stale data, or you can lose data, because it can easily be recreated. Here Fournier thinks NoSQL-databases are perfectly usable.