We currently have a Model wrapped in app layer operating as a hub with multiple apps acting as spokes. However, this is leading to many changes such as orchestration, encryption and decryption functions being pushed to individual spokes and being replicated for every spoke. What are the pros and cons of hub and spoke architecture?
Sort By:
Oldest
Chief Information Technology Officer in IT Services15 days ago
Adding new spokes (applications) is relatively straightforward since the hub provides centralized services that spokes can easily connect to without needing major architectural changes.Head of Transformation in Government14 days ago
Could you add a bit more detail? This is likely a perfect case of needing to look at an architectural problem holistically and at the same time take into consideration the local terrain before choosing an architectural pattern.Hub and spoke has the advantages of centralising the shared functions, including orchestration and encryption, so as to simplify management and efficiency. If in fact you are finding that orchestration and encryption have to be replicated in the spokes, then it might be the case that spoke specific requirements are preventing you from using the model-app hub fully. Or it could be the case that the model performance is not adequate to serve the spokes and that some functions that could be hubbed (but require a refactoring of the hub) are in your spokes which defeats the benefits of the hub and spoke pattern.
This pattern is sensitive and less efficient if there is a low tolerance in the overall system for latency, fault tolerance and standardisation. In these cases, you might consider transitioning to a microservices architecture with greater autonomy from what are today's spokes. Serialising vs normalising has, imho, always been the great tradeoff that is decided contextually, and sometimes even having to refactor to improve performnace and cost.