Use it and like it. If using aws is a requirement but you don’t want to get bogged down with their user experience it’s worth it IMO.
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”
There's definitely a market for something like this, because most software companies at a certain size end up needing to build something like this. The real question is, how much work will you need to do to fit your current software to their paradigm in order to get the benefit? For a newer project, there's likely little sunk cost, but for anything that's already productionalized, I don't doubt that the rework -- particularly around all the devops bits and pieces -- will likely be significant. And then of course, from a strategic standpoint, you need to balance the risks vs. rewards of hitching your wagon to Flightcontrol's set of conventions.
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.
Data point: I wouldn't use a service for this, but I can see that there are plenty who will. The defensible moat is pager duty as a service, every engineering org on the planet will push management for that.
This could have been some custom cdk constructs. Then at least you can plug in SQS / SNS / DynamoDB / CW / IAM all in one solution. Flightcontrol doesn't seem to offer these.
Nice idea. I work at SP500 corp and we have platform teams provide this. I always wondered if it could be a startup. My reservation with tbis is tbe classic one: not open source. But I totally get why it isn't. Although FOSS might work as the value (at work and here too) is in having someone in a Slack channel that can help if a deploy gets stuck. The code is kind of a terraform-esque of sorts.
It's a shame that "Preview environments" are only available on the business plan @ $397/m. I guess that it makes sense if you're expending $4k+/m on AWS.
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 liked Flightcontrol, found it more reliable and less finicky than Cloud Build + Cloud Run, but it was too expensive for me.
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.
Same problem, used them for about a year. Nice experience but too pricey. also escalated our aws fees, perhapsa good idea, but too pricey for what we need.
> Your team gets bogged down with complex Terraform scripts, manual configuration, and endless CI/CD pipelines.
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 ?
Non-ops teams in big corp / public services are often fed up by their own IT (slowness, incompetence) and want to deploy, budget lines for recruiting devops/sysops is sometimes different than software/platform licenses, even if the solution is sub-optimal.
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.
> Terraform is there specifically to solve the Aws infrastructure complexity.
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.
> Teams over-engineering their build pipeline, building "platforms" that other teams must use, an unmaintainable and untestable mess. Time better spent elsewhere.
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.
> 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.
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.
> 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.
That smells like some really nasty problem in your company. If the change was really what you said it was, it might take some time and terraform code (i.e. nested submodules with hardcoded values that needs to support parameters all the way down) but it should not be a diff of that size.
Its an anti-pattern that negates some of the advantages of the cloud and re-introduces issues people had when things were still handled by the old internal IT infra department. I‘ve seen it a lot.
Use it and like it. If using aws is a requirement but you don’t want to get bogged down with their user experience it’s worth it IMO.
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”
Can we fix the title? It’s not AWS PaaS but a PaaS built on top of AWS. I thought it was a new service being launched by AWS.
There's definitely a market for something like this, because most software companies at a certain size end up needing to build something like this. The real question is, how much work will you need to do to fit your current software to their paradigm in order to get the benefit? For a newer project, there's likely little sunk cost, but for anything that's already productionalized, I don't doubt that the rework -- particularly around all the devops bits and pieces -- will likely be significant. And then of course, from a strategic standpoint, you need to balance the risks vs. rewards of hitching your wagon to Flightcontrol's set of conventions.
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.
Similar and not tied to a cloud provider: https://dokku.com
Data point: I wouldn't use a service for this, but I can see that there are plenty who will. The defensible moat is pager duty as a service, every engineering org on the planet will push management for that.
I tried flight control but it was a bit buggy and rough. My docker image worked differently on their platform compared to other PAAS.
Lot of issues with slow AWS provision or missing APIs on AWS side so it would take hours to delete resources created by them.
When did you try it?
This could have been some custom cdk constructs. Then at least you can plug in SQS / SNS / DynamoDB / CW / IAM all in one solution. Flightcontrol doesn't seem to offer these.
Nice idea. I work at SP500 corp and we have platform teams provide this. I always wondered if it could be a startup. My reservation with tbis is tbe classic one: not open source. But I totally get why it isn't. Although FOSS might work as the value (at work and here too) is in having someone in a Slack channel that can help if a deploy gets stuck. The code is kind of a terraform-esque of sorts.
It's a shame that "Preview environments" are only available on the business plan @ $397/m. I guess that it makes sense if you're expending $4k+/m on AWS.
So this is basically a webgui for the aws cli ?
Looks like it offers a much higher level of abstraction than that.
Seems closer to Heroku/Vercel but running in your own AWS account.
So AWS Beanstalk? :)
You forgot the trigger warning :)
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.
Pour one out for Flight Control, the $0.99 phenom of an app back in the early iOS days.
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.
That was such an amazingly simple, well executed, and fun game.
Thanks for the reminder.
I liked Flightcontrol, found it more reliable and less finicky than Cloud Build + Cloud Run, but it was too expensive for me.
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.
Same problem, used them for about a year. Nice experience but too pricey. also escalated our aws fees, perhapsa good idea, but too pricey for what we need.
Seems like AWS should offer something like this.
> Your team gets bogged down with complex Terraform scripts, manual configuration, and endless CI/CD pipelines.
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 ?
Terraform used to solve the AWS infrastructure problem. But at a certain scale it becomes the problem.
>Terraform is there specifically to solve the Aws infrastructure complexity
No, terraform passes AWS complexity 1:! onto you, it just allows you to tackle it in an ordered fashion.
Non-ops teams in big corp / public services are often fed up by their own IT (slowness, incompetence) and want to deploy, budget lines for recruiting devops/sysops is sometimes different than software/platform licenses, even if the solution is sub-optimal.
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.
> Terraform is there specifically to solve the Aws infrastructure complexity.
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.
There are two devops patterns that WORK:
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.
> Teams over-engineering their build pipeline, building "platforms" that other teams must use, an unmaintainable and untestable mess. Time better spent elsewhere.
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.
> 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.
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.
> 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.
That smells like some really nasty problem in your company. If the change was really what you said it was, it might take some time and terraform code (i.e. nested submodules with hardcoded values that needs to support parameters all the way down) but it should not be a diff of that size.
Its an anti-pattern that negates some of the advantages of the cloud and re-introduces issues people had when things were still handled by the old internal IT infra department. I‘ve seen it a lot.
i remember deis, it was amazing self-hosted heroku. too bad they were bought by microsoft.
and then there's also flynn.
So it’s a neo-Heroku?