Year of the Cloud?
It is the time of the year that people are trying to fill the intellectual void caused by overabudance of eggnog, glögg and premium chocolate by producing predictions for the coming year 2015. I’m not much of a seer, so instead I’ll take a look at the past year 2014 and produce some probably blindingly obvious tautologies.
It is also interesting to see that cloud vendors are willing to cut their prices again and again and again and again. I remember someone commenting on Twitter at re:Invent 2012 about AWS’s price reductions, like, that a 30% price drop is not normal in a competed market. Or similar.
I took that to mean that in a mature competed market like electricity, seeing major price reductions on the baseline price is not possible because there are no such margins in already-furiously-competed prices. Just the fact that cuts are happening means the market has not matured into a (semi)stable state.
That’s not much of a news in itself — “the cloud” is a shift in the landscape itself and only a fool would expect stability right now.
The problem I see in 2014 is that it bought faster and faster chaos and complexity into the cloud market. I’ll try to explain:
Chaos is unpredictability, not randomness. All of the cloud vendors are what economics call rational players in the market and try to make optimal choices at any point of time. But this decision-making process is not visible to customers, so although customers and we, the Internet pundits can find post hoc narrative to all of these events they remain, at heart, unpredictable to us.
It is easy to predict that AWS, Google and Microsoft would drop their prices in 2015. So what? That’s just extrapolating past into future. Try predicting instead how much, how many times and when those price drops will occur. And who would be brave enough to predict that no price cuts would occur? Or even price increases? Anyone? Volunteers? (See here.)
Complexity … it is not enough that there are more cloud services, and these are more and more complicated but there are also more and more interactions between different systems leading to complexity. Complexity in turn easily leads to a priori unpredictable emergent and even chaotic behavior — again a problem especially for larger enterprises, but also for nimbler companies overreaching their capacity to handle emergent surprises.
Rapid change, chaos and complexity can cause havoc even before a single line of code is laid out. Analysis paralysis is always a real risk, with new stuff continuously popping into existence, potentially invalidating prior analyses is not helping planning-oriented organizations. Strategically, if you are not keeping an eye on the landscape your earlier assumptions about technological barriers of entry could be invalidated catching you unawares, hurting or obliterating your business case.
Usually you’d want to take a step up the abstraction layer when this kind of rapid chaotic evolution occurs to allow one to maintain an overview without losing too much of the necessary details, but I’m not sure it is yet possible. At least I feel not. I don’t personally have a useful abstraction at hand yet.
I’m seeing fragmentation of competence and skills for cloud consultants and engineers in 2015. At least for myself, as a sort of generalist bridging engineering and business strategy I see difficult choices ahead. Should I choose specialization into some part of the cloud landscape (technology or business-wise), or raising in the abstraction level?
Unfortunately the specialization path feels uncomfortably like 90’s fragmentation into different client-server camps and 00’s fragmentation into different web service full stack compositions. I didn’t like either of those when they occurred, mostly as it led to entrenched us-or-them positioning in the competence market. (Hardly benefiting customers.) Worst of all, now there’s a possibility of this fragmentation occurring within cloud service catalogues — Lambda vs. Beanstalk battle anyone? Even when AWS positions these as complementary, the growing service portfolio makes it harder and harder to have generalists on staff, leading (human nature and all that) into different specialization camps fighting for their viewpoints.
Perhaps a take-home message of that thought line is that cloud competence management increases in importance in teams when cloud is part of company strategy.
Earlier I noted that the abstraction-raising path does not seem to be open. I could ditch the technology and move purely into cloud business strategy level but that’s not what I mean with “going up in abstractions”. It’s a different business level with different abstractions, it is not a new abstraction for the technology layer that I’m looking for.
Personally I love working at two levels simultanously, both at the business and the technology level. It’s often difficult and challenging position, being judged by both camps, but also very rewarding because you can help customers find solutions that are beneficial win-win scenarios for all camps and business lines within the organization. And this of course within the context of cloud computing for which I have both personal, professional and scientific interest.
Yet it somehow feels there’s a pier and a ship, and I have a leg on both, and the ship is starting to drift off.
blog comments powered by Disqus