DISCLAIMER: I’m not a huge fan of microservices per se but I’m not against microservices or anything else just because it is.
IMHO, it’s all about the size of the service. How big (or small) is “micro”? Many agree that a microservice should be nearly the same as a bounded context as in domain-driven design (DDD). I definitely agree on this view; so, in this case, I’m a huge fan of microservices. Except that in this case we’re talking about services rather than microservices.
The three key benefits of microservices–written and rewritten all over the web–do shine here: self-contained modules, easy scalability and possibility of using ad hoc technologies. Interestingly, there’s a lot in common with the canonical attributes of a bounded context in DDD. A bounded context is a section of the business domain characterized by:
- Its own ubiquitous language
- Its own implementation (and related technologies)
- A well-defined interface towards the rest of the world, whether an API, a shared database, a message queue, web sockets and more
As that of a bounded context is an abstract definition, it may or may not be self-contained and easy to scale—that depends on the actual implementation. However, if you deploy the implementation of a business bounded context as a standalone app service you add to it the attributes of self-containment and easy scalability.
Yet, the code you deploy is a monolith!
Yet, the overall architecture you deploy is service-oriented or service-based or service-friendly or serviced or microservice-based. Or just modular with clear boundaries.
In the commonly regurgitated bloatware about microservices—the tons of (semi)commercial white papers that flood feeds as sponsored content—cons are also mentioned in a fit of political correctness. “Let’s just add some cons for completeness”.
In the microservice-as-a-bounded-context scenario, the well-known list of cons is a mere list of neutral attributes of the solution.
Increased complexity as a con? No, it’s the necessary complexity of the business domain assuming the functional analysis—the split in bounded contexts—is appropriate.
Distributed security as a con? No, the usual burden of making distinct and autonomous pieces of code to communicate, whether via token-based API or shared database. If user interface is required, single sign-on may be an option. Complex? Sure, but it’s just development.
Distributed testing as a con? No, it’s plain integration tests.
Extra costs as a con? It’s the budget you set up when you plan the solution. Too expensive? That’s another problem. Is the split in bounded contexts appropriate? Is the budget appropriate? The more you make it in smaller pieces, the more you end up to deploy and the more it costs.
What if, instead, micro is really micro and the size of the microservice is (much?) smaller than the size of a bounded context? This is where the aforementioned cons of microservices really shine.
Increased complexity? You bet! Dealing with security, testing, logging but also handling business transactions across independently deployed modules is complex, at least. Worse yet, whatever workaround you come up with just adds more complexity, more latency and more resources in the cloud and in the team.
Not to mention that specialized skills may be necessary and people with specific experience may be highly helpful. If you then move to containers for deployment the level of complexity grows and probably a new family of tools (FaaS?) may come into the discussion.
I’m not questioning FaaS and I’m not questioning containerization. I’m just questioning the size of microservices and if it’s the size of a bounded context, please, let’s just call them services or applications.
Pragmatic Opinions 