From microservices to hybrid services architectures
Microservices architecture has been hyped as the latest and greatest software model that will increase your flexibility, accelerate time-to-market and underpin your digital transformations. However, it’s not without its drawbacks. Brian Coombs, Product Director at Cerillion, explains why a pragmatic approach is required to ensure microservices are used where there are significant benefits to be gained, and not just for the sake of it.
In the last 5 years, microservices has emerged as an architectural concept which is transforming how software is developed and deployed, delivering benefits including increased agility, improved resilience and greater application scalability. However, microservices hype has now reached fever pitch with many parties believing that a microservices architecture is the goal itself, rather than just the means to get there. And though microservices can deliver significant business benefits when used effectively, they can equally be counter-productive if they introduce unnecessary complexity and overhead within the application architecture.
Microservices is a design approach with the intention of making continuous development, deployment, management and integration of software easier. So, for example, new software features built as microservices can be developed and deployed separately from other components of a software application. This dramatically speeds up the lifecycle from product idea to commercially available feature. Furthermore, if your application has specific performance requirements for certain features, these can be built as microservices and use containerisation technologies such as Kubernetes and Docker to scale independently from other application components and take advantage of elastic cloud capabilities.
All good so far, however the problems come when microservices are used simply for architectural purity, but without considering the impact on complexity or performance of the complete application or solution. The lowest common denominator should not be the smallest microservice possible, but the smallest component that makes sense to be used and managed independently. Indeed, this is often described in terms of the principle of cohesion - things that change together should stay together. So, if there is a dependency between components, these should be kept together in the same ‘service’.
The microservices approach is based on three core principles:
In practical terms, this means that each microservice also contains its own data and configuration via its own micro database or schema. And this is where the complexity can occur.
Whilst microservices communicate via APIs, a large number of microservices will increase the load on your network and can impact latency, resulting in higher infrastructure costs to meet performance requirements. Similarly, each microservice containing its own data can result in data replication between microservices and increased overall data storage requirements. Furthermore, distributed and replicated data between microservices components makes it much harder to achieve business level reporting, analytics and assurance. And finally, if your microservices are at such a granular level that you need to call multiple microservices to perform a standard business function, you are introducing additional points of failure and complexity, and may find that you have inadvertently introduced dependencies between microservices which means they can no longer be developed and deployed independently.
Microservices, miniservices and macroservices
At Cerillion, we see lots of benefits of microservices principles and we’re using them in the way that best complements our platform and supports the reasons why operators come to Cerillion in the first place; a key factor being our modular but pre-integrated Enterprise BSS/OSS product suite.
We have followed a service-oriented architecture for many years and also have a firm belief in the benefits of standardised interfaces where we are leading the charge with our commitment to the TM Forum Open APIs, which has already proved successful in our award-winning TM Forum Catalyst project.
However, we don’t see a benefit to our customers in deploying multiple schemas for each and every component within a large and comprehensive suite. This is where miniservices and macroservices are more appropriate, enabling related functionality and data to be grouped together either by domain or business process.
In fact, one of the great benefits of our pre-integrated product suite approach is the common data model used by multiple modules within the Cerillion platform. Having this single, shared data model gives our customers the following significant benefits:
The approach of each component carrying its own schema is a necessity for best-of-breed vendors offering siloed functionality where they must integrate with other, unknown systems on each new project. However, these implementations are notoriously complicated from a revenue assurance perspective; whereas CSPs like the Cerillion suite because of its mastery of data that is then exposed through lightweight, standardised and service-oriented interfaces.
Even so, this is not a hard and fast rule and where it makes sense for specialist components to carry their own data, we do take this approach. For example, in our Convergent Charging System, Enterprise Product Catalogue and Self Service modules, each of which can be deployed separately or as part of our pre-integrated suite. Our mantra is not to adopt design approaches dictatorially but to choose the right approach for our software and our customers, whether that be microservices, miniservices or macroservices.
Find out more about the transformative features of Cerillion's Enterprise BSS/OSS platform here.
Microservices is a design approach with the intention of making continuous development, deployment, management and integration of software easier. So, for example, new software features built as microservices can be developed and deployed separately from other components of a software application. This dramatically speeds up the lifecycle from product idea to commercially available feature. Furthermore, if your application has specific performance requirements for certain features, these can be built as microservices and use containerisation technologies such as Kubernetes and Docker to scale independently from other application components and take advantage of elastic cloud capabilities.
All good so far, however the problems come when microservices are used simply for architectural purity, but without considering the impact on complexity or performance of the complete application or solution. The lowest common denominator should not be the smallest microservice possible, but the smallest component that makes sense to be used and managed independently. Indeed, this is often described in terms of the principle of cohesion - things that change together should stay together. So, if there is a dependency between components, these should be kept together in the same ‘service’.
The microservices approach is based on three core principles:
- Service-oriented design around specific granular functions
- Those functions should be exposed with lightweight and standardised interfaces (APIs)
- Each function should be completely self-contained and independent
In practical terms, this means that each microservice also contains its own data and configuration via its own micro database or schema. And this is where the complexity can occur.
Whilst microservices communicate via APIs, a large number of microservices will increase the load on your network and can impact latency, resulting in higher infrastructure costs to meet performance requirements. Similarly, each microservice containing its own data can result in data replication between microservices and increased overall data storage requirements. Furthermore, distributed and replicated data between microservices components makes it much harder to achieve business level reporting, analytics and assurance. And finally, if your microservices are at such a granular level that you need to call multiple microservices to perform a standard business function, you are introducing additional points of failure and complexity, and may find that you have inadvertently introduced dependencies between microservices which means they can no longer be developed and deployed independently.
Microservices, miniservices and macroservices
At Cerillion, we see lots of benefits of microservices principles and we’re using them in the way that best complements our platform and supports the reasons why operators come to Cerillion in the first place; a key factor being our modular but pre-integrated Enterprise BSS/OSS product suite.
We have followed a service-oriented architecture for many years and also have a firm belief in the benefits of standardised interfaces where we are leading the charge with our commitment to the TM Forum Open APIs, which has already proved successful in our award-winning TM Forum Catalyst project.
However, we don’t see a benefit to our customers in deploying multiple schemas for each and every component within a large and comprehensive suite. This is where miniservices and macroservices are more appropriate, enabling related functionality and data to be grouped together either by domain or business process.
In fact, one of the great benefits of our pre-integrated product suite approach is the common data model used by multiple modules within the Cerillion platform. Having this single, shared data model gives our customers the following significant benefits:
- Single source of the truth for analytics
- No data replication between components
- Inherent revenue assurance
The approach of each component carrying its own schema is a necessity for best-of-breed vendors offering siloed functionality where they must integrate with other, unknown systems on each new project. However, these implementations are notoriously complicated from a revenue assurance perspective; whereas CSPs like the Cerillion suite because of its mastery of data that is then exposed through lightweight, standardised and service-oriented interfaces.
Even so, this is not a hard and fast rule and where it makes sense for specialist components to carry their own data, we do take this approach. For example, in our Convergent Charging System, Enterprise Product Catalogue and Self Service modules, each of which can be deployed separately or as part of our pre-integrated suite. Our mantra is not to adopt design approaches dictatorially but to choose the right approach for our software and our customers, whether that be microservices, miniservices or macroservices.
Find out more about the transformative features of Cerillion's Enterprise BSS/OSS platform here.
