Published on August 16, 2019
It seems we cannot say explicitly that a Microservice is a Service.
Here is a clear (to me) boundary between what Microservice implements and how it is used.
At least, we know that Microservice is a small application realising the particular business function and providing a certain outcome. End of the story. Everything else you might hear about Microservices is about how different people use them, i.e. not about Microservices per se.
Face 1. To be a #Service, a Microservice as a provider of business functionality or capability must have a consumer of its outcome. They both have to explicitly interact. In #Service-Oriented #Ecosystem, the interaction between service consumer and service provider cannot be implicit because Service operates based on the exact contract with the consumer where the contract can be individual or shared (explicit or implicit). This means that a Service A is not responsible for its work to a consumer C, which is a consumer of the consumer B that directly interacts with the Services A. That is, ‘a consumer of my consumer is not my consumer’, as well as ‘a service of my service is not my service’. For Microservices, this means:
1) The consumer should explicitly call the #API of the Microservice (synchronously or asynchronously)
2) The consumer must know the Microservice, i.e. its promised functionality and outcomes, and be sure these two are what the consumer needs. The opposite is not necessary.
Face 2. In contrast, a Microservice can exist/operate as a solo actor. In this case, Microservice does not need to know who uses its outcomes. Actually, this is a two-phase case. The most comprehensive phase is when a Microservice not only publishes its outcomes to anyone interested and received them via a subscription, but also can publish its events. The events can be of absolutely different nature – from reporting about the life-cycle like starting an operation to the reporting on its state change or execution of a persistent operation. The Microservice may be highly ‘talkative’ via events, but it does not serve any particular consumer, i.e. it is not an #SOA Service in this case. Another phase is more cumbersome. A Microservice can be developed and deployed independently from others as well as operate as a fully self-sufficient entity. If there are no explicit invocations to such Microservice (no consumers – no invocations), why the Microservice would do anything at all? For example, why would it listen to any messages or events –what they mean to the self-sufficient and isolated Microservice? Or the creators of Microservice technology just have forgotten to tell us that in reality, Microservices are not self-sufficient, not isolated, i.e. are dependent on the outside application environment, and while they can be deployed independently they are not free in this and a lot of integrity checks should be done to permit such deployment.
Well, let’s be sensible and reasonable and ignore isolationism of Microservices. That is, we agree with and assume that Microservices should interact in order to fulfill business functionality associated with the Microservice-based Application. Interactions can be viewed as mimics of each face of a Microservice.
Face 1. For years, there were a lot of critics for SOA Services and API that they constitute a point-to-point weakly scalable interactions. I think this how people use Services and APIs, not how they are supposed to use them. In SOA, there is an old pattern known as ESB. However, ESP products do not really implement the pattern. An SOA #ESB is about the bus – a dynamic network map of physical locations of Services’ end-points/APIs and nothing else. Not even data integration/transformation between the consumer and service provider. However, such data integration/transformation may be an extension of the pattern, which does not change the sense of the pattern. The core of SOA ESB is in that consumer knows and trusts the service and address consumer’s messages/notes to this particular service; how these messages and responses to that consumer are delivered via a network(s) is irrelevant. I mean global networks and related Service #Mesh if you want. The only what is required from a Service Bus is: 1) keep the actual picture of all related physical end-points and link to them, 2) find new actual end-point locations based on the URL/Identifier/name of the service provider supplied by the service consumers. If a Service #Broker is understood as an intermediary realising only 1) requirement, this is the only difference between the Service Broker and Service Bus.
Thus, a Service Bus is an explicit delivery mechanism to a particular trusted counterpart; it has nothing to do with the modern interpretation of a ‘bus’ as a pub/sub broadcast mechanism. If designed and implemented properly, it is unclear why described SOA ESB is less scalable than event-based interaction model. Moreover, SOA ESB allows all possible security protections and controls that are so important for business functionality.
Face 2. An #Event #Bus, because of unknown to me reasons, is widely interpreted as a pub/sub mechanism. This may be OK only if a Microservice does not care about who listens to its events. However, as we discussed before, this prevents sensible interactions between Microservices with a shared goal of solving given business task. A consequence of this consideration, only a few special Microservices can expose such events while others that are supposed to work together, should:
1) Issue/fire dedicated events – events for concrete addressee
2) The issue only special events preliminary agreed with counterparts
3) The overall security of the application has to control that not-authorised Microservices could not listen to events that are not addressed to them.
For example, if an application contains Microservices with event-based interactions and Even Bus is an open-subscription pub-sub intermediary, with modern DevOps practice many different people, even unrelated to the business supported by this application, can easily deploy their Microservices to spy on this application. Since information can be transmitted to another side of the world for a fraction of a second, the loss caused such spying for the business may be significant.
Therefore, a fact that we can create highly scalable systems based on uncontrolled pub/sub model, it does not necessary mean that we may do this. It is not a technology, but business security matter.
For the Event Bus that pushes received events, we have the same situation as with SOA ESB and the events notes appear as very similar to service’s messages. We can consider different Event Bus models here – with queuing, accumulation, hub-n-fire, durable push, etc. Another option is with polling events – we have here at least two sub-models: Event Sourcing and Temporary Container.
The Event Sourcing model is the most robust and can allow reconstruction of the event chains in the past, which may be very useful for distributed interactions with high latency. Nonetheless, this model still does not decouple event producer from the event consumer/listener. The latter has to impose requirements on the former which events should be collected in the Event Source store. If required events are not provided, the event consumer will not be able to operate and the application fails. While Event Sourcing store can survive the failure of the event producing Microservice, we have no guarantee when the consuming Microservice picks up the event(s). This can be a hit on application performance.
A Temporary Container model represented by Kafka is an event/message polling model what can be accurately targeted to certain consumers. Unfortunately, an Event Bus based on Kafka has an additional alerting aspect to the event transition performance – each partition has to be sized in the way that would balance the speed of producing-consuming events and the event life-time in the storage.
Knowing the “mimics” of the Microservice’s “faces”, overall conclusions I’ve come to are these:
1. A ‘push’ type interaction between Microservices is better predictable and manageable than the ‘pull’ type
2. Microservices working together in an application on the solution of the business task depend on each other by design and via interactions, i.e. overall integrity of the application is not less important than the efficiency of producing individual Microservice
3. Service Bus and Event Bus are very similar to each other in the requirement to deliver message or event note to particular addressee-Microservice while an open subscription or uncontrolled consumption of event-broadcast is a very special sub-case of Microservice interactions, not the other way around.
HOW to ARCHITECT for DEVELOPERS 