One of the most discussed software architectures are microservices. In other words, the request to split the monolithic applications of the past into small, autonomous services. However, there are some issues with microservices: They are expensive – as they are required for unlimited scaling – and only work if the underlying culture is embraced in its entirety.
This raises multiple questions. For us in the ERP world, is unlimited scaling a requirement? Also, our applications are expensive enough and a complete shift of the whole application towards a different architecture is often impractical. Nevertheless, SAP has a couple of offerings built on microservices, and we can learn from these examples.
Microservices are autonomous
At its core, the microservice architecture requires each service to be fully autonomous. It has a well-defined network API to get data in and out, no other methods allowed. The decision of which technologies to use to implement the service is up to the responsible team. Sounds simple enough, but the decision has consequences.
A sales order should reference existing customers and material master data, but these are other services and hence not part of our database’s tables. But if they are not part of this database, all features that a database provides for free, including transactions, enforcing foreign key constraints, fast joins and the like, need to be re-implemented on service level.
The obvious solution would be to make the database with its tables one service, and the business logic where sales orders are maintained would be another microservice. Something like a 3-layer service architecture with the UI layer, the application layer and the database layer. The application layer exposes function modules for the various operations and …. Did we just re-invent the R/3 architecture?
Eventing and eventual consistency
The software industry’s answer to that problem is to use events as the information backbone. Every service broadcasts all changes made to the data and the interested parties can listen and persist the required data in their own database.
In the example of the sales order database, it would have tables with material master data and business partner records for reference, except that these extra tables cannot be modified. When the material service broadcasts the event, effectively saying, “There is a new material with the following data”, it is modifying the local reference table.
SAP Cloud Platform’s microservices architecture
Each service deployed is an isolated entity, publishes its APIs in a central registry – the API Hub – and multiple instances can be started to increase throughput.
The CAPM supports even eventing of services but ignores out of the box support of distributing change data across the database instances. SCP does not need that, as the database is used as a service as in a client server model and is not an intrinsic part of the service itself.
One way to look at it is that it combines the worst of both worlds: It scales like a client server architecture and adds the complexities of microservices. Security is maintained outside of the database, services need various bindings, services require defined routes, every service must serialize and deserialize the payload for data exchange, every service needs to reevaluate the user security, etc. In brief, simple things are tedious, complex tasks are extremely difficult.
SAP Data Quality microservices
Another example are the SAP EIM Data Quality services to validate and cleanse various aspects of address data.
For such an offering, a microservice architecture is perfect. The required address reference data is part of each service instance. There is no need to sync the data across instances due to the static of the postal data. The user sends a http request with an in-doubt address payload to the service and gets back the corrected address, the information on what has been corrected, and the confidence level. It scales perfectly and the overhead is little.