Book Review: Technology Operating Models for Cloud and Edge

Technology Operating Models book cover

I was recently sent a copy of a new book by Ahilan Ponnusamy and Andreas Spanner, called Technology Operating Models for Cloud and Edge: Create your purpose-built distributed operating model for public, hybrid, multicloud, and edge.

It was interesting to read this book.

I spend more of my time on the Azure side of the fence than the AWS / RedHat side of things, so I have some pretty different opinions to the authors on many of the topics. I've have worked with multiple clouds, so what they were describing was familiar anyway.

I particularly liked their discussion near the beginning of the book that cover what often goes wrong in cloud moves. They talked about issues with:

  • Unclear direction-setting attempts like 'cloud first' left teams unsure of their future or what to do.
  • Moving to the Cloud is mistaken for innovation.
  • Goals to move large amounts of applications to the public cloud in an established enterprise without significant change management are not realistic.
  • High unanticipated bill shock.
  • Lift and shift shortcuts do not leverage Cloud on-demand scale-out/in features and, as a result, do not lead to the desired business demand-aligned pricing.

I regularly write articles on making real cloud transformations not just migrations. Too many people talk transformation, but end up doing migrations, and then enter the well of disappointment. And for their users, things are even worse.

So I liked to see their discussion warning against focusing on technology instead of transitioning people, processes, and culture to enable cloud ROI. And I had a chuckle when I read their recommendation to not start with logos that we want on our CVs. I can't tell you how often I've seen teams makign that mistake.

Robust, Antifragile, Application Lifecycles, and Data

I'm not 100% convinced by the Robust is out. Antifragile is in. discussion. I get why they're arguing that, but I see it differently. Similarly, I view application lifecycles now as very different to the:

  • innovate
  • operate
  • retire

options discussed.

Given my work focus, it's not entirely surprising that I differ a great deal with them in regards to how data should be handled today.

Edge Services and Hybrid Cloud

The authors must be seeing far more edge-based services than I commonly see in the market. They had an interesting discussion on that. Quite a large part of the book is dedicated to tackling edge services.

As for hybrid cloud arrangements, I'm quite pleased to see the lead Microsoft has taken in their Arc-enabled offerings.

Vendor Lock-In

Finally, I see their arguments around avoiding vendor lock-in. This is a topical one for me. I see people worried by this, and ending up with lousy outcomes.

It reminds me of application code that's written to avoid being locked into specific databases. Invariably, you end up with code that's not great with any database. And eventually, code gets added that's specific to one database. So then you have the worst of all possible worlds: poor code that's database agnostic, yet lock-in anyway because eventually, work just had to be done. And the kicker: I've never seen anyone who does this ever change databases anyway.

The same applies to multi-cloud thinking. What the authors don't really discuss, is that it's easy to end up with outcomes that work equally poorly on multiple platforms.

And it's a similar discussion in relation to committing to only use open source software. I understand the sentiment, and I've used many of the services that they mention in the book. I just haven't loved those services the way I do many of the options that aren't open source.

In today's world, your company can get run over by competitors who are quicker to market by using the best aspects offered by a single platform.


Regardless, I'm glad they've written on these topics. Even if you don't agree, it gives you a list of topics to consider.

7 out of 10

Leave a Reply

Your email address will not be published. Required fields are marked *