4 ms·

> What about observability? Logging, monitoring, alerting? Security infrastructure, everything from setting up IAM with better security for both human and machi

> 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".

solatic 5y ago
> 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).
- DangitBobby 5y ago
  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.

solatic 5y ago

> 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).

DangitBobby 5y ago
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.