The common definition we come across when talking Micro Services is that they are small (10-100 line of code) and that they are independently deployable.
This definition is severely lacking in two aspects. Micro Services need to achieve operational excellence and that in order to do so it isn’t just their size but how they communicate that matters.
If we call a service micro based on the fact that it has a small code size then we could just break our services into very small codes but allow them to have two-way communication, leading to coupling problems. Coupled services cannot be deployed independently!
One-way communication or asynchronous communication is the other option we have. If we talk about a purely asynchronous method of connecting two services then we may be on to something.
But, is it possible to get work done using only one-way communication? Not really.
The solution in this case lies elsewhere. It lies in a well-defined service boundary.
A service boundary is the business data and functionality that a service is responsible for. A well-defined service boundary implies that the service has its own data set and that it is aligned with its business functionality.
A well-defined boundary service model.
If our services have very well defined boundaries they will not need to depend on other services for responses or callbacks. Hence, one-way communication will not be a problem.
Looking at communication in this manner has led us, at Captain dash, to believe that services should be built around business capabilities instead of applications as they typically are.
As Bill Poole said, the advantage of business capabilities is their remarkable level of stability.
Applications change with time and need but the business capabilities stay the same. Aligning our services and thus, the teams around our capabilities help us ensure that communication is not a hindrance.
Written By: Meghna Verma Meghna Verma is the CMO at Captain Dash. You can reach her on Twitter @M3GV3RMa .