SYDNEY, AUSTRALIA - AUGUST 15: An O Bike and two Reddy Go bicycles are seen on August 15, 2017 in ... [+]
Software is getting bigger. Every iteration and release of enterprise software builds upon an already extensive base of code, datasets, functions and formulations that ultimately results in a bigger, more expansive and increasingly all-encompassing software application, suite or platform.
Equally, software is getting smaller.
In the pleasingly disaggregated world of the web and the cloud computing network that weaves throughout it, we are making increasing use of smaller incremental (often reusable) components and microservices. The use of microservices (and a microservices architecture) describes a software system built using modules, all with their own particularly defined function, task and role - each of which is connected via a standardized and clearly defined interface such as an Application Programming Interface (API).
There’s no question that the microservice approach is superior in most ways to legacy monolithic architectures. Many organizations turn to microservices to avoid vendor lock-in, combat the costs and limitations associated with the monolithic approach and increase agility (e.g. each service can be developed and deployed independently without incurring downtime or needing to refactor other parts of the app). Plus, there are obvious benefits to getting the right tool with the right capabilities for the job.
How to run microservices
If these introductory statements describe the shape of modern software, then at what cadence and in what operational format should we be using microservices? Co-founder and CEO of open source data platform company Directus Ben Haynes is convinced that a hub and spoke arrangement is the key.
He has tabled his theory as a result of the obvious truth that manifests itself in this sector of software application development i.e. there are a number of downsides to deploying a vast matrix of microservices.
“Moving from a simple monolithic model to a complex model with hundreds, or even thousands, of interdependencies can lead to a data ecosystem that is difficult to understand and maintain, requires many costly licenses and forces a steep learning curve for user training and onboarding,” explained Haynes. “If one of the services advances and another stagnates or is no longer supported, the integrations and dependencies between them may break. One dependency breaking can have a domino effect, bringing operations to a halt.”
Because microservices often don’t perfectly bookend to each other, there can be gaps in capabilities that need to be filled with custom-built software code and logic. In instances where data is siloed across disparate platforms, the tenuous connections between data streams doesn’t make things any easier either.
Why go hub & spoke
“When evaluating their technology stack, organizations should instead work toward a more balanced ‘hub-and-spoke’ approach, where they turn to solutions that lay a complete and solid data foundation that covers business needs (the hub) while still integrating with microservices to allow specialization, as needed (the spokes). This approach combines the stability of a monolithic architecture with the agility of microservices so organizations can take advantage without overrotating on the complexity,” enthused Haynes, speaking to a small group of international press.
Where he’s going with this whole theory and rationale is relatively easy to comprehend and grasp; organizations can think of the hub as the foundational data layer i.e. a single point of data access that can provide about 80% of the functionality they need.
“The hub is designed to connect with other tools and applications through APIs, Software Development Kits (SDKs), webhooks etc. allowing for specialized solutions to come together that best meet the needs of the business,” explained Haynes.
He then states that the hub serves as a baseline of common or critical functionality but still allows organizations to easily connect other business-critical systems such as Stripe, Hubspot, Salesforce, or any number of hyper-specialized tools.
“Removing the need to manage multiple base services eliminates any functionality gaps, as it becomes easy to connect a new tool or capability without altering the stack or interfering with operations,” clarified Haynes.
Proof of the pudding
How can he be so confident that this approach works? Because… he says openly, Directus used this exact template to create the open data platform technology proposition that it goes to market with today. Its platform is designed to replace many disparate systems within a single platform (consolidating data and making it accessible through a single, extensible API).
In a recent example, an international airline used the Directus platform to consolidate multiple systems with a single source of data, including reservations, inventory, airport kiosks, a mobile app and more, to ultimately cut costs and eliminate data discrepancies between systems.
“In general, we’ve found that the hub and spoke model eliminates roadblocks to software development/deployment and reduces the burden on engineers – freeing up their time to work on higher-value, revenue-generating activities,” concluded Haynes.
There’s an old much-loved maxim by the software engineering community that says something like ‘when faced with a choice, take both’ - and that truism is well borne out and validated here. As the software universe gets bigger and smaller at the same time, we need to be able to embrace zen-like balance at every level.
It’s time to go large, but also go small with hub & spoke logic - but let’s pump the tires up first, please.
