Cloud Native or Cloud Nightmare?

Cloud Native or Cloud Nightmare?

Chris Evans Cloud-Native Leave a Comment

For several years, the Cloud Native Landscape Diagram has been used to show the diversity of applications and solutions available for cloud-native infrastructure.  The potential selections are now so extensive that an interactive chart has replaced the PDF format. Is the landscape continuing to be cloud-native or a cloud nightmare?

Barriers to Entry

Let me initially highlight that the idea of the CNCF and a cloud-native diagram is a good one.  Here’s why.  In the late 1980s, I worked as a systems programmer and had access to an A0 image that mapped out all of the control blocks for MVS, the mainframe operating system.  The volume of information in this picture was huge, but over time and with familiarity, the content was incredibly useful. 

The CNCF diagram and now the interactive version also provides excellent detail, especially once you’re accustomed to the players and participants.  The breadth of offerings shows that the barriers to entry for cloud-native development are low, and that creates choice.  I’m sure that we’d all agree that choice and diversity are good things.

Selection Criteria

The more significant challenge though is how we consume these available products and solutions, while determining what fits best for our environment.  The most obvious starting point is to document requirements because they should then match to features and functionality. 

If only things were that simple.

image courtesy of https://blog.prototypr.io/design-for-crossing-the-chasm-1c4d4c68a3f1

Picking a product is only stage one.  In a world where the longevity of many solutions is uncertain, backing the wrong horse can result in a lot of undesirable technical debt and the risk of lurching from one solution to another.  This is why the technology adoption cycle, as documented by Geoffrey Moore in Crossing the Chasm, is so apt to describe the way in which businesses adopt technology. 

The innovators and early adopters to the left of the chasm are only seen as visionaries if the products they choose actually gain enough escape velocity to be successful in the mainstream market to the right of the chasm

Pick a Winner

So, there’s the challenge.  Not every product will make it over the chasm.  How do you pick a winner in a complex and evolving market?  The classic approach is to rely on analysts.  Gartner, IDC and their peers have built businesses and micro-economies based on selling opinion to CIOs and CTOs.  Methodologies such as the Gartner hype cycle are truly insightful as a process to determine how the market views technologies. 

My biggest issue with the analyst community is with the lack of hands-on testing and evaluation.  In a mature market, we can perhaps rely on features and functionality as provided by the vendor.  However, in nascent markets, where the requirements aren’t yet fully formed, this approach is less than optimal.

The most obvious example here is the way in which Kubernetes overtook Docker.  Did the Docker team take some missteps or was the transition to Kubernetes merely a case of evolution?  As we now look at how Kubernetes is being adopted, Could VMware be successful with Tanzu, or is it a misdirection to develop virtualisation and containerisation together?

Hands-On

In all of these scenarios, without hands-on experience that involves deploying and testing the technology, can anyone actually claim to be aware of where the market is headed?  I believe that without a knowledge of the implementation of new technology, we can never understand the nuances and potential risks that will come along to cause us future challenges.  This position is even more critical in the cloud-native world where the requirements of new platforms and solutions aren’t yet fully formed or understood. 

The Architect’s View

At Architecting IT, we aim to validate technology with both a market view and hands-on evaluation.  This process means understanding everything from ease of use, deployment, management and transitioning away from a solution as well as commenting on the vendor capability to deliver a platform.

Vendor capability is becoming increasingly important as we see the development of projects using an open-source model.  Rather than testing whether a vendor can deliver a solution effectively, we have to look at the community.  It’s time to evolve analysis and address the challenges of the cloud-native era. 


Copyright (c) 2007-2020 – Post #ba8d – Brookend Ltd, first published on https://www.architecting.it/blog, do not reproduce without permission.