On the technical side, this change is accompanied by the need for decoupled and physically separate systems that interact with each other. This is one of the main reasons why microservices have been experiencing such an uplift in recent years – although in a certain sense they are nothing more than what was originally propagated around the turn of the millennium with the term service-oriented architecture (SOA). Actually, only the packaging is new.
API-fying business models
Connecting your own business model with those of others using microservices requires the ability to offer an API for your own business. However, this causes large difficulties for many companies, especially when they have not been on the web and in the cloud forever. The challenges are not merely technical, but also, and above all, of conceptual and functional nature.
Most APIs today are designed according to REST, i.e. they represent different ways to access data. Data can be created, read, updated and finally deleted. APIs are therefore data-centric. From a technical point of view, this approach is pretty obvious, as it perfectly fits in with the CRUD database approach (create, read, update, delete).
CRUD is a design flaw
Unfortunately, business models do not follow REST and CRUD (for details see What's wrong with CRUD). The core of successful applications is not about data. Instead, it's about the processes that work with this data. So it's about things that happen – and data is just a static piece of information used by these processes. Of course, data is not irrelevant, it just no longer plays the leading role.
Regarding APIs, this means that they would have to be designed in a process-centric rather than a data-centric way. Only those who can be informed about processes can react to them. But the four verbs create, read, update and delete are too weak for that, because they do not contain any semantics and do not describe the reasons why things happen. However, it is precisely these semantics and reasons that are highly relevant for understanding and sensibly controlling business processes.
Events as DNA for distributed systems
Therefore, a new basic building block other than data is needed, which will take the primary role in the future, and around which APIs should revolve: We are talking about events. Events describe facts that have happened and are therefore predestined for if-this-then-that scenarios and for the integration of business processes across API and service boundaries.
From a technical point of view, using an event-centric approach for designing and developing APIs is a serious break with the past and requires new concepts and rethinking. The new world therefore feels unfamiliar at first, but it is the necessary basis for successful horizontal integration and offers a great deal of potential along the way.