Move monolith to Event Streaming in one step or multiple steps?

Question

I have been the sole developer on a project for the past eight years. Right now it's one big monolith, but at this point it's really three separate apps, and those really need to be broken down as the apps use some of the same data.

My original plan was to break all the bits into microservices, but after researching the last month I've realized that event driven architecture would really benefit this app. It is also unfortunately tightly coupled with the data access since it's using entity framework.. So I guess my question is should I first implement the data repository pattern to separate the data access from the app, then break it into microservices, then implement the event driven? Or do I just do the whole thing in one step?

Answer 1

So before you redesign an application to use a different architecture, you should be really clear about what your goals are. Microservices are not a goal. Event Streaming is not a goal. These are approaches that can be used, given the right preconditions to achieve one or more goals. So before doing anything you need to identify what problem(s) you want or need to solve.

Based on your description, I'm guessing that the main issue is that you've got 3 identifiable systems that are maintained in the same code base. This tends to lead to issues as you try to make changes to one of them because of unintended impacts on the others.

If that's a fair assessment of the situation, the first thing is to ensure you have regression tests. Just to be clear, I am not talking about unit tests. These are valuable as well but they don't tell you if the applications are meeting their requirements. A lot of unit tests are really more functional in nature, and address regression needs.

Once you can quickly determine if the application is working, I would first focus on the shared pieces of the design i.e. any shared code and especially shared data.

Shared code typically needs to be broken out as a library. Shared data is much trickier. Ideally, you none of the data is created or updated by more than one of these applications. If more than one of your 'applications' in this monolith is maintaining this shared data, microservices are off the table for those 'applications' for now. However, if you have one 'application' creating and maintaining part of the data and other applications using it, I would recommend starting by breaking one such application out into it's own with it's own database (or at least it's own schema.) You can provide interfaces for the other applications to access the data or request changes to it. Often this is done with services but there are many options here. Once you've got the three applications in their own separate code-bases and isolated data, you will have a much easier situation to deal with.

As far as event-based architecture goes, I would shy away from going all-in on that. There's no reason you can't support both pull and push models in a single system. I would argue that events work best when aligned with supporting pull-based services. For example an event references an identifier that can be passed to a service for more detail. Events are great but the idea of building something that's purely event-based, beyond something fairly simple, strikes me as something that you might do if you just learned about events. There are lots of challenges with events as well as benefits. Not everything is a good fit for that approach.