Few notes on Microservices
- At February 17, 2020
- By Alexander Yermakov
- In Architecture
0
I got a notification email from Medium.com saying that one of my comments on Microservices related article was attracting attention. It’s been a while since I’ve made that comment, so I’ve reviewed it and figured it makes sense to copy it to my personal page for reference sake.
With that comment I wanted to remind about the importance of SOA and indicate that various implementation patterns should be thought out, not simply adopted and followed just because someone else did it this way.
Read More»Sizing your Microservices
It’s common to hear that “microservice should be small” or “microservice should not be too big”. Well, this is not a very precise metric to go by. Very often teams start creating tiny executables each dealing with a very small concern, and sooner rather than later they run into lots of issues – tight coupling between microservices, distributed transactions, nightmarish development and release process, etc.
To be able to figure out what’s the right size for your microservices we need to go back to the fundamentals – in this case Domain Driven Design and its concepts of Bounded Context and Aggregate. We have already discussed microservices boundaries, and the sizing comes as a flip side of that discussion.
Once we have done a first pass at analyzing our domain model and have some rough bounded context identified, we are ready to look deeper – at DDD Aggregates, which would be our smallest possible releasable and deployable artifacts. We shouldn’t go smaller than a DDD Aggregate as that is our primary way to ensure transaction consistency in a given bounded context. On the flip side, should we go that granular with all of our microservices or should there be more coarse sized microservices?
My recommendation:
- Analyze the bounded context of interest and identify all of it’s aggregates – this would provide you with a list of potential releasable components
- Bounded Context analysis is an iterative process, so identification of aggregates will be happening over the course of system development as business domain understanding is growing, implementation of business processes is progressing.
- Determine which of the aggregates have their very own scalability, availability, security, etc. non-functional requirements – these, most likely, will become standalone microservices
- Determine which aggregates can comfortably co-exist in a single releasable and executable module – their scalability, security, availability, etc. non-functional requirements are similar and they wouldn’t affect each other too much
- In some cases we can have all aggregates (complete bounded context) in a single microservice – nothing is stopping us from doing that, really
- Take into account team ownership over bounded context. In most cases I would recommend having a single team own a bounded context for many reasons, however if there is more than one team involved – that would introduce another dimension of which components should be independently developed, released and managed.
Since we are building highly decoupled, autonomous components, the following set of checks may prove to be helpful to validate the breakdown:
- Transactions are not split between microservices – each request is processed and results in a persisted state change within the boundaries of a single microservice
- Eliminating distributed transactions
- Each microservice can be developed, versioned, released, scaled independently
Microservices. The boundaries.
One of the problems with designing and implementing a distributed software system using microservices implementation technique is figuring out the boundaries of microservices. And, indirectly, the size of these artifacts.
What happens if the boundaries are incorrect? You get coupling between various components (microservices) – both spatial and temporal. Such coupling can undermine a lot of implementation and delivery aspects. Some of these include inability for one team to fully implement a feature due to a dependency on some other service that implements something they require, inability to release without coordination with other teams, issues when releasing interdependent components may and will result in instability, loss or corruption of data, emergence of distributed transactions, etc. Many tried, many failed and questioned the concepts rather than their misunderstanding or mistakes.
So, is the concept flawed? Is there something that can help us deal with such issues? As always we need to start with the foundation. In this case our main foundational concept comes from Domain Driven Design – an Aggregate.
If you don’t know what Domain Driven Design is, or have a very basic, high level knowledge of it, it is crucial for you to start digging deep and wide, over and over, to start understanding what it’s all about. It is a philosophy of successfully modeling complex business domains and implementing those in software. There is a lot written on the subject and I would recommend to keep reading.
An aggregate is a very important, yet somewhat elusive concept that takes time to fully grok. At it’s core DDD Aggregate ensures the boundary for transactional consistency. When a transaction completes all entities represented by an aggregate must be in a consistent state – any business rules governing the state must be met, the data must be fully stored in a data store and the aggregate should be fully available for any other use case. From the implementation point of view, an aggregate is one or more classes representing an entity(-ies) that govern the state and the rules associated with it.
With the concepts of DDD Aggregate in mind we can now approach the sizing of a microservice and define its boundaries. Approaching the design thinking about the business process that drives the implementation we really localize the scope of change, encapsulate the logic and state. The implementation become autonomous, we remove any potential for cross-service requests, complex orchestration goes away, unnecessary generalization of code is not a factor anymore. The codebase becomes simpler, more robust, easier to reason about. It is easier to test, easier to maintain all of which really yields greater business agility – exactly what business asks of engineering.
So, why do people run into issues we’ve mentioned at the beginning of this post? It usually happens when implementation is based on technical concerns or driven by popular but often superfluous concepts such as code reuse, DRY, generalization, centralization of some logic. With this the chances of incorrect breakdown of business process into reusable parts may and will result in the issues that lead microservices solution to become overly complex – invalid services boundaries, coupling between services, emergence of distributed transactions, dependencies on other components and teams, lack of agility. Pretty much everything that the concept promises to solve and the reason you’ve decided to adopt it in the first place.
Disclaimer: I am a strong believer that microservices is an implementation technique, not an architectural style. As such, without proper foundation it most likely will cause more harm than good. More on this here.
Microservices without fundamentals
Couple weeks ago an article was brought to my attention. An article with a catchy title – “The Death of Microservices Madness in 2018”. Since I am greatly interested in software architecture for distributed software systems such statements are definitely too bold to be ignored.
One of the biggest misconceptions about Microservices I’ve observed is that people accept the idea as something holistic, self-contained and self-sufficient. In reality, Microservices is just an implementation approach for distributed systems architected and designed according to much wider concepts – Service Oriented Architecture, Event Driven Architecture, Domain Driven Design. Looking at microservices in a disconnect from these architectural styles is a mistake that will become costly and may lead to an ultimate failure. More on this here.
Read More»Microservices as a self sufficient concept
Over the past few years microservices became a very hot topic in development communities. More and more people talk about the approach and attempt to build large software systems according to various patterns published by enthusiasts. The buzz words (and buzz concepts) are a big driving force in software development, which in a lot of cases results in failures, as people simply don’t research and learn the subject deep enough to be able to make informative decisions. I think one of the concepts suffering from such high level approach is distributed systems development, which some are trying by going with microservices model.
I am greatly interested in software architecture for distributed enterprise-level systems and I believe that microservices concept has not only been greatly misunderstood by many, but also is flawed in the way it is presented – as a self sufficient “architecture”. However, microservices is merely an implementation approach and without proper fundamentals will not magically lead you to success. What are those fundamentals you may ask? Well, read on – this is not going to be very long, even though each of the fundamentals is a very large subject.
Read More»