[HN Gopher] Show HN: Stacktape - Full power of AWS with Heroku-l...
___________________________________________________________________
Show HN: Stacktape - Full power of AWS with Heroku-like experience
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.
Author : matus_congrady
Score : 75 points
Date : 2022-04-13 13:16 UTC (3 days ago)
(HTM) web link (www.stacktape.com)
(TXT) w3m dump (www.stacktape.com)
| blairanderson wrote:
| 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
| matus_congrady wrote:
| > 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.
| pdwittig wrote:
| 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.
| daxaxelrod wrote:
| Idk man, I agree with OP. Writing YAML configs is one of my
| least favorite things to do. Might be worth polling more
| people
| emptysongglass wrote:
| 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.
| matus_congrady wrote:
| 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.
| aalhafoudh wrote:
| Hey Matus, good job!
|
| YAML validation and vscode extension is very cool. I hope it
| helps adoption.
| solatic wrote:
| 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 wrote:
| > 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".
| surfer7837 wrote:
| 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 wrote:
| 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/
| rmbyrro wrote:
| 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.
| mdb31 wrote:
| 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 wrote:
| > 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.
| 0xCAP wrote:
| Very cool, maybe making a visual builder for YAML haters could be
| and additional killer feature.
| matus_congrady wrote:
| 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.
| pelagicAustral wrote:
| 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.
| aslakhellesoy wrote:
| This sounds very similar to AWS CDK. How does it compare?
| pharmakom wrote:
| I guess this will support other cloud providers in the future?
| tomatowurst wrote:
| 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.
| rmbyrro wrote:
| 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.
| matus_congrady wrote:
| 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).
| pharmakom wrote:
| Why is Python better than Terraform language for this use
| case?
| mysho wrote:
| 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
| [deleted]
| debarshri wrote:
| 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
| matus_congrady wrote:
| 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 wrote:
| 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.
| dsanchez97 wrote:
| 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?
| matus_congrady wrote:
| 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 wrote:
| 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 wrote:
| 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...
| nkotov wrote:
| 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
| andrew_ wrote:
| 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.
| matus_congrady wrote:
| 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 wrote:
| 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!
| bdcravens wrote:
| 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 wrote:
| Thanks for the tip!
| meowtastic wrote:
| 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 wrote:
| 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).
| meowtastic wrote:
| Oh I see, I'll take a look into it then. Thanks!
| jasonjmcghee wrote:
| EDIT: Was trying to figure out a disparity in timing- I didn't
| know about the rescue pool feature!
| matus_congrady wrote:
| 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.
| jasonjmcghee wrote:
| Never new about this feature! Super interesting. Congrats
| smt88 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| smt88 wrote:
| 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.
| noodle wrote:
| 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..
| leodriesch wrote:
| 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 wrote:
| 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.
| matus_congrady wrote:
| 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.
| mirkodrummer wrote:
| 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
| matus_congrady wrote:
| 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.
| rich_sasha wrote:
| 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.
| uuyi wrote:
| Spivak wrote:
| 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
___________________________________________________________________
(page generated 2022-04-16 23:01 UTC)