Show HN: Stacktape – Full power of AWS with Heroku-like experience(stacktape.com)
stacktape.com
Show HN: Stacktape – Full power of AWS with Heroku-like experience
https://www.stacktape.com/
84 comments
I wish you luck on your journey with this. We were in the similar space as a YC S20 company - trying to create a Heroku-like experience on AWS. There's been plenty other attempts as well.[1]
After working in this space for a couple years, I realized that unfortunately the market just doesn't exist. Small enough teams will typically hack their way through building an MVP and early versions. They don't need/want the complexity of kubernetes/terraform, most literally run their MVP on a couple of instances. On the other side, once you get big enough, you hire dedicated people to start solving these problems. The middle market in between the two is very small and you most likely will be beat by the services already built into AWS such as Amplify.
[1] https://github.com/debarshibasak/awesome-paas
After working in this space for a couple years, I realized that unfortunately the market just doesn't exist. Small enough teams will typically hack their way through building an MVP and early versions. They don't need/want the complexity of kubernetes/terraform, most literally run their MVP on a couple of instances. On the other side, once you get big enough, you hire dedicated people to start solving these problems. The middle market in between the two is very small and you most likely will be beat by the services already built into AWS such as Amplify.
[1] https://github.com/debarshibasak/awesome-paas
Reading this made me sad. I’ve wondered for a long time why no one ever bothered to build a Heroku for AWS.
My main complaint as an application developer these last few years is the amount of time I’ve had to spend wrangling infrastructure.
My main complaint as an application developer these last few years is the amount of time I’ve had to spend wrangling infrastructure.
I think the issue is cost. Heroku, which is itself on top
Of AWS, is expensive exactly because it has to charge a significant premium over AWS to work (although it is still overpriced). That’s where Render.com and Fly will succeed, by running on their own hardware they can save significantly over running on AWS. I don’t think it’s possible to build a PAAS on top of AWS, the OP with the I/PAAC would though as they aren’t trying to add a business service layer.
> “why no one ever bothered to build a Heroku for AWS”
You realize Heroku has always run on AWS. Heroku is the “Heroku for AWS”.
You realize Heroku has always run on AWS. Heroku is the “Heroku for AWS”.
Yup, fully aware.
Should’ve said “Heroku-like” instead of “Heroku for AWS”.
Should’ve said “Heroku-like” instead of “Heroku for AWS”.
Hello, thanks for a very valuable opinion.
I'm just now starting to realize the mistake I've made when coming up with the "Heroku-like experience" headline.
I meant it's similarly easy, not that it's PaaS.
Stacktape is a cloud development framework. It runs on the developer's machine (or on a CI/CD server). It's similar to Serverless framework, except it supports way more resources (containers, SQL databases, MongoDb Atlas clusters, Redis, Kafka, etc). And it also has some additional useful features on top.
> once you get big enough, you hire dedicated people
Stacktape is for these teams. Thanks to Stacktape, they can delay the hire by a year or 2. And they also need to hire fewer of them.
I'm just now starting to realize the mistake I've made when coming up with the "Heroku-like experience" headline.
I meant it's similarly easy, not that it's PaaS.
Stacktape is a cloud development framework. It runs on the developer's machine (or on a CI/CD server). It's similar to Serverless framework, except it supports way more resources (containers, SQL databases, MongoDb Atlas clusters, Redis, Kafka, etc). And it also has some additional useful features on top.
> once you get big enough, you hire dedicated people
Stacktape is for these teams. Thanks to Stacktape, they can delay the hire by a year or 2. And they also need to hire fewer of them.
I think "heroku-like" is a good generative metaphor. As for the market existing or not I think there are way more variables at play than that previous comment seems to account for and there's so much room in the cloud solutions market as it continues to grow. Also I could always see an exit where Amazon see's traction and acquires Stacktape to compliment it's existing solutions and fend off other "no dev-ops" solutions.
Good luck, product looks awesome!
Good luck, product looks awesome!
Agreed with these points. As someone who was using Serverless, and then moved onto using the CDK prolifically, I found that I could ship a single CDK setup via a shared package as easy as we could sharing Serverless config files. But at the end of the day, CloudFormation is a royal PITA and the weakness of both wrappers.
As an aside, I do like how Terraform manages things, but have never enjoyed their configuration language. CDK for Terraform is something I'm watching closely.
As an aside, I do like how Terraform manages things, but have never enjoyed their configuration language. CDK for Terraform is something I'm watching closely.
Also, stuff like Google Cloud Run and App Engine is pretty damn easy to use. I hate DevOps and neither of those products give me headaches. Same with spinning up Postgres on GCP, it's a few clicks.
https://cloud.google.com/run
https://cloud.google.com/run
I absolutely agree with you as well as disagree with you. There is market, few older players like platform.sh has been serving them. If you analyse their customer base, it is mostly agencies. The market is very very small, super saturated and competitive.
[deleted]
As someone that is happy paying 5-10x more for heroku, you can easily get me (and people like me) if you focus on onboarding.
Automatically generate the first yaml/config file from looking at my codebase? Heroku-like CLI that generates/updates the YAML file? Heroku gives me "redis" without me needing to learn anything about AWS/YAML-config shit.
One-Click starter file for 10-most popular apps...
- rails/postgres/redis
- create-react-app
- static site generator
- node/serverless
Automatically generate the first yaml/config file from looking at my codebase? Heroku-like CLI that generates/updates the YAML file? Heroku gives me "redis" without me needing to learn anything about AWS/YAML-config shit.
One-Click starter file for 10-most popular apps...
- rails/postgres/redis
- create-react-app
- static site generator
- node/serverless
> Automatically generate the first yaml/config file from looking at my codebase? Heroku-like CLI that generates/updates the YAML file? Heroku gives me "redis" without me needing to learn anything about AWS/YAML-config shit.
I will think about it. I do agree that we could do more here. I understand that you don't like writing YAML, but to be honest, it's not that complicated, especially if you use our VS code extension (it autocompletes and suggest all the properties, validates the config file, and give you on-hover documentation). Also, it's just few lines in most cases.
> One-Click starter file for 10-most popular apps...
We do have starters for Hello, we do have starters for: - (Typescript) Express.js API with Postgres - (Typescript) Lambda API with DynamoDb - (Typescript) Lambda API with MongoDb - (Typescript) Lambda API with MySQL - (Python) Flask API with Postgres - (Java) Spring Boot API with Postgres - (Ruby) Rails API with Postgres - Vite.js website (React/Vue/...) - this is a (better) CRA alternative - Gatsby.js website - Next.js website
We'll add more in the future. Redis will be the next on the list.
I will think about it. I do agree that we could do more here. I understand that you don't like writing YAML, but to be honest, it's not that complicated, especially if you use our VS code extension (it autocompletes and suggest all the properties, validates the config file, and give you on-hover documentation). Also, it's just few lines in most cases.
> One-Click starter file for 10-most popular apps...
We do have starters for Hello, we do have starters for: - (Typescript) Express.js API with Postgres - (Typescript) Lambda API with DynamoDb - (Typescript) Lambda API with MongoDb - (Typescript) Lambda API with MySQL - (Python) Flask API with Postgres - (Java) Spring Boot API with Postgres - (Ruby) Rails API with Postgres - Vite.js website (React/Vue/...) - this is a (better) CRA alternative - Gatsby.js website - Next.js website
We'll add more in the future. Redis will be the next on the list.
From pg's Do Things That Don't Scale (http://paulgraham.com/ds.html)
"Stripe is one of the most successful startups we've funded, and the problem they solved was an urgent one. If anyone could have sat back and waited for users, it was Stripe. But in fact they're famous within YC for aggressive early user acquisition.
..."At YC we use the term "Collison installation" for the technique they invented. More diffident founders ask "Will you try our beta?" and if the answer is yes, they say "Great, we'll send you a link." But the Collison brothers weren't going to wait. When anyone agreed to try Stripe they'd say "Right then, give me your laptop" and set them up on the spot."
Might be worth focussing on onboarding.
"Stripe is one of the most successful startups we've funded, and the problem they solved was an urgent one. If anyone could have sat back and waited for users, it was Stripe. But in fact they're famous within YC for aggressive early user acquisition.
..."At YC we use the term "Collison installation" for the technique they invented. More diffident founders ask "Will you try our beta?" and if the answer is yes, they say "Great, we'll send you a link." But the Collison brothers weren't going to wait. When anyone agreed to try Stripe they'd say "Right then, give me your laptop" and set them up on the spot."
Might be worth focussing on onboarding.
Idk man, I agree with OP. Writing YAML configs is one of my least favorite things to do. Might be worth polling more people
To counter this, it is so easy to write YAML I don't get the fuss. And this coming from someone who took a long time to learn Python.
Perhaps the issue is not the writing of the YAML, but the need to have a good understanding of all the resources/primatives in order to get things glued together. Many application developers just want to focus on their application, and not on all the nuances of subnets, security groups, autoscaling thresholds etc.
> Perhaps the issue is not the writing of the YAML, but the need to have a good understanding of all the resources/primatives in order to get things glued together.
This and the fear of making a mistake with the most important configuration file of the application.
OP this is a clear opporutinty for Stacktape.
This and the fear of making a mistake with the most important configuration file of the application.
OP this is a clear opporutinty for Stacktape.
I agree. A lot of people were asking about this. We will do our best to help.
First thing we want to do is an interactive CLI "tour" that auto-detects the project type, asks a few basic questions, and generates the YAML for you. Should be released in ~1-2 weeks.
Second thing we are thinking about is a visual GUI. Will be harder, but doable. We can integrate it into the local development studio.
First thing we want to do is an interactive CLI "tour" that auto-detects the project type, asks a few basic questions, and generates the YAML for you. Should be released in ~1-2 weeks.
Second thing we are thinking about is a visual GUI. Will be harder, but doable. We can integrate it into the local development studio.
I haven't looked at what your yaml is looking like, but I encourage you to consider having sensible defaults for most resource types (including their existence), and provide a way for Devs to go off the rails if they need to. Sensible defaults can get simpler use cases 95-100% of the way there, relieving the burden for app Devs to have good understanding of everything that is going on under the hood.
This is exactly what Stacktape does.
For example, the "HTTP API Gateway" resources has 0 required properties you need to configure.
We have sensible defaults for everything. We also try to automatically infer as many things as possible.
For example, the "HTTP API Gateway" resources has 0 required properties you need to configure.
We have sensible defaults for everything. We also try to automatically infer as many things as possible.
> I understand that you don't like writing YAML, but to be honest, it's not that complicated, especially if you use our VS code extension (it autocompletes and suggest all the properties, validates the config file, and give you on-hover documentation).
I think you've missed the point entirely. Just because _you_ do not find it complicated, doesnt mean others wont. This comes across dismissive, people dont want to use your flavor of YAML and have to install a VSCode extension to do so effectively. This alienates a bunch of people that dont use VSCode, and who would rather utilize a safely typed library that provides autocomplete out of the box regardless of which editor is being used. IaaC/S should move on from thousand long lined YAML files that shoe-horn in extensibility and composition in favor of using tools (programming languages) that support this out of the box. These libraries could output YAML files for the sake of compatibility.
I think you've missed the point entirely. Just because _you_ do not find it complicated, doesnt mean others wont. This comes across dismissive, people dont want to use your flavor of YAML and have to install a VSCode extension to do so effectively. This alienates a bunch of people that dont use VSCode, and who would rather utilize a safely typed library that provides autocomplete out of the box regardless of which editor is being used. IaaC/S should move on from thousand long lined YAML files that shoe-horn in extensibility and composition in favor of using tools (programming languages) that support this out of the box. These libraries could output YAML files for the sake of compatibility.
You just described render.com
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.
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".
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 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.
Looks like a great product! I am also working on a similar product (https://cdevframework.io) in the same space, but I am focusing only on Python at the moment.
Are you using a custom IaaC management tool for the deployments, or is it compiling down to something like Aws Cloudformation or Terraform Providers?
Are you using a custom IaaC management tool for the deployments, or is it compiling down to something like Aws Cloudformation or Terraform Providers?
Stacktape is built on top of AWS Cloudformation.
We also use CF infrastructure modules, CF custom resources and aws-sdk for certain features and integration.
We're also trying to smooth out some of the rough edges of Cloudformation (for example translating some of the crypting CF errors into a more developer-friendly errors).
Also, since CF can be pretty slow in some cases, we have a "fast deploy" mode that avoids CF and deploys (lambda functions and containers) way faster.
We also use CF infrastructure modules, CF custom resources and aws-sdk for certain features and integration.
We're also trying to smooth out some of the rough edges of Cloudformation (for example translating some of the crypting CF errors into a more developer-friendly errors).
Also, since CF can be pretty slow in some cases, we have a "fast deploy" mode that avoids CF and deploys (lambda functions and containers) way faster.
Appreciate it's just an MVP but I think there's a good niche you can go down. Big Data on AWS is such a pain to set-up (Glue, EMR, RedShift, LakeFormation), with IAM policies and roles a simple data pipeline is around 500 lines of YAML. Would be good if you could add native support for that, so say you have some CSV in S3 you want to convert to parquet, drop null fields, and then make shareable with another AWS account. Would solve a massive problem for me
Interesting idea. We will think about it and see what we can do.
It's not the most requested feature, but I do agree that is solves a huge paint point.
Also, maybe some of you big data use-cases could be handled by a custom batch job? https://docs.stacktape.com/resources/batch-jobs/
It's not the most requested feature, but I do agree that is solves a huge paint point.
Also, maybe some of you big data use-cases could be handled by a custom batch job? https://docs.stacktape.com/resources/batch-jobs/
That would be extremely useful. Apart from a CSV on S3, would be amazing if it handled DynamoDB to parquet in S3 for Athena querying.
I have been very active in the PaaS in your cloud model in past. My analysis leads to the fact that no one has really pulled off heroku in your cloud kind product in recent time. There has been big exits like pivotal et al. Mind you it was before the kubernetes era. Post kubernetes era PaaS in your cloud has become very commoditized. As a PaaS-in-your-cloud (piyc) model as product you are not only competing with other product in the category list here [1] but also the internal platform teams in bigger orgs. Also, it is one of the competitive segment in devtool, devops space. Also having spent over 2 year in the space, I think heroku on AWS is an anti-thesis. I wanted heroku like experience I would start with heroku and not AWS. What you dont know yet is that it is a leaky abstraction as you start acquiring customers and very slow onboarding experience. AWS also made an attempt to build a heroku like product called app runner, which is I think is not that successful.
[1]https://github.com/debarshibasak/awesome-paas
[1]https://github.com/debarshibasak/awesome-paas
Hello. Sure, I understand your point.
Stacktape is not exactly a "PaaS in your cloud".
Similarly to serverless framework, it works on the developer's machine (or on a CI/CD server). You don't have to "install it to your account".
Compared to those "PaaS in your cloud" tools, you don't lose control, flexibility or security. You have the the full power and control of AWS (and other 3rd party providers Stacktape supports).
Stacktape is also very transparent about what it does. You can extend it (using AWS CloudFormation) or modify the generated template.
Stacktape is not exactly a "PaaS in your cloud".
Similarly to serverless framework, it works on the developer's machine (or on a CI/CD server). You don't have to "install it to your account".
Compared to those "PaaS in your cloud" tools, you don't lose control, flexibility or security. You have the the full power and control of AWS (and other 3rd party providers Stacktape supports).
Stacktape is also very transparent about what it does. You can extend it (using AWS CloudFormation) or modify the generated template.
Why is everyone getting this as a PaaS?
It was immediately obvious to me it was a wrapper over AWS which abstracts the infra to a little higher level, simplifying the initial setup and maintenance.
It was immediately obvious to me it was a wrapper over AWS which abstracts the infra to a little higher level, simplifying the initial setup and maintenance.
Because Heroku is a PaaS and the headline said "with Heroku-like experience". If it's not a PaaS-like experience, then Heroku shouldn't be mentioned.
This looks pretty cool. My main question is: what would I have to do if I require an AWS component that is not supported by this tool? What is the developer experience of having to include a CloudFormation stack alongside this solution?
Asking because I see this as the #1 obstacle to getting buy-in in certain corporate environments. If we need a bit more flexibility, what does that look like?
Asking because I see this as the #1 obstacle to getting buy-in in certain corporate environments. If we need a bit more flexibility, what does that look like?
Hello. Our main design goal was to make Stacktape as easy to use as possible without sacrificing flexibility and control.
Stacktape is built on top of AWS CloudFormation (it also uses CF infrastructure modules, CF custom resources and aws sdk).
To modify the generated Cloudformation, you can use overrides: https://docs.stacktape.com/configuration/overrides/
You can also add any CF resources to the template: https://docs.stacktape.com/resources/cloudformation-resource...
Stacktape is built on top of AWS CloudFormation (it also uses CF infrastructure modules, CF custom resources and aws sdk).
To modify the generated Cloudformation, you can use overrides: https://docs.stacktape.com/configuration/overrides/
You can also add any CF resources to the template: https://docs.stacktape.com/resources/cloudformation-resource...
Thanks, this is exactly what I was looking to confirm!
Looks interesting but makes little sense for Rails stacks at least, Hatchbox is some kind of de facto, especially at 15 US per server.
I always think I should really look into automating deployment of Rails apps into a VPS. All these services seem to make really good money and I bet very few stacks beat the absolute hell that is to deploy Rails.
I always think I should really look into automating deployment of Rails apps into a VPS. All these services seem to make really good money and I bet very few stacks beat the absolute hell that is to deploy Rails.
The same issue I have with Render, I also have with this. If you have to create a config file for the environment, you aren't giving me a Heroku-like experience.
Give me an opinionated default that works well for most situations that I can then build on top of, configure further, etc..
Give me an opinionated default that works well for most situations that I can then build on top of, configure further, etc..
Render doesn’t require you to use a YAML file though.
I’ve deployed a couple of things there and never used the YAML files, just the UI.
I’ve deployed a couple of things there and never used the YAML files, just the UI.
They're definitely required for at least some scenarios, as a raw deploy didn't work for me, they're called out in the help docs, and I had a chat w/ their CEO on the topic a few weeks ago.
We are working on this.
In ~2 weeks, we'll release a version with an interactive CLI "tour" that can generate the "sane-defaults" configuration for your application.
Or you can start by copying the configuration from one of our quickstart tutorials.
In ~2 weeks, we'll release a version with an interactive CLI "tour" that can generate the "sane-defaults" configuration for your application.
Or you can start by copying the configuration from one of our quickstart tutorials.
[deleted]
Great idea! I'm curious how many options you're planning to cover. E.g. I couldn't find my use case of needing a Go Lambda triggered by a cron job that connects to an Aurora Postgres db.
Hello.
We do support Aurora postgres databases natively: https://docs.stacktape.com/resources/relational-databases/#a...
You can trigger lambda functions by a "cron" job (https://docs.stacktape.com/resources/lambda-functions/#sched...)
The only problem is that you need to package your lambda function yourself, as we currently don't natively support 0-config builds for Golang. (we can help you zip it, upload it to a deployment bucket, and effectively cache it tho).
We do support Aurora postgres databases natively: https://docs.stacktape.com/resources/relational-databases/#a...
You can trigger lambda functions by a "cron" job (https://docs.stacktape.com/resources/lambda-functions/#sched...)
The only problem is that you need to package your lambda function yourself, as we currently don't natively support 0-config builds for Golang. (we can help you zip it, upload it to a deployment bucket, and effectively cache it tho).
Oh I see, I'll take a look into it then. Thanks!
You may want to put a comparison to Cloud66 on your website, since it's a similar tool ("Heroku" hosted on your own cloud account) that's been around for years.
Thanks for the tip!
I think the comparisons on the site (e.g., vs. Heroku) are misleading. With Heroku (and true competitors such as Railway.app), I don't need to create configuration files for my app, for Redis and the PostgreSQL database I want to use, etc. I pick out some things from a UI, hook it up to my GitHub repo, and deploy (putting side the recent Heroku/GitHub OAuth security issues).
I'd be interested in seeing Stacktape vs. Qovery, which seems a bit more closely related.
I'd be interested in seeing Stacktape vs. Qovery, which seems a bit more closely related.
Sorry I’m sure that’s a great and wonderful product, but I’m so pissed off by yaml files that I can only hope one day humanity will figure out a better alternative to yaml and json for configuration files. I’m using a lot of yaml with the serverless framework and I hate that. And no, infrastructure as code like terraform or aws cdk always looked too limited or strangely designed
I'm not sure, if we, as a humanity, can do much here.
You have 2 choices:
- Use a "0-config" solution. You sacrifice control, efficiency and a lot more.
- You write configuration. In my opinion, the best language for configuration that humanity has come up with is YAML. Yes, it's not ideal, but it's expressive and (compared to alternatives), very readable. Compared to real programming languages, it lacks some of the goodies like autocompletion, validation, etc. Stacktape has a VScode extension for that. Also, you can write your config using Typescript: https://docs.stacktape.com/user-guides/writing-config-in-typ...
If you want a "quick-start" solution, we have a lot of those in our docs. Also, we are working on an interactive CLI "tour" that will "bootstrap" the configuration for you (with some sane defaults).
Edit: We are actively looking for a better and easier solution. If you have a suggestion, I will be very happy to discuss it.
You have 2 choices:
- Use a "0-config" solution. You sacrifice control, efficiency and a lot more.
- You write configuration. In my opinion, the best language for configuration that humanity has come up with is YAML. Yes, it's not ideal, but it's expressive and (compared to alternatives), very readable. Compared to real programming languages, it lacks some of the goodies like autocompletion, validation, etc. Stacktape has a VScode extension for that. Also, you can write your config using Typescript: https://docs.stacktape.com/user-guides/writing-config-in-typ...
If you want a "quick-start" solution, we have a lot of those in our docs. Also, we are working on an interactive CLI "tour" that will "bootstrap" the configuration for you (with some sane defaults).
Edit: We are actively looking for a better and easier solution. If you have a suggestion, I will be very happy to discuss it.
I quite like configuration written in Python. Clearly very different beast; but:
1. It’s not YAML (which I agree is dreadful after about 10 LOC)
2. You’re not fighting it. Want to condition the config on something? Just code that up, no need to introduce custom options etc.
3. A basic setup is barely more work than filling up a YAML file, it might even look like basically key=value kind of file.
4. Easier to structure. A big config file in YAML can only ever be a single large file. In Python/code, if you grow a big and complex config, you split it like you would with any regular code.
It is of course less safe to parse a config file than it is to read a YAML one (I guess?) but if you’re then running user code anyway then it probably is no additional security risk.
Clearly, can replace Python with any other language.
1. It’s not YAML (which I agree is dreadful after about 10 LOC)
2. You’re not fighting it. Want to condition the config on something? Just code that up, no need to introduce custom options etc.
3. A basic setup is barely more work than filling up a YAML file, it might even look like basically key=value kind of file.
4. Easier to structure. A big config file in YAML can only ever be a single large file. In Python/code, if you grow a big and complex config, you split it like you would with any regular code.
It is of course less safe to parse a config file than it is to read a YAML one (I guess?) but if you’re then running user code anyway then it probably is no additional security risk.
Clearly, can replace Python with any other language.
I've found Hashicorp's HCL to be excellent in comparison. It's open source and starting to be adopted by non hashi projects.
The weird design is the “construct programming model.” It’s pretty darn powerful but will always be a little weird because modeling “semi-free-floating objects in space” with a programming language that wants to do things one after the other will always have a bit of a mismatch. But classes work pretty well all things considered.
An example of a cdk that isn’t tied to a cloud would be https://cdk8s.io/docs/latest/getting-started
An example of a cdk that isn’t tied to a cloud would be https://cdk8s.io/docs/latest/getting-started
Congrats on launch!
How does this compare with Convox?
How does this compare with Convox?
Very cool, maybe making a visual builder for YAML haters could be and additional killer feature.
We were just thinking about something similar. We'll se what we can do.
Also, we're just now now working on an interactive CLI guide that auto-detects the project type, asks you a few questions, and generates the YAML for you.
Personally, I don't mind writing YAML at all, but we've heard a lot of people do. We'll do our best to make it easier.
Also, we're just now now working on an interactive CLI guide that auto-detects the project type, asks you a few questions, and generates the YAML for you.
Personally, I don't mind writing YAML at all, but we've heard a lot of people do. We'll do our best to make it easier.
Hey Matus, good job!
YAML validation and vscode extension is very cool. I hope it helps adoption.
YAML validation and vscode extension is very cool. I hope it helps adoption.
Years ago, there was a fantastic platform that did this called dotCloud. It worked great.
That company spun off its technology into Docker and then shut down dotCloud, which I have always been sad about.
Thanks for building this!
That company spun off its technology into Docker and then shut down dotCloud, which I have always been sad about.
Thanks for building this!
I'll be very happy if you give Stacktape a try and let me know if there's something you're missing (or something that dotCloud did better).
Will do.
One thing that we use a lot is Doppler for environment variable management, so some kind of official support for that would be hugely helpful.
We are able to sync from Doppler to AWS Secrets Manager, so maybe just Secrets Manager support would do it for us.
One thing that we use a lot is Doppler for environment variable management, so some kind of official support for that would be hugely helpful.
We are able to sync from Doppler to AWS Secrets Manager, so maybe just Secrets Manager support would do it for us.
Stacktape does support secrets https://docs.stacktape.com/resources/secrets/
You can easily inject them to a container environment variable (at deploy time). You can also fetch these secrets at runtime (using aws sdk).
Do you need anything else? I'll be happy to explore your use-case and see what we can do.
You can easily inject them to a container environment variable (at deploy time). You can also fetch these secrets at runtime (using aws sdk).
Do you need anything else? I'll be happy to explore your use-case and see what we can do.
I would just need to be able to point StackTape to a particular Secrets Manager store instead of setting secrets manually via CLI. Otherwise it looks good.
Not sure what to make of this. Given the active security incident, is "Heroku-like" really a recommendation?
But even past that, what does this give me beyond AWS CodePipelines? All comparisons on the site seem to be against "raw" AWS ("weeks to months" from code to deployment, really?).
But, hey, maybe I'm misunderstanding both this product and CodePipelines. Myself, I'm on Azure DevOps (which I guess is the same as "MS Azure" as opposed to "Google Azure"?), and there I can deploy my aspnetcore app to production in, like, 30s. Today.
So, what can I look forward to in 2023 with this product?
But even past that, what does this give me beyond AWS CodePipelines? All comparisons on the site seem to be against "raw" AWS ("weeks to months" from code to deployment, really?).
But, hey, maybe I'm misunderstanding both this product and CodePipelines. Myself, I'm on Azure DevOps (which I guess is the same as "MS Azure" as opposed to "Google Azure"?), and there I can deploy my aspnetcore app to production in, like, 30s. Today.
So, what can I look forward to in 2023 with this product?
> Not sure what to make of this. Given the active security incident, is "Heroku-like" really a recommendation?
The incident happened right after we posted this 3 days ago. Not a great timing, I have to agree :)
> Myself, I'm on Azure DevOps, I can deploy my aspnetcore app to production in, like, 30s.
I'm not very familiar with MS Azure and the way you can deploy your apps there.
The goal of Stacktape is to allow you to deploy your apps in a production-grade fashion (the infrastructure is scalable, reliable, cost-effective, secure and the deployment process is repeatable, auditable, etc..). Not sure if your Azure setup does the same. But again, I can be wrong as I'm not familiar with it.
The incident happened right after we posted this 3 days ago. Not a great timing, I have to agree :)
> Myself, I'm on Azure DevOps, I can deploy my aspnetcore app to production in, like, 30s.
I'm not very familiar with MS Azure and the way you can deploy your apps there.
The goal of Stacktape is to allow you to deploy your apps in a production-grade fashion (the infrastructure is scalable, reliable, cost-effective, secure and the deployment process is repeatable, auditable, etc..). Not sure if your Azure setup does the same. But again, I can be wrong as I'm not familiar with it.
This sounds very similar to AWS CDK. How does it compare?
Basically before CDK, this type of offering made sense but the truth is that AWS correctly identified this need to quickly scaffold infrastructures AND edit it without requiring YAML, Cloudformation or other declarative syntax like Terraform.
CDK is literally writing Python code. You can organize your files and write out logic in all the ways you could possibly. CDK offers tremendous value in this regard but the downside being you won't be able to generate the same layout on Azure or Google but that's a given.
On one end of the spectrum you could have a hybrid of Azure/Google cloud products but with AWS as your main base, vice versa. However, usually in my personal experience, you rarely end up deploying a complete stack on both clouds. It's like take that product from Google or Azure and make it work with AWS, in such scenario you could simply do most of the stuff in CDK and then wire up separate products (but to each their own).
The only use case where I think might require Terraform to a large degree is if you make heavy use of VPC'd, full stack across multiple clouds (ex. agency or consulting firm) but for majority of cases I don't really leave AWS and neither is there an expectation to from clients and employers (they rather just stick to AWS for everything if possible)
tldr: Terraform and tools like what OP is offering, were used to scaffold infra on AWS but CDK came along and really made it unecessary—just learn Python or a backend developer to scaffold infra on AWS in Python.
CDK is literally writing Python code. You can organize your files and write out logic in all the ways you could possibly. CDK offers tremendous value in this regard but the downside being you won't be able to generate the same layout on Azure or Google but that's a given.
On one end of the spectrum you could have a hybrid of Azure/Google cloud products but with AWS as your main base, vice versa. However, usually in my personal experience, you rarely end up deploying a complete stack on both clouds. It's like take that product from Google or Azure and make it work with AWS, in such scenario you could simply do most of the stuff in CDK and then wire up separate products (but to each their own).
The only use case where I think might require Terraform to a large degree is if you make heavy use of VPC'd, full stack across multiple clouds (ex. agency or consulting firm) but for majority of cases I don't really leave AWS and neither is there an expectation to from clients and employers (they rather just stick to AWS for everything if possible)
tldr: Terraform and tools like what OP is offering, were used to scaffold infra on AWS but CDK came along and really made it unecessary—just learn Python or a backend developer to scaffold infra on AWS in Python.
Stacktape is a whole "cloud development framework". It's not only about infrastructure management, but also about all the other DevOps-related tasks you come across when developing/running an application on AWS.
- In my opinion, it's even easier to use than a CDK L3 construct.
- It supports local/remote development, source-code packaging, deployment artifact management, secret management, domain management and much more.
- Besides AWS resources, it supports other 3rd party services (like MongoDB Atlas clusters and Upstash Kafka/Redis).
- It has a local development studio - GUI (currently in private beta).
- In my opinion, it's even easier to use than a CDK L3 construct.
- It supports local/remote development, source-code packaging, deployment artifact management, secret management, domain management and much more.
- Besides AWS resources, it supports other 3rd party services (like MongoDB Atlas clusters and Upstash Kafka/Redis).
- It has a local development studio - GUI (currently in private beta).
By the way, Hashicorp is working on a version of the CDK that outputs Terraform.
https://www.terraform.io/cdktf
https://www.terraform.io/cdktf
holy cow!!! thanks for this now i can point clients to this when they insist on Terraform.
I believe AWS CDK is actually written in JS, natively, and ported to other languages, inc. Python, using sort of a transpiler they created for that purpose.
True!
I guess this will support other cloud providers in the future?
It's always painful to setup infra for any project that I do as I want to focus on aplication not doing the devops, I'll try this one out
EDIT: Was trying to figure out a disparity in timing- I didn't know about the rescue pool feature!
Apparently, we were chosen for a second-chance pool. You can read more about it here: https://news.ycombinator.com/item?id=26998308
I didn't have a chance to read it myself tho.
I didn't have a chance to read it myself tho.
Never new about this feature! Super interesting. Congrats
[deleted]
As a full-stack developer, I was looking for an easy way to deploy and host my applications for years.
I could go with Kubernetes and Terraform. But the complexity of running this in production can be overwhelming even for a team of dedicated DevOps specialists. Or I could go with Heroku. But I’m not willing to pay 5-10 times more for my infrastructure just because my app was easier to deploy. I could also choose Serverless framework. But If my use case requires more than Lambda functions, I need to read through 100s of pages of AWS documentation figuring out how to configure VPCs, Security groups, Route tables and more…
Until now, I could choose either "powerful" or "easy". Today, after 2.5 years of development, I’m happy to introduce another option.
Stacktape is a DevOps-free cloud framework that’s both powerful and easy at the same time. It allows you to develop, deploy and run applications on AWS. With 98% less configuration and without the need for DevOps or Cloud expertise.
Unlike with other solutions, you can deploy both serverless (AWS lambda-based) and more traditional (container-based) applications. Stacktape also supports 20+ infrastructure components, including SQL databases, Load balancers, MongoDB Atlas clusters, Batch-jobs, Kafka topics, Redis clusters & more.
Besides infrastructure management, Stacktape handles source code packaging, deployments, local/remote development, and much more. It also comes with a VScode extension and local development studio (GUI).
Stacktape is a IaaC tool. The configuration can be written in YAML, JSON, or Typescript. A typical production-grade REST API is ~30 lines of config (compared to ~600-800 lines of CloudFormation/Terraform). The deployment can be done using a CLI or a programmatic SDK.
Stacktape is a premium tool with a forever-free tier. I’ll be very happy if you give it a try and let me know what you think.