Building the Ideal Kubernetes Distro for SaaS: Part 2
In the first article of this two-part series, we took a critical look at the Kubernetes distribution-for-SaaS landscape. While the InfluxData team proves that it’s possible to use Kubernetes as a cloud abstraction layer at scale (as we did for InfluxDB Cloud), the fact remains that the API wasn’t designed for this particular use case. That got me thinking—what would a “dream” Kubernetes distribution framework look like?
In this piece, we’ll look at a handful of sensible defaults under this “dream” scenario and how they could each impact SaaS providers. I’ll also name a handful of services whose creators are Kubernetes users to the core, each of which could serve as a crucial building block in the Kubernetes distribution model we all deserve.
Just to reset the stage a bit, the “we” in this scenario are operators of multi-tenant SaaS products that run SaaS on multiple clouds and in multiple regions. My experience with InfluxDB Cloud offers a unique perspective; the platform uses Kubernetes as its core orchestration layer across 10 cloud clusters worldwide—spanning AWS, Google Cloud and Microsoft Azure—with a single codebase.
Creating Sensible Defaults
Kubernetes is extremely flexible. There are numerous tools you can mix and match as you please, and these give users varying levels of value depending on their specific needs and use cases. But there is also inherent value in choosing a set of defaults and making sure they both work well together and support those of us on this mission. Here are some of the defaults I’d like to see:
- SLOs. When it comes to service level objectives (SLOs), the problem isn’t that there’s not enough data—it’s making sense of the monitoring data that you already have. Teams can automate this as it relates to SLOs and take actions in context. For example, you may need to invest more in availability at a given point in time while other times may present a better opportunity to work on rapidly deploying new features.
- On-premises parameters. It’s a common refrain within the industry: “We’re in banking [or some other highly regulated sector] and we can’t run anything outside of our own infrastructure.” There’s no need to reinvent the wheel for the customers who need it. Find a vendor with a Kubernetes installer, hosted services for things like release channels and other basic services as appropriate.
- Marketplace integration. You’ll also most likely run into customers who can’t pay you directly. For various reasons, they may need to use cloud credits instead. With this in mind, look for a service that provides an abstraction layer across all of the cloud marketplaces. In my dream Kubernetes distribution scenario, there would be a default service that provides the tools necessary for typical cloud marketplace activities such as billing and onboarding and offboarding customers.
- Logs and metrics. Organizations need a way to make sense of their log data in real-time while, ideally, saving time and money on log management. It’s also preferable if such a system extracts metrics it can then use to analyze the health of your system and detect anomalies based on log data.
- The Hard Part: CI/CD. There are tons of vendors that handle various parts of CI/CD, but you have to write “glue code” to effectively run it all together. The dream scenario is a hosted solution that allows us to write code so another company can watch your Git repositories and do CI/CD for you. I’ve been told that it has to be this way because different teams are so idiosyncratic that there can’t be a one-size-fits-all solution—but I’m not sure I agree with that. I’d like to see the ability to install a version of Kubernetes with the hooks to use a hosted CI/CD solution. For developers, the idea is if we assume we’re going to do CI/CD in a certain way we can assume the developer experience will play out in a certain way, as well.
The Dream Distro in Action
While this perfect Kubernetes distribution scenario may still be a bit of a dream, there are many services available that allow organizations to piece together a framework that produces the desired results. There are, of course, many solutions on the market and this is by no means an exhaustive list, but here are a handful I’ve come to respect and trust over the years:
- SLOs: Nobl9. Creating a distribution that assumes you’re using Noble9 gives you a universal set of defaults across your clusters, allowing you to settle on a standard of metrics collections, easily install Nobl9 agents and configure clusters across the board.
- On-premises: Replicated. This service deploys Kubernetes applications on-premises, meaning you don’t need to reinvent a strategic way of creating those on-premises solutions for customers who demand them.
- Marketplace integration: Tackle.io. This service isn’t necessarily Kubernetes-specific, but its single centralized API lets businesses automate marketplace workflows so developers can focus on more proprietary and valuable work.
- Logs and metrics: Edge Delta. The beauty of this service is that it constantly looks at your logs. If it detects an anomaly, it zooms in for a high-resolution view of your log data at the exact time in question. Log management is one of those tedious-but-necessary aspects of the job, but services like this help make it much more efficient.
- CI/CD. Again, there is no one-size-fits-all CI/CD solution for Kubernetes distribution—at least not that I’ve found—so the current landscape is more of a “choose your own adventure.” Services like CircleCI, Weaveworks and many others are useful with particular aspects of CI/CD, but I’d still like to see a more uniform and standardized option for developers.
Ultimately, now that we’re in this Kubernetes world and we ourselves are a community of SaaS service providers, we should adopt what I call a “SaaS mindset.” We should all default to using other SaaS service providers (when we can) so we can focus on the product or service that makes us unique to the market. Until the Kubernetes distribution model of our dreams becomes a reality, taking this SaaS mindset will help your teams shift their focus away from tasks that can be standardized and automated to those that create actual value for your organization.