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”
I built something very similar to this a few years ago, sold it for way less ($3/service), and ultimately decided not to spend money marketing it. Building the product made it super clear that AWS costs were grossly inflated, which they hid with dark UX, and I wanted to help small teams and hobbyists. Today, if you are a small team that doesn't really need more than one large VPS, you should seriously consider Docker Swarm. Not to say that Flightcontrol looks bad. In fact, it looks quite nice. Something like this could save you a lot of money if you would otherwise need full-time devops.
Swarm never died. Kubernetes was designed for an entirely different level of scale and there is inherent complexity in that. Whereas starting a production-ready container service with Swarm only takes a few commands on a fresh Docker installation.
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.
> 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.
Wow, they are definitely targeting Heroku with this... specifically calling them out towards the end of the page.
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.
Just reading over the docs, you'll need a lot more GCP services than Cloud Run to encompass what Flightcontrol is managing for you. The Cloud Run analog is Fargate. Which is only the container orchestration piece.
Looks like you can use your own Dockerfile or a container registry. Suspect nixpacks are just a recommended starting point for people looking to get up and running quickly.
I wonder how many of these exist at every company. At $dayjob we have built something similar over the years. We have a custom load balancer that will query ECS, provision certificates with lets encrypt and even provision domains inside Cloudflare. We also have deploy previews, and various services on lambda function urls. We used to use mesos but transitioned to ecs, so we even have a homegrown "chronos" for running scheduled jobs on ecs.
This is the end result of the “but kubernetes is too complicated” argument. You end up hand rolling all of the things it gives you out of the box. I’m sure you have your reasons for not using kube, but every one of those things you mentioned you get in a standardized way with kube
We were on Mesos before so k8s complexity wasn't the deciding factor. If I cared about being could-agnostic, I would have gone the kubernetes route. The main factor was we decided to move as much as possible to aws managed services so that we wouldn't be responsible for their operation. Once we have made this decision, then paying the premium for EKS over ECS Fargate didn't make much sense.
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.
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.
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.
I’ve been getting great mileage out of service catalog products. They’re a great middle ground between custom CDK and in-house PaaS. You can even use them as CloudFormation resources so they compose well and users are agnostic to which CDK language (or Terraform even!) that is used to write them. I’m currently experimenting with using them to expose terraform modules as CDK constructs.
Oh interesting, what was your experience with it, out of curiosity?
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.
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.
I think 'Batteries Included' would interest you, then. Like this, it's installable on AWS. It's a whole platform PaaS + AI + more built on open source. So Kubernetes is at the core, but with tons of automation and UI. Dev environments are Kubernetes in Docker (Kind-based).
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.
Amazon has their own PaaS offering called Elastic Beanstalk, with support for running docker containers and other popular platforms. It's not complicated to set up and is customizable if you need to tweak things. Any idea how Flightcontrol compares to this?
We acquired a company that use EB and they have no dedicated DevOps engineer. It was bad because every deploy is a full VM boot which takes a long time and you can't do things you can do with Argo Rollouts. We migrated them to EKS.
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?"
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.
Coolify is your best option here. It has preview environments and lots of other built-in features - just the cost of your server if you're savvy enough to get things setup yourself. https://coolify.io/
I think the problem with these general-purpose PaaS on top of Cloud is exactly that they're general-purpose. You will run into limitations and issues as soon as you start doing things only 5-10% of their customers need, like for example running privileged docker containers in kubernetes or wanting to manage parts of your infra with terraform.
I'd much rather see tools helping me deploy one particular niche use case in Cloud really well.
BTW I'm trying to follow this mantra while building https://staticbot.dev
And their value prop that you need expensive hard-to-find AWS DevOps Engineers to run your AWS infra is just fear-mongering.
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?
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.
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 do with app runner, but last I checked, for some reason services were capped at low CPU/Memory and didn't allow basic ECS features like attached storage. I think they also had another one... AWS is very fragmented and strange.
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.
> 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 isn't there to resolve the complexity of aws, it's there so you can manage tour aws deploy more easily.
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.
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.
> some standard that the hyperscalers implement themselves
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!"
> 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 guess in an ideal world, a service like this would be a layer on top of Terraform. Changes in the admin page would be applied using Terraform, and update the config in your own Git repository. I think this would be much easier to sell, even if they choose to make it "write only" to avoid potential complexity of managing user defined configs.
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.
In general I love the PaaS experience and I can see the value Flightcontrol can potentially provide to the companies that work mostly with AWS. The free starter plan for individual is tempting to try out Flightcontrol, BTW what is the service limit for free plan? I could not find it.
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.
I had the exact same reaction, and then when reading some of the copy thought to myself: "omg, can't believe they are being so degrading to how clunky their own dashboards and things are!" And then it hit me...
Why web developer culture is so annoying when it comes to naming things? Serverless? It is actually a server. Flight control? Nothing to do with airports or flights or whatsoever.
Creating new words from existing words or concepts is how language works. In fact, "airport" is an example of this... ports were originally for boats.
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.
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”
I built something very similar to this a few years ago, sold it for way less ($3/service), and ultimately decided not to spend money marketing it. Building the product made it super clear that AWS costs were grossly inflated, which they hid with dark UX, and I wanted to help small teams and hobbyists. Today, if you are a small team that doesn't really need more than one large VPS, you should seriously consider Docker Swarm. Not to say that Flightcontrol looks bad. In fact, it looks quite nice. Something like this could save you a lot of money if you would otherwise need full-time devops.
Can you elaborate on Docker Swarm? I thought it lost out to Kubernetes and was effectively dead.
Swarm never died. Kubernetes was designed for an entirely different level of scale and there is inherent complexity in that. Whereas starting a production-ready container service with Swarm only takes a few commands on a fresh Docker installation.
Using it. Moving off it.
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.
RDS has been default private for probably 6 months or longer.
> 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 ;)
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?
Found this in their roadmap [0]:
> 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.
[0]: https://roadmap.flightcontrol.dev/changelog
Wow, they are definitely targeting Heroku with this... specifically calling them out towards the end of the page.
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.
at least for GCP, isn't that cloud run?
Just reading over the docs, you'll need a lot more GCP services than Cloud Run to encompass what Flightcontrol is managing for you. The Cloud Run analog is Fargate. Which is only the container orchestration piece.
Looks like you can use your own Dockerfile or a container registry. Suspect nixpacks are just a recommended starting point for people looking to get up and running quickly.
Trust suggestion: make it easier to find photos of the founders, than the investors.
Good suggestion, our company page is updated to include the founders
Wait ... where are the founders?
Here, I guess: https://www.ycombinator.com/companies/flightcontrol
It is very strange to have headshots of individual investors on the page that would normally have pictures of your team.
I wonder how many of these exist at every company. At $dayjob we have built something similar over the years. We have a custom load balancer that will query ECS, provision certificates with lets encrypt and even provision domains inside Cloudflare. We also have deploy previews, and various services on lambda function urls. We used to use mesos but transitioned to ecs, so we even have a homegrown "chronos" for running scheduled jobs on ecs.
This is the end result of the “but kubernetes is too complicated” argument. You end up hand rolling all of the things it gives you out of the box. I’m sure you have your reasons for not using kube, but every one of those things you mentioned you get in a standardized way with kube
We were on Mesos before so k8s complexity wasn't the deciding factor. If I cared about being could-agnostic, I would have gone the kubernetes route. The main factor was we decided to move as much as possible to aws managed services so that we wouldn't be responsible for their operation. Once we have made this decision, then paying the premium for EKS over ECS Fargate didn't make much sense.
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.
> so we even have a homegrown "chronos" for running scheduled jobs on ecs
EventBridge scheduler is finally available in GovCloud
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.
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.
I’ve been getting great mileage out of service catalog products. They’re a great middle ground between custom CDK and in-house PaaS. You can even use them as CloudFormation resources so they compose well and users are agnostic to which CDK language (or Terraform even!) that is used to write them. I’m currently experimenting with using them to expose terraform modules as CDK constructs.
Service Catalog is on my top 5 list of terrible AWS developer experiences, and I've used practically every mainstream service.
Oh interesting, what was your experience with it, out of curiosity?
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.
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.
I think 'Batteries Included' would interest you, then. Like this, it's installable on AWS. It's a whole platform PaaS + AI + more built on open source. So Kubernetes is at the core, but with tons of automation and UI. Dev environments are Kubernetes in Docker (Kind-based).
- https://github.com/batteries-included/batteries-included/ - https://www.batteriesincl.com/
Skimmed the docs but does Flightcontrol allows a cost cutoff?
I wanted to go with AWS but ended up with Digital Ocean / Vercel for personal stuffs due to concerns on AWS horror bills.
No, but we support cost budget alerts.
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.
While I'm sure the implementation isn't the same, Cloud66 has been doing this for a long time.
Amazon has their own PaaS offering called Elastic Beanstalk, with support for running docker containers and other popular platforms. It's not complicated to set up and is customizable if you need to tweak things. Any idea how Flightcontrol compares to this?
We acquired a company that use EB and they have no dedicated DevOps engineer. It was bad because every deploy is a full VM boot which takes a long time and you can't do things you can do with Argo Rollouts. We migrated them to EKS.
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?"
EB is buggy garbage. We switched to FlightControl to get a similar experience without the bugs and headache.
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.
Coolify is your best option here. It has preview environments and lots of other built-in features - just the cost of your server if you're savvy enough to get things setup yourself. https://coolify.io/
Thanks, I was watching a video about Coolify vs Dokploy from "Dreams of Code", and I think I'm going to try Dokploy first.
I think the problem with these general-purpose PaaS on top of Cloud is exactly that they're general-purpose. You will run into limitations and issues as soon as you start doing things only 5-10% of their customers need, like for example running privileged docker containers in kubernetes or wanting to manage parts of your infra with terraform. I'd much rather see tools helping me deploy one particular niche use case in Cloud really well. BTW I'm trying to follow this mantra while building https://staticbot.dev
And their value prop that you need expensive hard-to-find AWS DevOps Engineers to run your AWS infra is just fear-mongering.
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?
I am still happy with northflank. A bit more infra provider independence is nice to have. (we are actually moving from gcp to 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.
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.
Dollar dollar bills y'all: https://aws.amazon.com/managed-services/
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.
I worked on one of the first aws managed services that integrated directly with service now back in the early 2010's at G.E.
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.
They do with app runner, but last I checked, for some reason services were capped at low CPU/Memory and didn't allow basic ECS features like attached storage. I think they also had another one... AWS is very fragmented and strange.
Is the paas built on Kubernetes?
Looks like it is ECS with either Fargate or EC2. If you don't need more control over your containers, Fargate is a good default.
Similar and not tied to a cloud provider: https://dokku.com
Not similar - dokku doesn't support distributed compute. It's a platform intended for use on a single server.
Dokku maintainer here.
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.
Please provide links for the docs to this, as this was a misconception I had about Dooku as well.
So it’s a neo-Heroku?
> 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 isn't there to resolve the complexity of aws, it's there so you can manage tour aws deploy more easily.
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.
>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.
Terraform used to solve the AWS infrastructure problem. But at a certain scale it becomes the problem.
Is this an issue with Terraform, or "infrastructure-as-code" in general?
Very much an IaC trait.
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.
> some standard that the hyperscalers implement themselves
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!"
> the hyperscalers implement themselves
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.
> 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.
Do you know what they did wrong? I would have made a stink about this.
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.
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.
I guess in an ideal world, a service like this would be a layer on top of Terraform. Changes in the admin page would be applied using Terraform, and update the config in your own Git repository. I think this would be much easier to sell, even if they choose to make it "write only" to avoid potential complexity of managing user defined configs.
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.
Stay tuned, we’re working on the next version of Flightcontrol which is in this direction.
In general I love the PaaS experience and I can see the value Flightcontrol can potentially provide to the companies that work mostly with AWS. The free starter plan for individual is tempting to try out Flightcontrol, BTW what is the service limit for free plan? I could not find it.
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
There is no service limit on the free plan. It’s limited to a single user instead.
i remember deis, it was amazing self-hosted heroku. too bad they were bought by microsoft.
and then there's also flynn.
> Flightcontrol gives our team the power to manage bare metal AWS ...
"bare metal"? Hmmm. I think we have different definitions of that phrase.
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.
We've changed the title now to what the page says. (Submitted title was "Flightcontrol: AWS PaaS")
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
I had the exact same reaction, and then when reading some of the copy thought to myself: "omg, can't believe they are being so degrading to how clunky their own dashboards and things are!" And then it hit me...
Ditto
All we need need now is "PaaS as Code" (PaC) services as the next iteration of DevOps stacks that increasingly border parody.
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.
Why web developer culture is so annoying when it comes to naming things? Serverless? It is actually a server. Flight control? Nothing to do with airports or flights or whatsoever.
Creating new words from existing words or concepts is how language works. In fact, "airport" is an example of this... ports were originally for boats.
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.
"Deploying" a new feature into "staging" also doesn't have to do anything with a battle. Naming is hard and most project names just pick a fun name.
Your point about "serverless" I can understand, but "Flight control" seems like a great name for a product like that.