Flightcontrol: A PaaS that deploys to your AWS account
flightcontrol.dev
flightcontrol.dev
Have run into some aws quirks leaking out of their abstraction. But personally that has only made me say “man if they couldn’t figure out how to make this clean, I would have been toast dealing with it on my own”
They introduced a cheaper plan since I tried it, but it's missing the main feature that I actually think makes FC worth it (preview environments)
I know not everyone wants to get in on the Vercel Cartel model of excessive free-tier generosity made up for by 1000% markups at scale... but $400/month is tough to swallow when you barely need $50/month of compute to handle your production workload.
Lot of issues with slow AWS provision or missing APIs on AWS side so it would take hours to delete resources created by them.
> Managed ECS-EC2 clusters in preview
> AWS has a long standing issue with the ECS agent randomly disconnecting, resulting in orphaned EC2 instances which can cause traffic or deployment degradation.
> We have attempted to solve this a few ways in the past, but there were still critical edge cases falling through.
> So we bit the bullet, and developed a robust, full featured ECS cluster management solution to solve this problem once and for all.
> It's currently in private preview. To get early access before we roll it out to everyone, contact support.
I found elsewhere in the Flight control docs where they recommend ECs+EC2. While I'm not surprised to hear about issues with ECS+EC2, given the reported issues above I don't know if I'd recommend it in my docs. Fargate is a far better option for most use cases, at least in my experience. Unless you need specialized instance types, like GPU workloads.
- https://github.com/batteries-included/batteries-included/ - https://www.batteriesincl.com/
It is very strange to have headshots of individual investors on the page that would normally have pictures of your team.
For my part, there was some initial friction making it usable from the publisher perspective but haven’t really had issues using it from the consumer side.
RDS public by default (!), and the private config just removes the public IP address rather than puts in private subnet. Causes it to fail CIS benchmark which is requirement for FTR.
When I raised it I was told I was wrong.
I think there is a good future for the product but one size fits all config comes with downsides. IMO Would be better if it was IaC but with pre built "blocks" app, cache, etc, which you could easily customize. I also think the pricing is too steep for your average scaling bootstrapper which is where Heroku et al shined.
> Would be better if it was IaC but with pre built "blocks" app, cache, etc, which you could easily customize
We are working on a major new product version that does exactly this ;)
That said, I'm surprised that Azure and GCP don't already have similar service offerings... I'm not sure about nixpacks over direct Dockerfile usage though. Would also be nice to see a WebASM package system as well for single ip/socket services and web-service request handlers. Simplify the application layer as much as possible and make logging via line-separated json on stdout the norm... add layers to relay logging and handle TLS termination. IT just makes sense... it also makes sense to bundle services onto fewer servers based on actual ram/cpu usage. Maybe an easy button for redundancy, and that's it.
There's a lot of appeal in what fly, deno, cloudflare and others are offering but to a broader range of options than just JS focus with WebASM as a minor afterthought with weird limitations in practice.
There will be a really solid chunk of projects that find good cost savings using this platform -- especially teams that are resource-constrained on devops and don't consider it their core competency.
They offer two discrete services. One is a simplified AWS where the interface is something like Service Now and you don't have access to the environment to make control plane changes. The second (and newer) offering is that they will onboard to your existing AWS operating environment and assist with running your applications.
They laid off my whole team because AWS started doing our job and better, LOL.
So I see OPs post and it brings back memories.
From there a lot of our custom software is just adapting the AWS platform for our taste. For example, we define a lot of our routing configuration using docker labels (similar to Traefik), so we needed a reverse proxy that could handle that.
EventBridge scheduler is finally available in GovCloud
I wanted to go with AWS but ended up with Digital Ocean / Vercel for personal stuffs due to concerns on AWS horror bills.
Seems closer to Heroku/Vercel but running in your own AWS account.
But jokes aside, I use Beanstalk quite a bit and it's mighty leaky, don't find it all that comparable to stuff like fly.io, although in spirit it's the same thing I suppose.
I casually asked our account manager "Do you know any local customer with EB success story?" Their answer was "Do you want to be one?"
"bare metal"? Hmmm. I think we have different definitions of that phrase.
I really hate marketing speak like this. Terraform is there specifically to solve the Aws infrastructure complexity.you create your system once and minor changes if needed.
> Flightcontrol fully automates infrastructure provisioning, CI/CD, and deployments. All within your own AWS account where you retain full visibility and control
Why does everyone think this is a desirable thing? Excluding adding to your aws price, you're now vendor locked in for your pipelines also.
I'm not seeing any benefits here for any already established company, maybe a small start-up of fresh graduates who don't want to learn Iac/DevOps ?
I don't know if anyone here remembers the Ant build system, but writing your own Terraform spaghetti strongly resembles the days of Ant, before Maven came along. Teams over-engineering their build pipeline, building "platforms" that other teams must use, an unmaintainable and untestable mess. Time better spent elsewhere.
This hits home so much!
I remember last year when I asked our Cloud Ops to add an additional EC2 instance and adjust sizes on two others. It took twelve work hours and resulted in +3k -2k changed lines "because they had no way of doing it now without merging seven hundred other changes.
I have to disagree a little here, if you're already in AWS, then an investment in fixing your terraform structure is not just worth the money, but gives you a better understanding of the infrastructure architecture, you also retain ownership of your deployments. What happens if Flightcontrol go down for whatever reason? Or are sold off like other's we've seen, or god forbid you need some fine tuning that isn't in the Flightcontrol's website. You're now depending on, and maybe even paying for, an external company for devops support to do something you already know how to do.
It seems to be in the long term, that time is definitely not better spent elsewhere.
These are all valid points. This is a fundamental issue with relying on non-open 3rd party solutions and (leaky) abstractions. The best solution here would be some standard that the hyperscalers implement themselves, but this is of course incredibly unlikely.
I wouldn’t be surprised to see that at some point if these tools catch on.
AWS in particular has a pattern of bringing toys everyone loves in house and making managed services out of them.
I'm kind of amazed that they haven't already. It would be such a good selling point for Azure, or GCP, etc. "We have a UI like Heroku or Vercel. Compare that to our confusing competitors!"
1. All centrally managed. Engineers hand off repos and devops own the instantiation. Devop is a core team with an infra monorepo.
2. Devops capable engineers are embedded into teams, and each project owns its own infrastructure with golden path guidance.
The hybrid version, central management of most stuff with project specific devops burden, is the worst of both and causes no end of problems.
They could get customers initially by promising a simple start to get "on the cloud", but would keep customers due to support, scaling, monitoring, ci/cd and maintenance. Cheap startups could use it as a one-time tool, but I think a lot would see the added value they bring.
Disclaimer I'm an SRE/sysops and went through a bunch of those projects where sometimes entire department see (often shadow) IT from contractors as the only solution moving forward.
No, terraform passes AWS complexity 1:! onto you, it just allows you to tackle it in an ordered fashion.
In fact, terraform exposes the complexity of AWS, since with terraform you need to hook everything up manually.
And avoiding vendor lock in is an illusion. Everyone is locked in to some extent. Just design things so you can move providers by understanding your system and architecting it correctly.
Not taking advantage of extra capabilities vendors provide you is just stupid. SQS/lambda is great. Why avoid it, because one day in the far future you might move to GCP? Protip: if you move to GCP (or Oracle cloud, or IBM cloud, or CloudFlare, etc) you're going to rebuild everything anyway.
For larger companies this will get shut down, because the idea of some random team deploying to the cloud by themselves is a security breach that hasn't been reported yet.
Clearly you've never had to deal with deploying large systems on AWS because if your account even has provisioning permissions, whish is usually a huge security risk in enterprise environments, the chances of you messing something up are all on your familiarity with Aws console. And if you get something wrong you're stranded without any kind of rollback. Terraform gives you rollback ability as well as validation against your requirements.
and then there's also flynn.
Dokku supports distributed compute via our k3s scheduler plugin. This can setup its own k3s cluster or connect to an existing Kubernetes cluster and deploys helm charts on this clusters for your app.
I am also working on similar tool[1] but it's bit more niche to batch jobs type functionality but not just limited to AWS rather it's cloud agnostic.
[1]: Daestro - https://daestro.com
Submitters: "Please submit the original source. If a post reports on something found on another site, submit the latter." - https://news.ycombinator.com/newsguidelines.html
It came to mind due to the iOS 26 "Games" app reminding me of 12-y/o "Achievements" that now only exist as flags in a database.
Thanks for the reminder.
Your point about "serverless" I can understand, but "Flight control" seems like a great name for a product like that.
New terminology may sound strange to people who are not familiar with it, but if people start to adopt it, it becomes a normal and accepted word. Basically every word has gone though this process at some point.
And brand names are often witty puns or irrelevant words, intentionally. Using descriptive words for a brand is legally a bad idea, because this can disqualify you for trademarks. The point of trade marks is to uniquely identify the offering -- if you named it descriptively you risk losing this. Apple computers are not fruit, and Windows computers are not transparent glass. If you named your computer "computer" you wouldn't have a brand, and nobody would be able to know what to refer to your computer.
I think people vastly overestimate how hard it is to learn AWS. It may seem daunting at first but it only takes like a week -- one good YouTube series to cover the basics like IAM, and a lot of playing around with the GUI console, CloudFormation, and pestering support till it all clicks. Multiple backend devs in your team should be able to own your CloudFormation/Terraform scripts and your cloud infra. I basically did exactly this in my new grad SWE job.
Just fucking learn it. You don't need to hire someone for every little thing. Don't treat AWS like some complex arcane machine that only a 3x AWS-certified "Cloud DevOps Engineer" with 10 years of experience should touch. And for the love of God don't add more 3rd party layers like TFA. Most of the world is raw-dogging AWS, why is your company an exception?