AIM | HDC

Microservices and monoliths are often pitted against each other as black-and-white alternatives where you adopt one or the other. However, both have some fantastic advantages that work well in different situations - so why not create an architecture that allows for both?

Over the last two years we’ve broken down much of Hudl’s original monolith into dozens of smaller microservices. Our approach places an emphasis on rapid development and iteration. To do that, the architecture doesn’t prescribe too many rules around how “micro” a service actually needs to be. This empowers development teams to make decisions about trade-offs on size, speed of development, stability, and everything else on the spectrum between microservice and monolith. At times, this has led to the creation of “mini-liths” - services that grow way larger than a microservice probably ought to, and that’s perfectly fine.

In this session:
- An architectural view of Hudl’s full-stack microservices that let teams build both UI and backend components at the same time, which enables rapid development and iteration.
- Examples of how teams scoped the “bounded context” for several of our services (both small and large), and the natural forces that help drive teams to break services apart when they become too large.
- The lifecycle of a microservice, and how we perceive ownership in an environment where development teams aren’t 1:1 with the services they develop.