Technical question: assuming we have different systems that need to be integrated with Cumulocity (Fleet Management, Asset Management, etc.), and all integrations are API-based, how should we estimate the number of microservices required?
Can we assume that each external system would require one dedicated microservice, or does it depend on the complexity, protocols, data models, and integration logic involved?
Microservices are calculated based on CPUs and memory, referred to as Cumulocity Compute Unit (CCU) == 1 CPU Core + 4 GB Memory, mainly. So, they will have a cost impact depending on how many CPUs and how much memory you need to fulfill your integration requirements. (Anyone: Please correct me if I’m wrong).
It makes no difference if you split the microservices into multiple ones (one for each integration) or keep them as one “big” monolithic microservice (all integrations combined in one).
I personally would definitely prefer to split them per integration, but be very precise on the resource assignment for each.
To get an answer to your questions, complexity does indeed play an important role:
To be more precise, the biggest factor is how many requests each integration needs to handle per second and how much logic is running in the background, e.g., scheduler threads, etc.
Are we talking about hundreds/thousands of requests per second to the 3rd party system, or just a few hundred or even less? With that, you can size each integration microservice and calculate the required CCUs.
In addition, the architecture and also the programming language of the microservice must be considered:
Is it mainly blocking and implemented in Python/Java? You may need more resources.
Could it be mainly non-blocking implemented using Rust (or any other more resource-efficient programming language)? You may need less resources.
Just a very rough estimation: A (Java) microservice with 0.5 CPUs (CCUs) can already handle tens to hundreds of requests per second when implemented async. 1 CPU might handle 4-digit requests/second already.
There are many factors that influence how you should structure your microservices. In addition to the points Stefan mentioned, here are a few other considerations:
Development Team Structure
If you have multiple development teams focused on different domains within your IoT solution, it is often best to reflect this in your microservice architecture. For example, if Team A is responsible for contract integration (ERP) and Team B manages field service management software, these should be kept as separate microservices rather than combined. The responisibility must be clear to the team! Who is owning the component!
Contract Versions and Compatibility
I generally prefer having a dedicated microservice for each external system. Each microservice must remain compatible with a specific contract version of the external system it integrates with. If you combine two system integrations into one microservice, you are forced to release a new version even if only one contract changes. Maintaining a one-to-one relationship is a cleaner way to manage versioning and compatibility.