9 ms·

Show HN: Stacktape – Full power of AWS with Heroku-like experience

115 points by matus_congrady 5y ago

Hello, Stacktape CEO here. 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.

meowtastic 5y ago
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.
- matus_congrady 5y ago
  Hello. We do support Aurora postgres databases natively: https://docs.stacktape.com/resources/relational-databases/#aurora-engine https://docs.stacktape.com/resources/relational-databases/#a... You can trigger lambda functions by a "cron" job (https://docs.stacktape.com/resources/lambda-functions/#schedule-event 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).
  - meowtastic 5y ago
    Oh I see, I'll take a look into it then. Thanks!
0xCAP 5y ago
Very cool, maybe making a visual builder for YAML haters could be and additional killer feature.
- matus_congrady 5y ago
  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.
dsanchez97 5y ago
Looks like a great product! I am also working on a similar product (https://cdevframework.io 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?
- matus_congrady 5y ago
  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.
redhale 5y ago
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?
- matus_congrady 5y ago
  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/ https://docs.stacktape.com/configuration/overrides/ You can also add any CF resources to the template: https://docs.stacktape.com/resources/cloudformation-resources/ https://docs.stacktape.com/resources/cloudformation-resource...
  - redhale 5y ago
    Thanks, this is exactly what I was looking to confirm!
jasonjmcghee 5y ago
EDIT: Was trying to figure out a disparity in timing- I didn't know about the rescue pool feature!
- matus_congrady 5y ago
  Apparently, we were chosen for a second-chance pool. You can read more about it here: https://news.ycombinator.com/item?id=26998308 https://news.ycombinator.com/item?id=26998308 I didn't have a chance to read it myself tho.
  - jasonjmcghee 5y ago
    Never new about this feature! Super interesting. Congrats
mdb31 5y ago
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?
- matus_congrady 5y ago
  > 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.
surfer7837 5y ago
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
- matus_congrady 5y ago
  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/ https://docs.stacktape.com/resources/batch-jobs/
- rmbyrro 5y ago
  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.
bdcravens 5y ago
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.
- matus_congrady 5y ago
  Thanks for the tip!
debarshri 5y ago
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 https://github.com/debarshibasak/awesome-paas
- matus_congrady 5y ago
  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.
  - rmbyrro 5y ago
    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.
    - tedyoung 5y ago
      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.
noodle 5y ago
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..
- matus_congrady 5y 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.
- leodriesch 5y ago
  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.
  - noodle 5y ago
    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.
- deleted 5y ago
  [deleted]
hollowturtle 5y ago
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
- uuyi 5y ago
- matus_congrady 5y ago
  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-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.
  - rich_sasha 5y ago
    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.
aslakhellesoy 5y ago
This sounds very similar to AWS CDK. How does it compare?
- tomatowurst 5y ago
  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.
  - pharmakom 5y ago
    Why is Python better than Terraform language for this use case?
    - mateuszf 5y ago
      I guess because the language is more expressive.
      - pharmakom 5y ago
solatic 5y ago
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.
- matus_congrady 5y ago
  > 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".
nkotov 5y ago
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 https://github.com/debarshibasak/awesome-paas
- matus_congrady 5y ago
  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.
  - jamesmcintyre 5y ago
    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!
- andrew_ 5y ago
  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.
throw03172019 5y ago
Congrats on launch! How does this compare with Convox?
tedyoung 5y ago
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.
deleted 5y ago
[deleted]
aalhafoudh 5y ago
Hey Matus, good job! YAML validation and vscode extension is very cool. I hope it helps adoption.
smt88 5y ago
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!
- matus_congrady 5y ago
  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).
  - smt88 5y ago
    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.
    - matus_congrady 5y ago
      Stacktape does support secrets https://docs.stacktape.com/resources/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.
      - smt88 5y ago
        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.
mysho 5y ago
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
blairanderson 5y ago
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
- digianarchist 5y ago
  You just described render.com
