Launch HN: Seed (YC W21) – A Fully-Managed CI/CD Pipeline for Serverless

I'm thinking about lock-in -- what if you suddenly deprecated the product? Will my deploys suddenly break?

Are you planning to maintain 1:1 feature parity with Serverless/CDK long-term? Could I fall back to those deployment tools, albeit slower, worst case?

Either way, this is awesome and congrats on the launch!

- The big one is the focus on speed, the incremental deploys at a service and Lambda function level (https://seed.run/blog/speeding-up-serverless-deployments-100...).

- We are also focussed on reliability, so setting up and tearing down environments while handling all the AWS rate-limit errors, or other timing related errors. We do this by connecting directly to CloudFormation.

- We also allow you to configure a deployment order for your services (https://seed.run/docs/configuring-deploy-phases).

On the alerts, logs, and metrics; the critical difference is that we query directly against your CloudWatch Insights or subscribe to your CloudWatch groups, instead of ingesting all your logs on our side. This allows us to:

- Provide real-time Lambda alerts basically for free (https://seed.run/docs/issues-and-alerts)

- And you don't need to configure anything on your side. You connect your AWS credentials and it works out of the box.

As always feel free to reach out if you need further details jay@seed.run

I'm new to all of it, but the security groups, route tables, internet gateways and other implementation details of AWS left me feeling overwhelmed and insecure (literally, because roles and permissions are nearly impossible for humans to reason about). AWS also suffers from the syndrome of: if you want to use some of it, you have to learn all of it.

Basically what I need is a sandbox for running Docker containers with any reasonable scale (under 100? what's big these days?). Then I just want to be able to expose incoming port 443 and one or two others for a WebSocket or an SSL port so admins can get to the database and filesystem (maybe). Why is something so conceptually trivial not offered by more hosting providers?

I researched Heroku a bit but am not really sure what I'm looking at without actually doing the steps. I'm also not entirely certain why CI/CD has been made so complicated. I mean conceptually it's:

1) Run a web hook to watch for changes at GitHub and elsewhere

2) Optionally run a bunch of unit tests and if they pass, go to step 3

3) Run a command like "docker-compose --some-option-to-make-this-happen-remotely up"

So why is a 3 step thing a 3000 step thing? Full disclose, I did the 3000 steps with Terraform and while I learned a lot from the experience, I can't say that I see the point of most of it. I would not recommend the bare-hands way on any cloud provider to anyone, ever (unless they're a big company or something).

I guess what I'm asking is, could you adapt what you've done here to work with other AWS services like ECS? It's all of the same configuration and monitoring stuff. I've already hit several bugs in ECS where you have to manually run docker prune and other commands in the EC2 instance because the lifetimes are in hours and they haven't finished the rough edges around their cleanup commands. So I've hit problems where even though I've spun down the cluster, the new one won't spin up because it says the Nginx container is still using the port. I can't tell you how infuriating it is to have to work around issues like that which ECS was supposed to handle in the first place. And I've hit similar gotchas on the other AWS services too, to the point where I'm having trouble seeing the value in what they're offering, or even understanding why a service exists in the first place, when I might have done it a different way if I was designing it.

TL;DR: if you could make deploying Docker as "easy" as Lambda, you'd quickly run out of places to store the money.