Steve Flanders (@smflanders) and I had a late-night Twitter conversation over the complexities inherent in cloud-native applications. My take was that we need to broaden our view and see the entire picture before we can delve into the weeds. Steve’s was that we need DevOps. I countered by saying we need better communication. In essence, we may have been saying the same thing, but we were on different planets, which led to a useful analogy. During the race to the moon, who were the systems engineers, the ones who saw the big picture of a program with well over 15 million moving parts, not to say people, involved?
A few years ago, I told HP’s product manager for public cloud that I thought all public cloud providers would run out of money and get out of the business. I was mostly being controversial to spark conversation. But HP has recently ceased selling its Helion public cloud. While this did prove me right in that case, I’m not sure every public cloud provider will remain unprofitable until it dies. I do think it is very hard to compete with AWS for a commodity public cloud. On the other hand, there are ways to build a public cloud that address clients who will not use AWS.
There are three pillars to the software-defined data centre (SDDC): software-defined compute, software-defined storage, and software-defined networking. Without any one of these three, the whole edifice of the data centre falls down. We build all three to be resilient, “designed for failure,” and robust. Each can be built and rebuilt from scripts that are stored in distributed version control systems. But at the bottom of every application stack in our SDDC, there is a database or file store that cannot—by definition—be re-created from scripts. This is the core data that we mine and make profit from. What happens if (or when) the edifice collapses? How is that core data protected, and is traditional backup up to the task?
Difficulty and complexity are two things human beings tend to avoid. For the most part, people seem to be much happier with concepts that are easy on the brain, take little time to implement, and have the promise of immediate return on investment. This tendency gives rise to quick fixes that are simple and low-cost. The problem with most of these approaches applied to transformation is that transformation does not come with speed or simplicity. I know many organizations that wish it did! It would make it so much easier in my consulting practice, and it would provide services to organizations making transformational changes. Unfortunately, it just doesn’t work out that way.
The Thursday keynote at VMworld USA is always about things unrelated to VMware’s products. It makes a welcome break from looking into the depths of IT. The keynotes are supposed to make us think about our place in the world, and that of the IT we support. One of the presentations this year was about the concept of “umwelt,” which is about how we perceive the world around us. I think that there is a parallel concept in how we perceive products and technology that colors our opinions. I’m fairly sure I’ll misuse “umwelt” here, but I don’t have a better term.
In my first article of this series on Support in the 21st Century, I laid out my thoughts about the baseline expectations for the corporate support model and structure established at most companies. This is where I first brought up technology silos and presented the correlation between the number of technology silos and the size of the infrastructure.