Thought for today: when I reflect on certain microservice architecture, I feel like an investor banker-type is pitching to me a new form of mortgage-backed securities (MBS). Like MBS, not all microservices are identical;they are organised in layers, each with a different level of priority in the technical debt repayment stream.
As a result, one ends up with an heterogenous architecture with different levels of risk and rewards that is constantly evolving while maintaining its structure via contracts (API). Effectively, the microservice approach is a form of architecture securitization by pooling various types of technical debt, generated by small individual microservice.
Subprime software risk and rise
The securitization of microservices debt has the advantage of providing more resources for development efforts at a time when we have a developer shortage and inflation is undermining a traditional source development funding. However, microservice-backed securities can also lead to an inexorable rise of the subprime software industry while creating hidden, systemic risks.
The granularity of microservice of securitized assets can mitigate the technical credit risk of individual developer groups. Unlike monolithic architecture project technical debt, the securitized technical debt is non-stationary due to changes in volatility that are time-and structure-dependent. If the development process and integration (devops) is properly structured, and the pooled microservices performs as expected, the overall technical debt risk of all layers of microservice structured debt improves. However, if improperly structured, the affected microservice layers may experience dramatic quality deterioration which can ultimately cause the overall project to fail.
The main issue with this form of software project securitization is that it limits the project, program manager and architect’s ability to monitor risk, and that further reliance of a nebula of securitized microservice via cloud API may be particularly prone to high spike in technical debt accumulation. With proper monitoring and constant effort, this risk can be efficiently mitigated. As the great benefit from the microservice approach is that the corrective effort is contained within the domain of the particular failing microservice.
Open sourcing : ultimate securitization tool
For corporations, the total face value of a large project decreases overtime, because like mortgages, the technical debt of a solution is not paid back as a single payment, but rather paid along with the interest in each periodic release. The microservice based approach is smooth and provides a continuous repayment plan of the project debt, greatly reducing the debt cliff risk. However, it also fragments the visibility of the overall debt risk.
When the cost of maintaining these microservices or even software stack becomes higher, the face value of the project companies tries to repackaged and reused in order to collateralize the technical debt obligations. Similar to MBS, the lower-priority in terms of business value and higher-interests services, form the bottom layer of the microservice architecture stack. They are the service bus, database, key/value store etc.. making the overall application work, doing direct delivery of business value.
When even the internal reuse is not able to cushion the cost of these software layers, corporations decide to use the ultimate securitization tool. They opensource the project, which allows for the refinancing of the underlying technical debt and redistributes it through the capital structure of influx new developer resources provided by the open source community.
In return, the open source community (and other companies), benefit from the principal and interest development efforts. However, like any financial product, open source efforts need to be carefully shepherded and promoted in order to yield the optimal benefits from the operation.
All in all, Microservice architectures are a great model for bringing greater fluidity to the software development ecosystem, however like any tools. User need to be wary of the unforeseen consequences if they lose track of the key metrics the wanted to optimise in the firs place.
No comments :
Post a Comment