What about observability? Logging, monitoring, alerting? Security infrastructure, everything from setting up IAM with better security for both human and machine users, to vulnerability scanning, WAF, anti-DDoS, TLS certificates, DNS, edge caching/CDN...? Backups? Separate environments for development, staging, production, that stay consistent?
Look, your landing page example is cute, but it's not fully production ready. And by the time you finish adding everything to make it fully production ready, you'll be back up to the 600 lines of configuration that you're currently demonizing.
Look, this shit is hard. I get it. I recently got mindfucked by the intricacies of single table design in DynamoDB, and the sheer complexity of doing that correctly, for the sole benefit of hiring fewer $200k/year engineers, plus the headache of trying to hire the right ones, plus their post-hire management overhead. And that's barely DevOps adjacent!
I'm not convinced that you can truly remove the complexity. The more features you throw on your PaaS, the more configuration options you expose. Eventually, the configuration for your PaaS gets complicated enough that you hire an engineer who knows the PaaS very well and they become your DevOps engineer. Then you realize that you didn't actually solve your problem, you just made it harder, because the PaaS never exposes everything you actually need, so either you need to wait for the PaaS to implement it, or you start to migrate off it.
> What about observability? Logging, monitoring, alerting? Security infrastructure, everything from setting up IAM with better security for both human and machine users, to vulnerability scanning, WAF, anti-DDoS, TLS certificates, DNS, edge caching/CDN...? Backups? Separate environments for development, staging, production, that stay consistent?
Stacktape does support 90% of these already.
> but it's not fully production ready
Yes, I agree it's not production ready for every use-case out there. But I truly believe it is for a majority of them.
I also believe that it's more production-ready than an average application that goes into production.
> Then you realize that you didn't actually solve your problem, you just made it harder, because the PaaS never exposes everything you actually need.
Stacktape is not exactly a "PaaS". Stacktape is a cloud development framework. It was designed to be flexible and extensible. Everything is "exposed" by default. It works on top of AWS Cloudformation. You can extend the CF template using native AWS Cloudformation, or override anything that Stacktape generates.
So basically, Stacktape gets you to production very fast, but isn't an obstacle when you need to scale and go "lower level".
> Everything is "exposed" by default. It works on top of AWS Cloudformation. You can extend the CF template using native AWS Cloudformation, or override anything that Stacktape generates.
> So basically, Stacktape gets you to production very fast, but isn't an obstacle when you need to scale and go "lower level".
I get what you're saying, but please look a little closer at your messaging and your value proposition.
Your value proposition is "with Stacktape, you don't need to hire a DevOps engineer, we charge you not even 10% the cost of a DevOps engineer, therefore by buying Stacktape you will save money." But, apparently, eventually your customer might/will grow out of what Stacktape can offer, in which case your customer will hire a DevOps engineer anyway, and well at least they can take comfort that there won't be any vendor lock-in.
Which begs the question - how is a customer supposed to know when that point in time could or would be? You're not promising that they'll never need a DevOps engineer, because you'll help them migrate, and you're not promising the benefits of a PaaS, including full responsibility for the resources you create, because ultimately they just belong to the customer on their account and it's all their responsibility.
I don't think telling people "we help you spin up lots of stuff that you don't understand but you'll be responsible for it anyway if something goes wrong" is a compelling message. People who look at your pricing page, they're not going to compare your price to the price of a PaaS or a DevOps engineer, because you're not providing the value of a PaaS or a DevOps engineer, i.e. someone with the experience to take responsibility and fix things when and if they go wrong. Instead, they will compare it to the actual value they are getting, which is "is it worth it to me to pay $45/month to read these docs and maintain this shorter YAML, than it is to read these other docs and maintain this admittedly longer YAML?" Maybe there is a market like that, and if so, then I wish you the best of luck (I'm a DevOps engineer so I already understand that longer YAML so your solution doesn't give me value).
I don't understand the problem here. You can manage the application stack until you can't anymore, just like every tool that simplifies the stack for you. This tool lowers the barrier to get something out there. DevOps engineers are not threatened in the least by this, it just reduces the amount of toil for people who have a hard time with a minimal deployment.
Look, your landing page example is cute, but it's not fully production ready. And by the time you finish adding everything to make it fully production ready, you'll be back up to the 600 lines of configuration that you're currently demonizing.
Look, this shit is hard. I get it. I recently got mindfucked by the intricacies of single table design in DynamoDB, and the sheer complexity of doing that correctly, for the sole benefit of hiring fewer $200k/year engineers, plus the headache of trying to hire the right ones, plus their post-hire management overhead. And that's barely DevOps adjacent!
I'm not convinced that you can truly remove the complexity. The more features you throw on your PaaS, the more configuration options you expose. Eventually, the configuration for your PaaS gets complicated enough that you hire an engineer who knows the PaaS very well and they become your DevOps engineer. Then you realize that you didn't actually solve your problem, you just made it harder, because the PaaS never exposes everything you actually need, so either you need to wait for the PaaS to implement it, or you start to migrate off it.