The benefits of decomposing your business’s large monoliths are well established. Your company’s systems may have started small, and their simplicity may have allowed for rapid initial development. However, as they’ve grown, complexity has increased, and work has slowed. It’s time to break things up into loosely coupled systems so that a slowdown in one area doesn’t affect the whole system, and multiple teams can make rapid iterations without getting bogged down in negotiating dependencies with other parts of the system.
Now the question is how. You’ve got ideas, and some of the components to break out seem obvious, but do those ideas add up to a coherent vision that puts you where you want to be a few years down the road? Or are you likely to hit stumbling blocks, like systems not getting the data they need via a reasonable path, complications arising from unexpected dependencies, or user experiences made complex by asynchronous data? Where should you start if you want to avoid troubles down the line?
Start with a Methodology
Domain-Driven Design is an approach that can help systematize the reorganization of your business systems into a well-architected set of microservices. By identifying the business domains, and the bounded contexts and models that comprise them, you will have taken a big step towards defining the microservices you will need and the types of events you will need to pass between them.
Domain-Driven Design should be approached holistically, but there are some aspects that may be especially important to keep in mind when designing event-driven systems. One example is the timeliness of information. If one piece of data is rarely updated and another is updated frequently, it may be that they do not belong on the same model. For instance, most data describing a product you sell might be updated only rarely when there is a revision to the product itself, but information on the quantity of that product you have on hand might be updated from moment to moment. Thus, it might make sense to have product metadata and stock-keeping information in separate models or even separate contexts. This would imply that events would relate only to one or the other so that downstream microservices could subscribe to only the information of interest to them and aggregate information from each event stream as needed if they had interests in more than one.
Leverage Your Existing System
If you already have an existing system, that’s a great resource to use in architecting your next big step. You have codified your needs and accumulated years of domain knowledge in your existing data structures. While you undoubtedly have changes and improvements in mind, keep in mind that what you already have provides a fully fleshed-out conceptual model that can help ground your future plans in reality. However, you can’t let your existing model become a prison. There are some relatively minor concerns in a monolithic system, such as timeliness and rates of updates, that will be critical to rethink in an asynchronous system. Your existing system will provide a lot of hints about where your domain boundaries will fall but taking a step back and thinking about what can be separated on both conceptual and practical levels will save you time and trouble later.
Start Small and Build Iteratively
Once your general plans are made and you’re ready to start implementing, there will inevitably be stumbles. It might be best to start in a part of the system that has enough throughput to justify the change and a relatively simple set of dependencies. This will let you spend relatively little time integrating events into other parts of the system to feed into and be consumed from your new microservice. Once your concept is proved out and stabilized, you can refine your implementation and expand to more involved microservice integrations. Once you’ve started and established your patterns, you should find that changes to individual microservices become more rapid, as loose coupling between different components leads to a greater locality for required changes.
Don’t Do It Alone
They say that intelligence is the ability to learn from your own mistakes, while wisdom is the ability to learn from the mistakes of others. In that sense, talking with an outside expert is a wise way to get started on a major project. At DragonSpears, our architects have helped many clients make the leap to event-driven microservices in the cloud. We can leverage that experience to help you make the right design decisions to avoid costly rework down the road. Give us a call to see where we can help.
