The ephemeral composable stack (series): Into the ether with cloud
It was somewhere around a decade ago that Red Hat CEO Jim Whitehurst (now president at IBM as he is) used the composability term as a hook for his keynote.
“I want to talk to you about the era of composable technology and how you [as developers] are all going to help build it,” said Whitehurst, or words very close to that and to that effect.
Back then, composable IT was rather more simplistically meant to convey some idea of ephemeral cloud resources that were essentially virtualised and abstracted in nature… and so, justifiably, superbly suited to being coalesced, connected and corralled into whatever composable stack of compute (and storage and analytics etc.) needed.
That was then and this is now and we understand virtualisation a whole lot better these days, but we’ve also extended our notion of composability from ‘just’ using it to denote software application development functionality components.
Indeed we have i.e. today we talk about composable disaggregated technology infrastructures and how only this more programmatically positionable approach is suitable for modern workloads.
So we need to ask what composability actually means in today’s platform terms.
The direction of composability
We need to think about what direction composability comes in i.e. does composability means bringing together compute resources (let’s say for AI or some other analytics function) to form one or more bigger more powerful tool? Or does composability means building a toolset that is so manifoldly multifarious that it enables software engineers to pick and choose which elements they need for which workloads in which environments?
The answer is probably both, but why?
No prudent customer of any size runs one cloud instance from one single Cloud Services Provider, a multi-cloud hybrid approach appears to have proven itself to a) spread risks b) widen functionality c) optimise cloud price purchase points d) enable IT stack optimisation based upon different cloud optimisation options and e) other.
So (if we accept that mult-cloud point to be true) does composable IT mean cloud composability and neural network engineering?
Talking of neural, we know that AI is only as good as the breadth and quality of its dataset, so… should IT composability be a delivery mechanism for whatever Machine Learning functions we wish to get out of our AI structures?
Best for me, equals best for you (user)
Is this whole conversation hinged around the best fit paradigm? We know that composable technology uses modern, modular architectures and open ecosystems, enabling organisatons to compose so-called ‘best for me’, multi-vendor solutions made up of preferred technology partners… so this is the way forward, right?
Is composable technology a natural throwback to open source? Surely open use of open components is open source. So how will open source be more composable moving forwards?
Evanescence: bring my IT back to life
With the rise of microservices and containerisation, composable technology was always an inevitability, surely? Quite how every ephemeral IT resource is secured and locked down (and indeed backed-up) is a massive consideration, so how do we do that.
Is serverless infrastructure essential for a composable top layer? It’s not a silly suggestion is it?
Composable IT might be functionally more adept, but it also needs to help firms get product to market faster if it is to prove its worth… so are all composable structures validated on that basis before they are architected?
Will composability eventually envelope back upon itself and deliver a sort of modular monolith that we buy as some utility-compute solution as we remain blissfully unaware of the modular nature within?
Deeper implementation questions
Other questions need to be asked here…
We need to ask how an organisation should develop a strategy and culture where composability and ephemeral IT is the norm… and, further, how do these same companies encourage strategic partners to adopt (and integrate with) their composable assets in their own projects?
Once we do move closer to composable orbit and exist happily within it, how do we measure Total Cost of Ownership (TCO) on IT assets that are ephemeral?
In the core developer zone, how should you deal with dependencies when elements of IT need to be retired? Plus anyway, what are the best practices for taking into account obsolesce of ephemeral assets during their lifecycle?
Perhaps finally (for now) how do we sell the concept of composable IT to a CEO or business chief who wants a quick ROI? So it’s time to think about composability in a neo-classical way and… what should our ethereal ephemeral ‘composer’-centric anthem be anyway?
Image source: Wikimedia Commons