Thread by @swardley

X : Thoughts on hybrid cloud?
Me : Do you mean consuming different services from different providers or the same services from different providers or mixing public and private?
X : All them.
Me : Consuming different services from different providers is still relevant.

X : Example?
Me : Sure. I might consume office services from MSFT and compute services from AWS.
X : What about compute from MSFT and AWS?
Me : Added complexity to protect against one of the hyperscalers failing? More likely that your own company will fail.

X : But I've got this tool ...
Me : ... that seemlessly bridges the two? You've disadvantaged yourself though lowest common denominator, added complexity and It is far more likely that the tool and the company providing it will fail rather than either of the hyperscalers.

X : Public and private.
Me : Completely relevant in 2010. But it's not 2010 anymore. Why anyone has a private cloud these days is ... well ... it's either inertia or in incredibly rare cases a very specific niche of massive scale.
X : Like banking?
Me : No, not like banking.

The problem with banking is there is no such thing as "core banking systems". There are instead 150+ banking applications often cobbled together in a mess with many "black box" solutions that were built so long ago that people are too scared to look at, let alone fiddle with ...

... on top of this you have layers of abstraction and supporting services adding additional data. It is layers upon layers of sticking plaster to create a sort of "round shape ball" that you call "core banking systems". I am truly amazed that it all keeps running.

The banking issue is inertia due to a mountain of technical debt. Obviously there are execs hoping for a technology that will just "cloudify" it. Good news is a group up at Hogwarts have been working on this for the past decade. Bad news is ... magic isn't real.

X : Any sufficiently advanced technology is indistinguishable from magic!
Me : That's the point. That's why many wait, in the hope that at some point in the future some super intelligent AI thingy will just come along and fix the problem. See also climate change.

X : Any way out?
Me : Keep holding on until retirement at which point it's someone else's problem or hard slog. There are some good potential pointers out there e.g. thoughtmachine.net

X : AI to refactor COBOL. I saw it on a big consulting firm’s slide deck.
Me : I told you Hogwarts was working on it.

X : Is inertia a valid reason for not moving to the cloud?
Me : It's not a valid reason but it's a reality you need to be aware of. Take the banking example, the fundamental problem is past failure to deal with technical debt ...

... same problem in financial instruments, layers upon layers built with each layer treated as a commodity and new layers built on top without the work to actually turn this stuff into an understandable commodity ...

... so in the system space you've got a "core banking system" which is many things all connected in many different ways with huge amounts of legacy components that few understand. It's akin to a house of cards (see also banking crash) that keep standing due to heroic efforts ...

... it's a lot easier to write "move to cloud" on a presentation than it is to move that sort of system, assuming this is possible at all. A complete replacement might be needed. But the underlying problem of not fixing debt (technical or otherwise) still needs to be fixed.

X : So, banks aren't moving to cloud?
Me : No, banks are moving to cloud. Slowly in most cases. Just be mindful of inertia is all I'm saying. Don't be surprised by it. This is not a quick journey. It took Netflix seven years to get rid of its data centres.

X : Does it help to have a composable architecture?
Me : Wow ... blast from the past. I haven't heard that word for ages. Last time I wrote something on composability was ... hmmm ... 2014 - blog.gardeviance.org/2014/03/compos… ... yes, it helps to understand the components in your landscape.

And yes, your map is a representation of architecture ... it's just one with context in it i.e.

take a systems diagram ...

... turn it into a chain with a focus on users ...

.... turn that into a map ...

... and now you can start to do all sorts of fun stuff from organising teams, to contracts, to methods, to capital flow to gameplay to anticipation of change ... long list.

But at its heart, it still remains a diagram of whatever system you're looking at i.e. technical architecture, economic system, social system, political system ... it just happens to be a map as well.

X : Is it composable?
Me : Depends upon what you mean. The architecture consists of components (and it's a good idea to have visibility aka situational awareness) but are you asking whether components are interchangeable? That's a function of evolution and varies over time.

But you have an added complication which is as components evolve many become abstracted over time. So, there's little point messing around trying to make your infrastructure more composable with interchangeable providers because you think that's where it is at in 2025 because ...

... by about 2030, it will all be disappearing under layers of abstraction. Which is why messing around at the lower ends of the stack is high risk investment today. Very easy to build a future liability, a new legacy.