At times, it seems wise to have applications share resources. This extends to microservices
In the last article, I examined where boundaries might be placed between microservices. This article continues this examination by discussing which resources might be shared.
Related Articles:
Security in a Microservices Environment
When to Share
In this case, sharing means turning a set of potential microservices into a single microservice. Our experience suggests that services are cominable when:
- there is no chance of a producing a security risk
- services share more than just a database backend
- services require similar resources OR
- services use different resources on the same system with different levels of intensity
- services will not require scaling on their own
- services are maintained in the same manner and share code
Always consider resource usage and security. Any system set to scale beyond current resource usage or where a hardware gap is recommendable should be separated.
If done appropriately, combining microservices can:
- reduce cost
- reduce resource usage
- increase speed
- increase ease of maintenance
Example
Consider a set of services related to licensing and access grants, not passwords. These services are often symbiotic as a license often carries what oauth considers scopes, rights to use certain components of the system.
These services can easily be combined and shared with tokenized access for any frontend. When using frameworks such as Django, the service avoids constant bombardment as well.
Conclusion
Combining microservices helps reduce cost. Knowing what to share is critical. Sharing is caring unless it hurts.