Monday, April 29, 2019

Microservices Architecture pt.2: Why do we want Microservices architecture?

After exploring what a microservices architecture actually is (see Microservices Architecture pt.1: Definition), we can ask ourselves why we want such an architecture. After all, it seems rather complex, discourages reusability, can lead to data inconsistency and any hype will be overtaken by something else in the future. However, there are benefits too and most of the downsides can be mitigated. It's also not always necessary to go for the most hardcore version of an idea, some middle ground can be reached to come up with a reasonable solution.

The most important reason for microservices architecture is to get rid of dependencies. Many systems are very hard to manage and maintain, because a small change can create a massive butterly effect and the entire application may be at risk. With microservices architecture, you isolate business modules, so a change in the insurance part of the company will not affect their marketing application and vice versa. This also makes it easier to release changes and updates, because the bounded context protects you from unexpected and undesirable side effects.

Another reason is that many organizations are disappointed with the traditional approach to SOA. In many cases, implementing SOA has not led to more flexibility, but actually less, as now multiple layers need to be tweaked to make a single change and massive enterprise metadata repositories make it virtually impossible to change things without massive consequences. If all your services are using your Person.xsd and you need to make a change to that one, you're going to be royally screwed. Besides, the Person.xsd will most likely contain everything from every context, which makes it unfocused and hard to work with. On the other hand, not using these metadata models also have downsides, as you need to make a lot of transformations. Microservices architecture can be a nice middle ground here, because you can isolate the Person's context to the business module and there are no dependencies between the different business domains. So, the context of a person is completely different for insurances as it is for marketing and guess what... that's totally okay and no longer an issue.

A third and also important reason is that microservices architecture forces organizations to really think about their business domains, leading to more proper architecture. There will be no confusion about which service does what (if done well, of course) and development teams can be organized around a product that they will know a lot about, instead of being unfocused by doing many different things. This also relates microservices architecture to the best practices of scrum, helping organizations to be more agile and manage things in a more logical way.

Have I written about deployment yet? With microservices architecture, it will be much easier to create releases and think about containerization, because there are much less dependencies. Applications gain a lot of independence like this and you can release more frequently with less risk of creating any issues. In a world where time-to-market needs to get faster and faster, this can be crucial for many businesses!

The most popular argument for microservice architecture is that microservices can be scaled independently. While I don't consider this crucially important for most organizations, who have predictable, stable loads on their systems, this could be interesting if there are big differences between different parts of the system or you need some flexibility to quickly make changes.

Last, but not least: runtime dependencies. When a struck thread pulls down an entire application server that runs everything, your business is on hold. If a struck thread pulls down an application server that runs a single microservice, everything else will still function well enough. So, errors and problems get isolated, which does not only increase stability, but also makes it easier to analyze what happened.

What about the downsides?

Microservices architecture is inherently complex. So, for smaller applications, it is not a recommended approach, because of the relatively large overhead. Also, when your business domains are not quite clear yet, you still have some work laid out for you before you will be ready for microservices.

The lack of reusability I actually see as an advantage, not as a disadvantage. You will be forced to take a more modular approach, but within your business domain you can reuse as much as you want, while maintaining flexibility in the interaction with the outside world. Obviously, there are some things that need to be centrally organized, like your API management, monitoring and traceability, so keep that in mind. Especially the latter is not going to be an easy ride when you're not running everything on the same platform or with the same technology.

Data inconsistency sounds really scary, doesn't it? It is and therefore it should be avoided. In microservices architectures, it is common to work with eventual consistency, which means that distributed will eventually be consistent throughout the system. Let's say you have three microservices all managing their own data and this data overlaps. A change happens in the first service, which pushes an event that can be consumed by the others. At that moment, your data are not consistent, but a few seconds later it will be, as the event gets consumed and the data gets processed. If you have a persistent publish/subscribe system like Apache Kafka, even newly added microservices can be fed with previous data or corrupted databases can be repopulated based on the information in the events. Obviously, you should test this well!

Conclusion: while we must be aware of the risks and mitigate them properly, microservices architectures have many advantages for creating consistent, independent and well-organized systems. Combined with agile principles, it encourages greater productivity and faster time-to-market. So, in many cases it will be good to at least add some elements of microservices architecture to your systems.

No comments:

Post a Comment