In the rapidly-evolving cloud native computing area where highly integrated components are critical, we need an assurance of interoperability and a baseline agreement among components: the things we can easily take for granted.
Computing history has demonstrated repeatedly how important it is to ensure compatibility among relevant software components. Confusion reigns when we lack agreed-upon definitions for file formats, file systems, or networking and data protocols. Rather than innovating, technologists spend their time reinventing wheels – or spinning their wheels. What a waste!
That’s certainly been true for anyone working in DevOps. Organizations embracing this new mindset have committed a ton of time with a goal of innovating in new areas. But this innovation can be expensive because gluing together components that don’t yet interoperate is a long-term commitment.
Choices are needed – until they get in the way of progress. With fragmentation, techies are forced to choose one platform over another (“Which operating systems must I support?”) and then cope with the consequences (“What if I make the wrong choice?”). Anyone working in this technical realm – software developer, vendor, provider – discovers that time and energy is expended on redundant work. And the result we fear is a new variation on – “This website only works well with Internet Explorer.”
Businesses thrive on predictability and so does software.
For example, compare the software that runs in a traditional data center to a new application with a cloud operating model. An application built in the last 20 years relies heavily on its infrastructure to help it function. But that’s changed with cloud native; the infrastructure no longer specifies, “highest availability.” Cloud native applications add abstractions that separate themselves from a reliance on infrastructure below them. They may even determine that specific infrastructure services are counter-productive to providing availability.
To move forward, we need what may be thought of as “a contract with cloud native services:” a set of industry agreements and interfaces that ensure interoperability. Then the assurance of interoperability through base-line agreements will enable us to spend less time contemplating the impact of cloud, building DevOps glue, and allow us to do more – much more. We all prefer to spend our time on better-quality problems. For example, if you don’t need to be concerned about how storage is being consumed, you can focus more on how the application makes use of storage.
As with other rapidly-evolving technologies, container storage interfaces need to identify with the goals we agree upon while remaining general enough to address today’s pragmatic concerns. We can take advantage of the loosely-defined container ecosystem and build on that foundation. That’s a strength that comes from the open source community’s understanding of iterative approaches that add value gradually – with every step being desired and appreciated.
In other words: We want to work towards simple ecosystem agreements that enable better applications and push the entire software industry to use cloud native services more consistently. It’s one reason why we’re participating in and relying on the Cloud Native Computing Foundation as an independent organization making thoughtful and autonomous decisions ensuring the ecosystem’s sustainability.