Why consider CNCF sandbox projects?
I am an advocate for finding solutions before writing code. I love to code. There is nothing more tantalizing to a software engineer than the prospect of building something, anything, from scratch. The siren’s call of invention is so deafening that it is easy to overlook the many off the shelf solutions available. That’s why I like to keep an eye on things like the CNCF sandbox. Here are a few CNCF sandbox projects currently on my radar. You never know if someone might already be solving your problem.
OpenCost is a tool or monitoring the cost of Kubernetes. In a world of horizontal pod autoscalers and autoscaling node groups it is important to be able to monitor and perhaps even regulate spend automatically. The obvious possibility of OpenCost is integrating with Prometheus and using Prometheus to create cost alerts. Another possibility I see is integrating OpenCost metrics with custom metrics for horizontal pod autoscalers in Kubernetes as a way to set limits on spend when scaling automatically. The
autoscaling/v2 API supports scaling based on multiple metrics. By leveraging custom metrics constraints on scaling can be set based on data from OpenCost.
kubescape is a security platform for Kubernetes. It integrates with IDEs, CI/CD workflows, and Kubernetes to cover the complete Kubernetes app development lifecycle. Under the hood kubescape uses Open Policy Agent with a set of best practices Rego polices, demonstrating the power of OPA and Rego for managing security and compliance. By integrating across the development lifecycle, kubescape helps shorten development cycles by getting feedback to the developer as early as possible. It is much better to know your code won’t deploy while developing in the IDE than finding out when it is time to deploy.
The local development workflow is an ever-troublesome invariant when developing applications for Kubernetes. Local development is easy enough as long as everything can be developed in isolation with perhaps a database and caching layer. Tools like docker-compose easily handle this use-case. Things start to get a lot more difficult when you have multiple applications in the mix that need to talk to each other and come with their own unique stacks. At certain point running everything locally becomes impractical or impossible. Nocalhost aims to make developing cloud apps in the cloud easy and collaborative by embracing the idea that cloud apps should developed in the cloud. Nocalhost integrates with the IDE to make this easy.
Not too long ago the topic of schema migrations came up in the context of rolling updates and multi-replica Kubernetes deployments and I am embarrassed to say that I really didn’t have much in the way of a good answer. Dealing with database schemas is a constant thorn in the side of cloud native innovation. For example, how do you deal with schema migrations in the context of a serverless deployment such as a Knative function? SchemaHero makes deploying schema migrations for popular RDMS declarative and decouples migrations from the application code. By making migrations declarative, developers can focus on what the schema is rather than how to make it so. This embraces the GitOps principals for software delivery.
I see the CNCF sandbox as a barometer for the demands of the cloud native ecosystem. These projects are on the cutting edge of solving the problems that everyone playing in this space faces. They are the front-runners in creating a common cloud framework.