Categories

When I was first reading about MSA architectures (MSA) I had a hard time figuring out what was so different from a Service Oriented Architecture (SOA). Main reason for this is that the SOA paradigm leaves quite a bit of room for interpretation and various people have different interpretations. When Martin Fowler wrote about MSA almost a year ago he also mentioned that some people see it as “SOA done right”, he himself considers MSA a subset of SOA. So, what are the differences, if any?
At first glance there seem to be more than a few similarities. Both talk about services as the cornerstone for the architecture, services need to loosely coupled, technology agnostic and there’s probably a few more. What sets the Microservices architectural style apart is that it’s more clear on where the focus needs to be when designing your services. The name suggests that the services need to very small and probably very fine grained but in reality no size restrictions apply. Ironically, it’s the size (and focus) of services that commonly cripple SOA implementations.
The main characteristics of MSA are: autonomy, high cohesion and low coupling. Out of these characteristics autonomy is the defining one. Here autonomy not only means that it can run or function independently (that is what low coupling is about), it means that a service should be able to provide business value on its own. This principle ties together the focus on low coupling and high cohesion. Lower coupling allows the service to operate independently and high cohesion increases it’s ability to add value on its own.
What you often see in SOA implementations is the focus on reuse. This means that a certain function should only exist in one place or a single service should handle a certain function. Where things go sour is in how these “functions” are determined. This is where cohesion comes into play. Cohesion is the degree in which functionality in services belongs together. The highest cohesion is functional cohesion where the services contribute to a well-defined task or business capability. MSA strives towards functional (high) cohesion. The cohesion found in common SOA implementations is logical cohesion (one step up from the worst kind, coincidental cohesion). With logical cohesion the services are grouped around similar tasks, like the one service for one function mentioned above. This approach leads to finer grained services that focus on atomic tasks. Take for instance a “data service” that handles all communication with a database. It accepts messages in a common format and then uses that information to execute the desired action on the database. Benefit is that applications that use this service don’t need to worry about the tech behind said service and only need to provide messages in a common format. If the database is shared by multiple services they all use this service when communicating with the database. Now imagine what would happen if this service goes down (intentionally or not). Or what the impact is when this service needs to be modified. And this is assuming that this service is well designed and built so it can handle all the different requests thrown at it.
With MSA the goal should be high cohesion, this means grouping things around a business capability (so it can add business value). It also provides all aspects of that capability end-to-end, from data storage to user interface functions. So instead of having a “data service” you create a “customer service” or “shipping service”.
Another aspect that is relevant here is that with MSA one should strive for low coupling (or better yet, no coupling). Low coupling boils down to the dependency between services. With no coupling the services can function completely independent of each other. If two services have no coupling downtime of one of the two will have zero impact on the other. The higher the coupling, the higher the impact.
With SOA implementations based on logical cohesion the coupling tends to be high. Because services depend on other services to function. High coupling increases the impact of changes.
For MSA the goal is no coupling. But lowering the coupling does not mean they can’t or shouldn’t interact. Services can still interact with other services but they don’t depend on them. Another distinction to take into consideration is that these are more technical dependencies, not functional ones. Take for instance an order service and a shipping service. Both can operate independently. The shipping service will process all the orders it has received, regardless of the availability of an order service. If the order service is down it simply means no new orders will be created for the shipping service. So when the shipping service is done handling its last known order it stops. Vice versa, if the shipping service is down the order service will still be able to process orders. They just won’t be processed by the shipping service. When the shipping service comes back up it will process the backlog created by the order service.
How much the Microservices architectural style differs from SOA depends on who you talk to. If nothing else, MSA offers a clearer and better defined approach on setting up an architecture built around services. The key differentiator being the focus on autonomously adding value. There is a lot more to say on the subject but hopefully this gives some insight into how MSA differentiates itself from what you typically see with SOA implementations.

Shares

Previous post

Next post

Comments

I think the coupling example you gave is quite the definition of a well designed SOA. That this is not the norm is – IMHO – due to the deployment overhead of current frameworks which leads to designs where several services are coalesced into a single heavyweight endpoint.

Trimming down the supporting infrastructure would naturally lead to smaller independent deployables and thusly services that feel more “micro”. So to me, “micro service” is more of a design characteristic enabled by lightweight tooling, rather than a different architectural approach altogether.

Would it be accurate to summarize you comments as “SOA focused on independent logical/functional services, MSA on independent business services”? Or, alternatively, “SOA prioritized functional de-duplication and created many contention points for business services as a result, MSA prioritizes business service independence and allows for functional duplication to achieve this”?

I had to re-read your formulation a couple of times to be sure. But I think that summarizes it, yes. Especially that functional duplication is “permitted” (or at least isn’t as mortal a sin) in order to achieve autonomy.

Since MSA encourage services to be decoupled what is the best approach to build communication between them. Would it be acceptable to have a controller type “service” that is aware of all the services and can serve as a proxy between them?
e.g. going back to your example controller gets the list of orders from Order Services and sends it to Shipping Service. This way both services are not aware of each other which makes them decoupled and controller is the only entity that knows how to talk to each service.

Most MSA implementation incorporate an event driven architecture for their communication.
A setup I like is to use atoms feeds for your event sourcing. This effectively is a pull mechanism where each service needs to poll for updates. You can also combine this with a push messaging mechanism like Kafka for a more performant push option.
Both of these option preserve the autonomy of the services. Using a form of messaging can introduce a runtime dependency but the atom feed serves as a fallback for that. The atom feed also provides a way to restore from a certain point in time.
Introducing a controller “service” sounds similar to the old ESB, a single point of failure where all services need to talk to. If it fails all communications go down. It may lower the coupling between the services themselves but introduces hard coupling with the service itself. Using a DNS to resolve the address of the services’ atom feeds should be enough.