Skip to Content
Technical Articles

Microservices? Really?

Eager to learn more about “the importance of the Integration aspect for the Intelligent Enterprise” this morning, I started with openSAP’s – very recently updated – Integrated Intelligent Suite. During Unit 1, we learn that “SAP has traditionally been a key player with its ERP-centric Business Suite”, but “Since 2010, acquisitions of a number of Cloud solutions have added substantial, additional functionality … to this portfolio”.

However, “as additional applications came in, Integration was not a given. Customers have repeatedly articulated perceived shortcomings, and expectations with regard to that”. A decade later, and as a consequence of these shortcomings, “In early 2020, SAP’s CEO … published a Paper: SAP’s Integration Strategy for the Intelligent Enterprise. It provides a comprehensive overview of SAP’s Integration Plan for the Cloud, and explicitly stresses that Intelligent Enterprises are Integrated Enterprises”.

At the 4-minute mark of Week 1, Unit 2 – Integration as a Strategic SAP Topic – I stopped the Course:

openSAP%3A%20Integration%20as%20a%20Strategic%20SAP%20Topic

openSAP: Integration as a Strategic SAP Topic

It turns out that this Course is not in fact aimed at explaining “the Integration aspect for the Intelligent Enterprise”, but instead at explaining that Integration actually became “a Strategic SAP Topic” in 2020; almost 10 years after the acquisition of SuccessFactors. What we ‘learn’ in the Course, is that “SAP needs to deliver true out-of-the-box integrations … to regain its strength”; that “SAP needs to provide strong integration capabilities … to defend and expand its footprint”. If Gartner is right that “integration work will account for 50% of the time and cost of building a digital platform” in the 2020s, then many will be unhappy to learn that “SAP needs to provide strong integration capabilities”; at some point in the future. If it is indeed true that “Intelligent Enterprises are Integrated Enterprises”, then what this Course actually teaches us, is that SAP is many years away from reaching its own lofty goal.

Having also recently started a separate Course – SAP Integration Suite and SAP Extension Suite: Introduction – SAP’s Integration Strategy had seemed a little clearer at the time. SAP is pushing hard for ‘Cloud Native’, as the basis of its Integration Suite: “an approach to designing, building, and running computer applications … Cloud Native computing uses [1] an open source software stack to deploy applications as microservices, [2] packaging each part into its own container, and [3] dynamically orchestrating those containers to optimize resource utilization”. We are told that “Applications in production are managed by a combination of containerization (a type of packaging that guarantees applications are delivered from development with all their local operational dependencies included), and a commercially available or open source orchestrator such as Kubernetes”.

As such, it seems clear that SAP is now pushing ‘microservices’ as their modern solution, to “the Integration aspect for the Intelligent Enterprise”. What I was nonetheless surprised to read in the Course, was that “containerization … guarantees applications are delivered from development with all their local operational dependencies”. I was surprised because individual microservices do not in fact live in a vacuum: they depend upon one another. If an updated microservice is “delivered from development with [a new API version as well as] all their local operational dependencies”, then the other microservices that depend upon that newly updated microservice can reasonably be expected to fail: unless they are also updated to take account of the changed API.

The API-versioning conundrum is one of the best known microservice ‘pain-points’ there is, and it calls entirely into question the notion of microservices as “packaging each part into its own container”. How, precisely, are ‘independent’ microservices supposed to make calls to other ‘independent’ microservices, unless they are informed of any updates to the underlying APIs by which they communicate? How, in other words, can they possibly be said to be ‘independent’ of each other? (see: https://camhunt.medium.com/requested-event-pattern-cf354deff906)

Should we consult other authorities on the topic, we read in Microsoft’s Communication in a microservice architecture, that “Each … microservice owns its own data and its own domain logic”. What’s more, we learn of the most critical microservice pain-point: “And finally (and this is where most of the issues arise when building microservices), if your initial microservice needs data that’s originally owned by other microservices, do not rely on making synchronous requests for that data. Instead, replicate or propagate that data (only the attributes you need) into the initial service’s database by using eventual consistency”. As such, Microsoft’s proposed solution to the principal microservice pain-point, is to duplicate data across the entirety of the microservice landscape, and to pray that “eventual consistency” will be considered adequate for Enterprise Applications: it typically is not.

Another question that might reasonably be asked is how, and when, we inform the “initial service’s database” that the data model of another ‘independent’ microservice – upon which it depends for its data – was significantly changed during its last update? We can’t: it’s packaged “into its own container”. We either update both microservices simultaneously, we decide the initial service doesn’t need to be made aware of the latest data model changes (for now), or the initial service fails (when searching for no longer existent data). If a microservice needs to be informed of changes to the data model of another – independent – microservice, then they are not independent at all, and should instead be merged into a single ‘macroservice’ (see: https://blogs.sap.com/2020/06/01/from-soa-to-macroservices/). This fairly obvious conclusion probably helps to explain why Uber – a microservices champion – started to abandon microservices in early 2020; about the same time SAP appears to have decided that they are instead the future.

Should SAP wish to prove that it is indeed an Intelligent Enterprise, it needs to stop pushing microservices as an Enterprise-grade solution: the (new) future in software architecture is Event-Driven.

See: https://blogs.sap.com/2021/01/02/the-erp-is-dead.-long-live-the-distributed-planning-system/

 

LINKS

https://docs.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/communication-in-microservice-architecture

https://camhunt.medium.com/event-oriented-architecture-manifesto-for-distributed-enterprise-applications-327f6e88b12f

 

 

 

 

 

 

 

/
openSAP%3A%20Integration%20as%20a%20Strategic%20SAP%20Topic
Be the first to leave a comment
You must be Logged on to comment or reply to a post.