In searching for inspiration for this post, I decided to bottom out an old suspicion of mine. After a brief but brave foray into the meme rabbit holes of the internet, I can confirm that indeed, "Everything-as-a-Service" remains a remarkably under-utilized as a buzzword. Something to strive for, I guess.
A shortage of memes might be behind the proliferation of the "-aaS" suffix in various areas. For example, let's talk about Containers-as-a-Service, or "CaaS". If containers are infrastructure, why do we need a new acronym, rather than using IaaS? And if your answer is "because IaaS is for VMs", then why don't we have VMaaS for virtual machines, BMaaS for bare metal, ARMaaS for ARM servers, and so forth?
So, is it just marketing hype, of the same variety that promotes "serverless" when most enterprise workloads are not even on the public cloud (yet), and those running on containers in production are just starting to emerge?
Or is one reason that actually, containers are different? It's great to have these ephemeral little Docker things, but to be usable they need orchestration, and tooling on top that is built-for-purpose, bridges Devs and Ops, and considers the architectural differences between the world of apps until now and microservices. And in this case, what is the scope of a CaaS offering?
For any cloud provider that isn't in the top-5 bracket, this isn't necessarily an amusing hypothetical question. As clouds like AWS and GCP add services and capabilities around containers, and expand into verticals and regions that were once strongholds for these regional providers, this becomes existential.
So let's ask again, more accurately: what could CaaS mean, as an effective competitive tool, for your medium-sized cloud provider? The annoyingly obvious answer is, "it depends" on the provider's overall competitive strategy and how containers fit into it. I see broadly two approaches.
For some, just having a UI on Kubernetes, or a minimal integration with a variety of open source services, would cover the urgent and visible need. This approach will likely run into problems once your usage goes from an experiment, to production workloads at scale. There's a reason why Google, the originator of Kubernetes, has a managed offering—they understand the complexity! The top clouds will no doubt be waiting patiently for these scenarios to unfold, taking advantage of the lack of customer added value of this approach.
For other providers, this will be about finding a way to emphasize their USPs. For example:
Features that support specific use cases, such as compliance with financial or data sovereignty regulation (this is where I get to namedrop GDPR): e.g., observability, security permissions and firewall management.
Functionality that supports/encourages a hybrid environment (multi-tenant/single-tenant/on-prem and server/VM/container): e.g., hosted, dedicated and on-prem installations.
Capabilities that don't just match that of GKE/ACS/ECS, but look to go beyond them.
This is a more thoughtful approach to product strategy in general, and as such, will likely require long-term thinking and commitment from the provider. It will also probably deliver much more value to you, the enterprise user.
Cloud 66 has been running its own stack on containers in production since 2012, and since then we (pragmatically) swapped out our own orchestration engine for Kubernetes. We come from the cloud-native production angle, and have run into many of the problems most enterprises haven't yet considered. Most importantly for providers, working with partners and providers is core to our strategy.