That's correct that the entire engineering team is on the platform. I appreciate the feedback and perhaps the post didn't message this well.
There are many value-adds that developers use from the platform beyond deployments like a monitoring/status dashboards, access control, and preview environments.
Many of our customers use our platform as a DevOps platform. We've seen many engineering teams hire 1 DevOps engineer per 10 software engineers (this varies based on industry and tech complexity). We chose to price the offering based on the value we're driving to each developer.
We have seen the same with our customers and our own experiences -- most teams "graduate" from a PaaS because you're locked into a set of proprietary technologies and hosting.
When they do get large enough, they leave to build their own infrastructure. Unfortunately, they have to rebuild much of the automation and user experience that a PaaS provided for them.
It's fair to call us a PaaS given our launch, but our vision is to give teams automation and collaboration in their own tooling and workflows.
As other replies have mentioned, Terraform is challenging to create a smooth experience. We have spent many cycles working on smooth orchestration so that it's fast and intuitive. Our primary motivation was to avoid hiding infrastructure behind proprietary technology.
We have support for other IaC tools on our roadmap so that each team can use what is comfortable.
We appreciate the honesty, but more importantly, we appreciate the willingness to try another one out. We welcome your feedback to see where we're doing things right or wrong.
This is something we support as well. You're correct that most of our documentation (including quickstarts) focuses primarily on web-facing apps.
Our current modules support running Python jobs using Fargate/ECS and Lambda (using Docker containers or packaged zip files).
Today, it is possible to pause workloads by destroying the app (nullstone down --app=<app>). Obviously, that's not ideal and we do have plans to support pausing workloads to reduce costs.
Sorry for the confusion. It's dangerous for junior developers to interact directly with cloud providers. Our motivation is to provide guard rails for developers of all skill levels to build and run their infrastructure without exposing their organization to risk.
Here are some dangers we've seen from our customers:
- Misconfigurations that result in no backups, disabled encryption, etc.
- Resources accidentally configured with Internet access
- Exposing internal secrets or credentials in source code
- Misconfiguration of IaC that results in destruction of databases
I'm not claiming that we have eliminated these dangers. Instead, our goal is to provide a platform for software teams to codify their security and compliance practices so that all developers on their team can avoid these dangers.
Kubernetes is a powerful platform. It has become a standard language for building and operating cloud/on-prem infrastructures. It will be the end point for how infrastructure is orchestrated and configured.
However, Kubernetes is more a primitive for infrastructure rather than a tool to build automation workflows for software teams. Our focus is to complement teams that may or may not choose Kubernetes.
I do think that AI is going to have a massive impact on development including cloud infrastructure; however, we rarely see junior developers setting up cloud infrastructure because it is dangerous.
Our motivation is to make the cloud easier for all skill levels. In many organizations, this usually requires platform engineers or lead engineers that determine what works best with their technical strategy.
Our goal is to (yes, remove the arcaneness), but also remove the tedium and distraction from development.
Thanks!
We are not affected by the license changes. We are a tech partner with Hashicorp which requires us to not be competitors. If Hashicorp ever changes this position, we have plans on our roadmap to support other IaC tooling.
This is great. We faced similar challenges as our team grew.
Since our organization was already on MS Teams, we designated one person on each team to transcribe each standup into a channel on Teams.
The feedback I've seen on this thread about taking too much effort for a dev each day is odd to me. Just as it's not wise to dive head-first into code before understanding problem, I think spending 5-10 minutes planning out your day is cheap; I'm already paying it, I'll just paste that into Spinach.
There are many value-adds that developers use from the platform beyond deployments like a monitoring/status dashboards, access control, and preview environments.
Many of our customers use our platform as a DevOps platform. We've seen many engineering teams hire 1 DevOps engineer per 10 software engineers (this varies based on industry and tech complexity). We chose to price the offering based on the value we're driving to each developer.