From Monolith to Microservices

The first step in the rebuild of our web platform is a proper foundation: the infrastructure. And our title has already given away the first decision that we’ve made: we’re going for microservices. This post will explain our move to microservices, our choice for Kubernetes, and some other infrastructure-related decisions. For more context on our project and its objectives, check out our previous post on this topic, in which we explain why we’re rebuilding from scratch. So why microservices? Many blog posts have been written about the pro’s and con’s of microservices in general, so we’re not going into that. Instead, we’ll dive a bit deeper into what we as a team like about microservices in particular. Microservices are designed for change We’re building a web platform, and the web is complex and changing rapidly. We’re assuming from the start that parts of our platform will eventually be scrapped. Microservices make that easier. Microservices also require us to design our systems for failure. Certain services might be unavailable at times and our systems needs to deal with that gracefully. The latter could be seen as a downside, because designing systems in this way requires extra thought, introducing additional overhead. However, it also means that our teams have to constantly reflect on how service failures have an impact on the user experience. We encourage our teams to take that kind of ownership, so we see that as a pro rather than a con. Microservices empower small, cross-functional teams to take ownership of our product Microservices are standalone services that can be built, deployed and maintained in isolation from other services and systems. Because of their small scope and separated nature, teams are enabled to take full responsibility for services and thus our product. ---- >More to come