Phil Calçado

Most people in the software industry would agree that you should not start a new business or large project with an architecture based on microservices (or services of any size!). The industry wisdom is that you start with a monolith and then break it into smaller services when complexity grows. The motivation is straightforward: distributed systems based on microservices require a lot in terms of processes, tools, and conventions to work well. If you invest in managing this overhead before, you will have less time and energy to invest in your actual business and product. Unfortunately, it is easy to extrapolate and think that a monolithic approach will forever be the simplest or less expensive approach and either stick to monoliths forever or miss the inflection point when you should start splitting your mothership into services. In this talk, I will go through my real-world experience with modern monolithic architectures for DigitalOcean, WeWork, and SeatGeek. We will discuss how the assumption of simplicity has failed us and some strategies to keep your sanity when steering a large codebase contributed to by hundreds of engineers.