Service Architecture: Splitting a Monolith to Microservices

- PDT
Workshop Stage 1
Join on Hopin

Joy Ebertz
Split, Sr. Staff Engineer

Joy is a Senior Staff Software Engineer at Split.io, focusing primarily on backend.  Prior to Split, she worked at Box, where she tried her hand at management for a short while before transitioning back to an individual contributor role.  She also has experience at a tiny startup and at Microsoft.  In addition to designing software and writing a lot of code, she also maintains a blog: https://medium.com/@jkebertz. ; In her free time, she does a lot of traveling, reading and running ridiculously long distances (mostly on trails).


Both Box and Split, like many other companies are working to split their monolith into microservices.  We didn't want to just end up with a distributed monolith (i.e. lots of services that still had a very high level of interdependency), so this required some specific thinking.  Additionally, we wanted to think about how to make sure we didn't have the overhead of hundreds of services while also not ending up with several mini-monoliths. In order to think about how to design our new services, we approached the problem using domain driven design and layered architecture.

DDD is an approach to developing software for complex needs by deeply connecting the implementation to an evolving model of the core business concepts.  It's an approach that was first coined in 2004 but is still very applicable today.  It emphasizes problem solving, cross functional collaboration and simplicity.

Meanwhile, layered architecture, while a fairly common approach, does not have the same common language or formalized concepts that domain driven design has.  We used layered architecture as a way to think about how we separate our front end services,  our core logic, and our infrastructure services.  

Together, these two approaches helped us think through how and where to divide our services.  In this talk, I will go into much more depth about what each of these two approaches are, as well as how we applied each to our problem space at Split.