- matus_congrady 5y ago
  > 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.
  - daxaxelrod 5y ago
    Idk man, I agree with OP. Writing YAML configs is one of my least favorite things to do. Might be worth polling more people
    - 5y ago
pelagicAustral 5y ago
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.

meowtastic 5y ago

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.

matus_congrady 5y ago
Hello. We do support Aurora postgres databases natively: https://docs.stacktape.com/resources/relational-databases/#aurora-engine https://docs.stacktape.com/resources/relational-databases/#a... You can trigger lambda functions by a "cron" job (https://docs.stacktape.com/resources/lambda-functions/#schedule-event 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).
- meowtastic 5y ago
  Oh I see, I'll take a look into it then. Thanks!

0xCAP 5y ago

Very cool, maybe making a visual builder for YAML haters could be and additional killer feature.

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

dsanchez97 5y ago

Looks like a great product! I am also working on a similar product (https://cdevframework.io 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?

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

redhale 5y ago

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?

matus_congrady 5y ago
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/ https://docs.stacktape.com/configuration/overrides/ You can also add any CF resources to the template: https://docs.stacktape.com/resources/cloudformation-resources/ https://docs.stacktape.com/resources/cloudformation-resource...
- redhale 5y ago
  Thanks, this is exactly what I was looking to confirm!

jasonjmcghee 5y ago

EDIT: Was trying to figure out a disparity in timing- I didn't know about the rescue pool feature!

matus_congrady 5y ago
Apparently, we were chosen for a second-chance pool. You can read more about it here: https://news.ycombinator.com/item?id=26998308 https://news.ycombinator.com/item?id=26998308 I didn't have a chance to read it myself tho.
- jasonjmcghee 5y ago
  Never new about this feature! Super interesting. Congrats

mdb31 5y ago

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?

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

surfer7837 5y ago

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

matus_congrady 5y ago
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/ https://docs.stacktape.com/resources/batch-jobs/
rmbyrro 5y ago
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.

bdcravens 5y ago

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.

matus_congrady 5y ago
Thanks for the tip!

debarshri 5y ago

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 https://github.com/debarshibasak/awesome-paas

matus_congrady 5y ago
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.
- rmbyrro 5y ago
  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.
  - tedyoung 5y ago
    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.

noodle 5y ago

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

matus_congrady 5y 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.
leodriesch 5y ago
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.
- noodle 5y ago
  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.
deleted 5y ago
[deleted]

hollowturtle 5y ago

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

uuyi 5y ago
matus_congrady 5y ago
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-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.
- rich_sasha 5y ago
  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.

aslakhellesoy 5y ago

This sounds very similar to AWS CDK. How does it compare?

tomatowurst 5y ago
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.
- pharmakom 5y ago
  Why is Python better than Terraform language for this use case?
  - mateuszf 5y ago
    I guess because the language is more expressive.
    - pharmakom 5y ago

solatic 5y ago

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.

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

nkotov 5y ago

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 https://github.com/debarshibasak/awesome-paas

matus_congrady 5y ago
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.
- jamesmcintyre 5y ago
  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!
andrew_ 5y ago
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.

throw03172019 5y ago

Congrats on launch! How does this compare with Convox?

tedyoung 5y ago

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.

deleted 5y ago

[deleted]

aalhafoudh 5y ago

Hey Matus, good job! YAML validation and vscode extension is very cool. I hope it helps adoption.

smt88 5y ago

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!

matus_congrady 5y ago
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).
- smt88 5y ago
  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.
  - matus_congrady 5y ago
    Stacktape does support secrets https://docs.stacktape.com/resources/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.
    - smt88 5y ago
      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.

mysho 5y ago

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

blairanderson 5y ago

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

digianarchist 5y ago
You just described render.com
matus_congrady 5y ago
> 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.
- daxaxelrod 5y ago
  Idk man, I agree with OP. Writing YAML configs is one of my least favorite things to do. Might be worth polling more people
  - 5y ago

pelagicAustral 5y ago

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.