The project makes a bet that Kubernetes is going to become a default way to consume computing power of cloud providers. But vanilla installation of Kubernetes is barely useable, especially when you know how powerful it can be with addons for developer productivity. DevStand is gonna give usual developers access to packed Kubernetes avoiding sophistication.
20% of efforts should give 80% of value. Sure there will be those who need a custom setup, but the majority just want to deploy their code. And if the default interface to the could is Kubernetes manifests
- therefore - they need a simple way to deploy to Kubernetes. The custom guys can switch to another provider (e.g. OpenShift, very expensive) or make their own platform (ridiculously expensive and time consuming).
Target audience - single developers and small teams. No Kubernetes knowledge required. Can be used within large enterprises when DevOps team provides their own abstractions, and usual developers can still use DevStand to
construct their infrastructure of these made-by-devops-guys abstractions. Focus on simplicity.
Contact the developer directly via email email@example.com
Cloud solution integrated with GitHub/GitLab and major cloud providers (Amazon, Microsoft, Google) and niche providers loved by individual developers (DigitalOcean, Linode) To automate push-to-deploy workflow for developers. This move is to actually validate applicability of the abstractions model to real-world use-cases. Because being able to quickly launch preview environments during the development process is the key advantage of switching to Kubernetes (if you do not have other reasons and just willing to know more about Kubernetes). Therefore to make it automated (and easy) - there have to exist a cloud watcher who watches your changes and deploy automatically you new code.
Broaden the landscape of custom abstractions/libraries. Primarily focused on DevOps teams inside large companies who are willing to make their existing Kubernetes computing solutions to be simpler for their internal developers. Basically this is Team Topologies and Platform teams. Easier onboarding for developers is crucial since demand for developers is so huge recently. Kinda HR-related move. This move is to explore our potential and opportunities in direction of on-prem offering and deep B2B operations. Initial iteration on our own managed hosted Kubernetes offering. Being focused on developer workflow - instances of apps that are not utilized by any person (not accessed by anybody, e.g during nights, weekends and holidays). It is possible to safely shut down instances to save computing power.
It is only possible if the deployment practices/tools are quite restricted, and this is fine with DevStand. When some instances are shut down in Americas, the computing power can be re-prioritised for Asia (the opposite side of the planet). That can allow keep reasonably low prices while devoting more computing power to users. Where to spend that extra computing budget? – In additional tooling for Kubernetes: Logging, Tracing, Metrics, in-cluster development, reliable backups for persistent storage, etc... For a price of a decent VM we can offer a top-notch development experience and out-of-the box without needing a DevOps professional hired. This is a move to build a sustainable and significant revenue to pay for the amount of developers required to keep up with the industry. Yet to build such a cloud cannot be built by a sole developer, so external investments are required to make this move possible.
Contact the developer directly via email: firstname.lastname@example.org